Измерение эффективности SOC. Часть 2

В конце прошлого года в России прошел SOC Forum, на сайте которого был проведен опрос среди владельцев центров мониторинга ИБ. По результатам опроса стало очевидно, что число SOC, использующих метрики для измерения эффективности, совсем невелико. С первой частью обзора ситуации в этой сфере можно ознакомиться в предыдущем номере нашего журнала. Продолжим рассмотрение метрик, показывающих эффективность инвестиций в SOC.

Автор: Алексей Лукацкий, консультант по информационной безопасности

Процент инцидентов, переданных аналитикам второй линии (от L1 к L2)

Эта метрика показывает эффективность команды аналитиков первого уровня, принимающей на себя все сигналы тревоги. Более высокие значения этой метрики будут влиять на команду L2 и могут указывать на низкий уровень знаний и компетенций аналитиков L1, что говорит о потребности в обучении сотрудников этой линии SOC, а также о неэффективном обмене информацией.

Процент точности эскалации

Связанная метрика – процент точности эскалации на вторую линию. Она также показывает эффективность команды аналитиков первого уровня. Более высокие ее значения будут влиять на команду L2 и так же, как и в предыдущем случае, подчас указывают на низкую квалификацию аналитиков L1, которые могут, не разбираясь, транслировать все инциденты на вторую линию, пытаясь сохранить установленный для них SLA (например, 3 или 5 минут).

Число ложных срабатываний

Еще одна полезная метрика – число ложных срабатываний, ее значение должно быть минимизировано. Более высокие значения могут указывать на плохую конфигурацию инструментов информационной безопасности, в том числе и инструментов, используемых в самом центре мониторинга.

Число открытых инцидентов первого уровня

Наконец, еще одним интересным показателем эффективности SOC является число открытых инцидентов первого, то есть критического или высокого уровня (зависит от принятой градации серьезности инцидентов). Значение этой метрики должно быть минимизировано, поэтому более высокие значения могут указывать на плохую конфигурацию инструментов ИБ, в том числе и инструментария SOC.

Что обычно измеряют российские SOC?

Вот небольшой пример метрик, с которыми мне приходилось сталкиваться в рамках проектов по аудиту SOC:

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

И конечно, российские SOC, как и многие другие по миру, измеряют временные параметры: время обнаружения, время реагирования, время локализации инцидента, количество новых выявленных угроз, а также количество разборов на новые угрозы.

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

Мне приходилось сталкиваться и с иными метриками, назову самые значимые из них:

1. Число закрытых требованиями нормативных актов по безопасности критической информационной инфраструктуры сегментов, бизнес-подразделений или устройств. Такие НПА требуют, чтобы мы мониторили все объекты КИИ, так что это может быть интересной метрикой, если наш SOC создавался именно под выполнение ФЗ-187 и подзаконных актов ФСБ или ФСТЭК.
2. Число отправленных в НКЦКИ или ФинЦЕРТ инцидентов. Метрика, больше говорящая нам о том, как мы выполняем требования законодательства, чем о качестве работы SOC.
3. Показатели загрузки аналитиков SOC. Это очень полезный показатель, который помогает выявить лентяев или просто неквалифицированных аналитиков и позволяет либо перестроить работу на линиях мониторинга, либо пересмотреть планы обучения аналитиков.
4. Количество пройденных аналитиками SOC-тренингов.
5. Процент эффективных Рlaybook. Метрика, говорящая о том, насколько мы знаем, с чем надо бороться, и насколько хорошо выстроены процессы в нашем SOC.
6. Процент используемых сервисов SOC. Когда SOC только строится, в нем может быть открыто много разных сервисов, начиная от мониторинга и реагирования на инциденты и заканчивая фишинговыми симуляциями, Red Team и проведением киберучений. Эта метрика позволяет оценить, насколько востребованы открытые сервисы и не надо ли пересмотреть каталог наших предложений во внешний (по отношению к SOC) мир.
7. Процент эффективных Use Case. Метрика, аналогичная предпоследней, но применительно к Use Case, а не Playbook.
8. Многое другое, в зависимости от ситуации.

А как в других странах?

Интересное наблюдение можно сделать, отслеживая метрики, которые используют зарубежные центры мониторинга. Крупные SOC меньше внимания уделяют числу инцидентов и времени восстановления после них. Гораздо большее значение для них имеет число эскалированных инцидентов, время простоя и время устранения последствий от выявленных инцидентов. Небольшие центры мониторинга, наоборот, сфокусированы на оценке длительности простоев и потерь для бизнеса.

Другие интересные метрики

Стоит отметить нижеследующие метрики, используемые в SOC:

• число пострадавших активов и устройств;
• финансовая стоимость инцидента с точки зрения затрат на "разруливание" инцидента, а не потерь от него для бизнеса;
• число инцидентов, произошедших по причине известных уязвимостей;
• число инцидентов, закрытых за одну смену;
• привязка к MITRE ATT&CK или стадиям Kil Chain.

Еще одна интересная, но очень редкая метрика, которую далеко не всегда способны посчитать даже руководители бизнес-подразделения, не говоря уже о начальстве SOC, – это соотношение понесенных и предотвращенных потерь.

