SIEM в АСУ ТП: как построить мониторинг, который помогает производству, а не мешает

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

 

 

 

 

 

 

1. 1. Введение
2. 2. Почему мониторинг АСУ ТП отличается от мониторинга ИТ
3. 3. Ключевые сложности мониторинга в АСУ ТП
   
   1. 3.1. События из технологического сегмента поступают редко или не поступают вообще
   2. 3.2. Узкие каналы связи ограничивают передачу данных
   3. 3.3. Промышленные протоколы требуют отдельной интерпретации
   4. 3.4. Ограничения промышленной среды определяют архитектуру мониторинга
   5. 3.5. На местах часто нет выделенных ИБ-специалистов по АСУ ТП
4. 4. А точно ли нужна SIEM или поначалу необходим ICS/OT Monitoring?
5. 5. Практические кейсы
   
   1. 5.1. Кейс 1. Изменение логики контроллера в «разрешённое» время
   2. 5.2. Кейс 2. Удалённая площадка с узким каналом и без ИБ-специалиста
   3. 5.3. Кейс 3. Команда в промышленном протоколе без явного инцидента в ИТ-логах
   4. 5.4. Кейс 4. Подрядчик подключился к площадке шире согласованного объёма работ
6. 6. Что должна видеть SIEM в промышленном контуре
   
   1. 6.1. Как правильно подходить к внедрению
7. 7. Что получает CISO
8. 8. Выводы

Введение

Когда обсуждают мониторинг безопасности в автоматизированных системах управления технологическими процессами (АСУ ТП), разговор часто быстро сводится к выбору конкретного решения: нужна ли система для мониторинга, анализа и управления событиями в области безопасности в ИТ-инфраструктуре (Security Information and Event Management, SIEM), какой продукт использовать, какие источники подключить и какие правила корреляции настроить. Но для промышленной среды такой подход слишком упрощает задачу.

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

Поэтому правильный вопрос звучит не «Какую SIEM поставить в АСУ ТП?», а иначе: «Как построить такую архитектуру мониторинга, которая даёт видимость промышленных рисков и при этом не становится дополнительным риском для производства?»

Почему мониторинг АСУ ТП отличается от мониторинга ИТ

В корпоративной ИТ-инфраструктуре система управления событиями и информацией безопасности обычно получает события постоянно: от домена, серверов, рабочих станций, сетевых устройств, средств защиты, бизнес-приложений и облачных сервисов. События можно собирать агентами, по syslog, через API, через коннекторы или другими стандартными способами. При необходимости можно достаточно быстро добавить новый источник, изменить схему сбора или включить дополнительные журналы.

В АСУ ТП такая логика работает не всегда.

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

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

Здесь появляется необходимость в контексте операционных технологий (Operational Technology, OT). Контекст OT — это данные о технологических активах, процессах, регламентах работ и допустимых действиях в промышленной сети. Иными словами, это понимание того, какие контроллеры, системы диспетчерского управления и сбора данных (Supervisory Control and Data Acquisition, SCADA), человеко-машинные интерфейсы (Human-Machine Interface, HMI), инженерные станции, участки производства, технологические окна, маршруты взаимодействия и действия считаются нормальными именно для этой площадки.

Без такого контекста SIEM будет видеть только технические события. С контекстом она начинает видеть риск для технологического процесса.

Ключевые сложности мониторинга в АСУ ТП

На практике трудности связаны в основном не с возможностями самой SIEM, а с особенностями промышленной инфраструктуры. Источники данных, каналы связи, используемые протоколы, архитектура сети и организация эксплуатации накладывают ограничения, которые приходится учитывать при построении мониторинга. Рассмотрим основные из них.

События из технологического сегмента поступают редко или не поступают вообще

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

Поэтому SIEM может хорошо видеть корпоративную инфраструктуру, но почти не понимать, что происходит на нижних уровнях технологической сети. Она может видеть VPN-подключение, вход администратора, сетевое соединение с промышленной демилитаризованной зоной (Demilitarized Zone, DMZ), но не видеть, какие действия после этого выполнялись с инженерной станции и какие команды уходили в сторону контроллеров.

Узкие каналы связи ограничивают передачу данных

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

