Как стать автором
Обновить

ФСТЭК: требования к файрволам

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

Что же должны уметь межсетевые экраны по мнению ФСТЭК?

Согласно Информационному сообщению «Об утверждении методических документов, содержащих профили защиты межсетевых экранов» от 12 сентября 2016 г. N 240/24/4278 разработаны Профили защиты типов:

  • межсетевой экран уровня сети (тип «А») – межсетевой экран, применяемый на физической границе (периметре) информационной системы или между физическими границами сегментов информационной системы. Межсетевые экраны типа «А» могут иметь только программно-техническое исполнение;

  • межсетевой экран уровня логических границ сети (тип «Б») – межсетевой экран, применяемый на логической границе (периметре) информационной системы или между логическими границами сегментов информационной системы. Межсетевые экраны типа «Б» могут иметь программное или программно-техническое исполнение;

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

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

  • межсетевой экран уровня промышленной сети (тип «Д») – межсетевой экран, применяемый в автоматизированной системе управления технологическими или производственными процессами. Межсетевые экраны типа «Д» могут иметь программное или программно-техническое исполнение и должны обеспечивать контроль и фильтрацию промышленных протоколов передачи данных (Modbus, Profibus, CAN, HART, Industrial Ethernet и (или) иные протоколы).

Для типов А, Б и В имеются требования к межсетевым экранам от первого до шестого класса защиты, для типов Г и Д — только от шестого до четвертого

Прежде всего об уровнях защищенности. Согласно Информационному сообщению «Об утверждении Требований к межсетевым экранам» от 28 апреля 2016 г. No 240/24/1986.
Межсетевые экраны, соответствующие 6 классу защиты, применяются в государственных информационных системах 3 и 4 классов защищенности*, в автоматизированных системах управления производственными и технологическими процессами 3 класса защищенности**, в информационных системах персональных данных при необходимости обеспечения 3 и 4 уровней защищенности персональных данных***.

Межсетевые экраны, соответствующие 5 классу защиты, применяются в государственных информационных системах 2 класса защищенности*, в автоматизированных системах управления производственными и технологическими процессами 2 класса защищенности***, в информационных системах персональных данных при необходимости обеспечения 2 уровня защищенности персональных данных**

Межсетевые экраны, соответствующие 4 классу защиты, применяются в государственных информационных системах 1 класса защищенности*, в авто матизированных системах управления производственными и технологическими процессами 1 класса защищенности**, в информационных системах персональных данных при необходимости обеспечения 1 уровня защищенности персональных данных***, в информационных системах общего пользования II класса****.

Межсетевые экраны, соответствующие 3, 2 и 1 классам защиты, применяются в информационных системах, в которых обрабатывается информация, содержащая сведения, составляющие государственную тайну.

* Устанавливается в соответствии с Требованиями о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденными приказом ФСТЭК России от 11 февраля 2013 г. No17.

** Устанавливается в соответствии с Требованиями к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды, утвержденными приказом ФСТЭК России от 14 марта 2014 г. No 31.

*** Устанавливается в соответствии Требованиями к защите персональных данных при их обработке в информационных системах персональных данных, утвержденными постановлением Правительства Российской Федерации от 1 ноября 2012г., No 1119.

**** Устанавливается в соответствии с Требованиями о защите информации, содержащейся в информационных системах общего пользования, утвержденными приказом ФСБ России и ФСТЭК России от 31августа 2010 г. No 416/489.

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

Что есть межсетевой экран согласно Профилю?
программное средство, реализующее функции контроля и фильтрации в соответствии с заданными правилами проходящих через него информационных потоков.

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

  • несанкционированный доступ к информации, содержащейся в информационной системе в связи с наличием неконтролируемых сетевых подключений к информационной системе;

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

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

  • несанкционированное воздействие на МЭ, целью которого является нарушение его функционирования, включая преодоление или обход его функций безопасности в связи с отправкой специально сформированных сетевых пакетов на интерфейсы МЭ.

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

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

Раскроем эти требования более подробно:

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

    Интересно, что в разделе FW_ARP_EXT.2 уточняется, что МЭ должен иметь возможность по блокированию неразрешенного информационного потока по протоколу передачи гипертекста — о иных протоколах нет указаний. Должен ли МЭ блокировать передачу информации по ним? Кстати вполне возможно, что данный пункт попал в документ из Профиля типа Г — там достаточно много внимания уделяется именно этому протоколу;

  • МЭ должен осуществлять фильтрацию по следующим признакам: сетевой адрес узла отправителя, сетевой адрес узла получателя, сетевой протокол, транспортный протокол, порты источника и получателя в рамках сеанса (сессии), разрешенные (запрещенные) команды, разрешенный (запрещенный) мобильный код, разрешенные (запрещенные) протоколы прикладного уровня. МЭ также должен иметь возможность «осуществлять политику фильтрации пакетов с учетом управляющих команд от взаимодействующих с МЭ средств защиты информации других видов». Также МЭ должен иметь возможность определять ПО, осуществляющее соединения и назначать для него разрешительные и (или) запретительные атрибуты безопасности с целью последующего осуществления фильтрации;

  • МЭ должен иметь «возможность осуществлять проверку каждого пакета по таблице состояний для определения того, не противоречит ли состояние (статус, тип) пакета ожидаемому состоянию»;

  • МЭ должен иметь «возможность осуществлять проверку использования сетевых ресурсов, содержащих мобильный код, для которого администратором МЭ установлены разрешительные или запретительные атрибуты безопасности». Означает ли это, что МЭ должен иметь возможность удаленной проверки сетевых ресурсов ", содержащих отдельные типы мобильного кода "? Странное требование, применимое больше к антивирусам. Скорее всего это должна выть отдельная операция, производимая по запросу. По результатам проверки МЭ должен иметь возможность разрешать и запрещать доступ к таким ресурсам;

  • МЭ должен иметь «возможность разрешать/запрещать информационный поток, основываясь на результатах проверок». Не уточняется, на основании каких проверок должен запрещаться или разрешаться информационный поток. Логично было бы, если бы запреты или разрешения были на уровне предопределенных правил;

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

  • МЭ должен поддерживать роли администраторов и возможность идентификации и аутентификации администратора для выполнения разрешенных данному администратору действий;

  • МЭ должен иметь возможность создания и назначения различных профилей (настроек);

  • МЭ должен иметь возможность ведения таблицы состояний каждого соединения с указанием его статуса;

  • МЭ должен иметь «возможность обеспечения перехода в режим аварийной поддержки, который предоставляет возможность возврата МЭ к штатному режиму функционирования» и «возможность тестирования (самотестирования) функций безопасности МЭ (контроль целостности исполняемого кода МЭ)»;

  • МЭ должен иметь «возможность осуществлять выдачу предупреждающих сообщений пользователю МЭ», позволяющих возможность «осуществить блокирование доступа к средству вычислительной техники».

