ИБ-метрики

В современных условиях метрики информационной безопасности играют решающую роль в понимании уровня защиты компании. Но, как отмечают эксперты, часто используемые метрики могут исказить реальную картину, если их применять без учёта масштаба инфраструктуры, специфики бизнес-процессов и качественных аспектов защиты.

Редакция CISOCLUB в своей новой статье собрала мнения специалистов, которые поделились опытом и предостерегли от ряда распространённых ошибок.

С нами поговорили:

• Павел Нагин, руководитель по развитию продуктов компании SQUAD;
• Алексей Новаков, руководитель направления по кибербезопасности «АйТи Бастион»;
• Даниил Бориславский, директор по продукту Staffcop (входит в экосистему «Контур»);
• Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision;
• Александр Зубриков, генеральный директор ITGLOBAL.COM Security;
• Алена Игнатьева, руководитель направления консалтинга и аудита информационной безопасности STEP LOGIC.

Какие метрики чаще всего используются неправильно и приводят к искажённой оценке уровня ИБ компании?

Павел Нагин, руководитель по развитию продуктов компании SQUAD, отметил, что количественные метрики без учета масштаба и сложности инфраструктуры могут приводить к неверной интерпретации данных, особенно при сравнении разных организаций. Он пояснил: «Что критичнее 3 уязвимости в сети с 10 серверами Windows или 10 уязвимостей в инфраструктуре с 1000 хостов и десятком различных операционных систем?

В таких случаях обычно оперируют метрикой «уязвимости на хост» и смотрят данные вместе с такими параметрам как скорость устранения уязвимостей, уровень ложных срабатываний, количество уязвимостей в критичных сервисах, возможность эксплуатации, доступность сервиса из недоверенных сетей и т. д. Также неправильно опираться на данные, которые не были подтверждены инструментальными проверками или независимым аудитом».

Алексей Новаков, руководитель направления по кибербезопасности «АйТи Бастион», считает, что оценка уровня защищенности компании может быть искажена, если метрики не отражают потенциальные направления развития или уязвимости в защите: «Сильнее всего искажают оценку уровня защищённости компании такие метрики, которые не показывают возможные линии роста или возможные дыры в защите. Например, среднее количество инцидентов не говорит о росте надежности защиты: может, администратор SOC стал внимательнее выявлять инциденты, а, возможно, в этом квартале число DDOS-атак было в разы больше, чем в предыдущем».

Даниил Бориславский, директор по продукту Staffcop (входит в экосистему «Контур»), добавил, что акцент на количестве выявленных инцидентов может подстегивать фиксацию событий в ущерб профилактике, что в конечном итоге снижает реальную защищенность организации: «Чаще всего, количество выявленных инцидентов — это стимулирует подразделение ИБ не заниматься профилактикой, а только фиксацией, причём, иногда это перерастает в то, что подразделению ИБ становится выгодно для обоснования своей полезности наличие большого числа нарушений. В итоге, реальная защищенность организации падает, система становится уязвимой, потому что приоритет смещается с предотвращения на учет угроз».

Алексей Новаков и Даниил Бориславский сходятся во мнении, что ориентировка только на количественные показатели инцидентов может приводить к сдвигу фокуса с превентивных мер на фиксацию уже имевшихся нарушений.

Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision, рассказал о проблемах использования метрик, когда отсутствует привязка к реальным бизнес-целям компании: «Наиболее распространенные и популярные метрики при неправильном их применении и отсутствии привязки к реальным бизнес-целям и задачам компании дают искажённую картину оценки уровня информационной безопасности в компании. Неправильное применение метрик, которые показывают процент устранённых уязвимостей в соотношении с найденными, оказывают большое влияние на общий уровень ИБ. Использование абсолютного числа уязвимостей (например, найденных за месяц с помощью сканеров) без учёта их критичности может искажать реальную картину. Ситуацию усложняет ещё то, что без доступа к системе сканеры могут неточно определять тип уязвимости и не понять, была ли она закрыта ранее или нет. В данной метрике также необходимо учитывать специфику работы компании и ее бизнес-процессов, что требует большого рода интеграций и учёта множества показателей, которые не всегда возможно собирать в автоматизированном виде.

Другая метрика, на которую также стоит обратить внимание, связана с оценкой количества инцидентов информационной безопасности. В некоторых компаниях часто считают, что снижение количества инцидентов свидетельствует об улучшении состояния ИБ. Это может быть связано не с реальным улучшением защиты, а с недостатками в системе мониторинга или классификации инцидентов. Чрезмерная фиксация количества инцидентов может свидетельствовать о неправильно настроенных правилах, которые начинают давать множество ошибочных срабатываний. Необходимо учитывать не только количество, но и качество обработки инцидентов, их категорию и время, затраченное на реагирование с момента фиксации. Сюда же можно отнести ещё ситуацию с метриками на SLA при реакции на инцидент и его устранением. Очень часто в оценку попадает общее затраченное время. Если в компании отсутствуют чёткие процессы эскалации, либо инциденты классифицируются некорректно, можно искусственно занижать время реакции, не давая объективной картины сложности или серьёзности инцидента. Более правильным в данном подходе будет разделение процесса реагирования на стадии, например: обнаружение, классификация, анализ и устранение. Отслеживание затраченного времени на каждом этапе будет давать более полную картину. Также важно учитывать и определять степень критичности инцидента.

Более серьёзные инциденты требуют больше времени на полноценное расследование и устранение. Таких примеров в популярных метриках оценки множество. Один лишь числовой показатель может вводить в заблуждение без дополнительного анализа контекста. Любой показатель должен иметь практическую ценность и использоваться в принятии решений. Если метрика не помогает оценивать риск или улучшать процесс, значит она неэффективна. Важны не только цифры как таковые, но и понимание, какие из них указывают на реальные угрозы, влияющие на ключевые бизнес-процессы».

