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

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

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

Здесь и появляется поведенческий анализ. UEBA (User and Entity Behavior Analytics, поведенческая аналитика пользователей и сущностей) помогает не только смотреть на отдельные события, но и сравнивать текущую активность с тем, как обычно ведут себя конкретные пользователи, учётные записи, инженерные станции, серверы, подрядчики и другие сущности в инфраструктуре.

Важно сразу обозначить: UEBA не заменяет SIEM и не отменяет необходимость ICS/OT-мониторинга. Это дополнительный слой аналитики. Он становится особенно полезным там, где прямой признак атаки отсутствует, но поведение начинает отклоняться от нормы.

Почему в АСУ ТП поведение важнее отдельных событий

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

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

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

UEBA как раз помогает отвечать на эти вопросы. Она не ищет только заранее описанный индикатор атаки. Она ищет отклонение от нормального поведения и помогает аналитикам быстрее понять, где событие действительно требует внимания.

Что такое UEBA простыми словами

UEBA строит поведенческие профили пользователей и сущностей. Сущность в этом контексте — это не только человек. Это может быть учётная запись, инженерная станция, сервер, контроллер как объект наблюдения, сервисная учётная запись, рабочая группа, подрядчик, площадка или сетевой сегмент.

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

Когда текущее поведение начинает существенно отличаться от привычного, UEBA повышает риск-оценку и формирует сигнал для аналитика. При этом зрелая UEBA не должна превращаться в генератор шума. Важен не сам факт отклонения, а сочетание нескольких факторов риска: нетипичное время, новый маршрут доступа, критичный актив, отсутствие заявки, необычная команда, новая инженерная станция или действие подрядчика за пределами согласованного объёма работ.

Что может быть объектом поведенческого анализа в АСУ ТП:

• инженеры АСУ ТП и администраторы технологического сегмента;
• подрядчики и временные учётные записи;
• сервисные и технические учётные записи;
• инженерные станции, HMI/SCADA, серверы истории, jump-серверы;
• PLC/контроллеры и другие критичные активы как объекты взаимодействия;
• сетевые маршруты между ИТ, промышленной DMZ и технологическими сегментами;
• команды и последовательности действий в промышленных протоколах, если такие данные поступают от ICS/OT-сенсоров.

UEBA как дополнение к SIEM и ICS/OT-мониторингу

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

UEBA хорошо ложится именно в эту архитектуру, но не заменяет её базовые элементы. Если нет событий, нет модели активов, нет данных от jump-серверов, VPN, PAM, инженерных станций, промышленных сенсоров и систем заявок, то поведенческому анализу просто не на чем строить выводы.

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

Класс решения	Что даёт в АСУ ТП	Ограничение
ICS/OT Monitoring	Видит технологическую сеть: активы, промышленные протоколы, команды, взаимодействия, изменения поведения оборудования	Сам по себе не всегда связывает событие с ИТ-контекстом, учётными записями, заявками и процессами SOC
SIEM	Собирает события из разных источников, коррелирует их, помогает расследовать инциденты, вести учёт, отчётность и управление реагированием	Анализирует то, что в неё поступило. Если в АСУ ТП нет источников и OT-контекста, SIEM видит только часть картины
UEBA	Ищет отклонения от нормального поведения пользователей и сущностей, повышает приоритет событий, помогает выявлять злоупотребления легитимным доступом	Не заменяет источники данных, SIEM и промышленную видимость. Требует истории, качества данных и аккуратной настройки моделей поведения

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

В чём ценность UEBA именно для АСУ ТП

1. Видеть злоупотребление легитимным доступом

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

UEBA помогает заметить, что разрешённый доступ начал использоваться не так, как обычно: другой маршрут, другое время, другой набор активов, другая последовательность действий, обращение к оборудованию вне зоны ответственности.

2. Находить слабые сигналы, которые не попадают в классические правила

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

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

3. Снижать нагрузку на локальные площадки

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

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

4. Работать в условиях узких каналов связи

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

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

5. Приоритизировать инциденты для SOC

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

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

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

Кейс 1. Подрядчик вышел за рамки согласованных работ

Подрядчику выдали удалённый доступ для обслуживания оборудования на конкретном участке. Вход выполнен через разрешённый VPN, учётная запись известна, доступ согласован. С точки зрения отдельного события всё выглядит нормально.

Но UEBA видит отклонение: подрядчик обычно работает днём, через один jump-сервер и с ограниченным набором инженерных станций. В этот раз подключение происходит поздно вечером, после входа появляется обращение к другой инженерной станции, а затем фиксируется взаимодействие с контроллером, который не входил в согласованный объём работ.

SIEM связывает эту цепочку с заявкой, данными VPN/PAM и событиями OT-сенсора. UEBA повышает риск, потому что поведение подрядчика не соответствует его обычному профилю и регламенту работ. Аналитик получает не набор разрозненных событий, а понятный вопрос для проверки: почему подрядчик работал с чужим участком и было ли это согласовано.

