Здравствуй, Дзен!

Добро пожаловать на мой Дзен!

Буду стараться, чтобы мои заметки на новом месте будут во всех отношениях не хуже прежних.

Увидимся на Дзене!

Ну, а если вам удобнее использовать Telegram, я там тоже есть - подписывайтесь.

Визуализация расследования

В прошлой заметке я примерно рассказал как выглядит расследование инцидента. Технически, для аналитика 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 при построении графа таймлайна показала воодушевляющие результаты, то можно какие-то сценарии затем перевести в автоматическую отработку, и аналитику при расследовании алерта сразу будет подрисовываться часть графа таймлайна на базе опыта прошлых расследований, аккумулированного в модели Машобуча.

Вторая линия, виртуальная

Ротация - важнейший инструмент борьбы с выгоранием, чем неизбежно страдает любой SOC. Многие психологические исследования, да и мой личный опыт, подтверждают, что мы отдыхаем от смены вида деятельности ( а безделье, напротив, зачастую утомляет), поэтому нам нужно обеспечить смену деятельности.

Из общения с различными менеджерами SOC, да и процессе собеседований с потенциальными коллегами на операционные линии, сложилась уверенность, что в большинстве SOC есть первая линия аналитиков, действующая практически полностью по алгоритму (~плейбуку) и более-менее проявить инициативу можно только на "второй" линии. При этом мне никто не объяснил, почему, если работа первой линии столь детально алгоритмизирована, ее нельзя полностью автоматизировать, да хоть даже с использованием машобуча. Да, есть определенные различия в квалификации аналитиков, в опыте, но это все равно не повод полностью обламывать крылья, превращая аналитиков SOC в биологические автоматы. Чтобы люди умели принимать решения,  им надо давать возможность принимать решения!

Постоянно раздумывая о проблематике, намеченной выше, мы в конечном счете пришли к выводу, что у нас не будет нескольких операционных линий с жестким назначением аналитиков. Я уже рассказывал (и раньше в этом посте есть ссылка на запись доклада), что "первой линией" в нашем случае является Автоаналитик, являющийся частью конвейера обработки телеметрии, а на команду SOC уже попадает меньше фолсы. Вместо нескольких у нас есть одна операционная линия, среди которой по расписанию выделяется группа, выполняющая функции второй линии. Поскольку состав группы по расписанию меняется каждую неделю, внутри мы ее называем "Виртуальная вторая линия" (Virtual Second Line, VSL). 

На VSL выпадают все более-менее творческие задачи за рамками расследования алертов, причем назначение конкретных членов VSL на функциональные участки также приводится в расписании, мы это тоже постоянно ротируем. Для понимания приведу примеры некоторых функциональных участков для VSL .

• Операционка. Эта группа занимается расследованием алертов, как и дежурные, но на нее дежурные могут выполнить эскалацию. При получении такой эскалации данная группа VSL (конкретный аналитик, на кого передали кейс) переключается на работу по эскалации и доводит ее до конца. По завершении работы на эскалации, снова "превращается" в операционного аналитика, расследующего поступающие алерты. Такой режим работы используется при высокой нагрузке команды SOC в целом (большой объем работы, много алертов и/или инцидентов). В более спокойное время, под операционку не выделяется группа из состава VSL, а на эскалации переключаются из других направлений (например, аналитик занимался ретро-хантингом, но, получив эскалацию. переключился на нее, а по окончании - продолжил проверять свои гипотезы)
• Перепроверка. Известно, что мы перепроверяем за Автоаналитиком, но мы перепроверяем и за аналитиками. Приоритезация перепроверки (за кем следует посмотреть побольше) управляется метриками SOC (в частности, на основе конверсии). Типы ошибок аналитиков я привел в докладе на слайде 32, ошибки регулярно обсуждаются, и тенденция к их уменьшению доказывает полезность этого мероприятия.
• Периодический ретро-хантинг. Не все гипотезы реализованы в виде алертов, ввиду своей склонности к ложным срабатываниям. Но это не отменяет необходимость их проверки вручную. Для ретро-хантинга есть несколько критериев. которые позволяют его применять с большей результативностью.
• Фильтрация, адаптация детектирующей логики. Давно писали о разных типах ложных срабатываний, с т.з. этой статьи "контекстные" ложные срабатывания в ответственности операционной группы и на их расследование требуются ресурсы.

Каждая из перечисленных активностей достойна отдельного поста, будем верить, что когда-нибудь мне удастся выделить на них время и раскрыть больше инсайдов нашей работы.

Сколько нужно операционной безопасности?

 Во второй день SOC Forum выступал с докладом в секции аналитических отчетов. Выкладываю презентацию. Остановлюсь тезисно на основных вещах, которые хотелось донести.

1. Лаборатория Касперского (да и все другие поставщики услуг) достаточно публикуют отчетности и записывают вебинары, где подробно рассказывают, как интерпретировать обнаруженные зависимости, поэтому данная презентация не об аналитике, а о том, как ее использовать в своей работе, в частности, для обоснования каких-либо трудозатрат на SOC (на примере данных аналитических отчетов Лаборатории Касперского, с которыми автор знаком наиболее близко).

2. Есть определенные различия в языке между CISO и Бизнесом, что в результате сводит общение об ИБ к пугалкам, типа: "Вот страшная-страшная угроза, но внедрив решение Х, уровень риска будет снижен до допустимых значений, нужны средства на этот Х". Подход не блещет новизной, и имеет проблемы эффективности и результативности.

3. На основании аналитики DFIR можно объективно оценить ландшафт угроз, а на базе метрик SOC - возможности соей операционной безопасности. Основной контент презентации - это те или иные цифры из аналитической отчетности, и вопросы, которые имеет смысл себе задать для оценки собственной готовности. Фактически, стоимость необходимой безопасности - это разница между возможностями атакующих (на базе фактических инцидентов, а не какого-то теоретического допущения) и способностями SOC (на базе метрик SOC, которые всегда надо считать, в случае любой операционки, иначе невозможно объективно судить о качестве сервиса)

3. Аналитическая отчетность поставщиков услуг - отличный старт для тех, кто не наработал еще статистику своего operations, из которой можно извлечь собственную аналитику.

4. Для тех, кто уже имеет SOC, а, следовательно, процесс управления инцидентами, статистика результатов расследования собственных инцидентов - отличный материал для понимания ландшафта угроз, а метрики SOC покажут готовы ли Синие управлять релевантными рисками ИБ.

5. Подход на базе метрик SOC, типа MTTD, MTTR представляется более точным и, самое главное, понятным менеджменту, чем, например, более академические модели оценки зрелости SOC, так как в большей степени подвержены субъективизму со стороны оценщика.

Сколько надо SOC? from Sergey Soldatov

От мониторинга к форенсике и обратно

15.11 выступал на мероприятии с более-менее техническим докладом, выкладываю презентацию.

В докладе были рассмотрены два сценария эскалации - SOC->DFIR и DFIR->SOC, на примере двух реальных инцидентов. Для инцидентов приведены техники и тактики атакующих, а также применяемые методы обнаружения.

От мониторинга к форенсике и обратно from Sergey Soldatov

Приятного просмотра!