Это важное отличие от офисной ИТ-инфраструктуры. В АСУ ТП нельзя просто сказать, чтобы все журналы событий и сетевая телеметрия передавались в центральную SIEM. Такой подход может перегрузить канал, увеличить задержки, привести к потере данных или вызвать обоснованное сопротивление со стороны эксплуатации.

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

В центральную SIEM не всегда нужно отправлять весь необработанный трафик. Часто правильнее передавать метаданные, инциденты, обогащённые события, изменения в составе активов, факты подключения, команды управления, признаки аномалий и другие данные, которые уже прошли первичную обработку на площадке.

Такой подход позволяет сохранить видимость и при этом не создавать дополнительную нагрузку на производственную инфраструктуру.

Промышленные протоколы требуют отдельной интерпретации

В АСУ ТП используются промышленные протоколы и специализированные взаимодействия: Modbus, OPC, PROFINET, PROFIBUS, HART, DNP3 и другие. Многие из них проектировались прежде всего для надёжной работы оборудования, а не для задач кибербезопасности. В них не всегда есть привычные механизмы аутентификации, шифрования и журналирования.

Для SIEM событие на уровне промышленного протокола может выглядеть как обычный обмен данными. Но для технологического процесса это может быть команда изменения параметра, запись значения, изменение режима работы или загрузка логики в контроллер.

Именно поэтому в АСУ ТП особенно важны специализированные источники данных: промышленные системы обнаружения вторжений (Intrusion Detection System, IDS), системы обнаружения и реагирования на сетевые угрозы (Network Detection and Response, NDR), ICS/OT-сенсоры, системы инвентаризации активов и мониторинга технологического трафика. Они помогают превратить промышленный сетевой обмен в понятные ИБ-события.

Ограничения промышленной среды определяют архитектуру мониторинга

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

Поэтому основной вопрос не в характеристиках SIEM как отдельного продукта, а в том, можно ли безопасно получить данные из конкретной технологической среды, не повлияв на производственный процесс, и правильно интерпретировать полученные события.

В некоторых случаях допустим только пассивный мониторинг. В других можно настроить выгрузку журналов через промежуточный узел. Где-то потребуется промышленная DMZ, отдельный коллектор, data diode, буферизация или передача данных строго по расписанию. Универсальной схемы нет: архитектура должна учитывать конкретную площадку.

На местах часто нет выделенных ИБ-специалистов по АСУ ТП

Ещё одна практическая сложность — дефицит ИБ-экспертизы на региональных промышленных площадках. На местах могут быть сильные инженеры АСУ ТП и ИТ-специалисты, но отдельной команды по кибербезопасности технологического сегмента часто нет. Если такие специалисты есть, их обычно мало, а круг задач у них широкий.

В результате задачи по анализу событий, согласованию источников данных, проверке отклонений и первичному реагированию ложатся на эксплуатацию или ИТ-подразделение. Для них это дополнительная нагрузка, а не основная функция.

Поэтому мониторинг АСУ ТП нужно строить так, чтобы минимально нагружать локальные команды. На площадке должны оставаться только те действия, которые действительно требуют физического присутствия или знания конкретного технологического процесса: подтверждение работ, проверка состояния оборудования, согласование вмешательства. Основной анализ событий, корреляцию, расследование, приоритизацию и подготовку рекомендаций логично переносить на уровень центральной ИБ-команды или центра мониторинга кибербезопасности (Security Operations Center, SOC).

А точно ли нужна SIEM или поначалу необходим ICS/OT Monitoring?

Для АСУ ТП важно честно ответить на вопрос: какую задачу мы решаем на первом этапе?

Если в технологическом сегменте нет нормальной видимости активов, промышленных протоколов, инженерных станций, PLC, HMI/SCADA и сетевых взаимодействий, то SIEM будет получать только фрагменты картины. Она сможет анализировать то, что до неё дошло, но не сможет сама увидеть данные, на которые не настроена.

В такой ситуации большую ценность может дать специализированное решение класса ICS Security / OT Monitoring. Например, промышленный сенсор или система анализа трафика АСУ ТП, которая пассивно наблюдает за технологической сетью, выявляет активы, фиксирует команды промышленных протоколов, показывает изменения в поведении оборудования и помогает понять, что реально происходит внутри технологического сегмента.