Крупные SOC меньше внимания уделяют числу инцидентов и времени восстановления после них. Гораздо большее значение для них имеет число эскалированных инцидентов, время простоя и время устранения последствий от выявленных инцидентов. Небольшие центры мониторинга, наоборот, сфокусированы на оценке длительности простоев и потерь для бизнеса.

В заключение приведу еще одну интересную метрику, с которой мне приходилось сталкиваться в одном из проектов по аудиту SOC, которые мы вели. Это стоимость учетной записи клиента компании в Darknet (компания была финансовая). Если вдуматься, то это действительно очень интересный показатель, так как его снижение показывает, что злоумышленникам становится проще получать доступ к святая святых финансовой организации. Если он растет, то усилия ИБ заставляют хакеров тратить на получение клиентских данных больше времени, усилий, денег. И самое интересное, что именно SOC, а точнее служба Threat Intellgence (TI), позволяет учитывать данную метрику, так как именно она следит за Darknet и собирает оттуда структурированную или не очень информацию (или привлекает для этого внешние сервисы).

Интересно, что сейчас на Западе наблюдается тенденция отказа от метрик, под которые аналитики подгоняют свои результаты, например таких, как число закрытых тикетов или кейсов в расчете на аналитика, приводящих к созданию фейковых тикетов в системах SOC. Россия пока еще не достигла такого уровня зрелости.

Анализ данных SOC с помощью SIEM

Подходя к завершению обзора, мне хотелось бы обратить внимание на средства, с помощью которых анализируются данные и оценивается эффективность SOC. В этом вопросе российские центры мониторинга не очень сильно отличаются от SOC во всем мире. Более половины респондентов полагается на SIEM, так как именно это решение позволяет собирать и накапливать всю необходимую информацию об инцидентах и может на ее основе выстраивать различные численные показатели эффективности деятельности по мониторингу и реагированию на инциденты. Однако большинство владельцев SOC не удовлетворены результатами такой оценки, так как, на мой взгляд, SIEM более подходит для оценки тактических, операционных метрик, но не стратегических. На втором месте по популярности находятся различные самописные системы, например Excel, инструментарий Open Source типа Grafana, а также использование решений типа Power BI, Tableau и т.п., которые умеют по API забирать нужные данные и визуализировать их, а также производные на их основе. Интересно, что сейчас на Западе наблюдается тенденция отказа от метрик, под которые аналитики подгоняют свои результаты, например таких, как число закрытых тикетов или кейсов в расчете на аналитика, приводящих к созданию фейковых (легко открываем и закрываем) тикетов в системах SOC. Россия пока еще не достигла такого уровня зрелости, потому что сам процесс измерения эффективности еще не выстроен на должном уровне. Как только у нас SOC научатся собирать данные и оценивать на их основе свою эффективность, можно будет говорить о качестве этих метрик и их улучшении.

Как отслеживаются и рапортуются метрики SOC

Проведенный опрос показал, что в 45% случаев и в России, и в мире данная задача частично автоматизирована. Примерно у 30% владельцев SOC она преимущественно автоматизирована, а число ручных операций сведено к минимуму. Хотя эти цифры выглядят достаточно странно, учитывая, что большинство владельцев SOC не удовлетворены тем, как их SIEM решает эту задачу, а ведь им пользуются в основном для измерения эффективности. По сути, мы сталкиваемся с классическим анекдотом про мышей, которые плакали, кололись, но продолжали кушать кактус. В целом визуализация метрик ИБ и, в частности, SOC – это высший пилотаж в работе любого SOC, и она требует отдельного внимания и навыков, зачастую отличных от тех, которые нужны при сборе и вычислении метрик.

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

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

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

Таблица 1

Как же правильно измерять эффективность SOC?

В заключение обзора ситуации с измерением эффективности центров мониторинга безопасности мне хотелось бы подвести итог и ответить на вопрос "Как же правильно измерять эффективность SOC?".

Во-первых, это нужно делать не снизу вверх, отталкиваясь от принципа "У меня есть данные, что я могу из них выжать?", а сверху вниз, следуя принципу "У меня есть цель, какие данные мне для этого нужны?".

Во-вторых, мы должны ответить на вопросы:

1. Почему мы тратим деньги на SOC?
2. Зачем нам нужен центр мониторинга? Этого требует законодательство, это модно или это потребность бизнеса?
3. Что важно нашему руководству и почему?

Когда вы ответите на эти вопросы (а они на самом деле очень простые), появится возможность выбрать нужные метрики, которые будут привязаны либо к различным законодательным аспектам, либо к бизнес- показателям. Либо следует опираться на так называемые общепринятые метрики (о некоторых из них я говорил выше) и многие другие, описанные в различных презентациях, книгах и статьях по теме оценки эффективности информационной безопасности. Однако я бы советовал не ориентироваться в этом вопросе на чужой опыт. Без понимания задач, исходных данных и условий бездумное использование чужих метрик окажется совершенно бессмысленным. Лучше понять, зачем именно вам нужен SOC и что вы хотите от него получить, а только потом выбирать метрики, которые и дадут ответы на эти вопросы. Может быть, именно поэтому 80% российских SOC не измеряют свою эффективность и не знают, зачем они создавались?.. Надеюсь, что нет!