В последний раз Мы рассмотрели требования ФСТ РФ к персональным межсетевым экранам – межсетевым экранам узлового уровня (тип «Б»), устанавливаемым на рабочих станциях защищаемой сети.
Продолжим разговор и рассмотрим требования к решениям по защите веб-серверов.
Напомним, что межсетевой экран уровня веб-сервера (тип «G») может использоваться на серверах, обслуживающих сайты, веб-сервисы и веб-приложения, или на физической границе сегмента таких серверов-серверов).
Межсетевые экраны типа «Г» могут быть программными или программно-аппаратными и должны обеспечивать контроль и фильтрацию информационных потоков по протоколу передачи гипертекста, проходящих на веб-сервер и с него.
Уже здесь возникает вопрос.
Видимо это М? рассматривается как М? для конкретного приложения (например, брандмауэра веб-приложения) и в сети должен быть основной M?.
Предполагается, что это основной M? Не могу разобрать HTTP. Но для работы веб-сервера нужны и другие протоколы.
Как минимум в связи с необходимостью закачки файлов есть FTP/SFTP/SCP(SSH); многие серверы имеют функции рассылки почты и другие функциональные возможности.
Предполагается, что основной M? не может анализировать HTTP, но может анализировать другие протоколы? А вот для типа А предписывается только знание типа протокола:
возможность фильтрации по следующим типам атрибутов информационной безопасности: сетевой протокол, используемый для взаимодействия; атрибуты, указывающие фрагментацию пакетов; транспортный протокол, который используется для взаимодействия, портов источника и назначения внутри сеанса (сеанса); разрешенные (запрещенные) команды, разрешенный (запрещенный) мобильный код.Изложены требования к межсетевым экранам типа G. Здесь .
Поскольку для типа G, как уже было сказано, класс 4 является максимальным, будем рассматривать именно его.
М? должен обеспечить нейтрализацию следующих угроз информационной безопасности:
- несанкционированный доступ к информации веб-сервера в результате установления веб-сервером сетевых соединений, не предусмотренных технологией обработки информации;
- отказ в обслуживании сервера, обслуживающего веб-сайты, веб-сервисы и веб-приложения, в результате установления сетевых соединений с веб-сервером, не предусмотренных технологией обработки информации в информационной системе для отправки множества сетевых пакетов (запросов) до их заполнения пропускная способность сети канала передачи данных или отправка специально сформированных аномальных сетевых пакетов (запросов) больших размеров или нестандартной структуры.
Угроза возможна из-за наличия уязвимостей в сетевых протоколах, недостатков в настройке механизмов безопасности, уязвимостей в программном и аппаратном обеспечении ИП;
- несанкционированное воздействие на M?, целью которого является нарушение его функционирования, в том числе преодоление или обход его функций безопасности путем отправки на M? специально сформированных сетевых пакетов.
интерфейсов, что приводит к отключению, обходу или преодолению механизмов защиты M? используя стандартные инструменты или специализированные инструменты.
А вот для типа А прописаны только знания о типе протокола:
возможность фильтрации по следующим типам атрибутов информационной безопасности: сетевой протокол, используемый для взаимодействия; атрибуты, указывающие на фрагментацию пакетов; транспортный протокол, используемый для взаимодействия, портов источника и назначения внутри сеанса (сеанса); разрешенные (запрещенные) команды, разрешенный (запрещенный) мобильный код.В М? Должны быть реализованы следующие функции безопасности:
- контроль и фильтрация;
- идентификация и аутентификация;
- регистрация событий безопасности (аудит);
- обеспечение бесперебойности работы и восстановления;
- тестирование и мониторинг целостности;
- менеджмент (администрация);
- взаимодействие с другими средствами информационной безопасности.
М? тип Г четвертого класса должен обеспечивать:
- возможность фильтрации сетевого трафика для отправителей информации, получателей информации и всех операций передачи, контролируемых M? информация на веб-сервер и обратно.
возможность обеспечить фильтрацию межсетевым экраном всех движений через M? информация на веб-сервер и обратно.
Интересный момент. Судя по определению, требования относятся к М?, предназначенному для защиты именно веб-сервера и дополнительному к основному М?.
Если это так, и по определению «брандмауэры типа G должны обеспечивать контроль и фильтрацию информационных потоков с использованием протокола передачи гипертекста» — то почему из этого вытекает это и другие положения Профиля? Нелогично объединять эти элементы или редактировать назначение M??;
- возможность поддержки мониторинга и анализа запросов и ответов через протокол передачи гипертекста определенных версий.
Логично ли считать это М? как дополнительное средство защиты веб-приложений при наличии основного М?, фильтрация вплоть до уровня пакетов;
- возможность поддержки контроля и анализа сообщений, отправляемых веб-браузером на веб-сервер и содержащих текстовый контент определенных кодировок и нетекстовый контент определенных типов (изображения, аудиоинформацию, видеоинформацию, программы).
Не совсем понятно, следует ли сюда включать действия по изменению сообщений, в том числе по удалению несанкционированного контента.
Уровень анализа также не определен;
- возможность поддержки контроля и анализа специальных маркеров взаимодействия (cookie) определенных типов, отправляемых веб-сервером веб-браузеру и возвращаемых веб-браузером веб-серверу, содержащих персонализированную информацию о сеансе взаимодействия пользователя с веб-сервером, на основе определенных атрибутов файлов cookie – неясно, для чего следует анализировать файлы cookie?;
- возможность поддерживать отправку и получение пользовательских данных информационной системы (в том числе файлов cookie – фрагментов информации, содержащих данные пользователя) способом, защищенным от несанкционированного раскрытия/нарушения целостности;
- способность явно разрешать или запрещать поток информации на основе M? настроено администратором? набор правил фильтрации на основе выявленных атрибутов блокирует все информационные потоки, в том числе на основе атрибутов, установленных взаимодействующими средствами защиты информации для контролируемого сетевого трафика и указывающих на отсутствие или наличие нарушений информационной безопасности;
- возможность проверки наличия фрагментов мобильного кода в запросах, в том числе фрагментированных и сжатых, к веб-сайту и (или) иному веб-приложению для ввода данных путем поиска в таких запросах определенных фрагментов регулярных выражений (тегов, команд в формат языков мобильного кода), используемый при инициализации мобильного кода или выполнении нежелательных действий.
Возможность блокировки информационных потоков с такими запросами;
- возможность фильтрации пакетов с учетом команд управления от взаимодействующих с М? другие типы средств защиты информации на основе атрибутов, указывающих на признаки нарушения безопасности в информации о сетевом трафике – очень интересное требование, которое существует и в других типах профилей.
ФНСЭК намерена стандартизировать некий протокол взаимодействия средств защиты?;
- возможность в случае обнаружения несанкционированного потока информации по протоколу передачи гипертекста - блокировка запроса, разрыв/перезапуск соединения, блокировка взаимодействия с конкретным сетевым адресом, блокировка сеанса на уровне конкретного приложения, блокировка взаимодействия на уровне конкретного пользователя приложения, отправляющего управляющий сигнал другому M? для блокировки несанкционированного информационного потока отправить уведомление администратору/пользователю о выполненном действии;
- возможность поддержки виртуализации внешнего представления приложений веб-сервера на уровне трансляции сетевых портов, трансляции единых идентификаторов ресурсов;
- возможность определять виртуализированные (видимые веб-браузером) сетевые порты приложений и сравнивать их с реальными (видимыми веб-сервером) сетевыми портами приложений;
- возможность определять виртуализированные (видимые веб-браузером) и идентификаторы ресурсов и сопоставлять их с реальными (видимыми веб-сервером) унифицированными идентификаторами ресурсов;
- возможность обеспечить переход в режим экстренной поддержки, что обеспечивает возможность возврата М? в нормальный режим работы, возможность отключения или восстановления (для предусмотренных сценариев отказа) нормального режима работы М?.
Возможно, требование означает назначение определенной политики на случай определенных ситуаций;
- возможность поддержки доверенного канала взаимодействия между М? и веб-сервер/пользователь (с помощью веб-браузера) для возможности получения доступа к исходным данным, передаваемым по протоколу передачи гипертекста, с использованием криптографических методов защиты информации в соответствии с законодательством Российской Федерации, для анализа и обеспечения их дальнейшая безопасная передача с использованием криптографических методов защиты информации в соответствии с законодательством Российской Федерации;
- возможность регистрации и фиксации выполнения проверок информации о сетевом трафике, событиях, соответствующих национальному стандарту РФ ГОСТ Р ИСО/МЭК 15408-2-2013 «Информационные технологии.
Методы и средства обеспечения безопасности.
Критерии оценки безопасности информационных технологий.
Часть 2: Функциональные компоненты безопасности» включены в базовый уровень аудита.
Возможность чтения записей аудита или их выбора (поиск, сортировка, систематизация данных аудита) для авторизованных администраторов;
- поддержка определенных ролей для управления M?, возможность идентификации и аутентификации администратора и M? прежде чем разрешить какое-либо действие (управление), совершаемое при посредничестве М? от имени этого администратора;
- возможность идентифицировать и аутентифицировать пользователя перед разрешением передачи через M? поток информации, связанный с этим пользователем, на веб-сервер (с веб-сервера);
- возможность от администраторов М? управлять режимом выполнения M? функции безопасности, управлять атрибутами безопасности, управлять M? данные, используемые M? функции безопасности.
Перечень требований составляет менее четверти документа.
Интересно сравнить разницу в требованиях между четвертым и шестым классами:
- Предупреждения безопасности появляются в 5-м классе.
Товар без уведомлений о нарушениях выглядит странно;
- Выборочный анализ данных аудита также появляется в пятом классе.
Пользователям такого продукта предлагается вручную искать то, что им нужно, в тоннах записей?
- в пятом классе есть потребность в виртуализации;
- базовая конфиденциальность обмена данными (FDP_UCT.1) должна быть только в классе 4, а также возможность взаимодействия с другими системами безопасности (базовая согласованность данных защитных функций между защитными функциональными возможностями - FPT_TDC.1) и требования к наличию доверенных каналы и маршрут передачи ( FPT_ITC.1 и FPT_TRP.1) — каналы связи с веб-сервером и удаленным пользователем соответственно.
FDP_UCT.1 включает требование иметь возможность блокировать несанкционированный поток информации протокола передачи гипертекста одним или несколькими способами.
Разве это не обязательно для 5 и 6 классов? Постоянно встречаются запросы пользователей на проверку данных, передаваемых на веб-сервер и с него, а также требование к каналам передачи данных, защищенным от перехвата злоумышленниками.
Странно, что этих требований нет для 5 и 6 классов;
Так в первом списке идет тестирование функций безопасности - и далее в документе это требование отсутствует применительно к продукту (кстати, речь идет о вреде тотальной секретности.
В версии DSP хорошо видно, что и где должен быть функционал).
Есть и другие подобные расхождения.
Также требования к M? присутствуют в Методическом документе ФНСЭК «Меры защиты информации в государственных информационных системах».
Напомним, что согласно этому документу в М? Необходимо использовать антивирусную защиту, защиту от спама и систему обнаружения (предотвращения) вторжений.
М? должен поддерживать кластеризацию.
В свою очередь, инструменты защиты от вторжений должны иметь возможность анализировать трафик, обновлять правила и централизовать управление.
Правила должны быть редактируемыми.
Подведем итоги:
- Документ очень высокого уровня.
Описания возможных типов и вариантов фильтрации нет. Фактически единственным указанием является требование наличия системы мониторинга и анализа запросов и ответов по протоколу HTTP определенных версий, а также требование проверки наличия мобильного кода в запросах.
Отсутствие четких требований позволяет представить на сертификацию продукцию, лишь формально соответствующую требованиям, либо отказаться от сертификации по чисто формальным причинам;
- Требуется доверенный канал для анализа HTTPS с использованием разрешенного в России шифрования;
- Перечня контролируемых протоколов нет. Упоминается только один — HTTP;
- Несмотря на то, что это тип М? должен использоваться как часть информационной системы – требований к централизованному управлению нет. Требуется лишь обеспечить доверенный канал управления как часть операционной среды;
- Нет требований к функционалу защиты от сетевых атак;
- Несмотря на необходимость процедур обновления, функциональных требований к функциям обновления нет;
- Совершенно непонятное требование по взаимодействию с другими средствами защиты.
Единого протокола для средств безопасности не существует — хотя производители того же SIEM от него не отказались бы.
Возможно, это требование к конкретному товару?
Межсетевые экраны, установленные до 1 декабря 2016 года, могут эксплуатироваться без ресертификации на соответствие.
Благодарю всех пользователей (особенно имбасофт ), который сделал ценные комментарии к предыдущей статье Теги: #информационная безопасность #законодательство и ИТ #фстэк #информационная безопасность
-
Немного О Работе С Контейнерами
19 Oct, 24
