Привет, Хабр! Хотим рассказать о технологии обнаружения атак и показать, как создавали систему, которая берет на себя рутину SOC-аналитиков.
Чтобы понять, о чем примерно пойдет речь, представьте сборку автомобиля. Когда вы решаете построить машину с нуля, вам нужно подобрать множество компонентов. Вы ищете лучший двигатель, самые надежные шины, удобные кресла и качественные материалы для салона. Но даже идеальные детали — это только половина дела.
Главная сложность — собрать все компоненты в работоспособную систему. Без грамотной интеграции можно получить либо сразу кандидата на Формулу-1, либо кучу дорогущего хлама весом в пару тонн. А иногда возникают неожиданные проблемы — например, когда прекрасное кресло для гоночной машины просто не помещается в салон.
Точно такие же вызовы стоят перед нами при развитии автопилолта по обнаружению кибератак. Мы должны не просто выбрать лучшие технологии, но и обеспечить их слаженную работу. Подробности — в этой статье.
Работа аналитика SOC — это постоянный поток данных из десятков источников: логи, алерты, отчеты сканеров, данные EDR. Нужно учитывать контекст угроз, бизнес-процессы компании и при этом быстро принимать решения. В таком потоке легко упустить реальную атаку или потратить часы на ложные срабатывания.
Наша цель — сделать этот процесс проще и эффективнее. Для этого в мы решаем три ключевые задачи:
Сбор и обогащение данных — агрегируем информацию из всех источников и добавляем контекст;
Детекция и оценка угроз — отличаем реальные атаки от ложных срабатываний;
Наглядная визуализация — представляем данные так, чтобы оператор мог принять решение за считаные минуты.
Разберём каждый этап подробнее, начиная с той самой «базы» — модели и сбора данных.
Как мы учились связывать события: от простого к сложному
Когда мы начали разрабатывать автопилот для расследования и реагирования на киберугрозы, перед нами стояла серьезная проблема. Разные системы безопасности поставляли данные в разных форматах: где-то были только IP-адреса, где-то — доменные имена, а где-то просто хэши файлов. Нам нужно было найти способ объединить эту информацию в единую консоль.
Первая попытка: простой таймлайн
Сначала мы попробовали просто собрать все события в хронологическом порядке. Казалось, что этого достаточно — аналитик увидит последовательность и поймет связь. Но на практике выяснилось, что такой подход не работает. События с IP-адресом и доменным именем одного сервера не связывались автоматически. Более того, вся активность на одном узле склеивалась в единую цепочку, и мы не могли отделить действия администратора от злоумышленника.
Второй подход: работа с сущностями
Тогда мы решили оперировать не сырыми данными, а сущностями — узлами и учетными записями. Это дало ощутимые преимущества. Например, наша система научилась понимать, что IP 192.168.1.10 и server1.company.com — это один и тот же узел. Мы смогли интегрировать данные asset-менеджмента, что особенно помогло с DHCP-серверами и меняющимися IP-адресами. Более того, такой подход позволял прогнозировать развитие атаки, анализируя доступы между узлами и привилегии учетных записей.
Однако у этого решения обнаружились ограничения. Мы могли реагировать только на уровне целых узлов или учетных записей — например, полностью блокировать доступ. Для критичных систем это часто было неприемлемо, поскольку так можно было вывести из строя важные для бизнес-процессов части инфраструктуры. Например, если злоумышленник использует учетную запись администратора ERP-системы вроде SAP или Oracle, ее блокировка может заморозить работу сотен пользователей, остановить обработку платежей и поставок и нарушить интеграцию с другими компонентами. Кроме того, мы все еще не могли разделить легитимную и вредоносную активность на одном узле.
Третий, финальный подход: сущности + контекст
Наш текущий подход сочетает лучшие стороны предыдущих решений. Мы по-прежнему используем узлы и учетные записи как базовые сущности, но добавили глубокий контекст. Теперь система анализирует процессы, артефакты и связи между ними. Это позволяет точно определять, какие события действительно относятся к атаке.
Вот как это работает на практике:
Песочница обнаруживает вредоносный хэш файла;
SIEM фиксирует создание этого файла после открытия документа;
EDR показывает сетевое соединение процесса из этого файла.
Система автоматически связывает эти события в цепочку, даже если в исходных данных были разные идентификаторы. При этом она учитывает контекст — например, понимает, что действия легитимного пользователя и злоумышленника под одной учетной записью нужно разделять.
Что это дало на практике
Благодаря такому подходу аналитики SOC получают готовую картину атаки вместо сотен разрозненных событий. Система сама определяет, какие события связаны, и показывает логичную последовательность действий злоумышленника. При этом значительно сокращается количество ложных срабатываний — теперь мы не объединяем в одну цепочку все, что происходит на одном узле.
Но собрав данные, мы столкнулись с еще одним вызовом — как сделать их полезными для аналитика?
Сбор и анализ данных: как мы восстанавливаем полную картину атак
При создании системы сбора данных для нашего автопилота мы столкнулись с ключевой проблемой — стандартные события безопасности дают лишь фрагментарное представление об атаке. SIEM, EDR и другие системы генерируют алерты, но не объясняют связей между ними. Это похоже на попытку собрать пазл, когда половина деталей отсутствует, а имеющиеся элементы принадлежат разным наборам.
Мы рассматривали два принципиальных подхода к решению этой проблемы. Первый вариант предполагал анализ всего сырого потока данных — максимально полный, но чрезвычайно ресурсоемкий метод. Второй подход, который мы в итоге выбрали, имитирует работу SOC-аналитика: система отталкивается от уже выявленных аномалий и постепенно восстанавливает контекст вокруг них. Этот выбор был обусловлен несколькими факторами. Во-первых, события безопасности уже содержат результаты экспертного анализа — корреляции и правила детекции, разработанные специалистами. Во-вторых, такой подход существенно сокращает объем обрабатываемых данных. И главное — он позволяет автоматизировать рутинные операции, исключая человеческий фактор при обработке тысяч однотипных событий.
Наш механизм анализа работает в два этапа. Первый этап — доуточнение внутреннего контекста — начинается с изучения отдельных событий. Например, при обнаружении подключения с одного узла на другой через mstsc.exe и последующего запуска подозрительного PowerShell, система автоматически проверяет факт успешной авторизации, анализирует созданные процессы и строит цепочку выполнения. Это позволяет установить, что интерактивный RDP-сеанс действительно привел к запуску вредоносного скрипта через explorer.exe.
Второй этап — построение внешнего контекста — расширяет анализ за пределы непосредственных событий. Система изучает источник подключения, анализирует предшествующие действия на узле-инициаторе, проверяет данные аутентификации. В результате выстраивается полная цепочка: от первоначального VPN-подключения через создание запланированной задачи до конечного выполнения вредоносной нагрузки.
Проблемы с данными. Часть первая: неполнота
Впрочем, реализация этого подхода сопряжена с серьезными техническими сложностями. Одна из основных проблем — неполнота данных. На практике часто отсутствуют логи критичных событий, данные поступают с задержкой, а глубина аудита оказывается недостаточной. Не менее сложной задачей является обработка несогласованных данных из разных источников — с расходящимися временными метками, противоречивыми сведениями о сессиях и процессах, несовпадающими идентификаторами ресурсов. Добавляет сложностей и нелинейный характер поступления данных, требующий постоянного пересбора контекста.
Яркий пример эффективности нашей системы — анализ аномального запуска adobe_reader.exe из svchost. Последовательная реконструкция событий позволяет выявить создание задачи через планировщик, установить связь с конкретной RDP-сессией, определить VPN-подключение и в конечном итоге — вычислить исходный внешний IP. Такая детализация достигается за счет рекурсивного анализа цепочек процессов, интеллектуального сопоставления данных из разных источников и сложных алгоритмов проверки временных меток.
Эти механизмы позволяют нашей системе не просто собирать разрозненные события, а восстанавливать полную картину атак, включая те этапы, которые не были зафиксированы системами мониторинга.
Проблемы с данными. Часть вторая: несогласованность
При ручном расследовании инцидентов аналитики часто не замечают мелкие несоответствия в данных — человеческий мозг умеет фильтровать такие шумы. Однако при автоматизации эти несостыковки становятся критичными. Рассмотрим типичные примеры:
В событиях интерактивного входа система часто указывает нулевое значение порта (SRC PORT = 0), что делает эту информацию бесполезной для анализа. Другая распространенная проблема — неполные данные. Например, событие запуска процесса может содержать только PID, без имени или пути исполняемого файла. В Windows, где идентификаторы процессов периодически переиспользуются, это создает серьезные сложности для корректного анализа.
Особенно показательны расхождения между разными источниками данных. Возьмем два события запуска одного и того же процесса: из журнала Windows и Sysmon. На первый взгляд они идентичны — совпадают временные метки, PID, имя и путь процесса, командная строка. Но при этом Sysmon указывает на пользовательскую сессию, а Windows — на системную. Какому источнику верить в таком случае?
Ситуация усложняется, когда данные проходят обработку в нескольких системах безопасности. Каждая платформа преобразует информацию по-своему, добавляя новые слои неопределенности. Но самые сложные случаи связаны с особенностями работы сетевых протоколов. Например, при атаке через проброшенный туннель, событие авторизации может содержать IP-адрес туннельного узла, но при этом сохранять hostname исходной машины, которая может находиться за пределами организации. Такие «разделенные» сущности требуют особой обработки в автоматизированных системах.
Анализ существующих подходов к автоматизации
Изучая опыт других SOC, мы рассматривали три типа решений:
Текстовые плейбуки — содержат ценные, но слишком абстрактные рекомендации («обнаружив хакера — реагируй»). Они плохо поддаются формализации для автоматизации.
Threat hunting плейбуки — предлагают конкретные запросы к системам с четкими параметрами. Однако они фокусируются на обнаружении угроз, а не на сборе контекста для принятия решений.
Кодовые реализации — представляют собой готовые скрипты, часто визуализированные блок-схемами. Но большинство таких решений ограничиваются базовым обогащением данных (GeoIP, IOC), не решая задач глубокого анализа.
Нам требовался принципиально иной подход — система, позволяющая экспертам формализовывать свои знания о методиках атак и способах их расследования. Аналог Sigma-правил, но для процедур реагирования, а не детекции.
Разработка собственного решения
Мы пошли путем постепенного накопления экспертизы:
Сбор кейсов — эксперты исследовали реальные атаки и фиксировали методики расследования;
Формализация знаний — аналитики переводили экспертные методики в алгоритмические последовательности;
Разработка MVP — создавался прототип системы, позволяющий кодировать логику анализа.
В результате появился специализированный SDK, который позволяет:
Описывать известные техники атак, например, 5 способов выполнения через scheduled task;
Автоматически проверять все возможные векторы;
Точно определять использованный метод даже в сложных случаях, например, при развертывании через групповые политики.
Этот подход сохраняет экспертные знания в воспроизводимом формате, значительно ускоряя анализ инцидентов. Если эксперт знает десять способов эксплуатации уязвимости, система может автоматически проверить все десять, а не полагаться на удачу в выборе правильного вектора анализа.
Как наше решение делает сложное простым
Когда мы собрали все данные и научились анализировать угрозы, перед нами встал главный вопрос: как показать это пользователю, чтобы он действительно тратил меньше времени, а не просто «перекладывал бумажки» из одной системы в другую?
Проблема перегруженных интерфейсов
Многие решения в области безопасности напоминают панель управления самолётом — десятки датчиков, которые нужно постоянно мониторить.
Наш подход другой. Возьмем простой пример: злоумышленник скачивает файл, создает задание и запускает его. Если показать всё как есть, пользователь увидит десятки взаимосвязанных процессов и потеряется в деталях. Если упростить слишком сильно — пропадет критически важный контекст.
Интеллектуальное представление данных
Мы нашли золотую середину. Система автоматически выделяет самое важное — тот самый скачанный файл и созданную задачу, — но при этом сохраняет возможность углубиться в детали. Это похоже на рассказ опытного аналитика, который сразу показывает ключевые моменты, но может ответить и на уточняющие вопросы.
Проверка в реальных условиях
Чтобы такая система действительно работала, мы тестируем ее сразу в четырех измерениях. Во-первых, используем MaxPatrol O2 для защиты собственной инфраструктуры. Во-вторых, воспроизводим атаки в лаборатории. В-третьих, участвуем в учениях Standoff. И наконец, разворачиваем пилоты у клиентов. Каждый такой тест дает уникальные insights, которые мы сразу закладываем в продукт.
Эволюция вместо революции
Система постоянно учится. Каждое ложное срабатывание делает алгоритмы точнее, каждая реальная атака расширяет базу знаний. Мы не просто добавляем новые функции, а переосмысливаем весь опыт взаимодействия. В итоге аналитик получает не груду данных, а готовую историю с выделенными ключевыми моментами.
Что в результате?
Представьте, что вместо часов кропотливой работы вам показывают слайды расследования с пометками «вот главное», «на это стоит обратить внимание», «здесь всё чисто». При этом в любой момент можно задать вопрос «а почему?» и получить развернутый ответ. Это и есть наш подход — сохранить всю глубину анализа, но избавить пользователя от рутины.
Так мы движемся к настоящему «автопилоту» в кибербезопасности — системе, которая не заменяет специалиста, а становится его интеллектуальным ассистентом.