АСУ ТП как отдельные объекты КИИ: как ОТ-специфика ломает стандартный акт категорирования

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

Почему это не просто формальность

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

Это удваивает объём документов там, где производственный объект одновременно является субъектом КИИ по другим основаниям - скажем, там же работает корпоративная информационная система. Оба объекта в периметр, у каждого свой акт.

Второе последствие интереснее: оценка угроз для АСУ ТП строится иначе, чем для корпоративных систем. И вот тут начинается та самая ОТ-специфика, с которой у нас сейчас много вопросов.

Профиль угроз, который не укладывается в стандартные методики

Наш заказчик - промышленное предприятие. АСУ ТП-сети физически изолированы от корпоративной сети: воздушный зазор, отдельные коммутаторы, отдельная адресация. На бумаге - классический периметр. Проблема в том, что угрозы, которые реальны для этой среды, определяются не наличием или отсутствием провода в корпоративную сеть.

Протоколы без аутентификации. Modbus RTU и Modbus TCP, которые работают на большинстве объектов, не имеют встроенной аутентификации и шифрования. Любое устройство, получившее физический или сетевой доступ к шине, может отправить команду на ПЛК - и тот её выполнит. OPC-DA поверх DCOM добавляет слой Windows-аутентификации, но это COM-интерфейс с известным набором проблем в части управления доступом. Для стандартной методики оценки угроз ФСТЭК эти протоколы не имеют отдельного раздела - нужно отображать вручную на существующие классы угроз, что создаёт зазор между реальным профилем и тем, что попадает в акт.

Устаревшее ПО как постоянный фактор. SCADA-системы и HMI на производстве работают на Windows XP и Windows 7 - не потому что заказчик не хочет обновляться, а потому что вендор оборудования сертифицировал конкретную версию ОС и не поддерживает переход на другую. Обновление ОС = замена или перепрограммирование ПЛК = остановка производства. Это реальная стоимость, и она влияет на категорию объекта, потому что уязвимость в части защищённости системы напрямую связана с критерием ущерба от нарушения её работы.

Цикл обслуживания через вендора. У нескольких установок есть канал для удалённой диагностики поставщиком оборудования - это отдельный модем или защищённый канал связи. Физическая изоляция от корпоративной сети существует, но изоляция от внешнего мира - нет. Это внешний интерфейс, который нужно фиксировать в акте и обосновывать в части угроз.

Как мы это отражаем в акте

Структура акта для АСУ ТП отличается от того, что мы делали для корпоративных ИС.

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

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

Раздел по невозможности обновления ПО - отдельная строка, где описывается зависимость от вендорской сертификации и реальная стоимость перехода. Это влияет на оценку рисков и на выбор компенсирующих мер.

Оценка компенсирующих мер - вместо стандартного «установить антивирус и патчи» - это сегментация внутри технологической сети, контроль доступа к физическим портам, мониторинг сетевого трафика на аномалии протоколов Modbus/OPC. Подходы есть, они описаны в публикациях ICS-CERT и ISA/IEC 62443 - нужно адаптировать под российский нормативный контекст.

Что это значит для сроков

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

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

Если у вас производственная площадка с АСУ ТП и категорирование ещё не начато - мы разбираем такие периметры в рамках аудита, с учётом специфики промышленных протоколов и ограничений по обновлению ПО.