Моделирование динамического плейбука. Практика расследования и реагирования, метрики качества
В предыдущей статье мы рассказывали про методику оценки качества процесса расследования и реагирования. В двух словах: мы рассуждали, каким образом сформировать систему метрик на основе статистики действий аналитиков SOC, которые позволят проанализировать процессы и процедуры security operation. Применение системы метрик позволит, с одной стороны, оптимизировать действия аналитиков за счет исключения лишних действий (возможно, сделав их необязательными), автоматизировать повторяющихся действий, разработать воркэраунды для слишком долгих действий, пополнить плейбуки действиями, которые в них отсутствуют, но в реальности всегда выполняются. С другой стороны, система метрик позволит повысить качество детекта за счет сбора статистики по условиям, при которых правило коррреляции фолзит из раза в раз. И, в конце концов, система метрик может помочь проанализировать утилизацию средств защиты, а также экономическую эффективность подписок на аналитические сервисы и фиды. Каким образом? Давайте разбираться на реальных примерах.
Оптимизация планов реагирования за счет анализа статистики действий по инцидентам
Анализ планов реагирования стоит начать с проверки достижения им цели полноценного анализа ландшафта инцидента. Почему именно с этого? Да потому, что весь security management стремится в первую очередь к максимальной полноте и актуальности контекста: чем чище и корректнее данные, тем вернее будет решение. Поэтому для выстраивания хорошего процесса расследования надо понять:
· Насколько качественно мы анализируем все артефакты, собранные в инциденте.
· Все ли объекты, связанные с событием безопасности были оценены и обезврежены.
· По каждому из связанных хостов, учеток и процессов иметь вердикт: вредоносный или безопасный.
· Если вердикт вредоносный, то, по возможности, нейтрализовать или снять компрометацию.
Следующим шагом плейбук анализируется более детально. Обыкновенно, оценка эффективности процесса расследования проходит достаточно верхнеуровнево на основе критичности и SLA. Руководители дежурной смены смотрят на количество флозов, проверяют время выполнения плейбуков в зависимости от критичности инцидента. При этом не учитываются типизация инцидента и время прохождения этапов.
Но давайте подумаем: где-то в отражении атак важна минимальная скорость сдерживания (как, например, при расследовании ВПО), где-то, наоборот, процесс энрича должен быть детальным, чтобы собрать больше информации прежде, чем принимать финальное решение (например, нарушение политик и блокировка внутренних учеток требует осторожности, чтобы не заблочить второпях легитимного и может быть обидчивого руководителя). Для получения более детальных метрик и оценок хочется разбить аналитику по этапам расследования и оценивать время выполнения каждого этапа для разных типов инцидентов.
Рисунок 1. Распределения временных показателей по фазам
Если декомпозировать анализ плейбуков до сбора статистики по времени выполнения фаз с последующим анализом конечных действий, то тут можно оптимизировать:
· Повторяющееся из раз от раза простые действиях выводить в автомат (и немаловажное преимущество: возможность безопасно автоматизировать действия, потому что мы знаем типовые условия их выполнения);
· Действия, которые не принесли результат исключать из плана реагирования (например, те действия, которые не обогатили контекст, не дали новых объектов, не подтвердили вредоность в TP инциденте);
· Действия, которые выполнялись слишком долго заменять другими действиями или выносить в другие фазы (допускающие большую длительность выполнения).
Если у нас есть ретроспективная аналитика по повторяющимся огрехам и «бутылочным горлышкам», можно приступать к совершенствованию процесса.
Но на этом история анализа плейбуков не заканчивается. Мы посмотрели, насколько мы проанализировали все артефакты. Мы посмотрели, насколько действия эффективно выстроены для достижения результата. А теперь давайте посмотрим:, а все ли действия плейбука выполняет аналитик SOCа. Супер-полезно проанализировать, какие действия выполнил безопасник в сравнении выполненные с теми, что были предложены.
Легче всего объяснить эти метрики через комбинаторику и пересечение множеств. Представьте, что у вас есть два множества: первое 
— это рекомендованные действия, второе 
— это выполненные действия, пересечение множеств 
— рекомендованные и выполненные.
Из этих множеств мы можем составить две метрики. Первая — это точность плейбука, или
.
Например, плейбук предлагает в своем составе 10 действий, из них реально было выполнено 3, значит 
. То есть коэффициент недостаточно высокий. Если из раза в раз план реагирования не дотягивает по точности и аналитик не выполняет предложенные шаги, их надо убирать или делать опциональными.
Следующая метрика, анализирующая выполнение плейбука — это полнота или
. Например, было выполнено 3 из 10 предложенных плюс еще 2 своих,
тогда 
.
Если из раза в раз в этом типе инцидента аналитик в дополнение к согласованному плану реагирования делает еще два дополнительных действия, плейбук надо ими расширить.
Успешность самих действий — тоже важный критерий, потому что выполненное впустую действие лишь потратит драгоценное время и, возможно, деньги (в случае платных подписок), не принеся никакого эффекта. Успешное действие — это то действие, которое:
· дало больше данных по существующим объектам,
· установило статус объекта,
· сделало сняло компрометацию объекта,
· принесло новые объекты, расширяя ландшафт атаки.
Неуспешные действия, соответственно, желательно удалять, о чем мы уже упоминали в предыдущих метриках аналитики планов реагирования.
Теперь применим метрики на практике, проанализировав их через призму плейбука «Заражение ВПО».
Рисунок 2. Пример анализа плейбука «Заражение ВПО»
Итак, соберем все верноположительные инциденты этого типа и проанализируем статистку на предмет выполнения аналитиками SOC рекомендаций из текущего плейбука. На стадии сдерживания мы видим, что действия «Проверка в песочнице» и «Обогащение в аналитических сервисах» либо не выполняются, либо выполняются очень долго. В контексте первичного реагирования на ВПО подобные временные затраты недопустимы (особенно, если мы сначала будем пытаться анализировать, а потом выполнять сдерживание). Поэтому разумный вывод — эти действия надо либо исключить, либо перенести в следующую фазу анализа.
Далее, мы видим на ретроспективных данных, что довольно-таки часто на этом этапе аналитики SOC выполняют дополнительную операцию «Проверка на массовость». Системное повторение действия, которого нет в данном этапе в этом типе инцидента, говорит о том, что полнота зафиксированного плейбука недостаточна и безопасник с меньшим грейдом и уровнем компетенций может пропустить это действие. Значит, плейбук надо расширить.
Обсудим еще одно применение методики статистического анализа исполнения процессов реагирования. В текущем мире очень важно учитывать высокую волатильность способов и техник проведения атак, потому что один и тот же вирус может сильно модифицироваться для обхода защиты и избегания детекта. Чаще всего хакеры используют привычные инструменты и утилиты, но меняют способы распространения, закрепления, порождаемые процессы: если вчера ВПО или группировка использовали технику обратного туннелирования, то сегодня индикатором присутствия становится тулза WSO. Посмотрим на картинку на блок ретропоиска: для отслеживания столь быстро меняющегося ландшафта нам помогут Threat hunting, поведенческие индикаторы и анализ окрестностей инцидента. Например, мы можем посмотреть историю запросов по инцидентам типа компрометации Bitrix и увидеть, что чаще всего она сопрягается с алертами IDS (событиями безопасности) попыток эксплуатации уязвимости Wordpress, значит этот этап ретроспективного анализа можно не только добавить в плейбук, но также автоматизировать, так как история типовая.
Оптимизация правил корреляции за счет обработки условий false positive
Еще один важный блок информации можно получить, проанализировав сугубо false positive, или ложноположительные инциденты. Если проанализировать все инциденты с одним и тем же корреляционным правилом, то можно найти те условия, при которых правило фолзит. Эти условия можно как добавить в правило корреляции, так и исключить, тем самым выполняя настройку базы решающих правил, снижая количество false positive.
Рисунок 3. Параметры событий, при которых корреляция фолзит
Второй вариант анализа результата: вместо того, чтобы добавлять события в исключения через доработку регулярок, можно определить близость обрабатываемых событий путем поиска семантически близких к определенным как FP инцидентам. Если сработка близка к каким-то FP, то вероятнее всего она тоже FP. Так можно решить проблему бесконечно раздувающихся списков исключений из корреляционных правил.
Оценка эффективности применяемых средств защиты, инструментов обогащения и аналитики
Другой набор выводов и решений можно получить, проанализировав верно положительные инциденты. В них мы точно знаем, что объекты были скомпрометированы и инцидент был создан обоснованно. Признак верно положительности может помочь нам очистить плейбуки от лишних действий, которые в итоге не принесли нам результата: объект вредоносный, но действие (и используемый инструмент) не смогли этого подтвердить множество раз в данном типе инцидента (не важно по каким причинам).
Проведем подобный анализ на примере плейбука по брутфорсу: множество неудачных попыток входа с последующей удачной.
Рисунок 4. Результативность инструментов плейбука «Брутфорс, или успешный подбор пароля»
Корреляционное правило принесло нам объекты внешнего хоста атакующего, внутренний хост жертвы и скомпрометированную учетку — прогоним их через инструменты обогащения, чтобы получить дополнительную информацию по вердикту вредоносности. По плейбуку из примера мы идем в Threat intelligence, SIEM и аналитические сервисы, такие как Virus Total. Если инцидент TP, внешний атакующий хост очевидно принадлежит злоумышленникам, но конкретный источник данных не дает (и все предыдущие разы так же не давал) информации о вредоносности или опасности артефакта, значит вероятнее всего, он просто нерелевантен в данном конкретном случае.
Рисунок 5. Скоринг источников обогащения
С помощью этого подхода можно фильтровать фиды, выбирать подписки на аналитические сервисы, оптимизировать подключение внутренних источников обогащения и рассчитывать утилизацию средств защиты. Статистика — богиня данных, она дает нам выводы по экономически эффективному применению инструмента в конкретном типе инцидента, на конкретном этапе расследования и при конкретных условиях: когда нам нужен антивирусный движок, когда краулер, а когда аналитический сервис полезен для получения вердикта по индикатору компрометации.
Вывод
С применением подобного системного подхода мы получаем расширенную информацию для фиксации и оптимизации процесса расследования и реагирования на основании ретроспективного анализа правильных и неправильных действий. Мы можем в автоматизированном виде:
· сохранить экспертизу крутых специалистов, зафиксировав их в плейбуках,
· подсветить и переработать узкие места «бутылочного горлышка»,
· оптимизировать слишком длинные ветки планов,
· исключить избыточные инструменты и средства аналитики,
· оптимизировать на регулярной основе в PDCA цикле плейбуки,
· поставлять в режиме реального времени интегральные оценки для принятия решения.
То есть система аналитики, применив свое основное преимущества перед человеком (что есть легкая обработка большого количества данных и поиск закономерностей) может помочь как сохранить ценные навыки, так и предложить шаги по сокращению костов и повышению эффективности процесса расследования и реагирования на инциденты.
