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