Александр Зубриков, генеральный директор ITGLOBAL.COM Security, поделился опытом, подчеркивая, что проблемы в оценке уровня ИБ возникают еще на этапе определения активов и области защиты: «Если посмотреть на опыт наших заказчиков, то хотелось бы отметить проблемы, еще до применения каких-либо метрик или фреймворков оценки, в частности, на правильной оценке активов и области защиты. Как пример, мы часто сталкиваемся с ситуацией, когда компания выпускает на рынок какой-то онлайн-сервис, выстраивает вокруг него всевозможные средства защиты, такие как WAF, Anti-DDoS и тд, и даже использует программы Bug Bounty и уверены, что они защищены, забывая о защите своей инфраструктуры, CI/CD пайплайна или просто упускает из виду внутреннего злоумышленника. Второй по популярности в этом анти-топе, это комплайнс подход “в лоб”, когда компания бездумно выполняет требования регулятора, часто забывая адаптировать их под свои реалии, что тоже приводит к неверной оценке эффективности мер защиты. Ну и на третьем месте, когда компания забывает что ИБ требует комплексного дедуктивного подхода (от общего к частному), и либо смотрит на защищенность только “сверху”, забывая про конкретные системы и активы, или наоборот, зацикливается на защите конкретных активов, забывая выстроить процессы ИБ и систему менеджмента в компании».

Руководитель направления консалтинга и аудита информационной безопасности STEP LOGIC, Алена Игнатьева, обратила внимание на метрики, зависящие от внешних факторов и не контролируемые непосредственно ИБ-подразделением. Она объяснила: «Как правило, это относится метрикам, которые не зависят напрямую от деятельности ИБ-подразделения, хотя и связаны c ним непосредственно».

К таким метрикам она отнесла:

• Количество замечаний со стороны контрольных и надзорных органов по направлению ИБ. Данный параметр зависит от огромного количества факторов, на которые не может повлиять служба ИБ: начиная с того, проводились ли проверки по направлению ИБ за оцениваемый период, были ли жалобы со стороны субъектов ПДн в адрес Роскомнадзора, какие инциденты ИБ произошли в отрасли и заканчивая квалификацией и опытом проверяющих.
• Количество инцидентов ИБ в компании. Служба ИБ не может влиять на интерес атакующих к организации. Это хорошо прослеживается на примере статистики за последние годы, где можно заметить, что атаки пошли «волнами». Сегодня ваше производство никому неинтересно, а завтра злоумышленники атакуют промышленные предприятия в вашем регионе. Сегодня этические нормы не позволяют хакерам атаковать больницы, а завтра мы читаем новости, что высокотехнологичную операцию на головном мозге пришлось завершать «вслепую», потому что произошла хакерская атака на системы больницы. Как правило, именно служба ИБ выполняет функции по классификации того или иного события как инцидента ИБ, что позволяет управлять статистикой.
• Величина бюджета на ИБ. В сфере информационных технологий одного и того же результата можно добиться, используя кратно отличающиеся по цене способы. Если вы, например, оцениваете бюджет на строительство бетонной дамбы, то есть понятные критерии стоимости кубометра бетона. Когда мы оцениваем ПО, к сожалению, нет «прозрачных» способов.

«Если говорить про ИБ, то нужно учесть не только стоимость реализации процесса защиты, но и косвенные затраты, которые вызваны изменениями в текущих бизнес-процессах. Пользователи не смогут работать так, как раньше, изменится клиентский путь, срок выполнения операций работниками. Новое ПО, СЗИ и оборудование – это новые «точки входа» для атакующих, уязвимости, которые надо отслеживать и устранять, источники генерации событий, а значит потребуются дополнительные затраты на системы хранения, мониторинга и анализа событий».

Как становится понятно из ответов экспертов, метрики должны быть практически ориентированными и учитывать контекст – масштаб, сложность инфраструктуры, специфику бизнес-процессов и реальные риски. Только комплексный анализ, предполагающий не только количественные, но и качественные показатели, способен дать объективную картину уровня информационной безопасности и помочь выстроить эффективную стратегию защиты.

На каких данных стоит строить метрики для оценки воздействия ИБ на бизнес-процессы, чтобы исключить их формальный характер?

Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision, обратил внимание на необходимость осмысленного подхода к построению метрик, которые должны опираться на данные, непосредственно связанные с ключевыми аспектами работы компании: «Такие метрики должны учитывать реальные угрозы, влияние инцидентов и эффективность мер защиты. Полезно сравнивать показатели за разные периоды времени, учитывать сезонность (например, всплески атак в «праздничные» периоды), изменения в инфраструктуре и т.д. Угроза, бывшая критичной год назад, может потерять актуальность, а новые технологические решения могут потребовать новых инструментов измерения и анализа.

Любой показатель должен иметь практическую ценность и использоваться в принятии решений. Если метрика не помогает оценивать риск или улучшать процесс, значит, она неэффективна. Чтобы метрики не носили формальный характер, необходимо применять их на реальных бизнес-процессах и результаты. Измерять, как инциденты и уязвимости влияют на продажи, доходность, непрерывность процессов, производительность и репутацию. Комплексный подход, в котором сочетается учёт финансовых, технических и поведенческих факторов, даёт объективную картину и позволяет демонстрировать ценность ИБ для бизнеса».

Павел Нагин, руководитель по развитию продуктов компании SQUAD, отметил, что для бизнеса критична непрерывность процессов, поддерживающих его работу, и именно к этому свойству следует привязывать метрики ИБ: «Например, количество инцидентов, оказавших влияние на простой критичных для бизнеса web-сервисов. Если в каком-то из бизнес-процессов возможны прямые финансовые потери из-за атаки или фрода, то как правило в инцидентах ИБ регистрируют размер таких потерь. В дальнейшем эти данные можно использовать для построения метрик, а также делать на их основе различные прогнозы».

