Добро пожаловать на мой Дзен!
Буду стараться, чтобы мои заметки на новом месте будут во всех отношениях не хуже прежних.
Увидимся на Дзене!
Ну, а если вам удобнее использовать Telegram, я там тоже есть - подписывайтесь.
REPLY-TO-ALL is a double language blog (English/Russian) run by three information security practitioners. Want to discuss information security problems? This is the place.
Добро пожаловать на мой Дзен!
Буду стараться, чтобы мои заметки на новом месте будут во всех отношениях не хуже прежних.
Увидимся на Дзене!
Ну, а если вам удобнее использовать Telegram, я там тоже есть - подписывайтесь.
Posted by Sergey Soldatov 0 comments
В прошлой заметке я примерно рассказал как выглядит расследование инцидента. Технически, для аналитика 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 при построении графа таймлайна показала воодушевляющие результаты, то можно какие-то сценарии затем перевести в автоматическую отработку, и аналитику при расследовании алерта сразу будет подрисовываться часть графа таймлайна на базе опыта прошлых расследований, аккумулированного в модели Машобуча.
Posted by Sergey Soldatov 0 comments
Labels: SOC, Technology
Добро пожаловать на мой Дзен ! Буду стараться, чтобы мои заметки на новом месте будут во всех отношениях не хуже прежних. Увидимся на Дзене!...