Правило «1-10-60» или три метрики SOC, когда вы не знаете как правильно измерить свой центр мониторинга ИБ

Помню 2 года назад, на SOC Forum, я выступал в модерируемой мной с Дмитрием Мананниковым секции по оценке эффективности SOC. В рамках своей презентации я описывал возможные подходы к оценке SOC различных точек зрения — технической, процессной, бизнеса и т.п. За прошедшие два года я не раз сталкивался с различными центрами мониторинга, создатели которых, построив неплохую инфраструктуру, набрав специалистов и даже выстроив  отдельные процессы, так и не смогли правильно оценивать свою деятельность. Участвуя в различных проектах по консалтингу SOC, а также имея доступ к нашей базе знаний по этой теме, могу отметить, что происходит это по двум основным причинам (движение снизу вверх вместо движения сверху вниз и плохо управляемые ожидания при создании SOC). В обоих случаях мы не понимаем, ЗАЧЕМ нам нужен SOC? Именно нам, а не кому-то. Для нашего бизнеса. Для нашей ИТ-инфраструктуры. Для нашей оргштатной структуры. Для нашего руководства. Чтобы это сделать надо двигаться сверху вниз — от стоящих задач к способам их решения. От них же, кстати, будет зависеть и все остальное, — архитектура, технологии, люди, процессы и т.п.

Но на практике обычно все бывает иначе. Поддавшись моде или желая замутить что-то новое инвестируются десятки и сотни миллионов рублей в прорывные технологии «из гартнера», нанимаются за бешеные деньги аналитики ИБ, закупаются сервисы Threat Intelligence из десятков источников, а потом приходит руководство и спрашивает «И что? Где результат?» И показать нечего. Но есть ряд метрик, которые все-таки можно использовать для того, чтобы показать эффективность своего SOC. Пусть не на бизнес-уровне, но хотя бы на уровне, понятном любому безопаснику. Для чего мы создаем SOC на понятийном уровне? Чтобы оперативнее обнаруживать и реагировать на угрозы. Это очевидно и именно это можно на первых порах поставить во главу угла своей программы (до момента осознания реальной потребности в SOC и стоящих перед ним задач).

Обычно выделяют 3 основных метрики, которые показывают:

• время обнаружения угрозы (Time-to-Detect, TTD)
• время локализации угрозы, включая расследование (Time-to-Contain, TTC)
• время реагирования на угрозу (Time-to-Response, TTR).

Измерить эти показатели проще простого, как и отслеживать их динамику. Но стоит помнить, что для разных угроз/инцидентов эти значения будут разные (хотя их и можно свести к некому единому показателю). Это по требованиям ФСБ в ГосСОПКУ данные передаются в течение 24 часов с момента обнаружения (хотя правильнее говорить, регистрации) инцидента независимо от его природы. Но мы с вами прекрасно понимаем, что время обнаружения спама, время обнаружения группировки Cobalt и время обнаружения соединения с командными серверами ботнетов могут сильно отличаться. Вот как, например, выглядит распределение данных показателей в одном из отчетов службы реагирования на инциденты Cisco:

Обычно считается среднее арифметическое параметров TTD, TTC и TTR, но у нас в Cisco также вычисляется и медиана, — две величины лучше отражают данные временные показатели в больших выборках с широким разбросом значений.

Как итог, отчет по эффективности SOC может выглядеть так:

Это фрагмент из трехлетней давности еженедельного отчета группы реагирования на инциденты Cisco. Обратите внимание, что помимо текущих значений TTD, TTC и TTR в отчете указано и целевое значение, к которому мы стремимся. Этот показатель тоже меняется время от времени и по мере улучшения процессов и технологий, а также роста квалификации персонала, он должен уменьшаться, но никогда не достигая нуля (это нецелесообразно).

Но есть и еще одна интересная метрика, которая не столь важна для представления ее наружу, сколько для оценки внутренней эффективности выстроенных в SOC процессов, поддержанных людьми и технологиями. Эта метрика называется время прорыва (breakout time). Ее предложила в 2018 году компания CrowdStrike, которая проанализировала около 30 триллионов событий безопасности в 2017-м году, и вычислила время, которое требуется злоумышленнику, чтобы уйти с первоначального плацдарма и начать распространение внутри корпоративной или ведомственной. Это время равно 1 часу 58 минутам. Важность понимания сути этого временного окна очень высока. Оно показывает, какой запас времени у нас есть, чтобы инцидент не превратился в катастрофу; чтобы взлом, например, публичного web-сайта (как это было с Equifax), не перетек во взлом баз данных.

CrowdStrike, кстати, предложила еще одно интересное измерение для SOC — это правило «1-10-60», которое означает, что хорошо защищенная компания должна уметь обнаруживать (TTD) угрозы за 1 минуты, проводить их расследование за 10 минут, а блокировать нарушителя за 1 час. Для этого надо использовать современные технологии ИБ, которые фокусируются не на предотвращении, а на всем жизненном цикле угрозы — ДО, ВО ВРЕМЯ и ПОСЛЕ.

PS. Скоро грядет очередной SOC Forum. Пройдет он в Москве 27-28 ноября (да, два дня, а не один). Пора регистрироваться!

PPS. А 9-10 октября буду на тему SOCов выступать на CyberCrimeCon 2018.