Даниил Бориславский, директор по продукту Staffcop, подчеркнул, что основой должны служить метрики эффективности бизнеса, а затем — детальная декомпозиция, позволяющая выявить именно те аспекты, за которые отвечает подразделение ИБ и которые они могут улучшить или поддержать.

Александр Зубриков, генеральный директор ITGLOBAL.COM Security, считает, что эффективность ИБ для бизнеса нельзя оценивать отдельно от самого бизнеса, поэтому данные следует собирать с учетом конкретного воздействия на ключевые процессы: «Мы всегда рекомендуем нашим заказчикам привязывать каждую метрику к бизнес-целям. Например, если основная задача компании — бесперебойное обслуживание клиентов, ключевые метрики должны быть связаны с доступностью систем и сервисов, а значит и снижением простоев. Если тяжело посчитать какие-то риски, такие как репутационные потери, то можно придерживаться подхода «недопустимых событий», а значит делать все, чтобы не допустить или хотя бы минимизировать последствия».

Алена Игнатьева, руководитель направления консалтинга и аудита информационной безопасности STEP LOGIC: «Доля охвата бизнес-процессов ИБ с заданной оценкой зрелости. Это позволит исключить ситуации, когда процессы ИБ полностью реализованы, но только в отдельных бизнес-процессах, а остальные не охватывают, либо дублируются и усложняют бизнес-процесс, фактически не повышая уровень ИБ. При этом желательно оценку зрелости доверить стороннему независимому аудитору, который ранее не был погружен в деятельность компании.

1. Величина издержек, связанных с нарушениями ИБ, в том числе, в результате исков со стороны клиентов или партнеров.
2. Величина убытков и недополученной прибыли, связанных с реализацией ИБ-процессов.

Например, после изменения процедуры входа на сайт компании существенно упало количество заявок на услуги, т. к. пользователи не могут пройти CAPCHA и уходят с сайта, не оформив заявку».

Эксперты сходятся во мнении, что метрики для оценки воздействия ИБ на бизнес-процессы должны строиться на данных, отражающих реальные бизнес-аспекты и эффективность процессов, а также быть связаны с бизнес-целями для исключения формального подхода.

Как на практике оценивать реальную ценность метрик, которые измеряют кибергигиену сотрудников?

Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision, отметил, что для оценки реальной ценности метрик кибергигиены важно удостовериться, что они охватывают ключевые аспекты поведения сотрудников. По его мнению, оценка должна выходить за рамки простых процентов прохождения обучения – необходимо отслеживать, как меняется поведение сотрудников после проведения тестовых рассылок фишинговых писем и иных тренировок. Он объяснил: «Нужно смотреть не только на проценты прохождения сотрудниками обучения или количество пройденных тестов по кибергигиене, но и на снижение инцидентов, которые возникают у них после обучения. Если после тренинга показатель успешного распознавания фишинговых писем улучшился, это свидетельствует о реальной ценности метрики. Сравнение данных показателей с аналогичными показателями в отрасли помогает понять, насколько положение компании соответствует среднему уровню или превосходит его».

Александр Зубриков, генеральный директор ITGLOBAL.COM Security, привёл практический пример из опыта одного из заказчиков, чтобы показать, что оценивать кибергигиену следует не в момент проведения обучения, а динамично, с учетом изменений в поведении сотрудников. Он рассказал о том, как даже после красивых отчетов по вебинарам и тестам, реальные действия сотрудников могут выявить скрытые риски: «Тут хотелось бы провести интересный пример одного нашего заказчика. Молодая, но амбициозная компания, с несколькими офисами в Санкт-Петербурге. Их руководство сами вышли из ИТ и понимают значимость ИБ в компании. Они обратились к подрядчику, который проводит курс мероприятия по Security awareness, провели среди своих сотрудников обучения в виде вебинаров, красивых листок и даже провели в конце контрольный тест. По результатам работы им были предоставлены красивые графики и отчеты, какой процент сотрудников справился с тестом, сколько сотрудников были вовлечены и тд.

Через пару-тройку месяцев, сотрудники ИТ подразделения просто разбросали специально помеченные флешки в курилке, опенспейсах, переговорках и даже в туалете, а потом средствами DLP смотрели, кто эти флешки нашел и вставил в свой рабочий ПК. В результате, было выявлено несколько сотрудников, которые проходили обучение, но все равно любопытство победило здравый смысл. Да, таких было немного, но даже одного-двух скомпрометированных ПК, например, в отделе HR, хватило бы, чтобы повлечь инцидент ИБ, например утечку ПДн сотрудников. Так что нужно оценивать не просто кибергигиену и осведомленность в моменте какой-то метрикой, но и смотреть на горизонте времени и лучше всего в динамике, а уже из этого можно строить риск-профиль конкретного сотрудника, особенного если у него есть доступ к конфиденциальной информации».

Павел Нагин, руководитель по развитию продуктов компании SQUAD, подчеркнул, что многие организации ошибочно полагают, что достаточно проводить регулярное обучение по ИБ для соблюдения кибергигиены. Он указал на необходимость обязательного тестирования и постоянного повышения осведомленности через фишинговые рассылки: «На практике этого недостаточно. Во-первых, обучение должно сопровождаться обязательным тестированием – в противном случае большинство будут нажимать кнопку «Далее», не читая текст на экране. Во-вторых, необходимо регулярно проводить мероприятия по повышению осведомленности, например, тестовые рассылки фишингового письма. Для такого сценария полезно отслеживать следующие метрики:

• количество сотрудников, открывших файл/ссылку из фишингового письма;
• количество сотрудников, сообщивших в отдел ИБ о фишинге;
• процент попавшихся на фишинг среди прошедших и не прошедших обучение ИБ».

Даниил Бориславский, директор по продукту Staffcop (входит в экосистему «Контур»), обратил внимание на то, что ценная метрика – та, по динамике которой можно оценить, приносят ли изменения в процессах реальную пользу.

Эксперты уверены, что реальную ценность метрик кибергигиены следует оценивать в динамике: важно не только фиксировать прохождение обучения, но и отслеживать, как изменяется поведение сотрудников и снижается количество инцидентов с течением времени.

Какие показатели наиболее подходят для мониторинга уровня готовности компании к киберинцидентам?

Александр Зубриков, генеральный директор ITGLOBAL.COM Security, считает, что истинная готовность компании к киберинцидентам демонстрируется не формальным наличием комплекса защитных мер, а реальной оперативностью в условиях «учебной тревоги», когда инцидент может произойти в любой момент. Он предлагает оценивать этот уровень с помощью конкретных количественных показателей.

«Если нужно оценить это в количественном показателе, то мы рекомендуем оперировать следующими метриками:

• Среднее время обнаружения и реагирование на инцидент.
• Процент покрытия систем и средств защиты.
• Скорость восстановления бизнес-процессов.
• Срок и точка восстановления данных.

И, конечно же, сравнивать целевые показатели с результатами имитационных учений».

Алена Игнатьева, руководитель направления консалтинга и аудита информационной безопасности STEP LOGIC, акцентирует внимание на том, что оценка готовности компании должна начинаться с наличия и актуальности планов реагирования, охватывающих все ключевые бизнес-процессы, а также с проверки технической оснащённости для противостояния типовым ситуациям: «Надо обратить внимание и на техническую оснащённость. Есть ли необходимые резервные площадки, оборудование, каналы связи, ПО и СЗИ для противостояния типовым ситуациям? Как обеспечены целостность баз данных событий ИБ и возможность для сбора и анализа событий в условиях недоступности основной системы?».

Павел Нагин, руководитель по развитию продуктов компании SQUAD, подчёркивает, что готовность к киберинцидентам необходимо проверять на практике посредством комплексных имитаций атак (red teaming), которые оценивают не только работу отдела ИБ, но и взаимодействие сотрудников других подразделений. Он приводит пример использования настольных игр для моделирования инцидентов при ограниченных ресурсах.

«В случае ограниченных ресурсов такие имитации могут проводиться в виде настольной игры, когда участникам раздаются карточки с описанием инцидента и проверяют эффективность коммуникаций и полноту озвученных мер. Из отчета команды red team можно выделить следующие показатели:

• количество неуспешных попыток эксплуатации;
• количество атак, выявленных командой реагирования;
• скорость устранения последствий инцидента;

Если red teaming проводится одной командой по единой методике, то результаты можно сравнивать в зависимости от атакуемой организации или информационной системы».

Алексей Новаков, руководитель направления по кибербезопасности «АйТи Бастион», обращает внимание на то, что при оценке готовности к киберинцидентам крайне важно соблюдать баланс между показателями систем предотвращения атак и показателями управления инцидентами.

«В случае с инцидентами ИБ важно соблюдать строгий баланс между метриками систем предотвращения кибератак (покрытие СЗИ, метрики патчей, доступов и других процессов ИБ) и метриками по управлению инцидентами ИБ (среднее время реагирования на инцидент, среднее время локализации, покрытие агентами EDR, к примеру, если используется для мониторинга). Иными словами, для оценки уровня готовности к кибератакам необходимо строго контролировать и метрики превентивных мер и метрики управления».

Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision, считает, что мониторинг уровня готовности компании к киберинцидентам должен базироваться на комплексном подходе, который объединяет оценку зрелости процессов ИБ и ИТ, технической стороны работы СЗИ, оперативности обнаружения инцидентов, а также влияние инцидентов на репутацию и финансы компании. Он подчёркивает значимость регулярного анализа динамики показателей.

«На практике необходимо использовать комплексный подход и комбинировать различные метрики, которые позволят оценить:

• Зрелость процессов ИБ и ИТ и уровень соблюдения политик.
• Технологическую сторону работы СЗИ.
• Уровень устранения уязвимостей.
• Процент защищенных критических систем.
• Среднее время обнаружения и реагирования.
• Соблюдение SLA.
• Количество ложноположительных срабатываний.
• Уровень компетенции и дисциплины сотрудников.
• Финансовый предотвращённый ущерб.
• Число инцидентов, приведших к публичной огласке или репутационному ущербу.

Важным фактором является анализ динамики и регулярный пересмотр показателей, это позволит поддерживать высокую готовность компании к киберинцидентам».

Эксперты уверены, что для объективного мониторинга уровня готовности компании к киберинцидентам необходимо применять комплексный подход, включающий практические имитационные учения, оценку технической оснащенности, а также динамический анализ разнообразных метрик, отражающих как превентивные меры, так и эффективность управления инцидентами.

Как учитывать скорость изменений в ИТ-ландшафте компании при пересмотре метрик ИБ, чтобы не терять актуальность данных?

Александр Зубриков, генеральный директор ITGLOBAL.COM Security, считает, что для того чтобы ИБ не отставало от стремительных изменений в ИТ-ландшафте компании, информационная безопасность должна быть неотъемлемой частью всех бизнес-процессов и потоков данных, а не функционировать как оторванное звено.

«Примерно такой же подход используется в методологии DevSecOps, что позволяет ИБ развивать свои подходы не просто с теми же темпами, а буквально одновременно с изменениями в разработке, сервисе или бизнес-процессах».

Павел Нагин, руководитель по развитию продуктов компании SQUAD, отмечает, что поддержание актуальности данных об ИТ-ландшафте начинается с выстроенных процессов инвентаризации, которые позволяют отслеживать состояние хостов корпоративной сети.

«Необходимо, чтобы эти данные как минимум содержали информацию о владельцах хостов и соответствующих им сервисах, о версиях ОС и ПО, о наличии обновлений и антивируса. Наиболее эффективным является автоматизированный сбор такой информации, например, с помощью агентов на хостах или централизованных консолей управления. Также полезно ограничивать доступ в сеть для хостов, которые не предоставляют данные инвентаризации (shadow IT)».

Алена Игнатьева, руководитель направления консалтинга и аудита информационной безопасности STEP LOGIC, считает, что для сохранения актуальности метрик ИБ необходимо регулярно пересматривать их как в рамках ежегодного планирования, так и в ходе оперативной деятельности через участие в технологических комитетах и мониторинг событий.

«Помимо этого, пересмотр можно проводить в рамках текущей деятельности: участие в технологических комитетах, согласование заявок на изменения, договоров на ИТ и ИБ услуги, а также мониторинг событий ИБ и реагирование на инциденты».

По словам специалистов, актуальность метрик информационной безопасности напрямую зависит от регулярной инвентаризации, интеграции ИБ во все бизнес-процессы и систематического пересмотра показателей в рамках как долгосрочного планирования, так и оперативного управления изменениями.

Какие метрики позволяют одновременно оценивать внутренние процессы безопасности и взаимодействие с подрядчиками, не упуская ключевых рисков?

Александр Зубриков, генеральный директор ITGLOBAL.COM Security, считает, что для комплексной оценки внутренней безопасности и взаимодействия с подрядчиками необходимо учитывать не только формальное соответствие требованиям, но и реальное состояние защищенности сторонних организаций. Он отмечает, что отказ подрядчика подписывать обязательные соглашения или учитывать требования по безопасности служит тревожным сигналом, а также подчёркивает важность проведения собственных аудитов и регулярного контроля за изменениями в оценке соответствия.

«Если подрядчик отказывается подписывать SLA, NDA или учитывать ваши требования по безопасности, это уже должно быть красным флагом для работы с ним. Также, неплохим методом оценки может быть не только запрос свидетельств соответствия 152-ФЗ, 21 приказу ФСТЭК России, ISO 27001 и тд, но и запрос результатов или хотя бы периодичности проведения различных оценок соответствия, например пентестов или аудитов ИБ, периодичность сканирования и сроки устранения уязвимостей.

Также, последнее время сталкиваемся на практике, что компания может запросить проведения собственного аудита ИБ в подрядчике, или подключить доверенную аудиторскую компанию. Чаще всего такие требования выдвигают финтех или бигтех компании. Эти сферы бизнеса появились сравнительно недавно, часто их руководство выросло в эпоху глобализации, сами вышли из ИТ сферы и часто имеют приличную ИБ зрелость, а также их компании вынуждены полагаться в работе на большее количество подрядчиков для выполнения своих бизнес-функций, которые еще могут часто меняться, в отличии от более классических схем бизнеса, где работа с подрядчиками сложилась исторически и менять что-то уже тяжело и/или затратно».

Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision, утверждает, что метрики для оценки безопасности должны быть риск-ориентированными и охватывать не только эффективность внутренних мер, но и аспекты, связанные с работой с внешними подрядчиками. Он подчёркивает важность применения единой методики для всех участников цепочки, регулярного анализа совместных инцидентов и динамики показателей, а также необходимости закрепления требований в контрактных документах посредством KPI и SLA.

«Метрики должны быть риск-ориентированными и охватывать ключевые аспекты: эффективность внутренних мер, соответствие стандартам, время реагирования, репутационные и финансовые аспекты, соблюдение договоренностей и минимизацию рисков, связанных с третьими сторонами. При работе с подрядчиками необходимо:

• Синхронизировать внутренние стандарты и требования – чтобы все участники цепочки (внутренние отделы и внешние подрядчики) измерялись по единой методике.
• Регулярно собирать и анализировать совместные инциденты и уязвимости – считать не только те проблемы, что возникают внутри компании, но и связанные с деятельностью подрядчиков.
• Отслеживать динамику – смотреть, меняются ли показатели в лучшую сторону при усилении контроля над внешними поставщиками и при совершенствовании внутренних процедур.
• Включать в контракты и отслеживать KPI и SLA по ИБ – чтобы иметь возможность требовать от подрядчика устранения уязвимостей и своевременного уведомления об инцидентах».

Эксперты отмечают, что метрики для оценки безопасности должны учитывать как внутренние процессы, так и взаимодействие с подрядчиками, обеспечивая комплексный подход к минимизации ключевых рисков.

Какие метрики на практике наиболее эффективно демонстрируют уровень соответствия ИБ-требованиям регуляторов?

Алена Игнатьева, руководитель направления консалтинга и аудита информационной безопасности STEP LOGIC, считает, что для объективной оценки соответствия ИБ-требованиям регуляторов следует использовать результаты независимой комплексной оценки. При планировании такой оценки важно ранжировать требования по степени значимости для бизнеса и сопоставлять их с результатами оценки рисков ИБ и ИТ.

«При планировании независимой комплексной оценки следует предусмотреть две вещи:

• Ранжирование требований по степени значимости для бизнеса. Например, для финансовой организации критично соответствие требованиям ЦБ, поскольку за нарушение может последовать приостановление деятельности или отзыв лицензии, а после ввода риск-ориентированного подхода – необходимость резервирования существенных сумм на покрытие риска ИБ. Далее по степени критичности можно отметить требования платежных систем, финансовой группы и отдельных регуляторов (ФСТЭК России, ФСБ России, Роскомнадзор).
• Необходимость корреляции результатов комплексной оценки с результатами оценки рисков ИБ и ИТ».

Александр Зубриков, генеральный директор ITGLOBAL.COM Security, отметил, что когда речь заходит о демонстрации уровня соответствия ИБ-требованиям регуляторов, необходимо учитывать не только процент выполнения мер, но и адаптацию этих мер к реалиям конкретной компании. Он подчеркнул, что оценка должна идти дальше формального процентного показателя, поскольку документация, подготовленная по шаблонам, без внедренных процессов становится лишь формальной бумагой.

«Также, если смотреть на метрики, которые можно выразить в каком-то количественном показателе и реально помогут оценить эффективность, то это будут:

• Процент охвата требований регуляторов при проведении внутренних контрольных мероприятий,
• Частота прохождения внешних оценок соответствия,
• Количество найденных нарушений,
• Среднее время устранение этих нарушений,
• Процент персонала, прошедшего обязательное обучение по требованиям регуляторов,
• Процент автоматизации контроля соответствия требованиям (например, с помощью SGRC системы).

Эти метрики позволяют комплексно оценивать уровень соответствия требованиям регуляторов, а главное, в динамике отслеживать эффективность не только выполнения требований регуляторов, но и работу ИБ отдела. Мы всегда пропагандируем комплексный подход в ИБ, так что и тут, чтобы добиться максимальной пользы, метрики следует использовать в связке: например, отслеживать как частоту проведения внутренних и внешних контрольных мероприятий, так и среднее время устранения выявленных нарушений».

Павел Нагин, руководитель по развитию продуктов компании SQUAD, отмечает, что уровень соответствия часто определяется процентом выполненных требований ИБ, при этом важна не только сама цифра, но и учет критичности каждого требования. Он поясняет, что выполнение регуляторных мер должно быть подкреплено данными инструментальных проверок и визуальными подтверждениями, а также измеряться с учетом покрытия инфраструктуры.

«Уровень соответствия как правило определяется процентом выполненных требований ИБ. Для части требований можно измерять процент покрытия в инфраструктуре (например, % рабочих станций с установленным антивирусом). Если регулятор определяет критичность требований, то метрики должны ее учитывать и задавать приоритет для устранения несоответствий. Выполнение требований регулятора должно не только регистрироваться в системах управления рисками (GRC), но и подкрепляться данным инструментальных проверок, выгрузками и скриншотами из средств защиты».

Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision, утверждает, что для эффективного демонстрирования соответствия требованиям регуляторов метрики должны базироваться на непрерывном мониторинге и оценке ключевых процессов. Он считает, что важны как показатели, связанные с технической защитой, так и показатели, отражающие организационные аспекты – от результатов аудитов до обучения сотрудников и интеграции требований в процессы разработки и закупок.

«Чтобы эффективно демонстрировать уровень соответствия ИБ-требованиям регуляторов, стоит:

• Поддерживать непрерывный мониторинг ключевых систем и процессов (и проверять, насколько он действительно осуществляется).
• Отслеживать результаты аудитов (количество и глубину несоответствий, а также время их устранения).
• Фиксировать все инциденты и оценивать по ним прямой финансовый и репутационный ущерб.
• На регулярной основе проводить обучение сотрудников и на практике проверять их знания по ИБ.
• Интегрировать требования регуляторов в процессы разработки, закупок и ведения проектов и на практике проводить оценку выполнения данных требований.
• Оценивать не только текущий уровень соответствия, но и динамику его изменения.

Метрики, которые будут охватывать вышеуказанные рекомендации, помогут не только выполнить формальные требования, но оказать практическое влияние на снижение рисков и повышение устойчивости компании».

Эксперты сходятся во мнении, что для демонстрации уровня соответствия ИБ-требованиям регуляторов необходимо использовать комплексный набор метрик, который сочетает количественные показатели выполнения мер, данные аудитов, динамику устранения нарушений, а также результаты независимых оценок с ранжированием требований по критичности для бизнеса.

Какие показатели помогают оценивать баланс между затратами на ИБ и реальными бизнес-выгодами от предотвращённых инцидентов?

Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision, заявил, что для оценки баланса между затратами на информационную безопасность и реальными бизнес-выгодами необходимо применять комплексный набор метрик, который включает финансовые, технические и репутационные показатели. Он указывает на необходимость оценки финансовой эффективности предотвращённых инцидентов.

«В данном случае эффективно использовать финансовые, технические и репутационные метрики, а также показатели, демонстрирующие финансовую эффективность предотвращённых инцидентов.

К таким показателям стоит отнести:

• Метрики возврата на инвестиции в ИБ (ROI и VOI).
• Метрики стоимости реальных и потенциальных инцидентов.
• Метрики оценки стоимости предотвращённого ущерба.
• Метрики непрерывности бизнеса и эффективности процессов.
• Метрики эффективности и производительности процессов ИБ.
• Репутационные метрики и клиентские показатели».

Александр Зубриков, Генеральный директор ITGLOBAL.COM Security, заметил, что защита должна быть «необходимой и достаточной», а затраты на ИБ не должны превышать стоимость защищаемых активов. Он подчёркивает важность правильно выстроенного риск-менеджмента, позволяющего оценить вероятность угроз и затраты на их нейтрализацию, при этом особое внимание уделяется метрике возврата на инвестиции в безопасность (ROSI).

«Самая популярная и полезная метрика в данном случае, это Возврат на инвестиции в безопасность (Return on Security Investment, ROSI), оценивающая, насколько оправданы затраты на ИБ с точки зрения предотвращённых убытков. Рассчитывается по формуле:

ROSI = (Стоимость предотвращения инцидентов – Расходы на ИБ) / Расходы на ИБ

Стоимость предотвращения инцидентов – это сумма, которую удалось сэкономить за счёт предотвращения потенциальных киберинцидентов.

К сожалению, не каждый бизнес может адекватно и правильно рассчитать стоимость инцидентов, особенно если ещё ни разу не сталкивался с их последствиями. Поэтому есть несколько более простых метрик. Например, можно отслеживать динамику количества инцидентов по уровням критичности. По этой методике необходимо сравнивать количество инцидентов разного уровня (низкий, средний, высокий риск) до и после внедрения мер безопасности. К сожалению, она не даёт объективного восприятия эффективности затрат, а лишь сравнительное. Также, данная метрика не работает, если у вас грамотно не выстроен процесс мониторинга и обнаружения инцидентов.

Ещё одна понятная и простая, не всегда эффективная метрика – это оценка выполнения требований регулятора или процент их выполнения до и после внедрения мер. Как уже было сказано ранее, требования регулятора не всегда закрывают все потребности в защите. Если санкции и штрафы за нарушения минимальны, то смысл в данной метрике отпадает и полезен только в случае, если нарушение требований может повлечь приостановку бизнес-процесса, но такое чаще всего встречается только в финансовом секторе.

Из простых, но полезных метрик, хотелось бы выделить оценку количества предотвращённых инцидентов от общего числа угроз. При ней мы высчитываем долю угроз, которые были успешно обнаружены и нейтрализованы до того, как они стали инцидентами. Например, из 100 потенциальных угроз, до внедрения средств защиты, осталось только 5, что говорит о 95-процентной эффективности. Минусы у данного метода в том, что полностью нивелировать угрозу без нарушения бизнес-процессов почти нереально, так и при этом методе не учитывается критичность и вероятность реализации угроз.

И главный минус всех этих метрик: чтобы они работали на практике, важно не только фиксировать данные, но и регулярно анализировать их, сравнивая с реальными бизнес-результатами. А также, они все бесполезны без правильно выстроенных процессов ИБ и грамотного риск-менеджмента в компании. Однако, при правильном и комплексном подходе, данные метрики позволяют оптимизировать расходы и аргументировать необходимость новых инвестиций в ИБ».

Алена Игнатьева, руководитель направления консалтинга и аудита информационной безопасности STEP LOGIC, подчёркивает, что эффективность системы ИБ и отдельных её процессов можно оценивать с использованием классической формулы расчёта окупаемости инвестиций (ROI). Она приводит конкретный пример, где предотвращённые расходы на инциденты выступают в качестве доходов, что позволяет наглядно продемонстрировать высокую эффективность вложений.

«Необходимо оценивать эффективность не только системы ИБ в целом, но и отдельных её процессов для своевременного реагирования и принятия корректирующих действий.
Можно использовать классическую формулу расчёта окупаемости инвестиций (ROI).
При этом к доходам относится сумма предотвращённых расходов на инциденты ИБ. Данная величина рассчитывается при оценке рисков и, при наличии соответствующей статистики, корректируется непосредственно в ходе расчёта окупаемости.

Например, комиссией было принято решение, что контрольное значение уровня риска для несанкционированных переводов денежных средств составляет 4 копейки на каждый рубль платежей в системах банка. На момент оценки окупаемости в базе рисковых событий содержится информация о том, что антифрод-системой были предотвращены попытки на сумму 7 копеек на каждый рубль платежей. Очевидно, что в расчёт окупаемости следует брать большую величину.
Стоимость антифрод-системы составляет 10 000 руб. в год (лицензии, сопровождение, ФОТ), платежей было совершено на сумму 1 000 000 руб. При этом по оценке рисков закладывали долю несанкционированных переводов денежных средств 1 000 000 * 0,04 = 40 000 руб. А в ходе оценки окупаемости в базе данных содержалась информация о попытках на сумму 70 000 руб.

Тогда, расчёт выглядит таким образом:

(70 000 (доход – предотвращённые попытки несанкционированных переводов) – 10 000 (расход, стоимость антифрод-системы)) / 10 000 * 100% = 600%»

Алексей Новаков, руководитель направления по кибербезопасности «АйТи Бастион», отмечает, что количественную оценку рисков в области ИБ вывести сложно, однако можно использовать такие показатели, как соотношение времени простоя к времени восстановления и отношение количества инцидентов к стоимости ущерба, чтобы дать представление о том, насколько эффективны предпринятые меры безопасности.

«Говорить про количественную оценку рисков ИБ сложно. Однако, например, показатель «время простоя/время восстановления», когда компания не может оказывать услуги клиентам из-за DDOS-атаки или иного инцидента ИБ, и показатель соотношения количества инцидентов к стоимости ущерба в результате атаки, вполне могут помочь в оценке.»

Павел Нагин, руководитель по развитию продуктов компании SQUAD, указывает, что в области информационной безопасности универсальные показатели вывести сложно, так как оценка зачастую проводится экспертно. Он отмечает, что антфрод-системы представляют собой исключение, поскольку для них предотвращённый ущерб рассчитывается достаточно просто.

«В ИБ очень сложно вывести такие показатели, обычно оценивается экспертно. Исключение – антфрод системы, для них предотвращённый ущерб считается достаточно просто».

Эксперты заявляют, что для оценки баланса между затратами на ИБ и реальными бизнес-выгодами от предотвращённых инцидентов необходимо использовать комплексный подход, объединяющий финансовые и операционные метрики, а также проводить регулярный анализ динамики ключевых показателей в рамках правильно выстроенного риск-менеджмента.

Какие показатели можно использовать для построения прогностической аналитики, которая заранее предупреждает о росте киберугроз?

Павел Нагин, руководитель по развитию продуктов компании SQUAD, считает, что для построения прогностической аналитики необходимо опираться на ретроспективный анализ различных источников информации: данных об инцидентах внутри организации, данных об атаках из Интернета, зарегистрированных средствами защиты (IDS, WAF, NGFW), а также данных о выявленных уязвимостях, их критичности и легкости эксплуатации. Он также указывает, что сервисы киберразведки (Threat Intelligence) значительно облегчают оценку угроз, предоставляя подробную информацию об актёрах атак и их методах.

«Если организация пользуется сервисами киберразведки (Threat Intelligence), то отчеты от данных сервисов хорошо помогают в оценке угроз, так как содержат информацию кто, кого и как атакует. Как правило в таких отчетах уже содержатся предупреждения о росте киберугроз и рекомендации как с ними бороться».

Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision, утверждает, что задача прогностической аналитики заключается в идентификации трендов и сигналов, указывающих на потенциальное увеличение киберугроз в информационном пространстве и инфраструктуре компании. Он настаивает на использовании метрик, отражающих динамику угроз, уязвимостей и активности злоумышленников, с опорой на данные как текущих, так и прошлых инцидентов, а также глобальные тенденции.

«Следует обращать внимание на следующее:

