Оценка эффективности SOC: старые песни о главном

За прошлый месяц у меня было 8 командировок, все на самолете, и часть из них была с задержкой, местами достаточно существенной, в несколько часов. Мы все понимаем, что сейчас, когда каждый день идут атаки дронов по всей стране, ожидать соблюдения расписания странно и поэтому к задержкам начинаешь относиться философски, просто выстраивая командировочный процесс с их учетом. Но регулярно сидя в зале вылета и наблюдая за пометками «ЗАДЕРЖАН ДО» против рейсов, я вспоминал, что когда раньше регулярно летал в США авиакомпанией Delta, то у нее было правило:

20-Minute Bag Guarantee: если зарегистрированный багаж на внутреннем рейсе Delta в США не поступил на багажную ленту в течение 20 минут после открытия двери самолета, пассажир, участник SkyMiles, может получить 2500 бонусных миль SkyMiles.

И я думал, что эту историю можно развить на тему оценки эффективности SOC. Ведь как было бы классно, если бы SOC, как Delta, не просто говорил «мы быстро обнаруживаем и отражаем инциденты», а превращал это в публичное обещание с измеримым SLA и компенсацией за невыполнение. Но потом ты понимаешь, что Delta не просто так красиво говорит об SLA в 20 минут, а потому что у них за этой метрикой стоит управляемый процесс, соответствующий понятной цепочке атомарных действий:

самолет встал → открыли багажный отсек → выгрузили контейнеры/тележки → доставили к терминалу → подали на ленту → багаж появился у пассажира

Да, там тоже бывают исключения: погода, удаленная стоянка, когда тебя только 20 минут везут по полю, перегруз аэропорта, поломка техники, спецбагаж, международные стыковки и т.п. Но в нормальной ситуации процесс достаточно стандартизирован, повторяем и измерим. Поэтому можно сказать 20 минут – это не просто маркетинг, а SLA на хорошо работающую операционную цепочку.

С инцидентами ИБ сложнее, так как «инцидент» – это слишком широкое слово. В одну категорию попадают:

• фишинговое письмо одному сотруднику;
• вредоносный файл на рабочей станции;
• компрометация учетной записи;
• lateral movement;
• утечка данных;
• ransomware;
• атака на облачную инфраструктуру;
• инцидент в промышленном сегменте;
• подозрение на активность инсайдера;
• инцидент у подрядчика или SaaS-провайдера.

Говорить для всего этого: «наш Time-to-Response должен быть 20 минут» бессмысленно. Это как если бы аэропорт обещал одинаковое время выдачи багажа для ручной клади, лыж, животных, дипломатического багажа, груза с пересадкой и чемодана, который прилетел другим рейсом.

Недавно мне попался материал от «английской ФСТЭК», центра компьютерной безопасности NCSC, в котором плохие метрики могут не просто быть бесполезными, а реально вредить SOC. Они превращают аналитиков в «ticket monkeys», которые соревнуются в скорости нажатия «false positive», вместо того чтобы думать, охотиться, понимать среду и искать атакующего. Правда, я тут с англичанами не совсем согласен, не бывает плохих метрик, бывает их неверное использование – не к месту и не ко времени. Но то, что SOC нельзя оценивать как службу обработки тикетов, я согласен. Как только мы начинаем мерить SOC по количеству закрытых алертов, скорости закрытия тикетов, числу написанных правил или объему собранных логов, мы почти гарантированно начинаем стимулировать неправильное поведение аналитиков: быстрее закрывать, больше генерировать, больше собирать, но не лучше обнаруживать атаки.

NCSC разбирает четыре популярные, но опасные метрики: количество обработанных тикетов (по сути инцидентов), время закрытия тикета, число правил обнаружения и объем собранных логов (вот эту метрику, если честно, я ни у кого не видел). Они аргументируют тем, что эти показатели легко объяснить начальству, но они почти ничего не говорят об эффективности центра мониторинга и могут искажать поведение команды.

Количество тикетов стимулирует их закрывать, а не расследовать. NCSC пишет, что встречал SOCи, где до 99% тикетов закрывались как ложные срабатывания. Если аналитика оценивают по числу обработанных тикетов, он начинает искать повод закрыть алерт, а не повод разобраться.

Скорость закрытия тикета – тоже ловушка. Чем сильнее давим на скорость, тем больше вероятность, что аналитик будет быстрее нажимать «false positive». Это не значит, что время не надо мерить. Это значит, что его нельзя делать главным стимулом поведения. Правильнее оценивать не один Time-to-Response, а несколько временных метрик по этапам жизненного цикла реагирования:

