Не буду тут писать длинные заумные тексты о том, «как правильно построить систему KPI для SOC». А просто расскажу, как мы боролись и искали нашли свою методику и как теперь измеряем, «насколько все плохо/хорошо/безопасно/(нужное подчеркнуть)».
Как ни странно, первые наши шаги к формированию KPI для Solar JSOC никак не были связаны с центрами мониторинга и реагирования на кибератаки. «На заре нашей юности» мы помогали компаниям строить системы оценки эффективности ИБ (СУИБ 27001 и вот это вот всё). Понимание их необходимости возникло тогда на рынке естественным образом: почти любое ИБ-подразделение изо дня в день вынуждено анализировать большие объемы данных от множества всевозможных систем. Конечно, каждая из них имеет некую свою отчетность, но при большом их количестве очень трудно сформировать целостную картину о состоянии ИБ, а впоследствии – предоставить отчёт руководству в удобном формате. Проблема усугубляется, если организация имеет географически распределенную структуру.
Мы как раз помогали заказчикам построить не просто комплекс KPI/метрик, но полноценное аналитическое решение, агрегирующее данные от систем обеспечения ИБ. Фактически – систему визуализации, в которой можно быстро и просто увидеть суть проблемы и ее локализацию, чтобы оперативно принять требуемые решения. В этих проектах мы набрались опыта и пришли к тому, что система действительно удобная и полезная. А еще – что работу SOC тоже необходимо оценивать.
Все просто: мы хотим, с одной стороны, понимать, насколько качественно оказываем услугу, а с другой – иметь максимально полное представление об инфраструктуре заказчика, видеть все «черные пятна», не попавшие в состав нашего аудита и ставшие факторами риска для сервиса. Проще говоря, хотим понимать: увидим мы ту или иную атаку на заказчика или нет.
Когда мы начинали работать как сервис-провайдер, бывало такое, что клиент отказывался давать нам на подключение конкретные источники, которые были необходимы для 100 % идентификации атаки. В итоге такая атака случалась, мы ее не видели и получали упреки, невзирая на изначальное наше предупреждение.
Другой пример: мы говорили, что для корректного и точного выявления инцидента нужно настроить источники определенным образом, выдавали перечень этих настроек, но заказчик эту работу не проводил. Итог тот же – пропущенный инцидент.
Так мы пришли к пониманию, что важно в явном виде подсвечивать и заказчику, и самим себе, что конкретно мы видим в его инфраструктуре, где есть «слепые зоны» для нас, какие вектора атак наиболее часто реализуются и на каких участках, какие ИТ-активы наиболее подвержены атакам и как это может повлиять на бизнес. Для этого система визуализации должна показывать реальную ситуацию и помогать в ее анализе, а не просто быть «вау-эффектом» для руководства (как это часто бывает).
Перво-наперво надо понять: зачем, для чего вам нужна эта самая система KPI/метрик? Вы хотите измерять эффективность работы вашего подразделения ИБ? Понимать, насколько хорошо/успешно (или наоборот) работают ваши процессы? А может, просто показать руководству, «кто молодец»? Или, может быть, от выполнения KPI зависят премии отдела? Без понимания целей оценки эффективности невозможно построить реально действующую систему KPI.
Допустим, с целями определились, и теперь встает самый интересный вопрос: а как измерять-то? К SOC с линейкой не подойдешь, тут все немного сложнее. Это ведь не только SIEM как система сбора и корреляции событий ИБ, это еще и огромное множество систем, которые позволяют корректно функционировать сервису. Данных внутри SOC безумно много, поэтому оценивать есть что.
И в этом вопросе мы стараемся максимально уйти от субъективных KPI, т.е. тех метрик, которые невозможно измерить автоматически. Например, метрику «Насколько у нас все плохо» сложно оценить напрямую, без участия человека (который выдаст своекривое не всегда правильное мнение, основываюсь на собственном опыте). Но если разбить эту метрику на более мелкие, то их уже можно посчитать на основе данных от технических средств. Т.е. нужно определить, что для нас входит в понятие «все плохо»: у нас нет конкретного СЗИ; антивирус внедрен не везде, где нужно; специалисты очень долго обрабатывают инциденты или заявки; на всех наших хостах есть более 10 критических уязвимостей и их никто не устраняет и т.д. И вот если все подобные маленькие метрики с учетом их весовых коэффициентов для нашего бизнеса собрать в единый расчет, то мы получим значение метрики «Насколько у нас все плохо». Более того – мы сможем объяснить, на чем она основывается и почему определенное ее значение говорит о том, что пора срочно решать серьезные проблемы в организации ИБ. И главное – мы всегда сможем опуститься в детали этой метрики и понять, какие задачи в каком приоритете стоят.
При построении своей системы KPI мы придерживаемся следующих принципов:
Также мы пришли к выводу, что система KPI не может быть плоской и должна иметь минимум три уровня:
Каждый из показателей влияет на вышестоящий. Так как это влияние неодинаково, каждому из показателей присваивается весовой коэффициент.
Разумеется, первое, что мы хотим видеть постоянно – это то, насколько эффективно работает наш сервис для заказчиков. И, естественно, эта информация должна быть своевременной. Для этого мы разработали (и продолжаем улучшать) систему метрик, которая отражает качество работы каждой из служб: 1-ой и 2-ой линии, сервис-менеджеров, аналитиков, реагирования, администрирования и д. т. По каждому из этих направлений было разработано порядка 10-15 KPI – считались они на базе данных от систем, в которых работают ребята (вовремя ли выполняются заявки, быстро ли мы отвечаем заказчику на его запрос, как подключаются источники и многое другое).
Для нас важно, чтобы покрытие сервисом позволяло выявлять максимальное количество инцидентов и атак, а не быть слепыми котятами. Чтобы мы могли интерпретировать инциденты у заказчика в формате его же ИТ-активов, а не абстрактных айпишников. Чтобы наши уведомления не сводились к тому, что «на хосте 10.15.24.9 обнаружен Mimikatz», и не вынуждали бы заказчика самостоятельно выяснять, что это за хост, теряя время, необходимое на реагирование и ликвидацию последствий.
Иными словами, нам важно понимать, насколько хорошо защищены заказчики нашим SOC. А значит, надо определить, насколько подробно и достаточно мы их «видим»:
А также – насколько «страшно жить внутри этого заказчика», то есть:
Чтобы посчитать все такие верхнеуровневые показатели, надо сначала разбить их на более мелкие, а те – на еще более мелкие – пока мы не дойдем додзена уровня маленьких метрик, которые можно однозначно посчитать на базе данных от источников и наших внутренних систем.
Самый простой пример: есть высокоуровневый показатель «Эффективность процессов ИБ», состоящий из более мелких, таких как «Степень защиты от ВПО», «Степень управления уязвимостями», «Степень защиты от инцидентов ИБ», «Эффективность управления доступом» и т.д. Сколько процессов ИБ реализовано в организации, столько и будет метрик второго уровня. А вот чтобы посчитать метрику второго уровня, надо собрать еще более мелкие метрики, например, «Степень покрытия антивирусом хостов организации», «Процент критичных инцидентов с ВПО», «Количество вовлеченных активов», «Процент ложных срабатываний», «Уровень киберграмотности пользователей», «Процент хостов организации с выключенной антивирусной защитой», «Процент хостов с неактуальными антивирусными базами» – далее можно продолжать до бесконечности. И вот эти метрики третьего уровня вполне можно собирать со средств защиты информации и других систем в автоматическом режиме, а расчет производить в системе аналитики ИБ.
Создание KPI и управление эффективностью SOC – та еще задачка как для разработчиков этих метрик, так и для заказчика (а это исключительно парный «танец»). Но игра стоит свеч: в итоге можно в полной мере, централизовано и быстро оценить состояние ИБ, найти слабые места, быстро отреагировать на инциденты и поддерживать СЗИ в актуальном состоянии.
Если тема окажется интересной, я подробнее расскажу о метриках в следующих статьях. Так что если хотите услышать о каких-то конкретных аспектах измерения SOC, пишите в комментариях — постараюсь ответить на все вопросы.
Елена Трещёва, ведущий аналитик Solar JSOC
С чего все начиналось
Как ни странно, первые наши шаги к формированию KPI для Solar JSOC никак не были связаны с центрами мониторинга и реагирования на кибератаки. «На заре нашей юности» мы помогали компаниям строить системы оценки эффективности ИБ (СУИБ 27001 и вот это вот всё). Понимание их необходимости возникло тогда на рынке естественным образом: почти любое ИБ-подразделение изо дня в день вынуждено анализировать большие объемы данных от множества всевозможных систем. Конечно, каждая из них имеет некую свою отчетность, но при большом их количестве очень трудно сформировать целостную картину о состоянии ИБ, а впоследствии – предоставить отчёт руководству в удобном формате. Проблема усугубляется, если организация имеет географически распределенную структуру.
Мы как раз помогали заказчикам построить не просто комплекс KPI/метрик, но полноценное аналитическое решение, агрегирующее данные от систем обеспечения ИБ. Фактически – систему визуализации, в которой можно быстро и просто увидеть суть проблемы и ее локализацию, чтобы оперативно принять требуемые решения. В этих проектах мы набрались опыта и пришли к тому, что система действительно удобная и полезная. А еще – что работу SOC тоже необходимо оценивать.
Зачем оценивать эффективность SOC, тем более внешнего?
Все просто: мы хотим, с одной стороны, понимать, насколько качественно оказываем услугу, а с другой – иметь максимально полное представление об инфраструктуре заказчика, видеть все «черные пятна», не попавшие в состав нашего аудита и ставшие факторами риска для сервиса. Проще говоря, хотим понимать: увидим мы ту или иную атаку на заказчика или нет.
Когда мы начинали работать как сервис-провайдер, бывало такое, что клиент отказывался давать нам на подключение конкретные источники, которые были необходимы для 100 % идентификации атаки. В итоге такая атака случалась, мы ее не видели и получали упреки, невзирая на изначальное наше предупреждение.
Другой пример: мы говорили, что для корректного и точного выявления инцидента нужно настроить источники определенным образом, выдавали перечень этих настроек, но заказчик эту работу не проводил. Итог тот же – пропущенный инцидент.
Так мы пришли к пониманию, что важно в явном виде подсвечивать и заказчику, и самим себе, что конкретно мы видим в его инфраструктуре, где есть «слепые зоны» для нас, какие вектора атак наиболее часто реализуются и на каких участках, какие ИТ-активы наиболее подвержены атакам и как это может повлиять на бизнес. Для этого система визуализации должна показывать реальную ситуацию и помогать в ее анализе, а не просто быть «вау-эффектом» для руководства (как это часто бывает).
KPI для SOC – что и как измерять?
Перво-наперво надо понять: зачем, для чего вам нужна эта самая система KPI/метрик? Вы хотите измерять эффективность работы вашего подразделения ИБ? Понимать, насколько хорошо/успешно (или наоборот) работают ваши процессы? А может, просто показать руководству, «кто молодец»? Или, может быть, от выполнения KPI зависят премии отдела? Без понимания целей оценки эффективности невозможно построить реально действующую систему KPI.
Допустим, с целями определились, и теперь встает самый интересный вопрос: а как измерять-то? К SOC с линейкой не подойдешь, тут все немного сложнее. Это ведь не только SIEM как система сбора и корреляции событий ИБ, это еще и огромное множество систем, которые позволяют корректно функционировать сервису. Данных внутри SOC безумно много, поэтому оценивать есть что.
И в этом вопросе мы стараемся максимально уйти от субъективных KPI, т.е. тех метрик, которые невозможно измерить автоматически. Например, метрику «Насколько у нас все плохо» сложно оценить напрямую, без участия человека (который выдаст свое
При построении своей системы KPI мы придерживаемся следующих принципов:
- KPI должен быть действительно важным и для SOC, и для заказчика;
- показатель должен быть измеряемым, т.е. должны быть построены конкретные формулы расчета и заданы пороговые значения;
- у нас должна быть возможность влиять на значение показателя (т.е. метрики из разряда «процент солнечных дней в году» нам не подходят).
Также мы пришли к выводу, что система KPI не может быть плоской и должна иметь минимум три уровня:
- «Стратегический»: это KPI, которые отображают общую картину достижения поставленных целей;
- «Расследование, анализ, выявление связей»: это KPI, на основе которых формируется первый уровень и которые вносят свой вклад в осуществление главной цели.
- «Мониторинг и реагирование»: самые базовые KPI, из которых строятся все вышестоящие (мы измеряем их автоматически – на базе данных от СЗИ и других источников).
Каждый из показателей влияет на вышестоящий. Так как это влияние неодинаково, каждому из показателей присваивается весовой коэффициент.
Разумеется, первое, что мы хотим видеть постоянно – это то, насколько эффективно работает наш сервис для заказчиков. И, естественно, эта информация должна быть своевременной. Для этого мы разработали (и продолжаем улучшать) систему метрик, которая отражает качество работы каждой из служб: 1-ой и 2-ой линии, сервис-менеджеров, аналитиков, реагирования, администрирования и д. т. По каждому из этих направлений было разработано порядка 10-15 KPI – считались они на базе данных от систем, в которых работают ребята (вовремя ли выполняются заявки, быстро ли мы отвечаем заказчику на его запрос, как подключаются источники и многое другое).
SLA хорошо, но важнее реальное качество услуги
Для нас важно, чтобы покрытие сервисом позволяло выявлять максимальное количество инцидентов и атак, а не быть слепыми котятами. Чтобы мы могли интерпретировать инциденты у заказчика в формате его же ИТ-активов, а не абстрактных айпишников. Чтобы наши уведомления не сводились к тому, что «на хосте 10.15.24.9 обнаружен Mimikatz», и не вынуждали бы заказчика самостоятельно выяснять, что это за хост, теряя время, необходимое на реагирование и ликвидацию последствий.
Иными словами, нам важно понимать, насколько хорошо защищены заказчики нашим SOC. А значит, надо определить, насколько подробно и достаточно мы их «видим»:
- все ли значимые источники к нам подключены;
- насколько эффективно СЗИ заказчика (они же источники для нашего сервиса) покрывают его инфраструктуру;
- все ли источники настроены так, как мы рекомендуем, и каковы отклонения;
- все ли необходимые и достаточные сценарии выявления атак и инцидентов запущены у заказчика;
- все ли подключенные источники отдают нам события с заданной регулярностью;
- на все ли наши извещения заказчик реагирует, и насколько своевременно он это делает.
А также – насколько «страшно жить внутри этого заказчика», то есть:
- как часто его атакуют, какова критичность этих атак (целенаправленные или массовые), каков уровень злоумышленника;
- насколько эффективна защита у заказчика (процессы и СЗИ) и как часто она актуализируется;
- какова критичность активов, участвующих в инцидентах, какие из активов используются злоумышленниками чаще всего и др.
Чтобы посчитать все такие верхнеуровневые показатели, надо сначала разбить их на более мелкие, а те – на еще более мелкие – пока мы не дойдем до
Самый простой пример: есть высокоуровневый показатель «Эффективность процессов ИБ», состоящий из более мелких, таких как «Степень защиты от ВПО», «Степень управления уязвимостями», «Степень защиты от инцидентов ИБ», «Эффективность управления доступом» и т.д. Сколько процессов ИБ реализовано в организации, столько и будет метрик второго уровня. А вот чтобы посчитать метрику второго уровня, надо собрать еще более мелкие метрики, например, «Степень покрытия антивирусом хостов организации», «Процент критичных инцидентов с ВПО», «Количество вовлеченных активов», «Процент ложных срабатываний», «Уровень киберграмотности пользователей», «Процент хостов организации с выключенной антивирусной защитой», «Процент хостов с неактуальными антивирусными базами» – далее можно продолжать до бесконечности. И вот эти метрики третьего уровня вполне можно собирать со средств защиты информации и других систем в автоматическом режиме, а расчет производить в системе аналитики ИБ.
Создание KPI и управление эффективностью SOC – та еще задачка как для разработчиков этих метрик, так и для заказчика (а это исключительно парный «танец»). Но игра стоит свеч: в итоге можно в полной мере, централизовано и быстро оценить состояние ИБ, найти слабые места, быстро отреагировать на инциденты и поддерживать СЗИ в актуальном состоянии.
Если тема окажется интересной, я подробнее расскажу о метриках в следующих статьях. Так что если хотите услышать о каких-то конкретных аспектах измерения SOC, пишите в комментариях — постараюсь ответить на все вопросы.
Елена Трещёва, ведущий аналитик Solar JSOC