Рубрикатор | ![]() |
![]() |
Блоги | ![]() |
Алексей ЛУКАЦКИЙ | ![]() |
![]() |
Правило "1-10-60" или три метрики SOC, когда вы не знаете как правильно измерить свой центр мониторинга ИБ
24 сентября 2018 |
![]() |
Помню 2 года назад, на SOC Forum, я выступал в модерируемой мной с Дмитрием Мананниковым секции по оценке эффективности SOC.
В рамках своей презентации я описывал возможные подходы к оценке SOC
различных точек зрения - технической, процессной, бизнеса и т.п. За
прошедшие два года я не раз сталкивался с различными центрами
мониторинга, создатели которых, построив неплохую инфраструктуру, набрав
специалистов и даже выстроив отдельные процессы, так и не смогли
правильно оценивать свою деятельность. Участвуя в различных проектах по
консалтингу SOC, а также имея доступ к нашей базе знаний по этой теме,
могу отметить, что происходит это по двум основным причинам (движение
снизу вверх вместо движения сверху вниз и плохо управляемые ожидания при
создании SOC). В обоих случаях мы не понимаем, ЗАЧЕМ нам нужен
SOC? Именно нам, а не кому-то. Для нашего бизнеса. Для нашей
ИТ-инфраструктуры. Для нашей оргштатной структуры. Для нашего
руководства. Чтобы это сделать надо двигаться сверху вниз - от стоящих
задач к способам их решения. От них же, кстати, будет зависеть и все
остальное, - архитектура, технологии, люди, процессы и т.п.
Но на практике обычно все бывает иначе. Поддавшись моде или желая замутить что-то новое инвестируются десятки и сотни миллионов рублей в прорывные технологии "из гартнера", нанимаются за бешеные деньги аналитики ИБ, закупаются сервисы Threat Intelligence из десятков источников, а потом приходит руководство и спрашивает "И что? Где результат?" И показать нечего. Но есть ряд метрик, которые все-таки можно использовать для того, чтобы показать эффективность своего SOC. Пусть не на бизнес-уровне, но хотя бы на уровне, понятном любому безопаснику. Для чего мы создаем SOC на понятийном уровне? Чтобы оперативнее обнаруживать и реагировать на угрозы. Это очевидно и именно это можно на первых порах поставить во главу угла своей программы (до момента осознания реальной потребности в SOC и стоящих перед ним задач).
Обычно выделяют 3 основных метрики, которые показывают:
![](/data/2018/09/24/1237479241/TTD2.png)
![](/data/2018/09/24/1237479247/ttd.png)
![](/data/2018/09/24/1237479245/TTD3.png)
![](/data/2018/09/24/1237479283/csirtTTD.png)
Но на практике обычно все бывает иначе. Поддавшись моде или желая замутить что-то новое инвестируются десятки и сотни миллионов рублей в прорывные технологии "из гартнера", нанимаются за бешеные деньги аналитики ИБ, закупаются сервисы Threat Intelligence из десятков источников, а потом приходит руководство и спрашивает "И что? Где результат?" И показать нечего. Но есть ряд метрик, которые все-таки можно использовать для того, чтобы показать эффективность своего SOC. Пусть не на бизнес-уровне, но хотя бы на уровне, понятном любому безопаснику. Для чего мы создаем SOC на понятийном уровне? Чтобы оперативнее обнаруживать и реагировать на угрозы. Это очевидно и именно это можно на первых порах поставить во главу угла своей программы (до момента осознания реальной потребности в SOC и стоящих перед ним задач).
Обычно выделяют 3 основных метрики, которые показывают:
- время обнаружения угрозы (Time-to-Detect, TTD)
- время локализации угрозы, включая расследование (Time-to-Contain, TTC)
- время реагирования на угрозу (Time-to-Response, TTR).
Иногда еще добавляют и время восстановления после угрозы
(Time-to-Remediate, TTR). Визуально связь между этими метриками выглядит
следующим образом:
![](/data/2018/09/24/1237479241/TTD2.png)
Измерить эти показатели проще простого, как и отслеживать их динамику.
Но стоит помнить, что для разных угроз/инцидентов эти значения будут
разные (хотя их и можно свести к некому единому показателю). Это по
требованиям ФСБ в ГосСОПКУ данные передаются в течение 24 часов с
момента обнаружения (хотя правильнее говорить, регистрации) инцидента
независимо от его природы. Но мы с вами прекрасно понимаем, что время
обнаружения спама, время обнаружения группировки Cobalt и время
обнаружения соединения с командными серверами ботнетов могут сильно
отличаться. Вот как, например, выглядит распределение данных показателей
в одном из отчетов службы реагирования на инциденты Cisco:
![](/data/2018/09/24/1237479247/ttd.png)
Обычно считается среднее арифметическое параметров TTD, TTC и TTR, но у
нас в Cisco также вычисляется и медиана, - две величины лучше отражают
данные временные показатели в больших выборках с широким разбросом
значений.
![](/data/2018/09/24/1237479245/TTD3.png)
Как итог, отчет по эффективности SOC может выглядеть так:
![](/data/2018/09/24/1237479283/csirtTTD.png)
Это фрагмент из
трехлетней давности еженедельного отчета группы реагирования на
инциденты 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.
Но есть и еще одна интересная метрика, которая не столь важна для представления ее наружу, сколько для оценки внутренней эффективности выстроенных в 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.
Оставить свой комментарий:
Комментарии по материалу
Данный материал еще не комментировался.