• Time-to-Detect – когда событие впервые было замечено.
• Time-to-Triage – когда стало понятно, что это не мусорный алерт, а потенциальный инцидент.
• Time-to-Assign – когда появился ответственный.
• Time-to-Contain – когда остановлено распространение или снижено влияние инцидента.
• Time-to-Eradicate – когда устранена причина инцидента.
• Time-to-Recover – когда восстановлена нормальная работа (но главное договорится, что такое «восстановлена нормальная работа»).
• Time-to-Learn / Improve – когда обновлены правила, playbook, архитектурные меры и проведено обучение аналитиков.

Число правил ведет к инфляции сигналов тревоги. Больше правил не равно лучшее обнаружение. Если KPI – «написать больше правил обнаружения», люди начинают плодить слабые, шумные и узкие правила, вплоть до правил под отдельные IOC вроде IP-адресов.

Аналогичная история не только с правилами обнаружения, но и с use cases, которые иногда тоже оценивают по их числу, а не качеству.

Объем логов не имеет отношения к их ценности. У NCSC есть отличный пример: один SOC собирал крупный поток логов, но из-за ошибки получал только первые 30 символов каждой записи и этого никто не заметил, потому что мерили объем, а не пригодность данных для обнаружения.

NCSC делает, как по мне, так не очень корректный вывод. По их мнению единственная метрика, реально показывающая эффективность SOC, – обнаруживает ли он атаки и реагирует ли на них вовремя. Но поскольку реальные успешные атаки редки и не всегда видимы, то эту метрику надо проверять через red team, purple team и тесты Atomic Red Team. Это было бы верным утверждением, если бы мы говорили только о технической стороне вопроса. Но атака атаке рознь – разные последствия, разные цели, разные атакующие… Учитывать надо бизнес-контекст, но об этом чуть дальше.

При этом NCSC не говорит «не измеряйте тикеты вообще». Они говорят: такие метрики могут быть полезны SOC-менеджеру для оценки внутреннего здоровья сервиса (health check), но их опасно репортить наверх или превращать в KPI аналитиков.

В этом плане интересна позиция Google Cloud, у которой тоже есть относительно свежий материал по метрикам SOC. Они говорят о парадоксе – SOC существует давно, метрики обсуждают уже десятилетиями, но до сих пор нет общепринятого «золотого списка». Причина в том, что SOCи разные – SOC оборонного подрядчика и SOC сети сельских больниц (интересный, конечно, у них пример) должны измеряться по-разному. Поэтому «copy-paste» метрик не работают.

Но я регулярно слышу вопрос-просьбу: «А вы можете поделиться списком метрик для SOC?» 🙂

Дальше Google Cloud пишет то, что я могу только подтвердить из своего опыта. Во-первых, метрика без контекста – это просто число. MTTD (mean time-to-detect) сам по себе может выглядеть прекрасно, но если ради снижения MTTD резко выросла доля ложных срабатываний, SOC стал не лучше, а хуже. Например, MTTD меньше минуты выглядит красиво, но при 95% false positive это сомнительный успех; лучше 5 минут MTTD при 10–20% false positive, чем «молниеносная» фабрика мусора.

Это к разговору о магической троице «1-10-60», о которой я писал 8 лет назад и которую до сих пор считают догмой.

Во-вторых, нельзя путать метрики инструмента и метрики SOC. Встроенные дашборды SIEM/XDR/SOAR часто показывают эффективность продукта, а не ценность SOC для бизнеса. Это то, почему на заявления вендора про то, как классно работает его продукт, я рекомендую отвечать, что: «ваш дашборд показывает, что ваша коробка работает, но не доказывает, что мы лучше защищены».

Вообще, темы измерения эффективности и ее визуализации на дашбордах или в отчетах, очень тесно связаны между собой. Я поэтому эти две темы в связке читаю на курсе «SOC 2.0».

В-третьих, метрики должны быть связаны в пирамиду: тактические → операционные → стратегические. Тактические метрики помогают улучшать процесс, операционные – управлять SOC и квалификацией аналитиков, стратегические – объяснять ценность CISO/совету директоров/бизнесу. Google прямо говорит, что эти три уровня метрик должны быть взаимосвязаны, иначе отдельные показатели не объясняют реальную картину. Ох, мне прям нравится эта история. Я про нее уже черт знает сколько лет говорю в выступлениях на тему SOCов, и вот и Google про нее тоже заговорил.

Наконец, Detection engineering – центральное звено для улучшения. Фокус надо смещать с «сколько тикетов закрыли» на «как улучшаются детекты, автоматизация и качество триажа». Как пишет Google, это позволяет пробросить мостик от SOC как диспетчерской к SOC как инженерной функции.

