ИИ-помощник PT Naira в MaxPatrol SIEM: почему аналитик перестал искать и начал спрашивать

Аналитики SOC — неважно, работают ли они в большой команде или в маленькой — регулярно говорят мне, что видят все срабатывания корреляционных правил, но не успевают в них разобраться. И это не значит, что они плохо работают. SOC в крупной организации фиксирует более 10 000 срабатываний в день, и физически невозможно для каждого из них вручную поднять контекст, свериться с базой знаний и принять решение. В таких условиях нерасследованными остаются почти две трети срабатываний, в большинстве своем — те, которым присвоены невысокие уровни значимости. Это позволяет злоумышленнику «замаскироваться под фон». Когда мы в Positive Technologies моделировали поведение инсайдера в корпоративной инфраструктуре, традиционная система, построенная на сигнатурах и корреляционных правилах, выдала лишь три алерта с уровнями значимости medium и low.

Чтобы в подобных ситуациях не упускать важные события и корректно присваивать им уровни риска, в MaxPatrol SIEM встроен модуль поведенческого анализа MaxPatrol BAD. Но сам факт того, что событие не затерялось в потоке, ещё не снимает с аналитика необходимость разобраться в нём. Вот в этой точке — между «система что-то нашла» и «специалист понял, что перед ним» — и лежит разрыв, который мы решили закрывать с помощью ИИ.

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

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

Поэтому мы пошли на более глубокий уровень: LLM, развернутая в нашем контуре, и собственное железо в наших дата-центрах. При этом мы ответственно подходим к выбору модели. Мы регулярно тестируем актуальные открытые модели именно на наших задачах — разборе процессов, выполняемых команд, корреляций, — берем ту, что на показывает лучший результат конкретно на них. А затем — снабжаем её экспертизой Positive Technologies: о том, как выглядит легитимная и нелегитимная активность, о специфике MaxPatrol SIEM. Это и есть, на моей взгляд, наш реальный дифференциатор: не просто собственная инфраструктура, но и опыт на стыке ИИ и информационной безопасности.

Подход, который мы выбрали, определило архитектуру решения: MaxPatrol SIEM работает on-prem, у клиента, а сам ИИ-ассистент — в защищённом облаке Positive Technologies, с которым MaxPatrol SIEM обменивается данными по контролируемому каналу.

Примеры на практике

Работу PT Naira проще всего показать на конкретных примерах — тех самых, что мы проверяли во время тестирования с реальными аналитиками.

Интерфейс при этом остаётся привычным. Открывается MaxPatrol SIEM, список событий, карточка события — всё как обычно. Разница в том, что теперь в карточке есть меню ассистента: можно выбрать готовую команду («объяснить событие», «описать процесс») или просто написать вопрос в свободном чате.

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

eval $(printf '\x70\x6f\x77\x65\x72\x73\x68\x65\x6c\x6c') 
-Command "$([Text.Encoding]
::UTF8.GetString([Convert]
::FromBase64String('R2V0LVByb2Nlc3MgTFNBU1MgfCBPdXQtTnVsbA==') ) )"

Ассистент проводит деобфускацию и объясняет, что происходит в командной строке, за секунды — в нашем случае это оказалась попытка обратиться к LSASS через PowerShell, то есть довольно однозначный признак кражи учётных данных.

Похожая история — с процессами, которые сами по себе выглядят безобидно. Например, запуск утилиты из стандартной поставки Windows: её название ничего не говорит о том, что именно происходит в системе. Пример атаки Living off the Land:

