Как мы научили нейросеть распутывать цепочки атак в SOC
Представьте суточный конвейер работы центра мониторинга безопасности.
В понедельник аналитик первой смены разбирает заражение через почту: пользователю прилетело письмо с вложением, антивирус сработал, в логах — подозрительный файл и странный процесс.
В среду другой аналитик, уже из следующей смены, получает алерт от NGFW: зафиксирована передача вредоносного файла с этого же хоста куда‑то наружу.
Оба специалиста действуют по регламенту, аккуратно закрывают свои алерты и переходят к следующим задачам. Но никто из них не замечает, что перед ними — два эпизода одной и той же атаки. Ключевая улика спрятана в глубине текстового описания: хитрое имя сигнатуры и пара «ненужных» на первый взгляд строк. Они не лежат в отдельном поле, не попадают в фильтры и отчёты — просто утонули в «простыне» текста.
Так рождается цифровой туман: данные вроде бы есть, но собрать их в понятную картину атаки практически нереально.
Почему привычная автоматизация пасует
На первый взгляд задача кажется очевидной: есть артефакты — IP, хостнеймы, хеши файлов, пути, сигнатуры атак. Совпадают артефакты в двух алертах — есть высокая вероятность связи. Значит, пишем скрипт, который ищет совпадения, и готово?
На практике всё рушится о реальный формат данных.
Проблема 1. Одинаковые сущности, разные строки
Вы внедряете простой поиск совпадений по именам хостов — и почти сразу выясняете, насколько хаотично системы представляют одни и те же объекты:
- в одном алерте: `SRV-DB01`, в другом — `srv-db01`;
- одна система пишет `hostname.corp.local`, другая — просто `hostname`;
- где‑то затесался лишний пробел;
- иногда в конце добавляют суффиксы, теги, метки среды.
Для человека всё очевидно: это один и тот же сервер. Для скрипта с проверкой `if str1 == str2` — два разных мира. Значительная часть потенциальных связей исчезает уже на этом уровне.
Похожие проблемы и с другими полями:
скрипт не понимает, что `HOSTNAME` и `hostname.corp.local` — по сути одно и то же, не умеет «нормализовать» формат, не различает контекст.
Проблема 2. Важное спрятано в неструктурированном тексте
Самые ценные улики зачастую живут не в аккуратных колонках, а в комментариях:
- заказчик: «Пользователь заметил странное поведение на хосте srv-app03 и получил файл invoice_new.docx»;
- аналитик: «Проверил хост, нашёл подозрительный процесс с IP 192.168.1.100, файл скачан из браузера».
Там же появляются домены, внутренняя нумерация систем, имена пользователей, артефакты из почтовых заголовков, фрагменты путей.
Вытащить всё это регулярками надёжно и без ложных срабатываний почти нереально:
одна опечатка — и вы пропускаете важный IP; одно слишком общее правило — и вы захламляете базу «артефактами», которые к делу не относятся.
В итоге мы имеем:
- алерт с формальными полями (источник, приёмник, тип события);
- огромный, крайне полезный контекст в описании;
- и при этом практически неизбежную потерю данных при автоматической обработке.
Проблема 3. Разная логика связей в разных типах атак
Даже если у нас гипотетически есть идеальная система извлечения артефактов, этого всё равно мало. Связи между событиями зависят от типа атаки.
Пример с подбором паролей:
- brute force: один IP, одна учётка, один хост; злоумышленник просто перебирает пароли;
- password spray: один популярный пароль против множества разных учётных записей и иногда разных сервисов, часто с одного IP, но не всегда.
Если сравнивать только IP-адрес, мы:
- пропустим серию brute force, где атакующий меняет адреса, но бьёт по одной и той же учётке;
- объединим несвязанные попытки password spray в один инцидент только потому, что совпал источник.
Если смотреть только на логины — наоборот, размажем одну сплошную атаку по десяткам разрозненных алертов.
Так и формируется цифровой туман:
аналитики видят десятки словно не связанных между собой событий, смены сменяют друг друга, описания пишутся разными людьми в разном стиле, а общая логика атаки теряется.
Почему мы пошли в сторону LLM
Нам нужно было лекарство от этого тумана: систему, которая умеет:
- понимать текст описаний и комментариев;
- находить сходства между инцидентами, даже если поля формально не совпадают;
- группировать события в логические цепочки атак;
- и при этом оставаться инструментом, а не «чёрным ящиком, который что‑то там нагенерил».
Мы решили рискнуть и построить механизм поиска неочевидных связей на базе большой языковой модели (LLM). Но сразу заложили важное ограничение: финальное решение принимает человек, а нейросеть — только помощник, рекомендательная система.
В качестве максимально жёсткого теста мы выбрали для валидации человека, который честно называет себя «одним из главных хейтеров LLM и нейросетей». И задачей было не «впечатлить» его красивой демкой, а добиться признания простого факта: да, в таком виде это действительно помогает SOC и не ломает рабочие процессы.
Архитектура цифрового сыщика
Чтобы нейросеть перестала быть просто «умным чат‑ботом» и стала инструментом расследования, мы выстроили целую архитектуру вокруг неё. В упрощённом виде она состоит из пяти шагов.
Шаг 1. Очистка данных
Сначала мы собираем всё, что относится к инцидентам:
- формальные поля алертов;
- текстовые описания;
- комментарии аналитиков и заказчика;
- дополнительные артефакты из внешних систем.
Далее:
- нормализуем формат (регистр, пробелы, доменные суффиксы, стандартные обозначения сервисов);
- отсекаем заведомый «шум» (служебные шаблонные фразы, общие формулировки без смысла);
- приводим разнородные события к единой структуре, чтобы модель работала с сопоставимыми объектами.
Шаг 2. Обработка в LLM
На этом этапе мы подключаем LLM не как чат, а как функцию:
- подаём ей на вход уже очищенное описание инцидента;
- просим кратко и строго по формату пересказать суть;
- дополнительно просим выделить и структурировать ключевые элементы:
тип атаки (предположительно), IP, домены, хосты, файлы, протоколы, шаг атаки, направление (входящий/исходящий), признаки компрометации и т.д.
Результат — компактное, но ёмкое текстовое «резюме инцидента» плюс список сущностей в машинно-читаемом виде.
Чтобы снизить вероятность галлюцинаций, мы:
- ограничиваем модель жёсткими инструкциями и примерами;
- проверяем, что она не «додумывает» артефакты, которых нет в исходном тексте;
- закладываем проверочные правила на стороне системы (например, IP должен быть валидным, хеш должен соответствовать ожидаемому формату).
Шаг 3. Векторизация
Получив нормализованные описания и структурированные сущности, мы преобразуем их в векторное представление — набор чисел, отражающих смысл текста и контекст.
Для этого:
- используем модель, обученную на задачах семантического поиска;
- учитываем как общий смысл описания («подбор пароля к AD-учётке», «запуск подозрительного процесса из почты»), так и конкретные артефакты.
Именно в векторном пространстве становится возможным то, чего не умеют простые строки:
- два описания с разными словами, но одной логикой будут близки;
- незначительные отличия или опечатки не ломают сходство;
- можно учитывать вес разных компонентов (например, совпадение хоста и IP важнее, чем похожий текст комментария).
Шаг 4. Кластеризация (Qdrant + DBSCAN)
Векторные представления инцидентов мы складываем в специализированное хранилище — векторную базу. Наша задача — находить среди них группы «похожих» событий.
Здесь входит в игру связка:
- векторная база (например, на основе Qdrant) для быстрого поиска ближайших соседей;
- алгоритм кластеризации вроде DBSCAN, который:
- не требует заранее знать, сколько у нас будет кластеров;
- хорошо работает с «шумом», оставляя одиночные не связанные инциденты отдельно;
- умеет выделять плотные группы похожих точек (в нашем случае — инцидентов).
По итогу мы получаем:
- группы, каждая из которых потенциально отражает одну цепочку атаки или один сценарий;
- инциденты, которые слишком отличны от других, остаются без кластера — это либо одиночные случаи, либо новые, ещё не типизированные сценарии.
Шаг 5. Результат для аналитика
Самое важное — как всё это видит человек:
- аналитик открывает свой алерт и сразу видит: «Похож на инциденты X, Y, Z, обработанные ранее»;
- может просмотреть «родственные» события: какие хосты, какие IP, какие артефакты повторяются;
- получает подсказки по вероятному сценарию атаки, основанные на предыдущих расследованиях.
Система не принимает решений за него:
- не закрывает алерты автоматически;
- не объединяет инциденты без подтверждения специалиста;
- лишь предлагает гипотезы и связи, которые можно подтвердить или опровергнуть.
Так мы превращаем LLM из «говорящего помощника» в инструмент расследования, встроенный в процесс SOC.
Как не превратить SOC в игрушку для нейросети
По мере работы быстро всплыли три типичные проблемы.
Синдром чат-бота
Если относиться к LLM как к универсальному помощнику, который «сам всё поймёт», результат будет плачевным.
Мы сознательно отказались от идей вроде:
- «пусть нейросеть сама решает, связаны ли инциденты»;
- «пусть она автоматически пишет выводы по расследованию»;
- «давайте просто зададим вопрос модели, как бы она объединила события».
Такая магия легко даёт эффект на демо, но в боевом SOC недопустима: объяснимость и воспроизводимость критичны.
Слепота к деталям
LLM хорошо справляется с общим смыслом текста, но:
- легко теряет мелкие, но важные улики;
- может пропустить значимый артефакт, если он упомянут один раз в длинном описании;
- склонна обобщать и упрощать.
Поэтому мы комбинируем:
- работу модели по пониманию контекста;
- дополнительные «жёсткие» проверки по артефактам (IP, домены, хеши) обычными алгоритмами.
Это снижает риск, что «тонкая» деталь, критичная для связи двух инцидентов, утонет в общем обобщении.
Борьба с галлюцинациями
Чтобы нейросеть не выдумывала данные:
- мы никогда не используем сырые ответы модели напрямую;
- проверяем каждое извлечённое значение по формату;
- сверяем ключевые артефакты с исходным текстом;
- ограничиваем словарь и структуру ответа, заставляя модель отвечать строго по шаблону.
Чем меньше свободы у LLM в этой задаче, тем надёжней система.
Взгляд скептика: два принципа, без которых всё развалится
Наш главный внутренний критик, изначально крайне негативно настроенный к нейросетям, сформулировал два принципа, с которыми мы в итоге полностью согласились.
Принцип 1. Это рекомендательная система, а не автомат
LLM в SOC должна:
- подсказать, но не навязать решение;
- предлагать связи между инцидентами, а не объединять их без подтверждения;
- поддерживать аналитика, а не подменять его.
Любая попытка автоматизировать критические решения («объедини эти алерты в один кейс», «закрой инцидент» и т.п.) без участия человека — путь к ошибкам, за которые в кибербезопасности платить слишком дорого.
Принцип 2. Цель — усиление экспертов, а не их замена
Система должна:
- помогать молодым специалистам быстрее понимать типовые сценарии атак, подсвечивая похожие инциденты из прошлого;
- разгружать опытных экспертов от рутинного поиска повторяющихся паттернов;
- сохранять накопленное знание SOC, превращая его в базу кейсов, к которой можно обращаться через семантический поиск.
Ни один даже самый продвинутый движок не заменит опыт человека, который годами разбирал логические цепочки атак и знает, где обычно прячутся улики. Нейросеть может лишь ускорить доступ к этому опыту.
Допустимая доля ошибки и где проходит красная линия
Ни одна система поиска связей не идеальна. Ключевой вопрос — какую долю ошибок SOC готов терпеть и в каких именно частях процесса.
Мы для себя разделили ошибки на типы:
1. Ложные связи: система считает два инцидента связанными, хотя это не так.
Допустимы как подсказка, если аналитик легко может отфильтровать и сказать «нет, это другое».
2. Пропущенные связи: система не увидела связь, которая существует.
Неприятно, но лучше, чем автоматическая неверная агрегация, если у аналитика остаётся возможность вручную её обнаружить.
3. Ошибки в артефактах: неверно извлеченный IP, домен, имя хоста.
Минимизируются за счёт валидации; критичны, поэтому к ним самые жёсткие требования.
Мы сознательно допустили:
- умеренный процент «лишних» рекомендаций (похожих инцидентов), понимая, что SOC всё равно работает глазами человека;
- крайне низкую толерантность к искажению исходных данных.
По сути, мы требуем от решения:
- можно «перестараться» в поиске связей (что‑то окажется просто похожим кейсом);
- нельзя искажать факты.
Как заставить это работать в реальном SOC
Внедрение подобной системы — это не «поставить модель и через неделю всё полетело». Это месяцы ручной настройки и отладки.
1. Начинать с реальной боли, а не с хайпа
Мы не ставили цель «встроить LLM, потому что так делают все».
Исходной точкой стала конкретная проблема:
- сотни алертов в день;
- потеря связей между сменами;
- повторяющиеся сценарии атак, которые каждый раз расследуются «с нуля».
Если нет понятной, измеримой боли — велика вероятность, что результатом будет красивая игрушка для презентаций, а не рабочий инструмент.
2. Человек в контуре — не опция, а обязательное условие
Мы с самого начала проектировали интерфейс так, чтобы:
- аналитик видел, почему именно система решила, что инциденты похожи (какие артефакты совпали, какой был контекст);
- мог быстро согласиться с рекомендацией («да, это одна цепочка») или отвергнуть её;
- мог добавлять свои заметки, которые тоже учатся учитываться в дальнейшем.
Чем больше эксперты взаимодействуют с системой — подтверждают, опровергают связи, дополняют описания, — тем точнее становятся кластеры и подсказки.
3. Готовность к длинному циклу обучения и правок
Реальность оказалась такой:
- на старте модель нередко объединяла инциденты только по совпадению пары слов;
- приходилось вручную разбирать спорные кластеры и донастраивать фильтры, веса, пороги;
- мы несколько раз меняли подход к формированию «резюме инцидента» для LLM, чтобы уменьшить влияние второстепенных деталей.
Этот цикл — наблюдение → анализ ошибок → обновление промптов и логики → повторный прогон — занял месяцы. Но именно он превратил систему из прототипа в рабочий инструмент, который главный скептик готов признать полезным.
4. Учёт специфики вашей инфраструктуры и заказчиков
Каждый SOC уникален:
- свои типовые инциденты;
- свои форматы логов;
- свои корпоративные сокращения и обозначения;
- своя терминология в комментариях.
Поэтому переносить такую систему «как есть» из одной организации в другую нельзя. Обязательно потребуется:
- адаптация словаря и шаблонов;
- настройка нормализации именно под ваши источники;
- натаскивание модели на ваших кейсах.
5. Постоянный пересмотр метрик успеха
Мы отслеживали не только «красивые» показатели вроде количества найденных связей, но и практические:
- насколько быстрее аналитики завершают расследование;
- сколько инцидентов удаётся объединять в логические цепочки;
- как уменьшается число дублирующих расследований одного и того же сценария разными сменами.
По мере взросления системы метрики приходилось пересматривать:
то, что казалось хорошим результатом на старте, через полгода становилось базовым уровнем, а фокус смещался на новые аспекты.
Итоги и практические выводы
1. Проблема цифрового тумана в SOC — не надуманная, а системная:
разнородные форматы, неструктурированный текст и разнообразие атак делают поиск связей руками тяжёлым и медленным.
2. LLM в связке с векторными базами и кластеризацией позволяет:_
- понять смысл описаний инцидентов;
- аккуратно извлекать артефакты;
- находить похожие кейсы даже при отличающихся формулировках;
- группировать события в логические цепочки.
3. Ключ к успеху — не «волшебная» модель, а архитектура вокруг неё:_
очистка, нормализация, жёсткий формат ответов, валидация артефактов, человек в контуре.
4. Важно относиться к системе как к рекомендательному инструменту:_
она предлагает связи и сценарии, а не принимает окончательные решения.
5. Главная ценность — в усилении экспертов:_
- ускорение расследований;
- сохранение и переиспользование накопленного опыта SOC;
- снижение потерь информации между сменами.
6. Внедрение — это долгий путь:_
- много ручной отладки;
- необходимость адаптации под конкретную инфраструктуру;
- постоянное взаимодействие с аналитиками, которые ежедневно работают с алертами.
Когда все эти элементы сходятся, нейросеть перестаёт быть модной игрушкой и действительно помогает развеять цифровой туман: инциденты больше не выглядят набором изолированных событий, а складываются в понятные и управляемые цепочки атак. Именно в таком виде даже убеждённый скептик готов признать: да, это работает и приносит пользу SOC.
