Системы обнаружения вторжений переходят от почти полной зависимости от известных сигнатур к гибридной архитектуре, объединяющей традиционное сопоставление, машинное обучение и агентное расследование. Согласно анализу, опубликованному в блоге Stack Overflow, SnortML представляет собой низкоуровневый сенсорный слой внутри Snort 3, тогда как агентный искусственный интеллект связывает события во времени и между источниками и определяет следующий шаг расследования.
Проблема традиционных сигнатур заключается не в их неточности, а в том, что они точны относительно того, для обнаружения чего были разработаны. Специализированное правило для конкретной уязвимости, например CVE-2024-12345, может обнаруживать известную эксплуатацию с очень низкой частотой ложных срабатываний, но не реагировать на изменённую полезную нагрузку, проходящую через тот же уязвимый программный путь. Между появлением новой эксплуатации в реальных атаках, её анализом, написанием правила, его тестированием и распространением могут пройти дни или недели — опасный разрыв, когда уязвимость уже активно эксплуатируется.
Как SnortML работает внутри Snort 3?
Компания Cisco Talos представила движок SnortML в марте 2024 года как встроенный в Snort 3 механизм обнаружения на основе машинного обучения. Движок не зависит от внешнего облачного сервиса: вывод выполняется локально в том же конвейере обработки, который используется для оценки правил, и выдаёт результат менее чем за одну миллисекунду.
Реализация состоит из модуля snort_ml_engine, который загружает предварительно обученные модели TensorFlow при запуске, и инспектора snort_ml, получающего данные от имеющихся инспекторов служб Snort 3 через интерфейс публикации и подписки. Когда инспектор HTTP завершает анализ запроса, он отправляет строку запроса и содержимое POST в шину событий; затем SnortML классифицирует их и возвращает вероятностное значение, указывающее на вероятность наличия попытки эксплуатации.
Модель основана на сети LSTM, которой предшествует слой встраивания, преобразующий необработанные значения байтов в векторные представления. Это позволяет фиксировать отношения и контекст между байтами, после чего LSTM обрабатывает их порядок и последовательность. Итоговый полносвязный слой сводит результат к одному вероятностному значению. LibML, поставляемая вместе с SnortML, использует библиотеку XNNPACK для ускорения матричных операций. Согласно материалу, одна операция классификации занимает около 350 микросекунд на процессоре AMD с частотой 4,7 ГГц.
Начиная с Secure Firewall 10.0.0 SnortML автоматически выбирает подходящую модель для длин 256, 512 или 1024 байта. Запросы длиной более 1024 байт перед классификацией обрезаются до этого предела. Первый выпуск обеспечивал обнаружение SQL-инъекций, а к концу 2025 года покрытие расширилось и включило XSS и инъекции команд. Обновления моделей поступают через ту же систему Lightweight Security Package, которая используется для распространения содержимого правил.
Сильные стороны и ограничения гибридного подхода
SnortML работает параллельно с сопоставлением сигнатур, а не вместо него. Модель способна обнаруживать новые варианты атак, относящихся к известным категориям, тогда как традиционные сигнатуры обеспечивают малошумный канал для подтверждённых шаблонов. Когда оба механизма выдают предупреждение для одной и той же полезной нагрузки, это можно считать более сильным сигналом, чем предупреждение, сформированное только машинным обучением, при этом каждый механизм сохраняет собственные характеристики ошибок.
Однако SnortML анализирует отдельный параметр HTTP, например строку URI-запроса или содержимое POST, и не знает, что происходило до запроса или после него и что делал исходный адрес в предыдущие минуты. Поэтому последовательность разведки, затем перечисления и затем целевой эксплуатации может пройти незамеченной, если ни один отдельный шаг не превысит порог обнаружения. Кроме того, текущая модель не видит DNS-туннели, атаки на уровне TLS, эксплуатацию SMB или аномальное поведение в протоколах, отличных от HTTP, поскольку доступные модели связаны с конвейером данных инспектора HTTP.
Время обработки около 350 микросекунд также создаёт реальную нагрузку, хотя она ограничена и предсказуема благодаря XNNPACK. Поэтому производительность модели не следует рассматривать в отрыве от размера набора правил, сложности протоколов и вычислительного бюджета защитного устройства.
Что добавляет агентный искусственный интеллект?
В анализе различаются модель машинного обучения, оценивающая только то, что находится перед ней, рабочий процесс SOAR, следующий фиксированным шагам, и агент, сохраняющий состояние многоэтапного расследования и решающий, что следует проверять дальше на основании предыдущих результатов. Согласно предложенной концепции, агент может запрашивать в SIEM связанные события, проверять отпечаток файла через платформу анализа угроз, извлекать активность пользователя у поставщика удостоверений, а затем собирать контекст перед рекомендацией ответных действий или передачей дела аналитику.
В статье упоминаются запуск компанией IBM платформы ATOM, или Autonomous Threat Operations Machine, в апреле 2025 года и запуск компанией Trend Micro платформы Agentic SIEM в августе 2025 года. Эти системы представлены как платформы координации и многоагентного расследования, а не просто как чат-интерфейсы, снабжённые сведениями о безопасности. Анализ связывает их распространение с нехваткой специалистов: в нём упоминается глобальный дефицит, составляющий около четырёх миллионов незаполненных вакансий в сфере кибербезопасности, а также опрос 2025 года, согласно которому 82% аналитиков центров управления безопасностью опасаются пропустить реальные угрозы из-за объёма оповещений.
В такой архитектуре Snort 3 и SnortML становятся сенсорами, расположенными близко к сети, и передают фактически наблюдавшиеся данные на вышестоящий уровень вывода. Однако повышение уровня автоматизации делает точность сенсора более важной: ложное срабатывание не только отнимает время аналитика, но и расходует ресурсы агентов и может запустить действия по изоляции в плохо настроенных средах. Вероятностный результат SnortML также позволяет формировать составную оценку уверенности: к предупреждению, объединяющему традиционную сигнатуру и оценку ML 0,97, следует относиться иначе, чем к предупреждению, выданному только ML с оценкой 0,61.
Архитектура интеграции и проблема петли обратной связи
В статье предлагается архитектура, начинающаяся со слоя захвата пакетов через DAQ с использованием AFPacket RSS или DPDK в зависимости от требований к производительности, затем следует слой обнаружения, который параллельно запускает движок MPSE Hyperscan и SnortML. Оба слоя отправляют события в формате JSON, содержащие оповещения, вероятностные оценки и данные потоков, в единую шину телеметрии.
Затем задачи распределяются между специализированными агентами: агентом сортировки, удаления дубликатов и оценки риска; агентами обогащения и анализа угроз; агентом расследования, связывающим журналы SIEM, поставщика удостоверений и данные конечных точек; и контекстным агентом, сравнивающим активность с историческими шаблонами и известными кампаниями. Концепция подчёркивает необходимость возвращать результаты подтверждённых расследований в движки моделей и правил, а не прекращать поток на этапе реагирования.
Полезные нагрузки, которые были подтверждены как атаки, но получили низкую оценку или не совпали ни с одной сигнатурой, могут быть преобразованы в обучающие данные или использованы как исходные данные для создания новых правил. Однако этот процесс требует проверки человеком и механизмов обнаружения отравления обучающих данных: злоумышленник может попытаться манипулировать результатами автоматического расследования, чтобы внедрить испорченные образцы в процесс повторного обучения.
Ограничения развертывания и практические рекомендации
В анализе отмечаются и другие пробелы, включая ограничение текущего покрытия SnortML параметрами HTTP, недостаточную зрелость протоколов координации агентов и низкую объяснимость предупреждений модели. Текущие результаты показывают вероятностную оценку и полезную нагрузку, вызвавшую предупреждение, но не объясняют, какие байты или области входных данных повлияли на результат. Кроме того, согласно материалу, устойчивость модели к обфускации, кодированию, манипуляциям с пробелами и внедрению комментариев SQL публично не описана в опубликованных оценках.
Практически статья рекомендует начать работу SnortML на порту мониторинга и в режиме только оповещения, а не в прямом потоке с блокировкой. Следует измерять количество ложных срабатываний на трафике известных приложений как минимум в течение двух недель, охватывающих обычные рабочие циклы, а затем настроить пороговые значения перед активацией выборочного развертывания inline. Кроме того, оценку ML следует рассматривать как один из факторов в составе комплексного расчёта достоверности, а не как замену традиционной сигнатуре или самостоятельный триггер блокировки.
Что касается мер сдерживания, имеющих значительное воздействие, таких как блокировка IP-адресов, изоляция устройств или сброс учётных данных, они должны оставаться в рамках проверки человеком. Основной вывод анализа заключается в том, что автоматизация может интенсивно выполнять сортировку, обогащение, сопоставление и сбор контекста, тогда как окончательное решение о реагировании остаётся более безопасным, когда его проверяет человек на основании контекста, собранного агентом.