{
    "event_src.ip": "192.168.0.111",
    "object.process.name": "esentutl.exe",
    "object.process.fullpath": "c:\\windows\\temp\\esentutl.exe",
    "object.process.chain": "esentutl.exe ← cmd.exe ← powershell.exe",
    "object.process.cmdline": 
"\"C:\\Windows\\Temp\\esentutl.exe\" /y \"C:\\Windows\\System32\\config\\SAM\" /d \"C:\\Users\\Public\\SAM.copy\" /o",
    "object.process.guid": "99bdc6a8-ac71-6a26-f501-000000004104",
    "object.process.hash.md5": "5C3C4D8D4B9B8A7D6F5E4D3C2B1A0987",
    "object.process.meta": 
"Description: Extensible Storage Engine Utilities | 
Product: Microsoft® Windows® Operating System | 
Company: Microsoft Corporation",
    "object.process.parent.fullpath": "c:\\windows\\system32\\cmd.exe",
    "object.process.parent.guid": "99bdc6a8-aac8-6a26-0a00-000000004103",
    "object.process.parent.name": "cmd.exe"
}

Но если попросить объяснить не сам процесс, а контекст вокруг него — путь запуска, цепочку родительских процессов — картина меняется: запуск из временной директории, двойная вложенность оболочек. Легитимная утилита оказывается инструментом Living off the Land, который атакующий использует, чтобы обойти защиту.

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

А теперь вернёмся к кейсу с инсайдером из первого раздела. Напомню: MaxPatrol BAD выдал алерт с оценкой риска “100” и десятком сработавших поведенческих моделей. Разобрать такую карточку руками можно — но это те самые минуты на каждое событие, о которых я говорил.

Здесь и проявляется синергия инструментов: MaxPatrol BAD находит аномалию, которую пропускают сигнатурные правила, а PT Naira —  раскладывает её на понятную историю: объясняет цепочку запуска процессов, даёт оценку подозрительности каждого шага и, если активность действительно похожа на атаку, — рекомендации, что делать дальше.

Отдельная история — подключение новых источников событий. Когда в SIEM приходит сырое событие в JSON, его нужно разложить по полям — написать правило нормализации. Ресурсы на это всегда ограничены: невозможно вручную покрыть правилами каждый источник. Ассистент сначала объясняет, что вообще произошло в событии и какие в нём ключевые сущности, — это помогает решить, стоит ли вообще собирать такой источник в SIEM.

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

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

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

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

За время предварительного тестирования более 250 аналитиков задали PT Naira больше 3500 запросов. Это подтвердило, что ассистентом активно пользуются, но нам хотелось подробнее узнать впечатления пользователей. Во время интервью, которые мы провели с участниками тестирования, мы услышали, что PT Naira заняла своё место в повседневной работе аналитиков. Люди не просто отмечали, что ассистент, например, помогает разбирать скрипты, а описывали свои ощущения: «не нужно переключаться между вкладками», «дописать правило проще, чем писать с нуля», «сразу видно, что требует больше внимания».

PT Naira не отбирает у аналитика его работу и ответственность. Финальное решение — расследовать инцидент дальше или закрыть как ложное срабатывание, дописать правило нормализации и принять его — по-прежнему остаётся за человеком. И, на мой взгляд, это и есть правильное место для ИИ в SOC: не вместо аналитика, а между ним и тем объёмом рутины, который раньше отнимал время у решений.

Что нужно, чтобы это заработало у себя

PT Naira доступна в MaxPatrol SIEM начиная с версии 27.6. Соответственно, первый шаг — обновить до этой версии или выше. Дальше нужен доступ к update.ptsecurity.ru — через него идёт обмен между вашим on-prem контуром и облачной частью ассистента, о которой я писал во втором разделе.

Второе — лицензия. Её нужно получить и обновить внутри продукта.

Третье — загрузить и установить шаблон кастомизируемой карточки события. Именно через неё в интерфейсе появляется меню ассистента и доступ к готовым командам («объяснить событие», «описать процесс» и так далее), о которых шла речь в третьем разделе.

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

Итог

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

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

Важно здраво оценивать способности PT Naira. Ассистент не расследует инциденты и не пишет финальные правила — он снимает первый, самый трудозатратный слой работы и передает человеку уже подготовленный контекст. Решение — закрыть срабатывание как ложное или эскалировать, принять правило нормализации или доработать — по-прежнему принимает аналитик. И, честно говоря, я не вижу в этом ничего, что стоило бы менять: место ИИ здесь — не вместо экспертизы, а рядом с ней, там, где раньше был только объём.