В прошлый раз мы рассмотрели требования ФСТЭК РФ к персональным файрволам — межсетевым экранам уровня узла (тип «В»), устанавливаемым на рабочих станциях защищаемой сети. Продолжим разговор и рассмотрим требования к решениям для защиты веб-серверов

Напомним, что межсетевой экран уровня веб-сервера (тип «Г») может применяться на сервере, обслуживающем сайты, веб-службы и веб-приложения, или на физической границе сегмента таких серверов сервера). Межсетевые экраны типа «Г» могут иметь программное или программно-техническое исполнение и должны обеспечивать контроль и фильтрацию информационных потоков по протоколу передачи гипертекста, проходящих к веб-серверу и от веб-сервера.

Уже тут возникает вопрос. Судя по всему данный МЭ рассматривается как МЭ для конкретного приложения (типа Web application firewall) и в сети должен быть основной МЭ. Предполагается, что этот основной МЭ не умеет разбирать HTTP. Но для работы и веб-сервера нужны и иные протоколы. Как минимум в связи с необходимостью загрузки файлов есть FTP/SFTP/SCP(SSH), на многих серверах есть функции рассылки почты и иной функционал. Предполагается, что основной МЭ не умеет разбирать HTTP, но умеет разбирать иные протоколы? Но для типа А прописано только знание типа протокола:

возможность осуществлять фильтрацию, основанную на следующих типах атрибутов безопасности информации: сетевой протокол, который используется для взаимодействия; атрибуты, указывающие на фрагментацию пакетов; транспортный протокол, который используется для взаимодействия, порты источника и получателя в рамках сеанса (сессии); разрешенные (запрещенные) команды, разрешенный (запрещенный) мобильный код…

Требования к межсетевым экранам типа Г выложены здесь. Поскольку для типа Г, как уже говорилось, класс 4 максимальный, то рассмотрим именно его.

МЭ должен обеспечивать нейтрализацию следующих угроз безопасности информации:

• несанкционированный доступ к информации веб-сервера в результате установления сетевых соединений веб-сервером, не предусмотренных технологией обработки информации;
  
  
• отказ в обслуживании сервера, обслуживающего сайты, веб-службы и веб-приложения в результате установления не предусмотренных технологией обработки информации в информационной системе сетевых соединений с веб-сервером для отправки множества сетевых пакетов (запросов) до заполнения ими сетевой полосы пропускания канала передачи данных или отправки специально сформированных аномальных сетевых пакетов (запросов) больших размеров или нестандартной структуры. Угроза возможна в связи с наличием уязвимостей сетевых протоколов, недостатков настройки механизмов защиты, уязвимостей в программном обеспечении программно-аппаратных средств ИС;
  
  
• несанкционированное воздействие на МЭ, целью которого является нарушение его функционирования, включая преодоление или обход его функций безопасности путем отправки специально сформированных сетевых пакетов на интерфейсы МЭ, приводящих к отключению, обходу или преодолению механизмов защиты МЭ с использованием штатных средств или специализированных инструментальных средств.

Правда в определении МЭ эго задача сужена — согласно Профилю МЭ «представляет собой программное или программно-техническое средство, реализующее функции контроля и фильтрации в соответствии с заданными правилами проходящих через него информационных потоков, и используемое в целях обеспечения защиты (некриптографическими методами) информации ограниченного доступа». Но для типа А прописано только знание о типе протокола:

возможность осуществлять фильтрацию, основанную на следующих типах атрибутов безопасности информации: сетевой протокол, который используется для взаимодействия;
атрибуты, указывающие на фрагментацию пакетов; транспортный протокол, который используется для взаимодействия, порты источника и получателя в рамках сеанса (сессии); разрешенные (запрещенные) команды, разрешенный (запрещенный) мобильный код…

В МЭ должны быть реализованы следующие функции безопасности:

• контроль и фильтрация;
• идентификация и аутентификация;
• регистрация событий безопасности (аудит);
• обеспечение бесперебойного функционирования и восстановление;
• тестирование и контроль целостности;
• управление (администрирование);
• взаимодействие с другими средствами защиты информации.

В числе прочего МЭ должен функционировать в среде, обеспечивающей безопасное функционирование МЭ.

МЭ типа Г четвертого класса должен обеспечивать:

