MLEP в KICS for Networks 5.0: как машинное обучение помогает отслеживать сетевое поведение OT-устройств

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

При этом зачастую данные инвентаризации активов предприятия оказываются неполными, что затрудняет своевременное обнаружение несанкционированных подключений. Допустим, мониторинг обнаруживает узел, который регулярно обменивается данными с программируемыми логическими контроллерами (ПЛК). Его IP-адрес известен, но инвентаризация не дает ответа, какую роль он выполняет: это инженерная станция, сервер технологических данных или оборудование подрядчика? Кроме того, узел мог работать в промышленной сети давно, а сведения о нем — устареть после ее модернизации.

В совместных рекомендациях по инвентаризации OT-активов, выпущенных CISA и партнерами в 2025 году, инвентаризация и классификация устройств по их роли рассматриваются как часть управления OT-активами (Asset Management). С точки зрения предприятий это направление — одно из наиболее важных: согласно опросу SANS о безопасности АСУ ТП в 2025 году, за предыдущие 12 месяцев 50% респондентов внедрили или существенно расширили средства инвентаризации и видимости АСУ ТП, а 54% включили их в инвестиционные приоритеты на следующие 12–24 месяца.

Инвентаризация устройств в Kaspersky Industrial CyberSecurity for Networks

В Kaspersky Industrial CyberSecurity for Networks основу видимости активов создает технология Asset Discovery. Пассивный анализ сетевого трафика обнаруживает устройства и их взаимодействия, а правила распознавания помогают определить категорию устройства и извлечь доступные сведения о нем, например производителя, модель или версию ПО и так далее. Какие именно атрибуты удастся получить, зависит от протокола и наблюдаемого обмена. Подробнее мы рассказывали об этом на Kaspersky Industrial Cybersecurity Conference.

Сведения об оборудовании и ПО в карточке устройства

Кроме того, продукт поддерживает модули активного опроса (МАО): там, где опрос допустим, они могут запросить у устройств дополнительные сведения о конфигурации и версии прошивки. Такая инвентаризация гораздо подробнее списка IP-адресов.

Состав и размещение модулей в корзине ПЛК

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

Устройства, категории которых не удалось определить

Когда прямых сведений об устройстве недостаточно, его категорию можно уточнять по характеру повторяющихся сетевых взаимодействий. На анализе этих взаимодействий специализируется сервис Machine Learning Event Processor (MLEP), входящий в версию Kaspersky Industrial CyberSecurity 5.0, — процессор событий на основе машинного обучения, который можно использовать как для уточнения категорий устройств, так и для выявления аномалий в их сетевом поведении.

Какие данные используются для анализа в MLEP

Чтобы сравнивать поведение устройств, не обязательно хранить каждый пакет как отдельное наблюдение (observation, объект данных) в ML-модели. В MLEP сетевые сессии представляются последовательностью коротких, 15-секундных фрагментов. Для каждого из них сохраняются сведения об участниках (IP, MAC, порт) и направлении обмена данными, протоколе, количестве и размерах переданных пакетов — что составляет событие, которое дополняется меткой времени. Таким образом, поток трафика превращается в последовательность событий, на основе которых можно проследить, с какими узлами связывалось устройство, когда это происходило и как менялась интенсивность коммуникаций.

Агрегация данных в события одновременно задает границу метода. По обобщенному фрагменту нельзя восстановить точный порядок отдельных пакетов или содержание команд. Например, сделать вывод о новом протоколе MLEP сможет, только если удалось его распознать при помощи другой технологии KICS. Зато для сравнения устойчивых сетевых связей и изменений объема обмена подробная запись каждого пакета не требуется. Эти наблюдения становятся основой поведенческой истории устройства.

От наблюдений к результату MLEP

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

Поясним, как это работает в MLEP, который построен на основе импульсной нейросемантической сети (NSN).

Идентификация событий

В нейросемантических сетях информация структурируется в виде многослойного упорядоченного графа, где данные в каждом последующем слое основываются на данных предыдущего. В роли нейронов выступают узлы этого графа, то есть единицы информации каждого слоя. Для работы с разными параметрами событий (порт, IP и т. д.) в NSN создаются соответствующие каналы. Уникальные значения параметров по каждому каналу сохраняются в виде нейронов нулевого слоя. Само событие, состоящее из набора значений параметров, сохраняется в виде нейрона на первом слое сети. Если событие случается в первый раз, за счет нейрогенеза создается новый нейрон, с входными связями к соответствующим нейронам параметров. Это позволяет сети обучаться и одновременно работать на потоке событий. Если же событие случается не в первый раз, то активируется именно тот нейрон, который был создан при его первом появлении. Таким образом сеть точно идентифицирует каждое событие. Причем каждый нейрон, соответствующий событию, копит базовую статистику: когда он активировался в последний раз и сколько раз он активировался.
 