• Количественная динамика индикаторов компрометации – IoC. Резкий рост количества IoC по вашей отрасли часто указывает на готовящуюся или уже ведущуюся атаку.
• Уровень критичности и опасности, присваиваемый внешними поставщиками IoC. Если наблюдается повышение уровня конкретной угрозы, это сигнал к усилению мониторинга и подготовке контрмер.
• Частота обнаружения критичных уязвимостей. Если появляется сразу несколько критичных уязвимостей, а цикл устранения затягивается, риск эксплуатации возрастает в геометрической прогрессии.
• Рост числа уязвимостей в используемых продуктах и решениях. Это часто предвещает появление новых эксплойтов, которые злоумышленники будут эксплуатировать в своих атаках.
• Аномальный рост неуспешных попыток входа в систему. Необходимо измерять их динамику. Если она выходит за привычные пороговые значения, это сигнал о возможных усиленных атаках.

Показатели поведенческих аномалий внутри компании. Резкие отклонения от нормального поведения сотрудников, такие как скачки в объёме скачиваемых данных, доступ к нестандартным ресурсам, активность в нерабочее время и т.д.».

Александр Зубриков, Генеральный директор ITGLOBAL.COM Security, привёл пример из практики своего сервиса SOC, где для прогнозирования роста киберугроз используется комплексный подход, объединяющий анализ как внутренних, так и внешних метрик. Он отмечает, что изучение динамики различных типов угроз, например, фишинговых атак, а также анализ аномалий в сетевом трафике и попыток сканирования публичных сервисов позволяет своевременно выявлять признаки надвигающихся угроз. Кроме того, он подчёркивает важность корректировки правил корреляции на основе данных Threat Intelligence и совместного анализа с экспертами по пентесту и менеджменту ИБ.

«Под внутренними метриками мы понимаем анализ роста или снижение числа событий, относящихся к определенным типам угроз (фишинг, атаки ransomware, DDoS и т.д.). Например, фишинговые атаки увеличиваются на 20% месяц к месяцу, это сигнал к пересмотру антифишинговых мер. Также, мы проводим анализ аномалии в сетевом трафике, что помогает находить подозрительные активности, которые могут предшествовать инцидентам. Например, увеличение количества попыток сканирования опубликованных сервисов и публичных адресов, что может свидетельствовать о подготовке к атакам. Еще одной нашей внутренней метрикой являются исторические данные об атаках на схожие компании, что часто позволяет заранее рекомендовать нашим клиентам применить превентивные меры защиты.

Из внешних метриками, данных, полученных вне нашего сервиса, мы используем технологии и методики Threat Intelligence, что позволяет учитывать глобальные тенденции и заранее подготовить наших клиентов к потенциальным угрозам, а также корректировать наши правила корреляции и аналитику, что позволяет улучшить точность срабатываний наших систем, минимизировать ложно положительные срабатывания, которые могут отвлекать внимание от реальных угроз.

Также, совместно с нашими специалистами из направления пентеста и менеджмента ИБ, мы анализируем тренды в векторах атак, новых методах взлома, а также анализируем не только факт, но и динамику новых уязвимостей, обнаруженных в продуктах, которые используются у наших клиентов. Как видите, только комплексный подход и анализ показателей, как с внешних, так и внутренних источников информации в связке с системами автоматизации, например SOC и Threat Intelligence позволяют своевременно выявлять признаки роста киберугроз, а также принимать упреждающие меры для их предотвращения».

Алена Игнатьева, руководитель направления консалтинга и аудита информационной безопасности STEP LOGIС, уверена, что для построения адекватных прогнозов важно учитывать широкий спектр факторов, выходящих за рамки технических показателей. По её мнению, при формировании прогностической аналитики следует анализировать тенденции изменения внешних условий (например, климатические и криминогенные показатели стран присутствия), инновационные технологии, стратегические и тактические планы компании, данные киберразведки, статистику инцидентов в отрасли, а также планы служб ИТ и ИБ.

«Для построения адекватных прогнозов следует учитывать следующие факторы:

• Тенденции изменения внешних условий для основных стран присутствия организации и ключевых подрядчиков ИБ и ИТ (климата, криминогенной обстановки, уровня жизни населения);
• Инновации и массовое распространение новых технологий;
• Стратегические планы компании – выход на новые территории присутствия, изменение бизнес-процессов, масштабов деятельности, клиентского портфеля, смена собственников, выход на биржу;
• Тактические цели компании – вывод новых бизнес-продуктов, изменения в штатной структуре и численности, переезд ИТ-инфраструктуры;
• Данные киберразведки (Threat Intelligence);
• Статистику инцидентов ИБ как в отрасли, так и по компании и ключевым ИБ и ИТ-поставщикам;
• Планы служб ИТ и ИБ».

Эксперты отмечают, что для построения прогностической аналитики, предупреждающей о росте киберугроз, необходим комплексный подход, включающий ретроспективный анализ инцидентов, оценку динамики уязвимостей и активности злоумышленников, а также учёт внешних факторов и стратегических планов компании.

Итог

В целом, подход к оценке информационной безопасности должен быть комплексным и ориентированным на реальные бизнес-процессы. Метрики не должны ограничиваться простыми количественными показателями, такими как количество уязвимостей или инцидентов, а учитывать контекст – масштаб и сложность ИТ-инфраструктуры, специфику бизнес-процессов, а также динамику изменений как внутри компании, так и в глобальной киберсреде. Только интеграция качественных и количественных данных, адаптированных под конкретные цели бизнеса, позволяет объективно оценить уровень защищенности и выявить области для совершенствования.

При этом крайне важно регулярно пересматривать и обновлять метрики, чтобы они отражали актуальные риски и тенденции, а также корректно демонстрировали эффективность принимаемых мер. Такой системный и динамичный подход способствует не только выявлению текущих уязвимостей, но и позволяет прогнозировать развитие угроз, что в итоге помогает оптимизировать затраты на информационную безопасность и повысить устойчивость бизнеса к киберинцидентам.