SIEM решает другую задачу. Она полезна там, где нужно объединить события из разных источников, сопоставить активность в ИТ и АСУ ТП, связать инцидент с учётными записями, VPN, PAM, jump-серверами, заявками на изменение, действиями подрядчиков и другими источниками данных. Это уровень централизованного анализа, расследования, отчётности и управления реагированием.

Поэтому вопрос не в том, что лучше, SIEM или ICS/OT Monitoring. Эти классы решений выполняют разные задачи и в зрелой архитектуре дополняют друг друга.

ICS/OT Monitoring даёт промышленную видимость: активы, протоколы, команды, взаимодействия, изменения и аномалии внутри технологической сети.

SIEM даёт централизованное управление событиями и инцидентами: корреляцию, приоритизацию, расследование, связь с ИТ-инфраструктурой, отчётность и работу SOC.

Если коротко: ICS/OT-система помогает увидеть, что происходит в промышленной сети, а SIEM помогает связать это с общей картиной кибербезопасности и организовать реагирование.

Практические кейсы

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

Кейс 1. Изменение логики контроллера в «разрешённое» время

На площадке есть регламентные окна обслуживания. В одно из таких окон инженерная станция подключается к контроллеру, после чего выполняется загрузка новой логики.

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

Именно такой сценарий должен попадать в зону внимания SOC. Не потому, что сам факт подключения всегда опасен, а потому, что действие не соответствует технологическому контексту.

Кейс 2. Удалённая площадка с узким каналом и без ИБ-специалиста

Есть удалённая производственная площадка, где работает SCADA, инженерная станция, несколько контроллеров и ограниченный канал связи с головным офисом. Локальной ИБ-команды нет. За эксплуатацию отвечает инженер АСУ ТП, а ИТ-специалист подключается по необходимости.

Если попытаться передавать в центральную SIEM все события и сетевую телеметрию, канал быстро станет узким местом. Часть данных начнёт теряться, передача будет нестабильной, а эксплуатация справедливо задаст вопрос: почему система безопасности создаёт нагрузку на производственную инфраструктуру?

Более правильная схема — разместить на площадке пассивный промышленный сенсор или локальный коллектор. Он наблюдает за технологическим трафиком, выявляет активы, фиксирует изменения и предварительно классифицирует события. В центр передаются только значимые события: появление нового устройства, подключение к инженерной станции, изменение маршрута взаимодействия, команда управления, загрузка проекта в контроллер, активность подрядчика вне согласованного окна.

Центральная команда SOC или ИБ анализирует эти события в SIEM, сопоставляет их с заявками, графиком работ, учётными записями и данными удалённого доступа. Локального инженера привлекают не для постоянного анализа событий, а только для проверки конкретных вопросов: выполнялись ли работы, относится ли контроллер к критичному участку, могло ли действие повлиять на технологический процесс?

Кейс 3. Команда в промышленном протоколе без явного инцидента в ИТ-логах

В технологической сети появляется команда записи значения в регистр или изменение режима работы устройства. На уровне сетевого взаимодействия это может быть обычный пакет промышленного протокола. Антивирус, EDR и классические ИТ-журналы ничего критичного не покажут.

Ценность мониторинга появляется только тогда, когда событие сопоставляется с промышленным контекстом: кто инициировал команду, с какого узла, к какому контроллеру, была ли команда допустима для этого участка и не совпадает ли она с другими подозрительными действиями.

Здесь ICS/OT-сенсор позволяет увидеть промышленное действие, а SIEM помогает связать его с пользователем, удалённым доступом, заявкой, подрядчиком и другими ИБ-событиями.

Кейс 4. Подрядчик подключился к площадке шире согласованного объёма работ

Для обслуживания оборудования подрядчику выдан удалённый доступ. Формально вход выполнен легитимно: учётная запись известна, VPN разрешён, доступ согласован. Но после подключения фиксируется обращение к инженерной станции или контроллеру, которые не входят в согласованный объём работ.

Без корреляции это может остаться незамеченным. VPN увидит только факт подключения, инженерная станция — локальную активность, промышленный сенсор — сетевое взаимодействие в технологическом сегменте. Но SIEM может объединить эти события и показать полную цепочку: кто подключился, когда, через какой канал, к каким узлам обращался и соответствует ли это заявке на работы.

