Проект Приказа ФСТЭК № 239: требования к значимым объектам КИИ и первые вопросы про ОТ-среды

ФСТЭК опубликовал проект приказа об обеспечении безопасности значимых объектов критической информационной инфраструктуры - тот самый документ, который определит, что именно нужно делать после категорирования. Это пока проект, он проходит обсуждение, но смотреть на него сейчас важно: субъекты КИИ из первой и второй категорий уже понимают, что их ждёт, и чем раньше оценить масштаб - тем меньше сюрпризов.

Мы читаем проект в контексте реальных объектов, с которыми работаем: промышленные площадки, АСУ ТП, среды с железом, которое не переустанавливается и не патчится по расписанию. И разрыв между логикой документа и реальностью ОТ-среды виден с первых разделов.

Структура документа и откуда она растёт

Приказ строится на базовой модели угроз ФСТЭК - той самой, по которой уже несколько лет работают госинформсистемы и персональные данные. Это предсказуемо: ФСТЭК не изобретает новую методологию, а расширяет существующую на сферу КИИ. Принцип тот же: определяется уровень защищённости объекта на основании категории, потом подбираются меры из базового набора, потом добавляются адаптированные меры.

Для каждой категории значимости - три набора требований: организационные, технические и специфические для типа объекта. Технические требования знакомы тем, кто работал с аттестацией ГИС или ИСПДн: идентификация и аутентификация, управление доступом, защита информации в сети, антивирусная защита, мониторинг, аудит. Всё это есть, и оно структурировано примерно так же, как в приказах 17 и 21.

Плюс этого подхода очевиден: методология не новая, регуляторы умеют с ней работать, аттестующие организации умеют с ней работать, и часть субъектов КИИ - особенно из банковского и телеком-сектора - уже делала что-то похожее для своих ИС. Для них приказ - это во многом перенос знакомой логики на новый периметр.

Где начинаются вопросы для ОТ-сред

Проблема в том, что промышленный объект с АСУ ТП - это не информационная система в классическом понимании. И базовая модель угроз ФСТЭК это в общем понимает, но специфические меры для ОТ в проекте прописаны скромно.

Возьмём конкретный пример из нашей работы. Требование к обновлению программного обеспечения - стандартная мера, есть в любом наборе требований по безопасности. Для корпоративной ИС это означает WSUS, контроль версий, расписание патчинга. Для АСУ ТП на промышленном предприятии это означает разговор с вендором оборудования о том, поддерживает ли он вообще обновление ПО на конкретном ПЛК, и если да - то при каких условиях это возможно без останова производственного процесса. Во многих случаях ответ: «обновление возможно, но только при плановой остановке линии раз в квартал» или «не поддерживается на этой версии прошивки».

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

Аутентификация в промышленных протоколах. Modbus и OPC-DA, которые работают на большинстве объектов, аутентификацию не поддерживают конструктивно. Требование «обеспечить идентификацию и аутентификацию» в этом контексте выполнимо только на сетевом уровне - через сегментацию, контроль доступа на коммутаторах, системы мониторинга трафика. Это рабочий подход, и он применяется, но в тексте документа явного разрешения строить защиту на сетевом периметре вместо аутентификации внутри протокола - нет. Аттестующая организация при проверке будет трактовать это по-своему.

Мониторинг и аудит в изолированных сетях. Требование вести аудит событий в изолированном сегменте - разумное. Вопрос в том, что SIEM-системы, которые умеют работать с событиями от промышленного оборудования (Siemens S7, Allen-Bradley), немногочисленны и дороги, а «стандартные» решения для корпоративных сред просто не имеют коннекторов для OPC-серверов или историков данных.

Сравнение с IEC 62443

IEC 62443 - это серия стандартов по безопасности промышленных систем управления, которую принял ISA и которую в Европе уже применяют при аттестации объектов в энергетике. Мы смотрим на неё в контексте наших проектов - не как на нормативно обязательный документ, а как на методологию, которая реально написана с учётом ОТ-специфики.

Главное отличие в том, что IEC 62443 строит модель защиты вокруг понятия зон и каналов (zones and conduits) - изолированных сегментов с явно определёнными точками взаимодействия. Это хорошо ложится на реальные ОТ-топологии, где сегментация - основной инструмент безопасности. Требования к каждой зоне формулируются с учётом того, какое оборудование в неё входит и какие протоколы там работают.

Проект приказа ФСТЭК работает с другой логикой - от класса угроз и категории объекта к мерам. Это не плохо само по себе, но для ОТ-среды нужно дополнительное звено: перевод общих требований в конкретику промышленного стека. Этого звена в документе пока нет.

На практике это означает следующее. Когда мы будем готовить план защитных мер для промышленного заказчика под приказ - нам придётся строить дополнительный слой обоснований: вот требование из приказа, вот мера, которую мы реализуем, вот почему она эквивалентна по смыслу тому, что требование имеет в виду применительно к данной системе. По сути - самостоятельно делать то отображение, которое должно быть в методических рекомендациях.

Что мы ждём от финальной версии

Проект - это хорошо, потому что есть возможность подать замечания. Мы готовим комментарии по нескольким пунктам: про специфику промышленных протоколов, про компенсирующие меры для необновляемого ПО, про критерии эквивалентности мер в ОТ-средах. Насколько это отразится в финальном тексте - неизвестно.

Пока документ в работе, мы продолжаем строить защиту для АСУ ТП-объектов, опираясь на здравый смысл и на то, что мы знаем из IEC 62443. Если финальный приказ выйдет и потребует корректировки - меры в правильном направлении дополнить проще, чем переделывать с нуля.

Если у вас объект КИИ с АСУ ТП и вопрос о том, что придётся делать после категорирования, - разбираем это в рамках аудита, в том числе с учётом требований проекта приказа в их нынешнем виде.