UDV Group: защита АСУ ТП начинается с видимости технологического контура
Защиту АСУ ТП нельзя выстроить только вокруг документов, схем и разовых проверок. Промышленная инфраструктура постоянно меняется: появляются новые устройства, обновляются версии ПО, меняются конфигурации, подключаются подрядчики, корректируются проекты ПЛК, открываются временные соединения между сегментами. Если эти изменения не видны службе ИБ, технологический контур постепенно уходит от утвержденного состояния.
Мы в UDV Group считаем, что базовый вопрос для промышленного предприятия звучит просто: компания понимает, что фактически происходит внутри АСУ ТП, или опирается на проектную схему, которая могла устареть после первых ремонтов, модернизаций и сервисных работ. Именно с этого начинается реальная защита: с понимания состава оборудования и ПО, сетевых взаимодействий, конфигураций, версий программ и изменений в процессе эксплуатации.
Проблема в том, что в АСУ ТП «нет инцидента» не всегда означает «нет риска». Неизвестный узел может работать в сети месяцами. Лишнее соединение между технологическим и корпоративным сегментом может оставаться незамеченным. Конфигурация оборудования может измениться без фиксации. Программа ПЛК может не совпадать с сохраненным проектом. Все это не обязательно приводит к немедленной остановке, но создает условия, при которых атака или несанкционированное изменение обнаруживаются уже после нарушения технологического процесса.
Поэтому оценивать защищенность стоит не только по наличию средств защиты. Важнее проверить, насколько быстро предприятие может ответить на прикладные вопросы. Есть ли актуальный перечень всех устройств в технологической сети? Известно ли, какое ПО и каких версий используется на объектах автоматизации? Как служба ИБ узнает о появлении нового устройства? Какие уязвимости есть у конкретных компонентов АСУ ТП и в каком статусе находится их устранение? Можно ли через месяц после инцидента восстановить последовательность событий?
Если на такие вопросы приходится отвечать вручную, запрашивать данные у нескольких подразделений и сверять их с устаревшей документацией, единой картины технологического контура нет. Значит, часть контроля держится на памяти инженеров, локальных таблицах и разрозненных источниках. Для промышленной среды это опасно: чем больше ручной сборки, тем выше вероятность, что важное изменение будет замечено слишком поздно.
Первый шаг — получить фактическую картину АСУ ТП. Нужно проверить состав оборудования и ПО, реальные связи между узлами, используемые промышленные протоколы и конфигурации компонентов. Эту картину важно сопоставить с проектными схемами, архитектурой АСУ ТП и эксплуатационной документацией. Именно на таком сравнении обычно проявляются неизвестные устройства, лишние соединения и изменения, которые не были отражены документально.
Второй шаг — проверить целостность проектов ПЛК. Здесь важно не пытаться автоматически «перезаливать» программу при любом расхождении, а зафиксировать сам факт изменения и разобраться в его причине. Для промышленной эксплуатации одинаково опасны две крайности: игнорировать расхождения или реагировать на них грубо, без учета технологического процесса.
Третий шаг — отделить критичные отклонения от допустимых изменений. Не каждое изменение является инцидентом. Но в приоритете должны быть события, которые могут повлиять на технологический процесс: появление неизвестного узла, несанкционированное соединение, изменение критичной конфигурации, использование уязвимого ПО, аномальное поведение ПЛК или изменение программы контроллера.
Мы в UDV Group видим, что разовая диагностика быстро теряет ценность, если после нее не появляется постоянный контроль. Получить фактическую картину недостаточно: после обслуживания, обновления, подключения подрядчика или ремонта она может измениться. Поэтому нужно определить критичные параметры, задать для них эталонные значения и настроить автоматическое выявление отклонений.
Отдельный слой — контроль фактических устройств и связей в технологической сети. Проектная схема показывает, как АСУ ТП должна быть устроена. Анализ промышленного трафика показывает, как она работает на самом деле. Для действующего производства такой мониторинг должен быть неинвазивным: по копии трафика, без воздействия на контроллеры, станции и технологический обмен.
При этом сам канал мониторинга тоже должен быть защищен. SPAN-порт или иной канал передачи копии трафика нельзя оставлять как техническую мелочь. Он должен быть изолирован и защищен от несанкционированного доступа, иначе средство наблюдения может превратиться в дополнительную точку риска.
Следующий обязательный слой — контроль конфигураций и уязвимостей оборудования. Предприятию нужно видеть соответствие настроек утвержденным значениям, незапланированные изменения, установленные версии ПО, связанные с ними уязвимости и статус устранения проблем. Без этой связки управление уязвимостями превращается в общий список CVE, который плохо помогает понять реальный риск для конкретного объекта.
В АСУ ТП нельзя автоматически переносить методы из офисной ИТ-среды. Там, где активное сканирование может повлиять на оборудование, проверку нужно выполнять безопасными способами. Это может быть пассивный анализ характеристик трафика или read-only команды, которые не меняют состояние устройств. Главное — не допустить ситуации, когда проверка защищенности сама создает риск для технологического процесса.
Третий слой — выявление аномалий. В промышленной сети нельзя искать только известные атаки по сигнатурам. ПЛК может продолжать работать по штатному протоколу, но изменить характер взаимодействия с другими компонентами. Для этого нужен поведенческий анализ: сначала формируется нормальная модель сетевого обмена контроллера, затем существенные отклонения становятся основанием для проверки.
Это особенно важно потому, что атака на АСУ ТП не всегда выглядит как вредоносный файл или очевидно запрещенное действие. Иногда это легитимная команда, отправленная не тем пользователем, не в то время, не с того узла или не в тот технологический контекст. Без модели нормы такие действия трудно отделить от обычной работы инженера.
Четвертый слой — контроль версий проектов ПЛК. После обслуживания, модернизации или работ подрядчика должно быть понятно, какая версия программы актуальна, что именно изменилось и соответствует ли сохраненный проект тому, что реально находится на контроллере. Для этого нужны централизованное хранение проектов, история изменений, контроль неизменности программы на ПЛК и возможность быстро вернуться к предыдущей рабочей версии.
Мы в UDV Group считаем, что контроль версий ПЛК напрямую связан с восстановлением производства. Когда линия остановится, предприятие будет восстанавливаться не по акту проверки, а по фактической рабочей конфигурации. Если неизвестно, какая версия программы была загружена, кто ее менял и где хранится актуальный проект, расследование и восстановление затянутся.
Пятый слой — связь отдельных событий в один инцидент. Новое сетевое соединение, изменение конфигурации, отклонение в поведении ПЛК и срабатывание средства защиты могут быть частями одной цепочки, даже если произошли в разное время. Система мониторинга должна позволять восстановить историю конкретного узла, посмотреть его активность до и после события, провести ретроспективный анализ и передать значимые данные в SIEM или SOC.
Без ретроспективы команда видит только последнюю точку. Она может заметить остановку, ошибку или алерт, но не понять, что было раньше: подключение подрядчика, изменение конфигурации, появление нового узла, нестандартный обмен или правка проекта ПЛК. В результате реакция становится медленнее, а причина остается неочевидной.
Шестой слой — единый контроль на всех площадках. Для распределенного промышленного предприятия локальная видимость уже недостаточна. На каждой площадке могут быть свои службы, оборудование, подрядчики и привычные способы учета. Но на корпоративном уровне должна формироваться сводная картина активов, событий, уязвимостей и критичных отклонений. Иначе головной офис узнает о проблеме только после того, как она уже повлияла на производство.
Для объектов КИИ к этому добавляются требования к применяемым средствам защиты, порядку контроля и подтверждению выполненных мер. Но выполнение требований не должно превращаться в отдельный документальный процесс. Данные для регулятора должны вытекать из реального контроля технологического контура, а не собираться вручную перед каждой проверкой.
Для нас в UDV Group главный вывод такой: защита АСУ ТП должна строиться не вокруг перечня средств, а вокруг способности видеть и объяснять изменения. Какие устройства есть в сети, как они взаимодействуют, какие конфигурации используются, какие версии ПО установлены, какие проекты загружены в ПЛК, кто вносил изменения и какие отклонения действительно критичны для технологического процесса.
Внутренними силами такой контур построить можно, если у предприятия есть компетенции сразу в нескольких областях: промышленная автоматизация, сетевые технологии, ИБ АСУ ТП, управление уязвимостями, мониторинг, реагирование и требования регуляторов. Если эти компетенции распределены между разными подразделениями и собираются только под отдельные задачи, проект почти неизбежно будет буксовать.
Подрядчик в такой ситуации нужен не просто как внешний исполнитель. Его ценность в том, чтобы быстрее провести обследование, настроить контроль под конкретное оборудование, учесть промышленные протоколы, интегрировать события с действующими средствами ИБ и передать предприятию работающую модель постоянного контроля.
CISO в промышленной компании важно смотреть на АСУ ТП не как на закрытую зону службы автоматизации, а как на критичный контур бизнес-устойчивости. Если служба ИБ полностью зависит от сведений технологов и не имеет собственных данных о сетевых взаимодействиях, изменениях конфигураций и событиях, она не может независимо оценивать риск.
Главный вопрос не в том, есть ли на предприятии средства защиты. Вопрос в том, может ли команда быстро доказательно ответить, что изменилось в технологическом контуре, кто это сделал, какие активы затронуты и может ли это повлиять на производство. Если такого ответа нет, защищенность АСУ ТП остается предположением. Если ответ есть, безопасность становится управляемым процессом.
