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

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

Что произошло

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

Авторы материала описывают сдвиг от классического контроля по правилам к поведенческой аналитике. Системы на базе AI/ML анализируют телеметрию, логи и сетевую активность, чтобы заметить аномалию раньше, чем она превратится в простой оборудования или инцидент.

Как это работает

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

Такой подход особенно полезен там, где сигнатуры бессильны против новых эксплойтов и атаки нулевого дня. В статье отдельно подчеркивается, что AI/ML может заметить тонкие изменения в поведении ПЛК, необычные команды или нетипичный трафик между устройствами одного класса.

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

Но у медали есть оборотная сторона. Слишком чувствительная модель начнет сыпать ложными тревогами, слишком грубая — пропустит атаку. Поэтому в промышленной среде любая AI/ML-система требует тонкой настройки и постоянной проверки.

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

Кого это затрагивает и какие риски остаются

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

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

Еще одна проблема — усталость от алертов. Если система видит слишком много ложных срабатываний, команда перестает доверять уведомлениям, а это уже прямой путь к пропущенному инциденту.

При этом AI/ML не отменяет классическую защиту. Наоборот, он лучше работает как слой поверх нормального сегментирования сети, строгого контроля доступа и понятной модели угроз.

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

Что делать сейчас

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

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

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

Практический чек-лист

  • Проверьте, какие устройства в вашей сети вообще пишут логи и как долго они хранятся.
  • Сравните, есть ли у вас базовая линия нормального поведения для ключевых сегментов.
  • Убедитесь, что оповещения не перегружены ложными тревогами.
  • Отдельно оцените устаревшие ПЛК и SCADA: что они могут, а что уже не контролируют.
  • Разделите доступы между ИТ, ИБ и инженерами, чтобы анализ инцидентов не зависел от одного человека.
  • Для рабочих устройств и поездок заранее продумайте защиту переписки и файлов от перехвата.
Поделиться: