Новый РД ФСТЭК по IPS

6 декабря 2011 года директор ФСТЭК подписал приказ №638 «Об утверждении требований к системам обнаружения вторжений» (зарегистрирован в Минюсте 1.02.2012), который вступает в силу с 15 марта этого года для вновь разработанных систем. Требования предназначены для разработчиков средств защиты, заявителей на сертификацию, а также испытательных лабораторий и органов по сертификации. Требования включают общие требования к СОВ и требования к функциям безопасности СОВ. Кстати я так и не нашел в документе эти самый общие требования к СОВ ;-(

Выполнение данных требований является обязательным при проведении работ по оценке соответствия СЗИ для государственных информационных ресурсов. Формулировка похожа на текст 330-го постановления Правительства за исключением упоминания персданных. Из этой формулировки можно сделать вывод, что для всех остальных ресурсов эти требования являются необязательными. Хотя по тексту ниже этот вывод уже ставится под сомнение.

Документ учитывает, что СОВ бывают активными (IPS) и пассивным (IDS). Вообще в документе дана неплохая классификация СОВ – по уровню обнаружения (HIPS/NIPS), используемым методам обнаружения (сигнатуры, поведение, профили и т.д.), месту расположения и т.д.

Для дифференциации требований к СОВ к функциям безопасности СОВ выделяют 6 классов защиты (шестой- самый низкий):

• 6 класс – применение в ИСПДн 3-го и 4-го классов
• 5 класс – применение в ИСПДн 2-го класса
• 4 класс – применение в ИСПДн 1-го класса, а также в ИС общего пользования II класса (согласно совместного приказа ФСБ и ФСТЭК 416/489) и в государственным ИС, обрабатывающих конфиденциалку (не ГТ)
• 3 и последующие классы – применение в ИС, обрабатывающих гостайну.

Тут возникает ряд вопросов. Собственно ключевой – какие классы применять в случаях, когда у меня ИСПДн классифицирована просто как «специальная»? А если у меня критически важный объект, который не обрабатывает ПДн (например, АСУ ТП)? Согласно документам ФСТЭК по КСИИ в таких системах обрабатывается открытая информация. И какой класс СОВ должен быть в этом случае? Кстати, эта классификация подтверждает тезис о том, что на коммерческие предприятия (исключая ИСПДн коммерческих предприятий) эти требования не распространяются. На закономерный вопрос, а какие СОВ надо применять для ИС общего пользования I класса, ответ прост — требования устанавливает ФСБ.

Обновление СОВ (исключая базу правил, по которой осуществляется обнаружение) подлежит контролю со стороны испытательной лаборатории. База правил проверяется испытательной лабораторией ежегодно. Налицо понимание авторами документа давно известного факта, что база сигнатур атак может обновляться ежечасно (и даже чаще) и нельзя требовать пересертификации продукта при каждом изменении такой базы. Но… Проблема в том, что далеко не всегда база правил реализуется в виде отдельного компонента СОВ, который можно отделить от программной части СОВ, обновление которой и подлежит контролю со стороны испытательной лаборатории. Например, обнаружение атак для IPv6 требуется не только наличия соответствующих сигнатур, но и специального движка, который умеет распознавать протокол IPv6. Аналогичная ситуация с атаками на IP-телефонию, видеоконференцсвязь, АСУ ТП, СУБД и т.д. По сути, авторы нового РД упустили из виду, что современные СОВ строятся не по двухуровневой схеме «ядро СОВ + система управления – сигнатуры», а по трехуровневой «ядро СОВ + система управления – движки для обработки различных протоколов – сигнатуры». Второй компонент такой схемы обновляется тоже достаточно регулярно.

Тип СОВ (HIPS/NIPS) и класс защиты определяет совокупность требований к функциям безопасности СОВ. Эти требования, установленные в соответствие с ГОСТ Р ИСО/МЭК 15408, делятся на 4 набора:

• Требования к составу функций безопасности СОВ и сред, в которых эти СОВ функционируют
• Требования к составу функциональных возможностей СОВ, обеспечивающих реализацию функций СОВ
• Требования к реализации функциональных возможностей СОВ
• Требования доверия к безопасности СОВ.

Функций безопасности, которые должны быть реализованы в СОВ, выделяется 10:

1. Разграничение доступа к управлению СОВ
2. Управление работой СОВ
3. Управление параметрами СОВ
4. Управление установкой обновлений базы правил СОВ
5. Анализ данных СОВ
6. Аудит безопасности СОВ
7. Контроль целостности СОВ
8. Сбор данных о событиях и активности в контролируемой ИС
9. Реагирование СОВ
10. Маскирование СОВ.

В качестве функций безопасности среды функционирования выделяются:

1. Обеспечение доверенного маршрута с администраторами СОВ (аутентификация и защищенный канал управления)
2. Обеспечение доверенного канала обновлений базы правил
3. Обеспечение условий безопасного функционирования (в т.ч. регистрацию событий внутри СОВ)
4. Управление атрибутами безопасности.

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

• Функция автоматического блокирования атак устанавливается только для СОВ 2-го класса защиты и выше. На этом же уровне устанавливается требование удаленного управления. Графический интерфейс управления требуется, начиная с 3-го класса защиты.
• Для 1-го класса СОВ появляется требования звуковой сигнализации об обнаруженных вторжениях. Этот пункт вызовет улыбку у специалистов, которые имеют практический опыт эксплуатации СОВ. Представьте, что СОВ обнаруживает 10000 событий в сутки (это по одному событию за 8.6 секунд). Какофония звуков будет просто потрясающей 😉 Не ошибусь, если предположу, что звуковая сигнализация будет отключена через полчаса работы СОВ 😉 К слову, в достаточно крупной распределенной сети на консоль СОВ может поступать до нескольких миллионов сигналов тревоги. Единственная надежда, что в ИС, обрабатывающих сведения «особой важности» (а именно в таких ИС должны устанавливаться СОВ 1-го класса), нарушителей мало и СОВ будет срабатывать нечасто.
• Анализ требований к хостовым СОВ показывает, что авторы не до конца понимают, как эти системы функционируют (в отличие от сетевых СОВ). Все-таки основная задача хостовых СОВ анализировать логи или поведение приложений и пользователей на конкретном узле. Функция анализа сетевого трафика для них вторична, в то время как авторы РД делают акцент именно на этой функциональности хостовых СОВ. Возможность анализа логов появляется только для СОВ 2-го класса. А вот возможность анализа поведения пользователей вообще не заявлена ни для одного из классов.
• Требование невозможности обнаружения сенсора СОВ на сетевом уровне стандартными средствами ОС как для NIPS, так и для HIPS, вызвало у меня долгие раздумья. Я так и не понял, как выполнить это требование? Видимо авторы все-таки имели ввиду, чтобы сенсоры сетевых СОВ не могли быть обнаружены путем сканирования сети или анализа сетевого трафика, а сенсоры хостовых СОВ не могли быть обнаружены путем анализа процессов ОС. Хотя второе малореализуемо – обычно хостовые СОВ висят как сервис, и увидеть их может любой желающий. А вот снести этот сервис стандартными средствами ОС должно быть проблематично.

РД также устанавливает требования доверия, определяемых на основании ГОСТ Р ИСО/МЭК 15408-3:

• Для СОВ 6-го класса — ОУД1 усиленный. Требования контроля НДВ не предъявляются.
• Для СОВ 5-го класса – ОУД2 усиленный. Требования контроля НДВ не предъявляются.
• Для СОВ 4-го класса – ОУД3 усиленный. Требования контроля НДВ – 4 класс.
• Для СОВ 3-го класса – ОУД4 усиленный. Требования контроля НДВ – 3 класс.
• Для СОВ 2-го класса – ОУД5 усиленный. Требования контроля НДВ – 2 класс.
• Для СОВ 1-го класса – ОУД5 усиленный. Требования контроля НДВ – 1 класс.

Что меня смутило в РД, так это то, что для сертификации необходимо представить базу данных по обнаруживаемым вторжениям. Как авторы себе это представляют? Современная СОВ – это вам не Snort десятилетней давности, в котором все сигнатуры были в отдельном файле. Это если не вдаваться в то, что требуется именно база атак, а не база сигнатур атак. Аналогичное требование, кстати, есть и в РД ФСБ по системам обнаружения атак.

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

Кстати, РД ФСТЭК очень сильно напоминает ФСБшные документы по СОВ по своим требованиям. Вдумчивое изучение обоих документов привело меня к мысли «а не планируют ли ФСТЭК и ФСБ объединить свои требования к СОВ в одном документе?» А вообще давно ходят слухи о создании единой системы сертификации средств защиты (ФСТЭК, ФСБ и МО). Может этот РД – это первый шаг?

А пока я предвижу следующее. Число IDS/IPS, прошедших сертификацию, будет невелико. Не исключаю, что этот процесс вообще пройдет всего две из них — «Ручей» и «Аргус». Обе отечественных системы имеют сертификат ФСБ как системы обнаружения атак. Отзывы об этих системах впечатляют ;-(  Кстати, в документах на «Аргус» есть замечательный фрагмент в скобках 😉

ЗЫ. А еще мне непонятно, почему у этого РД гриф ДСП. Ничего даже близко похожего на закрытую информацию я не нашел. Не считать же таковой требования к СОВ 1-3-го классов? Там ничего «служебного» нет — описание указанного там функционала можно найти в документации на любую систему обнаружения вторжений. Да и в моей книжке 2000 года все это есть. Описание требований к доверию есть в международных профилях на IDS многолетней давности. Может именно поэтому данный документ уже можно найти в Интернете (если правильно сформулировать запрос в Google), как и многие другие документы ФСТЭК — СТР-К, КСИИ и т.п.