Помню 2 года назад, на SOC Forum, я выступал в модерируемой мной с Дмитрием Мананниковым секции по оценке эффективности SOC. В рамках своей презентации я описывал возможные подходы к оценке SOC различных точек зрения - технической, процессной, бизнеса и т.п. За прошедшие два года я не раз сталкивался с различными центрами мониторинга, создатели которых, построив неплохую инфраструктуру, набрав специалистов и даже выстроив отдельные процессы, так и не смогли правильно оценивать свою деятельность. Участвуя в различных проектах по консалтингу SOC, а также имея доступ к нашей базе знаний по этой теме, могу отметить, что происходит это по двум основным причинам (движение снизу вверх вместо движения сверху вниз и плохо управляемые ожидания при создании SOC). В обоих случаях мы не понимаем, ЗАЧЕМ нам нужен SOC? Именно нам, а не кому-то. Для нашего бизнеса. Для нашей ИТ-инфраструктуры. Для нашей оргштатной структуры. Для нашего руководства. Чтобы это сделать надо двигаться сверху вниз - от стоящих задач к способам их решения. От них же, кстати, будет зависеть и все остальное, - архитектура, технологии, люди, процессы и т.п.
Но на практике обычно все бывает иначе. Поддавшись моде или желая замутить что-то новое инвестируются десятки и сотни миллионов рублей в прорывные технологии "из гартнера", нанимаются за бешеные деньги аналитики ИБ, закупаются сервисы Threat Intelligence из десятков источников, а потом приходит руководство и спрашивает "И что? Где результат?" И показать нечего. Но есть ряд метрик, которые все-таки можно использовать для того, чтобы показать эффективность своего SOC. Пусть не на бизнес-уровне, но хотя бы на уровне, понятном любому безопаснику. Для чего мы создаем SOC на понятийном уровне? Чтобы оперативнее обнаруживать и реагировать на угрозы. Это очевидно и именно это можно на первых порах поставить во главу угла своей программы (до момента осознания реальной потребности в SOC и стоящих перед ним задач).
Обычно выделяют 3 основных метрики, которые показывают:
Измерить эти показатели проще простого, как и отслеживать их динамику. Но стоит помнить, что для разных угроз/инцидентов эти значения будут разные (хотя их и можно свести к некому единому показателю). Это по требованиям ФСБ в ГосСОПКУ данные передаются в течение 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.
Но на практике обычно все бывает иначе. Поддавшись моде или желая замутить что-то новое инвестируются десятки и сотни миллионов рублей в прорывные технологии "из гартнера", нанимаются за бешеные деньги аналитики ИБ, закупаются сервисы Threat Intelligence из десятков источников, а потом приходит руководство и спрашивает "И что? Где результат?" И показать нечего. Но есть ряд метрик, которые все-таки можно использовать для того, чтобы показать эффективность своего SOC. Пусть не на бизнес-уровне, но хотя бы на уровне, понятном любому безопаснику. Для чего мы создаем SOC на понятийном уровне? Чтобы оперативнее обнаруживать и реагировать на угрозы. Это очевидно и именно это можно на первых порах поставить во главу угла своей программы (до момента осознания реальной потребности в SOC и стоящих перед ним задач).
Обычно выделяют 3 основных метрики, которые показывают:
- время обнаружения угрозы (Time-to-Detect, TTD)
- время локализации угрозы, включая расследование (Time-to-Contain, TTC)
- время реагирования на угрозу (Time-to-Response, TTR).
Иногда еще добавляют и время восстановления после угрозы (Time-to-Remediate, TTR). Визуально связь между этими метриками выглядит следующим образом:
Измерить эти показатели проще простого, как и отслеживать их динамику. Но стоит помнить, что для разных угроз/инцидентов эти значения будут разные (хотя их и можно свести к некому единому показателю). Это по требованиям ФСБ в ГосСОПКУ данные передаются в течение 24 часов с момента обнаружения (хотя правильнее говорить, регистрации) инцидента независимо от его природы. Но мы с вами прекрасно понимаем, что время обнаружения спама, время обнаружения группировки Cobalt и время обнаружения соединения с командными серверами ботнетов могут сильно отличаться. Вот как, например, выглядит распределение данных показателей в одном из отчетов службы реагирования на инциденты 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.
Спасибо за пост! Я живу за границей, только недавно открыл для себя ваш ИБ блог. Очень полезно про метрику
ОтветитьУдалить