О необходимости регулярного пересмотра метрик в SOC

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

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

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

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

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