В общем все. Требования к функционалу заканчиваются на странице 28 и до конца документа (размером в 78 страниц) идут повтор ранее написанного и требования к процедурам по выпуску, документированию и поддержке ПО.

В профиле указывается, что функциональные требования безопасности для МЭ составлены на основе требований ГОСТ Р ИСО/МЭК 15408-2-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности» и достаточно сильно напоминают требования Профилей антивирусной защиты.

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

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

  • антивирусная защита и защита от спама должны применяться на средствах межсетевого экранирования (требования АВЗ.1 и ОЦЛ.4);

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

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

Указывается, что средства защиты от вторжений должны иметь возможность анализа трафика, обновления правил и централизованного управления. Правила должны иметь возможность редактирования.

Итого, что мы имеем? На первый взгляд базовая функциональность персонального файрвола описана. Но:

  • Несмотря на то, что данный тип МЭ должен применяться в составе информационной системы — требований по централизованному управлению нет. Требуется только обеспечить доверенный канал управления в составе среды функционирования. Напомним, что в профилях антивирусных решений есть отдельные профили для централизованно управляемых решений и для отдельно стоящих;

  • Несмотря на требование по фильтрации соединений от конкретных приложений — нет требований по наличию баз профилей приложений. Без таких баз правил администратору придется настраивать каждое новое соединение. Не есть хорошо и удобно;

  • Нет требований по режимам работы — все запрещено/разрешено/режим обучения. Предполагается настраивать каждое соединение по одному?;

  • Нет списка контролируемых протоколов. Упоминается только один — HTTP. Скажем как контролировать соединения по разрешенным протоколам (типа DNS), нужно ли фильтровать соединения, инкапсулирующиеся в разрешенные протоколы — вопросов много;


    источник картинки

  • Нет требований по функционалу защиты от сетевых атак. Естественно ожидать внутри сети DDoS не стоит, но уведомления от скажем перебора портов вещь не слишком ненужная. По сути сейчас большинство персональных файрволов имеют такой функционал. Вопрос не праздный. За любую сертификацию берут деньги — и достаточно большие. Но об этом чуть ниже;

  • Несмотря на требование наличия процедур обновления — в функционале нет требований по наличию функций обновлений. Не будем говорить об уязвимостях, но те же вредоносные программы не стоят на месте и список используемых ими протоколов изменяется;

  • Совершенно непонятное требование по взаимодействию с иными средствами защиты. Единого протокола для средств защиты нет — хотя производители тех же SIEM от него не отказались бы. Возможно это требование под конкретный продукт? Возможно это требование под МЭ с антивирусным плагином. Но такие продукты не составляют большинство на рынке. Как правило дело обстоит наоборот — для защиты станций ставятся антивирусы с модулем файрвола;

  • Сообщения должны отправляться пользователям. Зачем они им в корпоративной сети? Обычно такие уведомления идут администраторам, а для пользователей скрываются. Нет требований по типам уведомлений администраторам — или они должны по мнению ФСТЭК круглосуточно сидеть за мониторами рабочих станций, ожидая уведомлений?

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

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

  • закладывать в бюджет средства и на сертифицированный антивирус и на сертифицированный МЭ;
  • продлить ранее купленный сертифицированный антивирус на много лет вперед, так как ранее закупленные МЭ могут продолжать использоваться;
  • надеяться, что ФСТЭК одумается.

Пячаль в любых вариантах.

До 1 декабря осталось немного, интересно, кто успеет провести сертификацию
Теги:
Хабы:
Всего голосов 27: ↑24 и ↓3+21
Комментарии57

Публикации

Истории

Работа

Ближайшие события

19 августа – 20 октября
RuCode.Финал. Чемпионат по алгоритмическому программированию и ИИ
МоскваНижний НовгородЕкатеринбургСтавропольНовосибрискКалининградПермьВладивостокЧитаКраснорскТомскИжевскПетрозаводскКазаньКурскТюменьВолгоградУфаМурманскБишкекСочиУльяновскСаратовИркутскДолгопрудныйОнлайн
3 – 18 октября
Kokoc Hackathon 2024
Онлайн
24 – 25 октября
One Day Offer для AQA Engineer и Developers
Онлайн
25 октября
Конференция по росту продуктов EGC’24
МоскваОнлайн
7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань