А вот теперь можно поставить и точку в длинной дискуссии о SOC и поговорить о том, что происходит, когда SOC выбран или построен, запущен и даже приносит первые плоды. Пора оценить эффективность SOC.
Я не буду сейчас вдаваться в вопрос, что такое эффективность и можно ли измерять ее деньгами или только немонетарными метриками. Это вопрос отдельный и непростой. Лучше сразу обратиться к вопросу измерения. Оно может разбиваться на две больших части - эффективность процессов ИБ, реализуемых в SOC (число отраженных инцидентов в их числе или в предотвращенных потерях, устраненных уязвимостей и т.п), и эффективность самого SOC (число сотрудников, оперативность реагирования и т.п.). Если мы строим SOC собственный, то нас должны, в первую очередь, интересовать метрики первой категории. В случае с аутсорсинговым SOCом, заказчика также интересуют первый вид измерений, а его владельца, как правило, второй.
Универсального перечня метрик для SOC не существует и каждая организация выбирает свой набор - в зависимости от задач, сервисов, уровня зрелости. В любом случае не стоит измерять просто число проанализированных событий в пересчете на аналитика SOC. Выглядит красиво, но никакой ценности для конечного результата не имеет. Также как и отношение числа "сырых" к числу скоррелированных событий.
Почему эти показатели не очень интересны? А они условны и ничего не говорят о реальном уровне защищенности организации. Более того, причиной изменения этих значений может быть куча разных причин. Вот пара примеров, которые я привожу в рамках курса по измерению эффективности.
Гораздо более интересны различные временные параметры. Например, время отклика на события из сферы действия того или иного сервиса SOC (инцидент, уязвимость) - время обнаружения, время реагирования, время устранения. Также может быть интересно среднее время реагирования на инцидент (с привязкой к приоритету инцидента). Но в последнем случае стоит обратить внимание, что сотрудники SOC могут подгонять свои показатели деятельности под целевое значение.
Например, стоит задача - оценить время реагирования на звонок об инциденте. За снижение этого времени аналитик SOC может быть поощрен. В самом худшем случае сотрудник будет класть трубку сразу после звонка. В этом случае время реагирования будет минимальным, а премия максимальной. Если поощрять аналитиков за число разрешенных инцидентов, то сотрудники будут самостоятельно пытаться закрыть инцидент, не эскалируя его правильному специалисту. В итоге увеличивается время реагирования, длительность звонков и ожидания клиентов на линии, доступных аналитиков становится меньше – удовлетворенность клиентов становится ниже.
Но время - не единственное, что может быть интересно и нужно измерять. Например, соотношение открытых и закрытых инцидентов. Или стоимость инцидента (расследование, восстановление, общение с прессой, юридические издержки и т.п.). Или уровень терпимости к рискам - тоже очень интересная метрика, по которой нельзя оценивать сам SOC, но которую он может генерить для более высокоуровневых измерениях.
Если SOC среди услуг по реагированию на инциденты предлагает функции реконфигурации средств защиты, сетевого оборудования, ОС, СУБД и т.п., то их можно оценивать следующим образом:
Наверное, эту тему можно продолжать бесконечно. Особенно, если SOC рассматривать именно как центр управления всей ИБ, а не только реагирования на инциденты. В таком случае метрик может быть огромное количество и задача создателей/заказчиков SOC выбрать для себя те, которые лучше соответствуют поставленным на конкретный интервал времени задачам.
В заключение приведу еще один набор метрик оценки эффективности SOC, которые предлагает HP в рамках предоставления своих услуг. Местами спорные метрики, но если они устраивают все стороны (и заказчиков, и поставщиков), то почему бы и нет?..
ЗЫ. Видимо, это будет моя последняя заметка по результатам посещения SOC Forum. Все, что так или иначе меня интересовало или заинтересовало я уже выплеснул на "страницы" блога и даже немного за его пределы. Поэтому стоит финализировать эту SOC-серию списком всех заметок:
Я не буду сейчас вдаваться в вопрос, что такое эффективность и можно ли измерять ее деньгами или только немонетарными метриками. Это вопрос отдельный и непростой. Лучше сразу обратиться к вопросу измерения. Оно может разбиваться на две больших части - эффективность процессов ИБ, реализуемых в SOC (число отраженных инцидентов в их числе или в предотвращенных потерях, устраненных уязвимостей и т.п), и эффективность самого SOC (число сотрудников, оперативность реагирования и т.п.). Если мы строим SOC собственный, то нас должны, в первую очередь, интересовать метрики первой категории. В случае с аутсорсинговым SOCом, заказчика также интересуют первый вид измерений, а его владельца, как правило, второй.
Универсального перечня метрик для SOC не существует и каждая организация выбирает свой набор - в зависимости от задач, сервисов, уровня зрелости. В любом случае не стоит измерять просто число проанализированных событий в пересчете на аналитика SOC. Выглядит красиво, но никакой ценности для конечного результата не имеет. Также как и отношение числа "сырых" к числу скоррелированных событий.
Почему эти показатели не очень интересны? А они условны и ничего не говорят о реальном уровне защищенности организации. Более того, причиной изменения этих значений может быть куча разных причин. Вот пара примеров, которые я привожу в рамках курса по измерению эффективности.
Гораздо более интересны различные временные параметры. Например, время отклика на события из сферы действия того или иного сервиса SOC (инцидент, уязвимость) - время обнаружения, время реагирования, время устранения. Также может быть интересно среднее время реагирования на инцидент (с привязкой к приоритету инцидента). Но в последнем случае стоит обратить внимание, что сотрудники SOC могут подгонять свои показатели деятельности под целевое значение.
Например, стоит задача - оценить время реагирования на звонок об инциденте. За снижение этого времени аналитик SOC может быть поощрен. В самом худшем случае сотрудник будет класть трубку сразу после звонка. В этом случае время реагирования будет минимальным, а премия максимальной. Если поощрять аналитиков за число разрешенных инцидентов, то сотрудники будут самостоятельно пытаться закрыть инцидент, не эскалируя его правильному специалисту. В итоге увеличивается время реагирования, длительность звонков и ожидания клиентов на линии, доступных аналитиков становится меньше – удовлетворенность клиентов становится ниже.
Но время - не единственное, что может быть интересно и нужно измерять. Например, соотношение открытых и закрытых инцидентов. Или стоимость инцидента (расследование, восстановление, общение с прессой, юридические издержки и т.п.). Или уровень терпимости к рискам - тоже очень интересная метрика, по которой нельзя оценивать сам SOC, но которую он может генерить для более высокоуровневых измерениях.
Если SOC среди услуг по реагированию на инциденты предлагает функции реконфигурации средств защиты, сетевого оборудования, ОС, СУБД и т.п., то их можно оценивать следующим образом:
- Число авторизованных изменений в неделю
- Число актуальных изменений, сделанных за неделю
- Число несанкционированных изменений, сделанных в обход утвержденного процесса внесений изменений (в среднем - 30-50%; у лидеров - менее 1% от общего числа изменений)
- Показатель (коэффициент) неудачных изменений, вычисляемый как отношение несанкционированных изменений к актуальным
- Число срочных изменений
- Процент времени, затрачиваемого на незапланированную работу (в среднем - 35-45%; у лидеров - менее 5% от общего числа изменений)
- Число необъяснимых изменений (вообще, это основной индикатор уровня проблем в данной сфере).
Наверное, эту тему можно продолжать бесконечно. Особенно, если SOC рассматривать именно как центр управления всей ИБ, а не только реагирования на инциденты. В таком случае метрик может быть огромное количество и задача создателей/заказчиков SOC выбрать для себя те, которые лучше соответствуют поставленным на конкретный интервал времени задачам.
В заключение приведу еще один набор метрик оценки эффективности SOC, которые предлагает HP в рамках предоставления своих услуг. Местами спорные метрики, но если они устраивают все стороны (и заказчиков, и поставщиков), то почему бы и нет?..
ЗЫ. Видимо, это будет моя последняя заметка по результатам посещения SOC Forum. Все, что так или иначе меня интересовало или заинтересовало я уже выплеснул на "страницы" блога и даже немного за его пределы. Поэтому стоит финализировать эту SOC-серию списком всех заметок:
- Тематические мероприятие по ИБ на примере SOC Forum
- SIEM-процесс или SIEM-продукт?
- В чем разница между CERT и CSIRT?
- Что такое Security Operations Center (SOC)?
- Когда ни покупной SIEM, ни аутсорсинговый SOC не помогают
- Книги про проектирование, построение и эксплуатацию SOC
- 45 афоризмов SOC Forum
- SOC Forum в социальных сетях
- Моя презентация с SOC Forum по Threat Intelligence
- ArcSight Forum или SIEM Forum или SOC Forum? Что это было?
- Positive отказался от вывода своего SOCа на рынок!
- Превратится ли ГосСОПКА в ГосКУРГАН?
- FinCERT: с чем его едят?
- Свой SOC или аутсорсинговый? А может быть государственный?
- Экономика SOC или то, о чем на SOC Forum так и не поговорили
