Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №10 «Применяйте метрики оценки эффективности для улучшения работы SOC»

Руслан Рахметов, Security Vision

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

В рамках описания данной стратегии авторы используют следующие термины:

- Показатель/метрика: показатель является единичной величиной (например, количество инцидентов в месяц), а метрика может быть комплексной величиной (например, изменение количества инцидентов год к году в процентах);

- КПЭ, ключевые показатели эффективности (англ. KPI, Key Performance Indicator): показатели/метрики, которые демонстрируют достижение ключевых бизнес-целей;

- Оценка: подход, процесс или способ оценки, в результате чего формируются показатели/метрики. 

1. Элементы программы метрик SOC-центра

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

- Бизнес-цели: причина проведения измерений эффективности работы SOC;

- Источники данных и сбор информации: сведения о работе SOC, которые можно использовать для формирования показателей/метрик;

- Синтез, анализ данных: формирование метрик на основании полученной информации;

- Отчетность: представление метрик стейкхолдерам;

- Принятие решений и действия: дальнейшее использование сформированных метрик. 

1.1. Бизнес-цели:

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

1.1.1. Внутренние бизнес-цели:

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

- Улучшения эффективности и качества действий аналитиков (мониторинга, выявления, расследований и т.д.);

- Контроля качества и стабильности функционирования систем и инструментов SOC-Центра;

- Непрерывного улучшения и оптимизации процессов SOC;

- Оценки и устранения недостатков в выявлении и предотвращении TTPs атакующих (например, оценивая TTPs в соответствии с матрицей MITRE ATT&CK);

- Понимания и оценки готовности SOC-центра к новым целям, функционалу, инструментам, которые планируются к внедрению (например, готов ли SOC-центр к проактивному поиску киберугроз, анализу ВПО, внедрению deception-решения).

1.1.2. Внешние бизнес-цели:

Аудиторией для результатов оценки достижения внешних бизнес-целей будут заказчики услуг SOC: руководители, стоящие «над» SOC, управляющий комитет SOC-центра, руководители ИТ-блока, владельцы ИТ-сервисов, а также те, кто оплачивает услуги, предоставляемые SOC-центром. При оценке эффективности также часто используют такие метрики, как SLA и SLO: SLA (Service Level Agreement, соглашение об уровне оказываемых услуг) - это обязательные и утвержденные контрактами и соглашениями показатели, за несоответствие которым могут налагаться штрафы; SLO (Service Level Objective, цель уровня обслуживания) - это показатели, характеризующие работу SOC, обязанность соответствия которым не утверждено юридически. Внешние способы оценки могут использоваться для:

- Отражения состояния и уровня готовности SOC-центра к выполнению своих функций в разрезе персонала, процессов, технологий;

- Контроля соответствия SLA и SLO ожиданиям потребителей услуг SOC-центра;

- Контроля соответствия инфраструктуры заказчиков требованиям по кибербезопасности;

- Демонстрации окупаемости затрат в кибербезопасность. 

1.1.3. Бизнес-цели для использования вне SOC:

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

- Контроля прогресса внедрения мер защиты информации;

- Эффективность результатов применения мер защиты информации;

- Влияние работы SOC на бизнес компании-заказчика, включая отчетность по инцидентам, отработанным в SOC;

- Вклад SOC в общие показатели кибербезопасности и киберрисков компании-заказчика. 

1.2. Источники данных и сбор информации

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

- Системы Log Management и SIEM, аналитические платформы;

- Тикетинг-системы, системы кейс-менеджмента, SOAR-платформы;

- Репозитории SOC-центра, системы управления задачами для DevOps;

- Системы контроля за расходованием бюджета SOC-центра;

- Системы управления активами;

- Системы управления уязвимостями и сканированиями на наличие уязвимостей;

- Платформы эмуляции кибератак. 

Для оценки эффективности SOC можно также использовать следующие способы формирования данных для анализа:

- Результаты проведения учений и эмуляций кибератак: тренировки, учения, эмуляция реагирования на критичные инциденты помогут оценить, как SOC будет вести себя в «боевых» условиях и оценить качество процессов, коммуникации, действий по реагированию;

- Фокусные технические оценки эффективности: проведение мероприятий Red/Purple Team, использование специальных платформ эмуляции кибератак помогут оценить опасность актуальных киберугроз и проверить реагирование на них;

- Использование фреймворков для оценки зрелости SOC: комплексная оценка персонала, процессов и технологий SOC-центра поможет составить более целостную картину состояния SOC; такую оценку можно проводить с применением открытых фреймворков (например, с помощью NIST Cybersecurity Framework или SOC-CMM). 

1.3. Синтез, анализ данных

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

1.4. Отчетность

Следует определить формат и целевую аудиторию для формируемой отчетности. Авторы рекомендуют:

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

- Учитывайте возможность дальнейшей работы с отчетностью: метриками и отчетностью смогут обмениваться различные сотрудники компании, поэтому наряду с отчетом следует приводить и использовавшуюся методологию. Кроме того, следует быть готовым к необходимости предоставить доступ к «сырым» техническим данным, на основании которых отчетность была сформирована;

- Используйте формат, принятый у заказчика: для построения отчетности рекомендуется использовать инструменты, с которыми работает компания-заказчик и которые позволяют автоматизировать обновление данных в отчете;

- Используйте визуализацию: применение средств визуализации поможет лучше донести информацию до аудитории. 

1.5. Принятие решений и действия

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

2. Использование услуг сторонней организации для оценки работы SOC

