В прошлой заметке я примерно рассказал как выглядит расследование инцидента. Технически, для аналитика SOC это выражается в необходимость на базе имеющейся информации строить запрос к используемому data lake из данных (событий систем, EDR-like и NTA-like телеметрии, Netflow и т.п., что там у кого еще есть...). Запрос возвращает новые, связанные по observables, события, в которых есть новые поля, по которым также можно далее поискать. Каждое новое событие добавляет контекста в инцидент, что позволяет более точно интерпретировать происходящее, а более точная интерпретация позволяет спланировать более эффективные и результативные мероприятия по реагированию. Детализация контекста зависит от ширины и глубины телеметрии, но, в любом случае, ограничена, в сравнение с форенсикой, так как объем телеметрии и\или логов - это компромисс межу собирать все подряд и умереть под объемом данных, и собирать мало и не иметь возможности обнаруживать современные атаки. Как правило, этот компромисс решается очень просто: нужно обнаружить любую современную атаку и иметь возможность ее валидировать, т.е. насколько это возможно, подтвердить, что выявленная активность не является ложным срабатыванием, далее инцидент передается в команду расследования, которая делает форенсику и восстанавливает полную картину. Задача полного расследования исключительно по телеметрии MDR не ставится.
Ответственный MDR провайдер стремится в карточке инцидента заказчику предоставить как можно больше информации, насколько это возможно на основе собираемой телеметрии (== насколько позволяет технологический стек MDR). Для этого аналитик SOC/MDR собирает таймлайн - это последовательность всех, связанных с данным инцидентом, алертов и сырах событий (событий, релевантных действиям атакующих, но не попавших в какие-либо алерты). Связка релевантных алертов и событий вместе (== событий, подтверждающих те или иные действия атакующих) производится именно как указано выше - по observables\IoC.
Практика показывает, что аналитику SOC намного удобнее строить таймлайн визуально на графе, чем делать это, например, в Блокноте, а потом копи-пейстить это в Карточку инцидента, публикуемую заказчику. Технически это выглядит так: алерт - первый узел графа. В алерте есть связанные события, у каждого из которых есть поля, и каждое поле может служить ключом поиска в качестве observable. Аналитик изучает события алерта и задает вопросы, ответы на которые приводят к появлению на графе новых связанных узлов. Новые узлы - это тоже события и\или алерты (совокупности событий), в которых есть тоже уже свои поля, каждое из которых можно использовать как observable для поиска новых связанных событий и\или алертов, и т.д.
Это звучит сложно на слух, поэтому попробуем придумать примеры. Всем известна и понятна цепочка запуска процесса, типа процесс1 --> процесс2 --> процесс3 и т.п. , пример можно увидеть в Kibana здесь. С учетом предлагаемого нами подхода эта цепочка запуска процесса является частным случаем графа из событий телеметрии EDR "запуск процесса" - здесь мы связываем события запуска процесса по полю Unique PID. Но связывать между собой можно не только события запуска процесса, а вообще любые события. Например, мы имеем алерт на событие запуска процесса - построили цепочку из событий запуска. В событии запуска процесса видно в контексте какой учетной записи (УЗ) пользователя произведен запуск. Для дальнейшего расследования аналитику SOC нужно найти информацию об этой УЗ и отобразить ее на графе таймлайна - аналитик кликает по SID с запросом "найти вход" - на граф подрисовывается событие входа этой УЗ. В событии входа виден тип входа и адрес и\или имя системвы, откуда произведен вход, далее аналитик ищет запуски процессов от данной УЗ, но уже на системе с которой был зафиксирован вход... Подстраивать узлы графа можно не только "назад", но и "вперед". Мы начали с первого алерта на запуск процесса, в котором есть хэш, допустим, в телеметрии на этот файл можно найти срабатывания AM-движка (AM == anti-malware), - эти события также стоит добавить на граф таймлайна.
Ключевым отличием нашего графа от используемого в решениях других производителей является то, что здесь узлы - не информационные системы, а события телеметрии, ребра - связи между событиями на основании observables. Метод построения - выбор аналитика SOC из списка предопределенных поисковых запросов по артефакту (observable, IoC) и возвращенных данных на выбранный запрос, причем начать можно с наиболее общих запросов, типа, найти все события, где фигурирует этот хэш, или все запуски процессов от данной конкретной УЗ, или все события срабатывания AM-движка с конкретным вердиктом и т.п.
Такой интерактивный метод построения таймлайна в виде графа позволяет быстро и удобно для аналитика SOC найти все связанные с данным инцидентом события телеметрии и сформировать наиболее полную картину происходящего...
Текст Карточки инцидента представляет собой обычную хронологию, типа: Дата, время: Что произошло (буквально текстовое описание события телеметрии). Имея полную совокупность связанных с инцидентом событий телеметрии, сгенерировать подобную хронологию можно автоматически, особенно на английском языке, ввиду минимальных изменений слов по лицам, числам и падежам. По имеющейся у нас статистике, формирование Карточки инцидента, даже в нашем случае, когда многие типовые описания хорошо шаблонизированы, отнимает значительную часть рабочего времени аналитика SOC, и здесь всегда есть перспективы для улучшений. Автоматическое формирование Карточки инцидента на основе собранного таймлайна - отличная оптимизация.
Но это еще не все! Процесс построения таймлайна аналитиком SOC, а именно, при каких начальных условиях какие запросы к телеметрии формирует аналитик (по-человечески это можно перефразировать как "какие алерты как расследуются аналитиком SOC"), нужно подробно логгировать/журналлировать. Очевидным использованием таких логов является оценка эффективности работы аналитиков, - этим всегда полезно заниматься. А также на эти логи можно натравить Машобуч, который можно обучить на успешных расследованиях, и затем использовать Машобуч для подсказки запросов аналитикам SOC в процессе построения ими графа таймлайна. Успешными расследованиями для Машобуча будут те, которые в итоге были опубликованы заказчикам в качестве инцидентов и впоследствии не были помечены как ложные срабатывания, а также успешно прошли перепроверку. Если практика использования Машобуча в качестве подсказчика\помощника аналитику SOC при построении графа таймлайна показала воодушевляющие результаты, то можно какие-то сценарии затем перевести в автоматическую отработку, и аналитику при расследовании алерта сразу будет подрисовываться часть графа таймлайна на базе опыта прошлых расследований, аккумулированного в модели Машобуча.