Что должна видеть SIEM в промышленном контуре

Для АСУ ТП недостаточно подключить пару сетевых устройств и считать, что мониторинг построен. Минимально полезная картина складывается из нескольких типов данных:

• инвентаризация технологических активов (PLC, SCADA, HMI, инженерные станции, серверы истории, шлюзы, сетевое оборудование);
• сетевые взаимодействия между сегментами (кто, куда, по какому протоколу и в какое время подключается);
• события промышленной DMZ, jump-серверов, VPN, PAM и удалённого доступа подрядчиков;
• события промышленных IDS/NDR и ICS/OT-сенсоров по протоколам, командам и изменениям;
• журналы инженерных станций и серверов, если их можно безопасно собирать;
• данные о заявках на изменение, технологических окнах, планово-предупредительных ремонтах (ППР) и разрешённых работах;
• перечень критичных активов и участков производства;
• данные о локальных ограничениях (пропускная способность каналов, допустимый объём передаваемых событий, режимы передачи и требования эксплуатации).

Таблица 1. Примеры сценариев корреляции

 

Как правильно подходить к внедрению

SIEM в АСУ ТП не должна внедряться по шаблону корпоративного SOC. Рабочая последовательность обычно выглядит так:

1. Обследовать архитектуру АСУ ТП и понять, какие сегменты, активы, каналы обмена и ограничения реально существуют.
2. Определить, какие данные можно собирать безопасно: без активного воздействия на контроллеры, без установки агентов там, где это запрещено, и без риска для производственного процесса.
3. Оценить пропускную способность каналов связи и определить, какие данные можно передавать в центр постоянно, какие — по расписанию, а какие должны оставаться на площадке.
4. Разместить локальные коллекторы или промышленные сенсоры там, где требуется предварительная фильтрация, агрегация и буферизация событий.
5. Выделить промышленную DMZ или иной безопасный контур передачи событий в SIEM.
6. Собрать базовую модель активов и нормального поведения: кто с кем взаимодействует, в какие часы, по каким протоколам и в рамках каких работ.
7. Настроить не универсальные правила для АСУ ТП, а сценарии под конкретную площадку: технологические окна, критичные контроллеры, инженерные станции, подрядчики, маршруты доступа.
8. Определить модель ответственности: что анализирует центральный SOC, что подтверждает локальная эксплуатация, кто принимает решение о реагировании и в каких случаях.
9. Согласовать порядок реагирования с эксплуатацией. В АСУ ТП реакция SOC не может быть оторвана от технологов: иногда правильное действие — не блокировка, а немедленная эскалация ответственному инженеру.

Когда архитектура мониторинга выстроена корректно, меняется не только глубина видимости событий, но и управляемость рисков. Это особенно важно на уровне руководства, где требуется не поток разрозненных сигналов, а целостное понимание ситуации и основание для принятия решений.

Что получает CISO

Для руководителя ИБ ценность SIEM в АСУ ТП не в том, что «ещё один сегмент подключили к мониторингу». Ценность в другом: появляется управляемая видимость промышленного риска.

CISO видит:

• какие технологические активы находятся в зоне мониторинга;
• какие площадки остаются слепыми зонами;
• какие события передаются в центр и с какой задержкой;
• где каналы связи ограничивают глубину мониторинга;
• какие сценарии атак и ошибочных действий покрыты детектированием;
• где не хватает локальной ИБ-экспертизы;
• какие задачи можно централизовать на уровне SOC;
• какие ограничения связаны с оборудованием, регламентами и производственной эксплуатацией.

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

Выводы

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

В промышленной среде важно строить не просто сбор логов, а безопасную архитектуру видимости. На локальном уровне нужны источники, которые понимают технологическую сеть: промышленные сенсоры, ICS/OT Monitoring, пассивный анализ трафика, локальные коллекторы и буферизация. На центральном уровне нужна SIEM, которая объединяет эти данные с ИТ-контекстом, учётными записями, удалённым доступом, заявками, действиями подрядчиков и процессами SOC.

Поэтому зрелый подход — это не «купить SIEM для АСУ ТП», а выстроить связку: локальная промышленная видимость на площадке плюс централизованный анализ и принятие решений в головном офисе.

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