• возможность осуществлять фильтрацию сетевого трафика для отправителей информации, получателей информации и всех операций передачи контролируемой МЭ информации к веб-серверу и от веб-сервера. возможность обеспечить, чтобы в межсетевом экране фильтрация распространялась на все операции перемещения через МЭ информации к веб-серверу и от веб-сервера. Интересный пункт. Судя по определению требования касаются МЭ, предназначенного для защиты конкретно веб-сервера и дополнительного к основному МЭ. Если так, а по определению «межсетевые экраны типа «Г» должны обеспечивать контроль и фильтрацию информационных потоков по протоколу передачи гипертекста» — то зачем это и иные истекающие из этого положения в Профиле? Не логично слить эти пункты или отредактировать назначение МЭ?;
  
  
• возможность поддержки контроля и анализа запросов и ответов по протоколу передачи гипертекста определенных версий. Логично в случае если мы рассматриваем данный МЭ как дополнительное средство защиты Web приложений при наличии основного МЭ, фильтрующего вплоть до уровня пакетов;
  
  
• возможность поддержки контроля и анализа сообщений, отправляемых веб-браузером веб-серверу и содержащих текстовый контент определенных кодировок и нетекстовый контент определенных типов (изображения, аудиоинформация, видеоинформация, программы). Не совсем понятно, должны ли здесь включаться действия по модификации сообщений, включая удаление неразрешенного контента. Не определен и уровень анализа;
  
  
• возможность поддержки контроля и анализа специальных маркеров взаимодействия (куки) определенных типов, отправляемых веб-сервером веб-браузеру и возвращаемых веб-браузером веб-серверу, содержащих персонифицированную информацию сеанса взаимодействия пользователя с веб-сервером, основываясь на определенных атрибутах куки — не ясно, на что должны анализироваться куки?;
  
  
• возможность поддержки отправления и получения данных пользователя информационной системы (в том числе куки – фрагменты информации, содержащие данные пользователя) способом, защищенным от несанкционированного раскрытия/от нарушения целостности;
  
  
• возможность явно разрешать или запрещать информационный поток, базируясь на устанавливаемом администратором МЭ наборе правил фильтрации, основанных на идентифицированных атрибутах, блокировать все информационные потоки, в том числе по атрибутам, установленным взаимодействующими средствами защиты информации для контролируемого сетевого трафика и указывающим на отсутствие или присутствие нарушений безопасности информации;
  
  
• возможность осуществлять проверку наличия фрагментов мобильного кода в запросах, в том числе фрагментированных и подвергшихся сжатию, к сайту и (или) иному веб-приложению на ввод данных путем поиска в таких запросах определенных фрагментов регулярных выражений (тегов, команд в формате языков мобильного кода), используемых при инициализации мобильного кода или выполнения нежелательных действий. Возможность блокирования информационных потоков с такими запросами;
  
  
• возможность осуществлять фильтрацию пакетов с учетом управляющих команд от взаимодействующих с МЭ средств защиты информации других видов, основанную на атрибутах, указывающих на признаки нарушения безопасности в информации сетевого трафика — очень интересное требование, имеющееся и иных типах профилей. ФСТЭК предполагает стандартизировать некий протокол взаимодействия средств защиты?;
• возможность в случае обнаружения неразрешенного информационного потока по протоколу передачи гипертекста — блокирования запроса, разрыва/перезапуска соединения, блокирование взаимодействия с конкретным сетевым адресом, блокирование сессии на уровне конкретного приложения, блокирование взаимодействия на уровне конкретного пользователя приложения, отправки управляющего сигнала на иной МЭ для блокирования неразрешенного информационного потока, отправки уведомления администратору/пользователю о выполненном действии;
  
  
• возможность поддержки виртуализации внешнего представления приложений веб-сервера на уровне трансляции сетевых портов, трансляции унифицированных идентификаторов ресурсов;
  
  
• возможность определения виртуализированных (видимых для веб-браузера) сетевых портов приложений и их сопоставления с реальными (видимыми для веб-сервера) сетевыми портами приложений;
  
  
• возможность определения виртуализированных (видимых для веб-браузера) и идентификаторов ресурсов и их сопоставления с реальными (видимыми для веб-сервера) унифицированными идентификаторами ресурсов;
  
  
• возможность обеспечения перехода в режим аварийной поддержки, который предоставляет возможность возврата МЭ к штатному режиму функционирования, возможность завершения работы или восстановления (для предусмотренных сценариев сбоев) штатного режима функционирования МЭ. Возможно требование означает назначение определенной политики в случае каких-то ситуаций;
  
  
• возможность поддержки доверенного канала взаимодействия между МЭ и веб-сервером/ пользователем (использующим веб-браузер), чтобы иметь возможность получения доступа к исходным данным, передаваемым по протоколу передачи гипертекста с применением криптографических методов защиты информации в соответствии с законодательством РФ, для анализа и обеспечения их дальнейшей защищенной передачи с применением криптографических методов защиты информации в соответствии с законодательством РФ;
  
  
• возможность регистрации и учета выполнения проверок информации сетевого трафика, событий, которые в соответствии с национальным стандартом Российской Федерации ГОСТ Р ИСО/МЭК 15408-2-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности» включены в базовый уровень аудита. Возможность чтения записей аудита или их выборки (поиск, сортировка, упорядочение данных аудита) уполномоченным администраторам;
  
  
• поддержка определенных ролей по управлению МЭ, Возможность идентификации и аутентификации администратор а МЭ до разрешения любого действия (по администрированию), выполняемого при посредничестве МЭ от имени этого администратора;
  
  
• возможность осуществления идентификации и аутентификации пользователя до разрешения передачи через МЭ информационного потока, ассоциированного с этим пользователем, к веб-серверу (от веб-сервера);
  
  
• возможность со стороны администраторов МЭ управлять режимом выполнения функций безопасности МЭ, управлять атрибутами безопасности, управлять данными МЭ, используемыми функциями безопасности МЭ.