Кейс 2. Сервисная учётная запись начала вести себя как пользователь

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

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

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

Кейс 3. Инженерная станция начала работать с новым сегментом

Инженерная станция обычно используется для обслуживания определённого участка. Её сетевые взаимодействия стабильны: известные контроллеры, привычные протоколы, понятный график активности.

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

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

Кейс 4. «Разрешённое» изменение в неправильном контексте

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

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

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

SIEM + UEBA на одной платформе или отдельная UEBA?

На практике встречаются два подхода. Первый — когда UEBA является модулем или встроенной функцией SIEM-платформы. Второй — когда используется отдельное полноценное UEBA-решение, интегрированное с SIEM, источниками данных и процессами SOC.

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

Подход	Когда подходит	Сильные стороны	Ограничения
SIEM с UEBA-модулем	Когда уже есть SIEM как центральная система мониторинга, а организации нужно усилить корреляцию поведенческими признаками без отдельного сложного проекта	Единая платформа, меньше интеграций, единый интерфейс для SOC, быстрее запуск типовых сценариев, проще связать UEBA-сигналы с инцидентами SIEM	Глубина моделей может быть ограничена возможностями платформы. Сложные промышленные сценарии всё равно потребуют качественных источников и настройки под площадки
Отдельная UEBA	Когда инфраструктура крупная, источников много, требуется глубокая аналитика поведения пользователей, сущностей, групп, площадок и сложных цепочек действий	Более гибкие модели поведения, развитая риск-оценка, расширенная аналитика сущностей, больше возможностей для сложных сценариев и расследований	Выше требования к качеству данных, интеграциям, команде эксплуатации и процессам. Может потребоваться отдельный проект внедрения и настройки

Для многих организаций разумный путь — начать с UEBA-возможностей внутри SIEM или XDR/SOC-платформы, если они уже есть, и проверить ценность на нескольких понятных сценариях: подрядчиках, удалённом доступе, инженерных станциях, сервисных учётных записях, изменениях в контроллерах. Если сценарии подтверждают ценность, а данных и задач становится больше, можно рассматривать отдельную UEBA как следующий уровень зрелости.

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

Какие данные нужны для UEBA в АСУ ТП

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

• учётные записи и события аутентификации (AD, LDAP, локальные учётные записи, привилегированный доступ);
• VPN, PAM, jump-серверы и удалённый доступ подрядчиков;
• события инженерных станций, HMI/SCADA и серверов технологического сегмента, если их можно безопасно собирать;
• события ICS/OT-сенсоров (активы, протоколы, команды, сетевые взаимодействия, изменения);
• информация о технологических окнах, плановом проведении работ (ППР), заявках на изменение и согласованных работах;
• модель активов (площадки, участки, критичность, принадлежность оборудования, зоны ответственности);
• сведения о штатных ролях (инженеры, администраторы, подрядчики, смены, группы сопровождения);
• данные SIEM и SOC (алерты, инциденты, история расследований, исключения и подтверждённые ложные срабатывания).

Чем лучше описаны роли, активы и регламенты, тем полезнее UEBA. Без этого система будет видеть отклонения, но не всегда сможет отличить риск от нормальной производственной особенности.

Как внедрять UEBA в промышленной среде

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

Понять, какие данные уже есть в SIEM, а каких данных не хватает. Возможно, сначала нужно подключить OT-сенсор, jump-сервер, PAM или систему заявок.

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

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

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

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

Оценивать качество не количеством алертов, а пользой для расследований. Хорошая UEBA должна помогать найти важное отклонение быстрее, а не просто создавать ещё один поток событий.

Где UEBA может не сработать

У UEBA есть ограничения, и их лучше проговаривать заранее. Это не самостоятельная система защиты АСУ ТП и не замена инженерной экспертизы. Поведенческая аналитика хорошо работает там, где есть история, качественные источники данных и понятный контекст.

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

Поэтому UEBA должна внедряться аккуратно: через понятные сценарии, совместно с эксплуатацией, с постепенной настройкой профилей и риск-оценки.

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

Для CISO ценность UEBA в АСУ ТП не в том, что появляется ещё один класс продукта. Ценность в том, что организация начинает видеть отклонения в поведении людей и систем, которые раньше могли теряться среди штатных операций.

UEBA помогает ответить на вопросы, которые важны для управления рисками:

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

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

Вывод

UEBA в АСУ ТП — это не замена SIEM и не альтернатива ICS/OT-мониторингу. Это дополнительный аналитический слой, который помогает понять, когда привычные на первый взгляд действия начинают выбиваться из нормального поведения.

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

Зрелая архитектура выглядит так: ICS/OT-мониторинг даёт промышленную видимость, SIEM объединяет события и управляет инцидентами, UEBA выделяет нетипичное поведение и помогает SOC быстрее понять, где действительно есть риск.

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

Автор: Сергей Скородумов, руководитель отдела систем мониторинга и реагирования Angara Security