Авторы публикации указывают, что для реализации некоторых элементов программы метрик SOC-центра может потребоваться помощь сторонней организации для оценки эффективности. Независимая внешняя экспертиза оценит состояние SOC-центра свежим взглядом, поможет выявить незамеченные ранее сложности, сможет привлечь для оценки дефицитных специалистов, а также позволит удовлетворить нормативные требования. Самым логичным вариантом будет привлечение другого SOC-центра для проведения независимой экспертизы эффективности: это может быть SOC, с которым установлены партнерские отношения, координирующий SOC или национальный SOC; такие SOC-центры часто предлагают подобные услуги, у них может быть уже разработана методология оценки эффективности и присутствовать понимание контекста деятельности SOC. Кроме того, можно обратиться к специализированным консалтинговым компаниям, у которых есть соответствующий опыт и фреймворки для проведения оценки. В случае проведения независимой оценки деятельности SOC-центра со стороны сторонней организации, следует обеспечить корректную передачу запрашиваемой информации, наладить сотрудничество работников SOC и представителей оценивающей организации, а также обеспечить защиту передаваемой вовне информации и обеспечить юридическое обеспечение проведения оценки, например, с помощью подписания соглашения о неразглашении. 

3. Примеры метрик оценки эффективности SOC

В публикации приводятся следующие советы и рекомендации по применению метрик оценки эффективности SOC:

- Не все метрики применимы ко всем SOC-центрам и во всех ситуациях: следует ориентироваться на размер и задачи SOC для выбора применимых метрик оценки эффективности;

- Некоторые метрики могут быть технически невыполнимы в определенных случаях и в определенных SOC;

- Адаптируйте используемые метрики для целевой аудитории: разные лица могут быть заинтересованы в получении различных метрик, при этом могут возникнуть сложности в случае использования метрик, которые будут непонятны тому, кто не работает непосредственно в SOC-центре;

- Следует использовать компенсирующие меры контроля для метрик, с которыми могут производиться манипуляции («читинг») со стороны сотрудников SOC-центра;

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

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

3.1. Примеры метрик для оценки достижения внутренних бизнес-целей:

- Состояние «здоровья» инструментов и технологий SOC;

- Состояние «здоровья» источников данных;

- Задержка данных при обработке инструментами SOC;

- Охват матрицы MITRE ATT&CK средствами обнаружения;

- Соотношение ложноположительных и истинноположительных предупреждений / инцидентов;

- Скорость разработки правил обнаружения и их количество;

- Соотношение инцидентов, обработанных аналитиком по сценариям с помощью средств автоматизации, к инцидентам, обработанных аналитиком вручную;

- Объем предупреждений / инцидентов, эскалированных в результате триажа на следующий уровень, которые были затем закрыты как истинноположительные инциденты;

- Объем предупреждений / инцидентов, по которым не проводилось дальнейшее реагирование;

- Время, затраченное аналитиками на рутинные операции;

- Время, затраченное аналитиками на работу с программой метрик. 

3.2. Примеры метрик для оценки достижения внешних бизнес-целей:

- Уровень готовности SOC к выполнению своих задач;

- Медианное/среднее время выявления инцидента (от момента первичного проникновения атакующих в инфраструктуру до момента их выявления);

- Медианное/среднее время реакции SOC на обращение заказчика (с помощью заявки, звонка, email о подозрении на инцидент);

- Медианное/среднее время реагирования на инцидент (от момента выявления кибератаки до выполнения действий по активному реагированию);

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

- Медианное/среднее время устранения угрозы (очистка инфраструктуры от присутствия атакующих);

- Назначение владельцев для активов (следует стремиться к 100% охвату для всех типов активов и используемых инфраструктур);

- Управление активами (следует стремиться к 100% охвату процессом управления активами, включая управление конфигурациями и патч-менеджментом, для всех типов активов и используемых инфраструктур);

- Охват сканирования (следует стремиться к 100% процентному охвату активов процессом сканирования на наличие уязвимостей);

- Охват мониторинга (следует стремиться к 100% процентному охвату активов процессом ИБ-мониторинга);

- Глубина мониторинга (процент охвата мониторингом активов на аппаратном, системном, прикладном уровне, учитывая также полноту мониторинга по матрице MITRE ATT&CK);

- Распределение количества инцидентов по заказчикам;

- Распределение количества инцидентов по атакующим (если они были установлены). 

3.3. Примеры метрик для оценки достижения бизнес-целей для использования вне SOC:

- Установка обновлений безопасности (целевым значением может быть 90% активов, пропатченных в течение 7 дней для стандартной процедуры);

- Неустановленные обновления безопасности (обновления доступны, но не установлены по разным причинам; целевым значением должно быть отсутствие таких явлений, если только этот риск не был корректно обработан);

- Присутствие ПО с истекшим (end-of-life) сроком эксплуатации (целевым значением должно быть отсутствие таких явлений, если только этот риск не был корректно обработан);

- Утилизация ИТ-ресурсов (загрузка аппаратных мощностей, использование ПО);

- Выполнение тренингов по ИБ;

- Результаты учебных фишинговых рассылок (процент пользователей, перешедших по ссылке в учебной фишинговой рассылке (цель - менее 5%), и сообщивших о полученной рассылке (цель - более 50%));

- Использование и корректность работы СЗИ (например, охват инфраструктуры установленными и обновленными антивирусами, средствами проверки подписи исполняемого кода, с целевым значением 100%);

- Использование высокорисковых сервисов (использование в инфраструктуре сервисов с известными уязвимостями или доступными из интернет);

- Использование высокорисковых учетных записей (использование постоянных учетных записей с административными привилегиями). 

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