В общем все. Список требований составляет менее четверти документа.

Интересно сравнить разнице требований между четвертым и шестым классами:

• сигналы о нарушении безопасности появляются в 5м классе. Продукт без уведомлений о нарушениях смотрится странно;
• выборочный просмотр данных аудита также появляется в пятом классе. Пользователям такого продукта предлагается искать нужное в тоннах записей вручную?
• в пятом классе появляется требование о виртуализации;
• базовая конфиденциальность обмена данными (FDP_UCT.1) должна быть только в 4м классе, как и возможность взаимодействовать с иными системами защиты (базовая согласованность данных функциональных возможностей безопасности между функциональными возможностями безопасности — FPT_TDC.1) и требования о наличии доверенных каналов и маршрута передачи (FPT_ITC.1 и FPT_TRP.1) — каналов связи с веб-сервером и удаленным пользователем соответственно. FDP_UCT.1 включает в себя требование о возможности блокирования неразрешенного информационного потока по протоколу передачи гипертекста одним или несколькими способами. Это не нужно для 5го и 6го классов? Просьбы пользователей о проверке данных передаваемых на веб-сервер и с него встречаются постоянно, как и требование о наличии защищенных о перехвата злоумышленниками каналов передачи данных. Странно, что эти требования отсутствуют для 5го и 6го классов;

Интересно, список того, что должно быть реализовано в составе функций безопасности не совпадает с описанными требованиями. Так в первом списке присутствует тестирование функций безопасности — и далее по документу применительно к продукту это требование отсутствует (это кстати о вреде тотального засекречивания. В ДСП версии четко видно, что и где из функционала должно быть). Есть и иные аналогичные расхождения.

Также требования к МЭ присутствуют в Методическом документе ФСТЭК «Меры защиты информации в государственных информационных системах». Напомним, что согласно этому документу в МЭ должны применяться антивирусная защита, защита от спама и систему обнаружения (предотвращения) вторжений. МЭ должен поддерживать кластеризацию. В свою очередь средства защиты от вторжений должны иметь возможность анализа трафика, обновления правил и централизованного управления. Правила должны иметь возможность редактирования.

Подведем итоги:

1. Документ очень высокоуровневый. Описания возможных типов и вариантов фильтраций нет. Фактически единственное указание — требование о наличии системы контроля и анализа запросов и ответов по протоколу HTTP определенных версий, а также требование о проверке на наличие мобильного кода в запросах. Отсутствие четких требований дает как возможность подачи на сертификацию продуктов лишь формально удовлетворяющих требованиям, так и отказа в сертификации по чисто формальным причинам;
2. Требуется доверенный канал для анализа HTTPS, использующего разрешенное в России шифрования;
3. Нет списка контролируемых протоколов. Упоминается только один — HTTP;
4. Несмотря на то, что данный тип МЭ должен применяться в составе информационной системы — требований по централизованному управлению нет. Требуется только обеспечить доверенный канал управления в составе среды функционирования;
5. Нет требований по функционалу защиты от сетевых атак;
6. Несмотря на требование наличия процедур обновления — в функционале нет требований по наличию функций обновлений;
7. Совершенно непонятное требование по взаимодействию с иными средствами защиты. Единого протокола для средств защиты нет — хотя производители тех же SIEM от него не отказались бы. Возможно это требование под конкретный продукт?

По требованиям ФСТЭК с 1 декабря 2016 г. разрабатываемые, производимые и поставляемые межсетевые экраны должны соответствовать описанным в Профилях требованиям. Межсетевые экраны, установленные до 1 декабря 2016 г., могут эксплуатироваться без проведения повторной сертификации на соответствие требованиям.

Благодарю всех пользователей (особенно imbasoft), высказавших ценные замечания по предыдущей статье