УПРАВЛЕНИЕ

Измерение эффективности SOC

Часть 2

Алексей Лукацкий,

консультант по информационной безопасности

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

Вконце прошлого года в России прошел SOC Forum, на сайте которого был проведен опрос среди владельцев центров мониторинга ИБ. По результатам опроса стало очевидно, что число SOC, использующих метрики для измерения эффективности, совсем невелико. С первой частью обзора ситуации в этой сфере можно ознакомиться в предыдущем номере нашего журнала. Продолжим рассмотрение метрик, показывающих эффективность инвестиций в SOC. Процент ний, ее значение должно быть вроде показателя уязвимости); инцидентов, минимизировано. Более высоl количество верно выявленпереданных кие значения могут указывать ных угроз; аналитикам второй на плохую конфигурацию l процент отработанных инцилинии (от L1 к L2) инструментов информационной дентов от их общего числа; Эта метрика показыбезопасности, в том числе и l среднее время реагировавает эффективность команды инструментов, используемых в ния; аналитиков первого уровня, присамом центре мониторинга. l контроль полноты; нимающей на себя все сигналы l количество ложных срабатытревоги. Более высокие значеЧисло открытых ваний; ния этой метрики будут влиять инцидентов первого l количество обработанных на команду L2 и могут указывать уровня инцидентов; на низкий уровень знаний и комНаконец, еще одним интеl количество выполненных глопетенций аналитиков L1, что ресным показателем эффекбальных задач в SOC. говорит о потребности в обучетивности SOC является число И конечно, российские SOC, нии сотрудников этой линии открытых инцидентов первого, как и многие другие по миру, SOC, а также о неэффективном то есть критического или высоизмеряют временные параметобмене информацией. кого уровня (зависит от приняры: время обнаружения, время той градации серьезности инциреагирования, время локализаПроцент точности дентов). Значение этой метрики ции инцидента, количество эскалации должно быть минимизировано, новых выявленных угроз,

Связанная метрика – процент поэтому более высокие значеа также количество разборов точности эскалации на вторую ния могут указывать на плохую на новые угрозы. линию. Она также показывает конфигурацию инструментов Мы прекрасно понимаем, что эффективность команды анаИБ, в том числе и инструментаSOC – это не только технологилитиков первого уровня. Более рия SOC. ческий стек, наполненный больвысокие ее значения будут влишим количеством очень интеять на команду L2 и так же, как Что обычно измеряют ресных продуктов и технологий. и в предыдущем случае, подчас российские SOC? На самом деле центр монитоуказывают на низкую квалифиВот небольшой пример метринга – это также процессы кацию аналитиков L1, которые рик, с которыми мне приходии люди, деятельность которых могут, не разбираясь, транслилось сталкиваться в рамках протоже требует измерения. Мне ровать все инциденты на вторую ектов по аудиту SOC: приходилось сталкиваться и с линию, пытаясь сохранить устаl отсутствие незакрытых инцииными метриками, назову новленный для них SLA (напридентов; самые значимые из них: мер, 3 или 5 минут). l скорость реакции; 1. Число закрытых требоваl отсутствие претензий от служниями нормативных актов по Число ложных бы реагирования; безопасности критической срабатываний l количество инцидентов или информационной инфраструк

Еще одна полезная метриобщее количество выявленных туры сегментов, бизнес-подразка – число ложных срабатываи пропущенных угроз (что-то делений или устройств. Такие НПА требуют, чтобы мы мониторили все объекты КИИ, так что это может быть интересной метрикой, если наш 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: l число пострадавших активов и устройств; l финансовая стоимость инцидента с точки зрения затрат на "разруливание" инцидента, а не потерь от него для бизнеса; Рис. 2

l число инцидентов, произошедших по причине известных уязвимостей; l число инцидентов, закрытых за одну смену; l привязка к MITRE ATT&CK или стадиям Kill Chain.

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

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

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

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

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

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

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

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

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

Таблица 1

Уровень Инструментарий Функции Threat Intelligence Метрики Персонал

1 SIEM Базовый Нет фидов Метрик нет Мониторинг мониторинг событий событий (L1-L3) 2 SIEM + базовый Мониторинг событий, Базовые фиды TI Базовые метрики, Мониторинг мониторинг тюнинг контента ориентированные событий, на инструментарий разработка (например, число событий) контента 3 SIEM + NTA Базовое обнаружение Широкое использо- Метрики, ориентированные Базовый TI FTE аномалий, периоди- вание тактического на инструментарий, ческие пентесты и стратегического TI и временные метрики (TTD, TTC, TTR) 4 SIEM + NTA + EDR Анализ ВПО, базовый Широкое использо- Метрики эффективности TI FTE или отдел TI, threat hunting, вание тактического аналитиков, фокус Red Team FTE киберучения и стратегического TI, на улучшения или служба Red/Blue Team внутренняя служба TI, процессы, основанные на TI 5 SIEM + NTA + Интегрированные Широкое использование Метрики результативности, Hunting Team, EDR + SOAR мониторинг и реагиро- тактического и стратеги- доказательства улучшения Red Team, TI Team вание, Threat Hunting, ческого TI, внутренняя обнаружения продвинутая аналитика служба TI, процессы и реагирования для обнаружения основанные на TI, аномалий, Red Team обмен данными

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

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

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

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

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

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

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

3. Что важно нашему руководству и почему?

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

Ваше мнение и вопросы присылайте по адресу is@groteck.ru