История событий

Хранение последовательностей событий во времени — повторяющихся паттернов и всей истории — в задачах обработки событий с помощью NSN происходит на последующих (втором и выше) слоях сети. Однако для решения задач категоризации и выявления статистических аномалий не требуется сохранять полную последовательность пакетов или подробную хронологию каждого сетевого события. Как мы уже отмечали, сами события — агрегаты, то есть порядок следования сетевых пакетов уже усреднен. Поэтому в работе MLEP используется только временное хранение истории в рамках каждого эпизода (по умолчанию эпизод включает 30 тысяч агрегатов) — это позволяет экономить вычислительные ресурсы.

Обработка статистики в MLEP

Основной механизм обработки статистики в MLEP — специализированные нейроны-слушатели на –1-м (минус первом) слое сети. На основе таких нейронов работают головы внимания и мониторы.

Основные компоненты нейросемантической сети NSN

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

Сеть называется импульсной, поскольку информация об активации — это импульс, а не число. Этот импульс «говорит» голове, что случилось что-то, в чем она заинтересована.

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

Головы внимания работают очень похоже на семантику обычного человеческого языка. В запросе есть предмет внимания (подлежащее или несколько подлежащих) и условия (другие члены предложения). В контексте инфраструктуры предприятия «подлежащие» — это устройства в сети, а условия — различные аспекты сетевого взаимодействия, например адреса портов, протокол, средний размер пакета. Если «подлежащих» много, например, голова «интересуется» всеми устройствами в промышленной сети, то на каждое отдельное значение предмета внимания (на каждое отдельное устройство) она создает дочернюю голову (Fun-out). И уже дочерняя голова «следит» за конкретным устройством и рапортует родительской голове.

Головы внимания не копят и не обрабатывают статистику. Они лишь фильтруют потоки событий. Когда голова внимания получает нужное событие, она сама активируется и посылает импульс (spike) монитору, который подписан на эту голову.

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

Мониторы бывают разных типов:

• Стат-мониторы, которые реагируют на изменения средних значений количества определенных событий (например, активности устройств) за характерные для этих событий интервалы времени или же на изменения средних значений численных параметров событий (например, как меняется объем трафика от устройств).
• Мониторы, которым достаточно информации от самого события: что оно случилось сколько-то раз за определенный интервал времени или случилось впервые.
• Мониторы похожего поведения — мониторы, которые работают с головами, способными обобщать события — выделять из них только несколько параметров, сочетание которых будет общим (generalized) для многих событий.

С помощью таких типов мониторов в MLEP реализуются сценарии для категоризации устройств и определения их аномального поведения:

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

   Группы устройств со сходным сетевым поведением

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

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

Текущую версию MLEP мы поставляем с преднастроенными головами и мониторами.

Функциональная динамическая схема работы с событиями от устройств в промышленной сети представлена ниже.

Схема обработки событий (нажмите для воспроизведения)

Применение MLEP на практике: как поведение помогает дополнить инвентаризацию

На предприятии с несколькими однотипными технологическими линиями полнота сведений об устройствах на разных линиях может различаться. На одной линии устройства определены как ПЛК, а на другой после модернизации часть узлов видна только по адресам: сведений из доступного трафика не хватило для определения категории. Тем не менее устройства участвуют в обмене с теми же типами HMI и серверов сбора технологических данных. Направления, периодичность и объемы коммуникаций могут быть похожими.

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

Категория устройства, предложенная MLEP

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

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

Отображение предложений MLEP в списке устройств

Аномальная активность и статистика на потоке

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

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

В первой версии MLEP преднастроены шесть мониторов по типам отклонений от привычного сетевого профиля устройства:

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

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

Карточка аномалии «Нетипичное время активности»

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

Заключение

В промышленной сети определение аномальности поведения зависит от того, на каком узле оно возникло и какое место этот узел занимает в технологическом процессе. Повторяемость многих коммуникаций помогает заметить перемену в привычном обмене данными, сведения о функции и критичности устройства — понять возможные последствия. Когда эти наблюдения рассматривают вместе, сетевой трафик дает больше, чем перечень соединений: он помогает оценивать новые события в контексте конкретного объекта, даже без заранее известного сценария атаки. Такой комплексный анализ хорошо выполняют технологии машинного обучения, способные обработать и систематизировать огромные потоки неоднородных данных. В Kaspersky Industrial CyberSecurity for Networks, начиная с версии 5.0, эту функцию берет на себя технология MLEP, эффективно работающая в связке с уже имеющейся в продукте функциональностью.