Ну что, завершаем серию заметок про то, как иностранные CISO ходят к топ-менеджменту, защищая себя, свои проекты, своих подчиненных, свои инициативы. На этот раз поговорим на мою любимую тему — о метриках, которые позволяют демонстрировать определенные достижения в области кибербезопасности. CISO из описываемых мной примеров в части применения метрик при общении с руководством активно спорили о том, что лучше, — больше рассказывать, а не фокусироваться на числах, или наоборот. Понятно, что какие-то метрики все равно будут включены в отчеты для руководства (тот же уровень зрелости), но надо сразу сказать, что универсального перечня метрик не было, нет и вряд ли будет. Все очень сильно зависит от кучи условий, ключевых инициатив и инцидентов, отрасли компании и множества других факторов.
Вот так выглядит пример одного из наборов метрик, которые включаются в полную версию отчета для топ-менеджмента.
Вы же помните, что обычно отчет/презентация состоит всего из 3-5 страниц, а все остальное уходит в приложения?
Все эти метрики отображаются не на одном дашборде, а на нескольких, под разные информационные блоки и инициативы, в том числе и отображенные в таблице — безопасность приложений, аудит, доверие клиентов, кибергигиена, управление инцидентами, работа с кадрами, риски третьих сторон, а также security governance.
А вы измеряете доверие клиентов?
Поделившиеся своим опытом CISO так описывают причины, по которым они включают метрики в свои отчеты и презентации для руководства:
- метрики помогают руководству, непогруженному в тему ИБ, отслеживать прогресс в достаточно сложных для понимания вопросах
- метрики дают руководству определенную уверенность, что они держат руку на пульсе и имеют достаточно деталей для того, чтобы обеспечивать эффективный контроль
- парочка солидных американских ассоциаций опубликовала рекомендации для топ-менеджмета, что «метрики — это хорошо»
- регулярная демонстрация метрик позволяет менеджменту думать, что служба ИБ и сама использует метрики в своей деятельности и принимает на их основе правильные решения
- включение метрик в каждый отчет для руководства обеспечивает базовый уровень прозрачности касательно продуктивности службы ИБ
- в случае инцидента история метрик, отображенная в отчетах, защищает правление, топ-менеджмент и CISO, доказывая что они правильно выполняли свои обязанности (интересный довод, но с другой стороны подложить соломку под задницу — штука полезная в определенных случаях).
В следующем примере метрики сгруппированы в 4 блока:
- в сфере, в которой работает компания,
- в области базовых защитных мер (патчинг, харденинг, антивирусная защита),
- в области ИБ-инструментов, в частности EDR и WAF (помните, что это пример),
- в части операционной деятельности (инциденты, фишинг, уязвимости).
На вопрос о том, какие метрики надо включать в отчеты и презентации, CISO рекомендовали обращать внимание на то, чтобы метрики:
- учитывали важные для бизнеса проекты и критические риски / недопустимые события
- могли служить ключевыми индикаторами рисков / недопустимых событий и подсвечивать остаточные риски
- могли быть интересными для топ-менеджмента. Например, если на предыдущем совещании топов заинтересовал какой-то вопрос или инициатива, то на следующем совещании CISO вставляет соответствующие метрики в свой отчет.
- демонстрировали прогресс в области ИБ (по достижении нужных целей, метрика исключается из отчетов)
- сообщали, что пороговые значения рисков превышены (только в случаях, когда определен риск-аппетит).
В примере ниже из интересного я бы отметил метрики для уровня зрелости ИБ компании, а также отдельно выделенный уровень защиты для критических систем в организации:
У каждого CISO был свой список критериев полезности и бесполезности метрик. Но все сходились, в том что:
- полезные метрики
- Показывают тенденции. Эти метрики наиболее полезны и имеют больший смысл, чем точечные истории.
- Показывают цели, которые являются предметом договоренностей между ИБ и бизнесом, так как это всегда некий баланс между затратами и бизнес-преимуществами.
- Передают правильный смысл. Метрики могут быть сформулированы, чтобы показывать низкие (уровень переходов по фишинговым ссылкам — 5%) или высокие (уровень отказа от переходов по фишинговым ссылкам — 95%) значения. Интуитивно, высокие значения кажутся лучшим выбором. Однако в тех областях, где ИБ пока слаба, CISO может наоборот показать низкие значения метрик, чтобы «подсказать» топ-менеджменту, в каком направлении требуются улучшения (и ресурсы).
- Несут смыслы корпоративных политик ИБ. Например, если в политики ИБ написано, что уязвимости критического уровня должны быть устранены в течение 24 часов (так требует и методика ФСТЭК по оценке критичности уязвимостей), то метрика должна звучать как «процент систем, на которых критические уязвимости пропатчены в течение 24 часов». И это гораздо лучше, чем «процент полностью пропатченных систем».
- Отражают приоритеты. Не надо считать абсолютно все — фокусируйтесь на главном для бизнеса. Вместо всех тысяч приложений в компании, возьмите Топ100. Вместо оценки безопасности у всех подрядчиков, возьмите только самых важных. Вместо оценки уровня доверия от всех заказчиков, сфокусируйтесь на 20%, которые приносят вам 80% доходов. Используйте правило Паретто, примененное к приоритетам бизнеса.
- бесполезные метрики
- Требуют глубокой экспертизы в ИБ
- Излишне детальны для топ-менеджмента. Тут нет четкой грани, где детально, а где нет. Одни CISO говорят, что их топ-менеджмент интересуют такие метрики как MTTD/MTTC/MTTR (среднее время обнаружения/локализации/реагирования), а другие — что им это совершенно неинтересно.
- Базируются на неполных данных. Если компания не знает число активов, которые регулярно сканируются в поисках уязвимостей, достаточно странно показывать число найденных уязвимостей или непропатченных узлов.
- Отражают устаревшие стратегии и инициативы ИБ. Количество сработок правил на МСЭ менее релевантно в условиях удаленной работы и внедрения концепции Zero Trust.
Следующий пример все метрики объединил в три высокоуровневых группы — соответствие требованиям (в том числе и поставщиков), зрелость ИБ и операционная деятельность, включая соблюдение SLA.
Финальный пример показывает динамику в достижении поставленных ИБ-задач, связанных с предыдущим набором метрик.
Вот такая серия заметок получилась. Не претендуя на истину в последней инстанции, мне просто хотелось показать, что общение с руководством — это не бином Ньютона. Его можно разложить на составные части и каждую представить определенным образом. Да, к отдельным описанным моментам могут возникнуть вопросы (у меня они лично возникли), но значит ли это, что они плохие? Нет. Если они работают в конкретной компании, значит они свою задачу выполняют. Значит можно попробовать перенять этот опыт, возможно модифицировав его под свою ситуацию. Никакой серебряной пули тут, увы, нет. Но и никаких секретов тоже. Было бы желание начать общаться с бизнесом и его руководством. А дальше дело техники…