И Google и NCSC сходятся в том, что метрики должны менять поведение, а не украшать отчет. Если метрика ни на что не влияет, то она превращается в обычный шум. Если приводит к неправильному поведению, то она вредна. Дальше, скорость без качества опасна. MTTD/MTTR/TTD/TTR нужны, но только вместе с оценкой качества: число true positive, груз false positive, полнота расследования, корректность эскалации, покрытие use cases. Оба согласы в том, что нельзя давать бизнесу «количество закрытых алертов» как доказательство защищенности компании или ее отдельных систем и процессов.

Интересное замечание. Матрица ATT&CK является полезной основой для оценки покрытия детектами, но только если предварительно проведено моделирование угроз. NCSC предупреждает, что простое отслеживание покрытие матрицы MITRE позволяет недобросовестным вендорам заявлять «идеальное покрытие» в узких условиях, которые часто не описаны. Поэтому покрытие ATT&CK хорошо только с привязкой к релевантным угрозам, тестам и качеству детектов.

Возвращаясь к описанному выше про отсутствие единой метрики для всех инцидентов, могу привести пример разных временных метрик и разных SLA/SLO на отдельные типовые этапы и классы инцидентов:

И если зациклить это на историю с Delta, то у нас будет не метрика: «мы реагируем на все инциденты за 20 минут», а что-то такое:

• «Критический инцидент должен быть взят в триаж за 15 минут».
• «Хост с подтвержденным вредоносом должен быть изолирован за 10 минут после подтверждения».
• «Компрометированная учетная запись должна быть заблокирована или переведена в контролируемый режим за 15 минут после подтверждения».
• «Кризисная команда должна быть собрана за 30 минут после объявления инцидента с приоритетом P1».

И даже это работает только при наличии трех вещей. Во-первых, классификация инцидентов. Нельзя управлять временем реакции, если все называется просто «инцидент ИБ». Во-вторых, описанные playbook’и. Без них время реакции зависит от героизма конкретного аналитика, а не от процесса. И наконец, понятные полномочия. SOC может обнаружить проблему за 5 минут, но если для блокировки учетной записи нужно согласование трех начальников, реальное время реагирования будет не технической, а организационной метрикой.

Тут в одной компании произошел инцидент с шифровальщиком, который был достаточно быстро обнаружен, но локализовать его не могли несколько дней, так как никто не мог принять решение об отключении «нулевого пациента» – все пытались переложить ответственность на другого менеджера. И так, пока не дошло до большого начальника спустя дни, который и приказал вырубить процесс, из-за которого все и началось.

И тут мы возвращаемся к формализации процессов, из-за которых в Delta так четко выстроен процесс выгрузки багажа. В ИБ тоже самое. Вместо «расследовать подозрительную активность учетной записи» должна быть прописана конкретная последовательность, например:

1. Проверить источник алерта.
2. Найти последние успешные и неуспешные входы.
3. Проверить географию, ASN, устройство, User-Agent.
4. Посмотреть MFA-события.
5. Проверить новые токены, правила пересылки почты, изменения прав.
6. Сравнить активность с обычным поведением пользователя.
7. При таких-то признаках – эскалировать как подозрение на компрометацию учетной записи.
8. При таких-то признаках – закрыть как нормальное событие / ложное срабатывание.
9. При подтверждении – выполнить локализацию учетной записи: сброс всех активных сессий, смена пароля, отзыв выданных токенов, блокировка правил пересылки и т.п.

Такая детализация позволяет посчитать время, затрачиваемое на каждый шаг, оценить медиану, и сложить все вместе, которую и брать за основу значения своей метрики. Без таких детализированных плейбуков оценивать время реагирования практически бессмысленно. Один аналитик проверит 15 вещей, другой – 3 вещи, третий сразу закроет как ложное срабатывание, четвертый эскалирует без проверки. Формально все «отреагировали», но качество реакции разное.

Так, что-то я расписался на свою любимую тему, надо останавливаться, хотя сказать есть еще что; хотя бы про ту же зрелость SOC, которую я не очень люблю в виду ее не очень большой практической пользы. Думаю, надо тоже что-то написать про это. Но уже в одной из следующих заметок.

На основе описанных в этой статье материалов обновлю свою презентацию для нашего курса «Построение SOC 2.0: от концепции до реализации«, который разработан Positive Education и где я читаю несколько разделов, в том числе и по метрикам SOC. Хотя большую часть описанного я там и так включил по собственному опыту.