Комплексная защита АСУ ТП: скрытые риски и инженерный подход к безопасности
Автор: Петухов Олег Анатольевич, эксперт по информационной безопасности, руководитель юридической компании ЛЕГАС.
Контакты: сайт - legascom.ru, e‑mail - petukhov@legascom.ru .
Основные проблемы при внедрении защиты АСУ ТП
Многие ИБ‑директора при построении комплексной защиты фокусируются только на технологиях и требованиях регуляторов - но такой подход приводит к формальному результату. Защита становится набором разрозненных решений, не встроенных в архитектуру предприятия. Разберём ключевые проблемы.
1. Активы за периметром защиты
Часть инфраструктуры остаётся вне контроля из‑за разрыва ответственности между подразделениями. К таким активам относятся:
инженерные и технологические станции (ноутбуки и планшеты в цехах);
встроенные (Embedded) системы;
программируемые логические контроллеры (ПЛК) с сетевыми интерфейсами;
пассивное сетевое оборудование в цехах;
устройства индустриального интернета вещей (IIoT): датчики, умные счётчики, камеры.
Дополнительно риски создают:
сервисные технологические учётные записи без парольной политики и контроля;
удалённый доступ подрядчиков, организованный в обход ИТ и ИБ.
2. Инженерные ограничения АСУ ТП
Защита АСУ ТП не может внедряться по принципам обычных ИТ‑проектов из‑за ряда ограничений:
жёсткая привязка изменений к технологическим остановам;
длительный жизненный цикл оборудования (контроллеры и SCADA работают десятилетиями);
требования к работе в реальном времени (задержки недопустимы);
необходимость отказоустойчивости (защита не должна создавать единую точку отказа);
несовместимость промышленных протоколов с современными механизмами безопасности;
несовпадение жизненных циклов средств защиты и оборудования (новые решения плохо взаимодействуют со старыми системами).
3. Точки риска в архитектуре
Часто недооцениваются временные или вспомогательные элементы, которые остаются в системе надолго:
точки удалённого администрирования;
временные каналы связи (подключения для подрядчиков, временный выход в интернет и т. д.).
4. Отсутствие карты активов и информационных потоков
Без понимания реальной архитектуры промышленных сетей невозможно определить:
границы доверия;
точки входа;
реальные векторы атак.
Карта должна включать не только сетевую схему, но и логику прохождения данных - от полевого оборудования до верхнего уровня управления.
5. Сложности на стадии эксплуатации
Проблемы проявляются после внедрения, когда система уже работает. Ключевые ошибки:
игнорирование этапов Check и Act в цикле Деминга‑Шухарта;
изменения конфигурации без контроля и документации;
накопление ошибок проектирования, из‑за которых защита либо перестаёт работать, либо мешает процессу.
6. Отсутствие владельца технологического риска
Ответственность за АСУ ТП размыта между подразделениями:
ИТ и ИБ ориентируются на конфиденциальность и целостность;
технологи - на доступность и недопущение остановов.
Это приводит к конфликту приоритетов и техническим проблемам: средства защиты мешают работе протоколов, а производственные подразделения обходят ИТ и ИБ, создавая неучтённые изменения.
Инженерный подход к управлению безопасностью
Чтобы избежать перечисленных проблем, нужно выстроить ответственность в соответствии с реальной архитектурой и влиянием решений на процесс. Модель работы:
Главный инженер (производственный блок) - владелец технологического риска. Определяет допустимые последствия для оборудования и процесса.
ИТ - обеспечивает инфраструктурную основу: сети, вычислительные ресурсы, рабочие станции.
ИБ - отвечает за методологию, архитектуру защиты и управление рисками, но в связке с АСУ ТП.
Такой тандем позволяет избежать технических блокировок и конфликтов решений. Безопасность становится частью системы управления производством.
Что определить до начала внедрения?
Подготовка - ключевой этап. Необходимо заранее получить ответы на вопросы:
Полнота картины: проведена ли инвентаризация активов, понятны ли зоны ответственности?
Нормативный контекст: какие требования применимы к конкретному производству?
Практическая применимость: подходят ли выбранные решения для технологических узлов, как они будут контролироваться?
Процессы реагирования: кто отвечает за инциденты, как формируется группа реагирования?
Минимальный архитектурный пакет данных:
объединённая карта активов и информационных потоков (физическое размещение и логическая структура);
перечень критичных технологических процессов;
модель угроз, отражающая реальное производство.
Ключевые инженерные факторы успешной защиты:
Корректно заложенная архитектура (сегментация, изоляция, отказ от избыточных подключений).
Эксплуатационные процессы (контроль изменений, мониторинг, реагирование).
Управление рисками и чёткое распределение ответственности.
Критерии успешной защиты
Чтобы проект был жизнеспособным, нужно требовать:
Подтверждённую совместимость - средства защиты должны реально работать с оборудованием и протоколами.
Понятную модель эксплуатации - как система будет обслуживаться и обновляться с учётом производственного цикла.
Связку с модернизацией - защита должна быть встроена в дорожную карту развития АСУ ТП.
Единую модель знаний и ответственности - ИБ, ИТ и технологи должны работать в связке.
Критерии успеха - оценивать не факт установки средств, а метрики устойчивости: контроль изменений, выявляемость инцидентов, снижение архитектурных слепых зон.
Этот подход превращает комплексную защиту из формального проекта в управляемую систему, встроенную в процессы предприятия.
