Отчётность по безопасности и язык денег
Метрики собраны — теперь их нужно донести до тех, кто принимает решения. Руководству не нужны графики: ему нужно понимать, стало ли безопаснее, где рискуем и сколько это стоит.
В этой главе — форматы доклада, постановка целей, перевод риска в рубли и модель зрелости, по которой видно движение.
Лидер безопасности — сотрудник, который берёт на себя вопросы информационной безопасности в команде как дополнительную зону ответственности. Далее по тексту — «лидер безопасности».
Отчётность перед руководством
Метрики бесполезны, если руководство их не видит. Регулярная отчётность делает безопасность видимой и демонстрирует ценность.
Периодичность отчётности
| Отчёт | Периодичность | Аудитория | Содержание |
|---|---|---|---|
| Дашборд | В реальном времени | Команда ИБ | Все метрики, детально |
| Еженедельная сводка | Еженедельно | Лидер безопасности + IT-руководители | Ключевые изменения, оповещения |
| Ежемесячный отчёт | Ежемесячно | Руководители подразделений | Тренды, направления фокуса |
| Квартальный обзор | Ежеквартально | Топ-менеджмент | Стратегический взгляд, достижения |
| Годовой отчёт | Ежегодно | Совет директоров (если применимо) | Итоги года, дорожная карта |
Шаблон квартального отчёта
Все шаблоны — в библиотеке шаблонов.
Как презентовать руководству
1. Начинайте с главного: «Безопасность в хорошем состоянии. Два пункта требуют внимания.»
Не: «Позвольте провести вас через наши 47 метрик...»
2. Используйте светофор:
- Зелёный: цель достигнута
- Жёлтый: требует внимания
- Красный: критичная проблема
3. Показывайте тренды, а не только числа: «Кликабельность при фишинге снизилась с 18% до 4% за год» — это история. «4% кликабельности при фишинге» — просто цифра.
4. Связывайте с бизнес-последствиями:
- «Эта уязвимость могла раскрыть данные клиентов»
- «МФА предотвращает главную причину компрометации учётных записей»
- «Быстрое реагирование = меньше простоя = меньше потерь выручки»
5. Говорите честно о проблемах: Руководство ценит честность. Замалчивание проблем разрушает доверие.
6. Приходите с решениями: К каждой проблеме — план. «МФА в CRM на уровне 83%. Достигнем 100% до 15 апреля».
7. Просите то, что нужно: Формулируйте запрос чётко. «Прошу одобрить пилот SIEM стоимостью 90 000 руб./квартал».
Как отвечать на сложные вопросы
| Вопрос | Как отвечать |
|---|---|
| «Мы защищены?» | «Ни одна организация не защищена на 100%. Мы эффективно управляем ключевыми рисками. Вот подтверждение: [метрики]» |
| «Как мы выглядим на фоне других?» | «По данным российских ИБ-компаний, компании нашего масштаба в среднем [X]. У нас [Y], что [выше/ниже/на уровне] среднего.» |
| «Зачем нам больший бюджет?» | «Текущий бюджет даёт нам [X охват]. Дополнительный бюджет закрыл бы [конкретный пробел], который представляет [риск].» |
| «Гарантируете, что взломов не будет?» | «Никто не может дать такую гарантию. Мы снижаем вероятность и ущерб. Вот что для этого делаем: [конкретно]» |
| «Каков наш главный риск?» | «[Конкретный риск] — потому что [причина]. Мы работаем над этим через [действие].» |
Постановка целей
Метрики нужны только вместе с целями. Без ориентиров числа ни о чём не говорят.
Как ставить реалистичные цели
1. Сначала базовый уровень: Измерьте текущее состояние перед постановкой целей. Нельзя улучшить то, что не знаешь.
2. Отраслевые ориентиры: Используйте данные российских аналитических компаний:
- Кликабельность при фишинге без обучени я: 25–35%, цель — менее 10%, отлично — менее 5%
- Кликабельность при фишинге с обучением: 10–15%, цель — менее 5%
- Охват МФА: типично 60–70%, цель — более 90%, отлично — 100%
- Патч-комплаенс (критические, 7 дней): типично 60%, цель — более 85%, отлично — более 95%
По данным Positive Technologies, ГК «Солар», F.A.C.C.T., Лаборатории Касперского — в качественных формулировках.
3. Учитывайте ограничения:
- Размер команды
- Бюджет
- Технический долг
- Конкурирующие приоритеты
4. Постепенное улучшение: Если кликабельность 15% — не ставьте цель 2%. Сначала целевой показатель 10%.
Пример годовых целей по безопасности
Все шаблоны — в библиотеке шаблонов.
Деньги: метрики на языке бизнеса
Руководство говорит на языке денег. Перевод безопасности в финансовые термины делает позицию убедительнее.
Упрощённый подход к оценке риска
Для оценки риска используйте базовую формулу:
Риск (руб.) = Вероятность события × Ущерб от события
Пример: атака с целью захвата учётных записей (credential stuffing)
- Вероятность: ~20% в год (на основе отраслевых данных и вашей экспозиции)
- Ущерб: ~1 500 000 руб. (реагирование на инцидент, простой, репутация)
- Годовой риск: 0,20 × 1 500 000 = 300 000 руб. ожидаемых потерь
Если МФА стоит 60 000 руб./год и снижает вероятность до 2%:
- Новый риск: 0,02 × 1 500 000 = 30 000 руб.
- Снижение риска: 300 000 − 30 000 = 270 000 руб.
- ROI: (270 000 − 60 000) / 60 000 = 350%
Шаблон для быстрой оценки риска
Для каждого ключевого риска оцените:
| Фактор | Как оценить | Пример |
|---|---|---|
| Вероятность | Отраслевые данные + ваши меры защиты | 20% в год |
| Прямой ущерб | Реагирование на инцидент, восстановление, штрафы | 500 000 руб. |
| Вторичный ущерб | Репутация, потеря клиентов, судебные издержки | 1 000 000 руб. |
| Общий ущерб | Прямой + вторичный | 1 500 000 руб. |
| Ожидаемые потери | Вероятность × Ущерб | 300 000 руб./год |
Ориентиры стоимости инцидентов для российского бизнеса
По качественным оценкам российских ИБ-компаний (без точных цифр, варьируется по отраслям и масштабу):
| Категория инцидента | Малый бизнес (до 100 чел.) | Средний бизнес (100–500 чел.) |
|---|---|---|
| Утечка данных клиентов | от 300 тыс. руб. | от 1,5 млн руб. |
| Шифровальщик (с восстановлением) | от 500 тыс. руб. | от 3 млн руб. |
| Компрометация деловой переписки (BEC) | от 200 тыс. руб. | от 1 млн руб. |
| Простой инфраструктуры (за сутки) | от 50 тыс. руб. | от 300 тыс. руб. |
По данным Positive Technologies, ГК «Солар», F.A.C.C.T. Точные суммы зависят от отрасли, масштаба, скорости обнаружения и наличия страховки.
Расчёт ROI инвестиций в безопасность
При запросе бюджета — покажите расчёт:
Инициатива: внедрение анализа защищённости кода (SAST) в CI/CD
Стоимость: 180 000 руб./год (инструмент + время на настройку)
Без SAST:
- Уязвимостей в продакшне ежегодно: ~20
- Средняя стоимость устранения в продакшне: 75 000 руб.
- Итого: 1 500 000 руб./год + риск утечки
С SAST:
- Уязвимостей перехвачено до продакшна: 18 из 20 (90%)
- Уязвимостей в продакшне: 2/год
- Средняя стоимость устранения на этапе разработки: 7 500 руб.
- Итого продакшн: 2 × 75 000 = 150 000 руб.
- Итого разработка: 18 × 7 500 = 135 000 руб.
- Общая стоимость: 285 000 руб.
Экономия: 1 500 000 − 285 000 = 1 215 000 руб.
ROI: (1 215 000 − 180 000) / 180 000 = 575%
Плюс: снижение вероятности утечки (сложнее оценить, но реально)
Совет: не ну жна ложная точность. «Риск от 500 тыс. до 1,5 млн руб.» — полезно. «Риск 847 342 руб.» — подрывает доверие.
Модель зрелости безопасности
На каком уровне зрелости находится ваша организация? Это помогает ставить реалистичные цели и коммуницировать прогресс.
Пять уровней зрелости
Экспресс-оценка зрелости
| Область | Уровень 1 | Уровень 2 | Уровень 3 | Уровень 4–5 |
|---|---|---|---|---|
| Уязвимости | Устран яем после взлома | Иногда сканируем | Регулярные сканы, SLA | Автоматизировано, на основе рисков |
| Доступ | Общие пароли | Индивидуальные аккаунты | МФА, проверки доступа | Zero trust, JIT |
| Реагирование | Паника | Базовые рунбуки | Отработанный ПРИ | Автоматизированный отклик |
| Обучение | Никакого | Разовый онбординг | Ежегодное обучение | Постоянное, ролевое |
| Метрики | Никаких | После инцидентов | Базовый дашборд | Предиктивная аналитика |
Метрики по уровню зрелости
Уровень 1–2 (начало):
- Есть ли базовые меры? (чек-лист да/нет)
- Защищены ли критические системы? (бинарно)
- Можем ли обнаружить очевидные атаки? (результаты тестирования)
Уровень 2–3 (построение фундамента):
- Количество и тренд уязвимостей
- Процент охвата МФА
- До ля прошедших обучение
- Количество инцидентов и критичность
Уровень 3–4 (зрелость):
- Тренды MTTR, MTTD
- Взвешенные по рискам оценки уязвимостей
- Опережающие индикаторы (безопасность в дизайне)
- Стоимость устранения одной уязвимости
Уровень 4–5 (оптимизация):
- Предиктивные оценки рисков
- ROI безопасности по инициативам
- Метрики рисков в бизнес-терминах
- Сравнение с отраслевыми ориентирами
Как метрики становятся инструментом манипуляции
Любая метрика, ставшая целью, будет оптимизироваться. Предвидьте это и проектируйте противовесы.
Типичные паттерны манипуляции
| Манипуляция | Как выглядит | Реальная проблема |
|---|---|---|
| Занижение критичности | «Это средний, не высокий» | Критические уязвимости проходят мимо SLA |
| «Не будем исправлять» | MTTR выглядит отлично, уязвимости остаются | Риск не снизился |
| Фокус на лёгком | 50 низких закрыто, 2 критических проигнорированы | Неверные приоритеты |
| Манипуляция знаменателем | «Только 5 систем нуждаются в патчах» (50 исключено) | Скрытые пробелы |
| Игры со временем | Уязвимость обнаружена 1 апреля, зафиксирована 5 апреля | MTTD выглядит лучше, чем есть |
| Дрейф определений | «Это не инцидент, просто событие» | Меньше инцидентов, меньше обучения |
Как предотвратить манипуляции
-
Несколько коррелирова нных метрик: если MTTR оптимизируется через «не исправлять», также отслеживайте «% уязвимостей, принятых как допустимый риск» и требуйте одобрения руководителя.
-
Метрики результатов вместе с метриками активности: считайте и «закрытые уязвимости», и «уязвимости, обнаруженные в продакшне».
-
Случайные проверки: периодически выборочно проверяйте закрытые уязвимости. Действительно ли они исправлены?
-
Аномалии в трендах: внезапные улучшения должны вызывать вопросы. Что реально изменилось — или изменилось измерение?
-
Независимая валидация: периодический пентест выявляет то, что скрывают собственные метрики.
Реальные истории: когда метрики меняли всё
История 1: График фишинга, которы й принёс бюджет
Лидер безопасности в компании на 150 человек полгода отслеживал результаты симуляций фишинга. Первая симуляция: 24% кликабельности. После ежемесячных симуляций и целевого обучения: 4%.
На встрече с CEO он не говорил об «осведомлённости по безопасности». Он показал:
- «24% сотрудников отдали бы реквизиты атакующим»
- «Сейчас 4% — снижение в 6 раз»
- «По оценкам, инцидент с компрометацией деловой переписки стоил бы компаниям нашего масштаба от нескольких сотен тысяч рублей»
- «Мы снизили этот риск, потратив [сумму] на обучение»
Результат: CEO одобрил бюджет на платформу симуляции фишинга и отметил инициативу на общем собрании.
История 2: MTTR, выявивший сломанный процесс
Компания отслеживала MTTR уязвимостей и гордилась средним показателем 5 дней. Потом лидер безопасности покопался глубже:
- Критические: 3 дня (хорошо)
- Высокие: 8 дней (нормально)
- Средние: 45 дней (скрыто средним значением)
Усреднение маскировало игнорирование средних уязвимостей. После выявления проблемы ввели SLA по уровням критичности, и реальная ситуация улучшилась.
История 3: Отсутствие опережающих метрик
Стартап измерял инциденты и уязвимости, но ничего — о процессе разработки. Инцидентов не было (хорошо!), но также:
- Безопасность не включена в код-ревью
- Нет SAST и проверки зависимостей
- Нет обучения разработчиков по безопасному коду
Новый лидер безопасности добавил опережающие метрики:
- % репозиториев с автоматическим сканированием: 0%
- % разработчиков с обучением по ИБ: 10%
- % PR с ревью безопасности: 0%
Эти данные убедительно показали, что низкое число инцидентов — удача, а не защита. Через 6 месяцев после внедрения практик первая критическая уязвимость была поймана в CI/CD — до продакшна.
История 4: Отсутствие метрик как причина катастрофы
Среднее предприятие не имело метрик безопасности. Руководство считало: нет новостей — хорошие новости. Потом случилась атака шифровальщика:
- Нет видимости состояния патчей — 40% систем отставали на месяцы
- Нет инвентаря доступа — невозможно определить скомпрометированные учётные записи
- Нет метрик инцидентов — нет базового уровня «нормального» времени обнаружения
- Восстановление заняло 3 недели; ущерб — от нескольких миллионов рублей
Первый вопрос CEO после инцидента: «Почему мы не знали, что уязвимы?» Ответ: «Мы не измеряли».
Управленческое задание: создайте дашборд безопасности
Поручите лидеру безопасности разработать систему отчётности. Ваша роль — согласовать метрики, которые важны для бизнеса, и регулярно получать отчёты.
Часть 1: Определение метрик (1 час для лидера безопасности)
Что поручить:
- Выбрать 5–7 метрик из списков выше
- Обеспечить охват: уязвимости, доступ, инциденты, осведом лённость
- Выбрать метрики, которые реально можно измерять уже сейчас
- Собрать текущий базовый уровень по каждой
Что вам нужно сделать:
- Согласовать, какие 2–3 метрики наиболее важны для вас как CEO/CTO
- Убедиться, что метрики связаны с реальными рисками, а не с активностью
Часть 2: Построение дашборда (2 часа для лидера безопасности)
Что поручить:
- Создать структуру в выбранном инструменте (Яндекс Таблицы, МойОфис, корпоративная вики)
- Построить представление для руководства (5–7 метрик)
- Построить детальное операционное представление
- Добавить тренды там, где есть исторические данные
Что вам нужно сделать:
- Согласовать частоту обновления и периодичность отчётности
Часть 3: Первый квартальный отчёт (1 час для лидера безопасности)
Что поручить:
- Использовать шаблон из этой главы
- Заполнить текущими данными
- Написать нарративное резюме ключевых моментов
Что вам нужно сделать:
- Запланировать ежеквартальный 30-минутный разбор с лидером безопасности
- На первом разборе: задать хотя бы 3 вопроса по данным (это показывает важность)
Ожидаемые артефакты
- Список из 5–7 ключевых метрик безопасности
- Базовые измерения по каждой метрике
- Целевые значения и сроки
- Дашборд для руководства (таблица или инструмент)
- Детальная таблица отслеживания метрик
- Черновик первого квартального отчёта
- Расписание сбора данных и отчётности
- Определены 5–7 метрик безопасности, покрывающих ключевые риски
- По каждой метрике установлен базовый уровень и целевое значение
- Дашборд для руководства существует и обновляется регулярно
- Квартальные отчёты запланированы и проводятся
- Метрики связаны с конкретными бизнес-рисками, а не только с техническими показателями
- Руководство знает статус хотя бы 3 ключевых метрик без специального запроса
- При ухудшении метрик — есть объяснение и план
Вопрос, который покажет зрелость программы: «Назовите две метрики, которые сейчас хуже целевого значения. Что мы с этим делаем?» Если лидер безопасности отвечает без замешательства — программа измерения работает.
Заключение
Измеряйте, чтобы улучшать — а не чтобы отчитываться. Дашборд, на который никто не смотрит, — лишняя нагрузка. Три метрики, влекущие действия каждый месяц, стоят больше двадцати метрик, которые раз в квартал представляют и тут же забывают.
Начните просто. Таблица — нормально. Привычка измерять важнее инструмента.
См. также
- Метрики безопасности — откуда берутся цифры
- Риск в деньгах и STRIDE — количественная оценка риска
- Получение поддержки руководства — разговор с руководством
Что дальше
На этом раздел о культуре безопасности завершён. Следующий раздел — стратегия и долгосрочное развитие: управление рисками, соответствие требованиям, безопасность поставщиков и масштабирование программы.