Три квартала подряд я защищал бюджет на пентесты перед советом директоров финтех-компании - 6 миллионов рублей в год на четыре проекта. Каждый раз один и тот же вопрос от CFO: «Вы нашли 47 уязвимостей в прошлом квартале - и что изменилось?». Ответ «мы стали безопаснее» не конвертируется в подпись на бюджете. Конвертируется дашборд с тремя числами: risk exposure до пентеста в рублях, risk exposure после ремедиации и дельта между ними. Эта дельта и есть ROI. Ниже - конкретные формулы, 9 метрик, шаблон квартального отчёта и decision tree: какие KPI для пентеста показывать CISO, а какие оставить внутри команды.
Почему «47 уязвимостей» - бесполезная оценка результатов пентеста
Количество найденных уязвимостей - самая распространённая и самая бесполезная метрика в отчётах. Три причины.Число зависит от scope. Нашли 47 в этом квартале и 32 в следующем - это улучшение security posture или урезали scope на два приложения? Без нормализации на единицу покрытия (endpoint, KLOC, IP-подсеть) число плавает от проекта к проекту и ни о чём не говорит.
Severity распределена неравномерно. 40 Informational и 7 Critical - совершенно другая картина, чем 47 Medium. Для CISO один Critical RCE на внешнем периметре опаснее сотни информационных утечек заголовков. И он прав.
Количество находок не коррелирует с реальным снижением риска. Если из 47 уязвимостей за 90 дней закрыли только 12, а 5 Critical висят без патча - пентест не снизил risk exposure, а только задокументировал его. По данным Software Secured, среднее время патчинга уязвимости в dev-командах - около 202 дней, а weaponization эксплойта после публичного раскрытия занимает в среднем 8 дней. Окно уязвимости - почти 7 месяцев. Семь. Месяцев.
Бизнесу нужно не «сколько нашли», а «на сколько снизилась вероятность инцидента» и «сколько стоил бы инцидент без пентеста». Для этого и существует фреймворк метрик.
Фреймворк метрик информационной безопасности: 9 показателей эффективности
Метрики делятся на две группы: операционные (измеряют качество самого пентеста) и метрики ремедиации (измеряют, что произошло после отчёта). Первая группа - для пентест-команды и тимлида. Вторая - для CISO и CFO. Нужны обе, но показывать их надо разным людям.Операционные метрики: что измерять во время и после проекта
1. Attack Surface Coverage. Процент активов организации, покрытых тестированием. Веб-приложения, API, внешний периметр, внутренняя сеть, Wi-Fi, социальная инженерия - каждый класс активов считается отдельно. Если в прошлом квартале тестировали 3 из 12 production-приложений - coverage 25%. Метрика выражается как чек-лист: актив протестирован / не протестирован.Тут есть нюанс, который часто мешают в кашу: для внешнего пентеста coverage считается по количеству внешних IP, доменов и API-endpoints. Для внутреннего - по сегментам сети и критичным хостам (DC, файловые серверы, jump hosts). Смешивать их в одном показателе - ошибка, которая маскирует реальные gaps.
2. Vulnerability Discovery Rate. Количество находок на единицу scope - на приложение, на IP-адрес или на 1000 строк кода (для code-assisted пентеста). По данным Cobalt, если discovery rate и частота критичных находок снижаются от проекта к проекту при стабильном scope - это признак зрелости программы, а не повод менять подрядчика. Скорее сигнал, что пора переходить к следующему уровню: code-assisted pentest или red teaming.
3. Critical Vulnerabilities Found. Абсолютное и процентное количество находок с CVSS >= 9.0. На этапе reconnaissance (Vulnerability Scanning, T1595.002) и initial access (Exploit Public-Facing Application, T1190) пентестер ищет именно те уязвимости, которые дают точку входа - они отслеживаются отдельной строкой.
4. False Positive Rate. Доля находок, не воспроизведённых при верификации. Высокий показатель - прямой сигнал о зависимости от автоматических сканеров без ручной валидации. Целевой ориентир в зрелых программах - менее 5%. Если у вас 15-20% - пора задать вопросы тому, кто проводил тестирование.
5. Test Cadence. Частота тестирования определяет актуальность данных. Ежегодный пентест - compliance-минимум (и по сути галочка). Ежеквартальный - базовая зрелость. Continuous validation - зрелая программа. По данным Software Secured, квартальные пентесты сокращают время триажа на 69 минут на каждую уязвимость - в среднем 29 часов экономии на проект.
| Cadence | Ориентир стоимости | Coverage | Актуальность данных | Когда применять |
|---|---|---|---|---|
| Раз в год | 1.5–3 млн руб./проект | Низкий | Устаревает через 2-3 месяца | Compliance-минимум, legacy с редкими релизами |
| Раз в квартал | 4–8 млн руб./год | Средний | Актуальна 60-80 дней | Регулярные релизы, fintech, e-commerce |
| Continuous (BAS + ручной) | 6–15 млн руб./год | Высокий | Актуальна непрерывно | Зрелые программы, критичная инфраструктура |
Ограничение, о котором молчат вендоры BAS: continuous validation проверяет известные TTPs и конфигурации controls, но не находит zero-day и logic-баги в бизнес-логике. Automated pen testing не заменяет ручного - он дополняет его между ручными engagement'ами. Путать одно с другим дорого.
Метрики ремедиации: MTTR, remediation rate, vulnerability density
6. MTTR - Mean Time to Remediate. Среднее время от попадания уязвимости в отчёт до подтверждённого исправления. Считается отдельно по severity: для Critical целевой показатель - 7-14 дней, для High - 30 дней, для Medium - 60-90 дней. MTTR Critical свыше 30 дней - красный флаг. Не оранжевый. Красный.Как считать: если трекинг находок ведётся в Jira, MTTR извлекается из разницы между Created Date и Resolved Date. Запрос вроде
project = PENTEST AND status = Resolved AND priority in (Critical, High) AND resolved >= -90d даст выборку для расчёта median MTTR. Median здесь предпочтительнее average - один тикет, зависший на полгода, не должен искажать общую картину.7. Remediation Rate (Open-to-Remediated Ratio). Формула:
Remediated / (Remediated + Open) * 100%. Целевой показатель для зрелой программы: не менее 85% для Critical + High в пределах SLA. Метрика показывает, работает ли процесс ремедиации или пентест-отчёт оседает в папке (спойлер: обычно оседает).8. Vulnerability Density Trends. Плотность уязвимостей на единицу scope, отслеживаемая поквартально. Формула по Software Secured: VD = V / S, где V - количество уязвимостей, S - размер scope в выбранных единицах (KLOC для кода, количество endpoints для API). Снижение VD от квартала к кварталу - самый убедительный индикатор улучшения security posture для бизнеса. CFO понимает тренд вниз на графике лучше, чем любой CVSS.
9. Reopen Rate. Процент уязвимостей, закрытых, а затем вновь открытых при ретесте. Показатель выше 10% - проблемы с качеством патчинга: dev-команда закрывает симптом, а не root cause. Особенно критичен для уязвимостей, связанных с Valid Accounts (T1078, initial-access / persistence / privilege-escalation) - если учётные данные по-прежнему утекают через другой вектор, reopen гарантирован.
ROI пентестирования: считаем в рублях, а не в уязвимостях
Обоснование бюджета на пентест - это конкретная формула, которая сравнивает стоимость тестирования с потенциальной стоимостью инцидента, скорректированной на эффективность ремедиации. Никакой философии - арифметика.KPI-дашборд для программы security validation
Семь показателей для квартального отчёта
Минимальный набор KPI, который закрывает потребности и технической команды, и бизнеса:| Метрика | Формула / источник | Целевое значение | Аудитория |
|---|---|---|---|
| Attack Surface Coverage (%) | Протестированные активы / Все активы x 100 | >80% критичных активов | CISO, Tech Lead |
| Critical Vulns Found | Абсолютное число CVSS >= 9.0 | Тренд снижения | CISO, Board |
| MTTR Critical (дни) | Median(Resolved Date - Created Date) | <14 дней | Tech Lead, Dev Lead |
| Remediation Rate (%) | Remediated / Total x 100 | >85% для Critical+High | CISO |
| Vulnerability Density Trend | V / S поквартально | Снижение 10-20% y/y | Security Team |
| ATT&CK Coverage (%) | Проверенные техники / Релевантные x 100 | >60% для Tier 1 threats | CISO, Red Team Lead |
| Risk Reduction (руб.) | Breach Risk Before - Breach Risk After | Положительное значение | CFO, Board |
Привязка метрик к MITRE ATT&CK coverage
ATT&CK Coverage - одна из немногих метрик, которая показывает не «что нашли», а «что проверили». Разница принципиальная. Для каждой релевантной тактики определяется набор техник, а затем отмечается, какие из них протестированы и какие дали результат.Пример маппинга для типового внешнего + внутреннего пентеста:
| Тактика | Техника (MITRE ATT&CK) | Протестировано | Результат |
|---|---|---|---|
| Reconnaissance | Vulnerability Scanning (T1595.002) | Да | 3 сервиса с известными CVE |
| Initial Access | Exploit Public-Facing Application (T1190) | Да | RCE на staging, WAF блокирует на prod |
| Initial Access | Valid Accounts (T1078) | Да | 2 пары через credential stuffing |
| Privilege Escalation | Exploitation for Privilege Escalation (T1068) | Да | Kernel exploit на legacy Ubuntu 18.04 |
| Credential Access | OS Credential Dumping (T1003) | Да | LSASS dump, 4 доменных аккаунта |
| Discovery | Network Service Discovery (T1046) | Да | Полная карта внутренней сети |
| Discovery | Security Software Discovery (T1518.001) | Да | CrowdStrike Falcon на endpoints |
| Defense Evasion | Impair Defenses (T1562) | Нет | Не входило в scope |
Coverage: 7 из 8 техник проверены = 87.5%. Defense Evasion (T1562) не тестировался - это gap для следующего engagement.
Такой маппинг показывает CISO не «сколько уязвимостей», а «какие пути атаки мы проверили и где остались слепые зоны». Это принципиально другой разговор с бизнесом: «в следующем квартале нужно закрыть Defense Evasion и Lateral Movement - 2 тактики, 6 техник, оценка X рублей». Конкретный scope → конкретный бюджет → конкретный результат.
Отчётность по результатам пентеста: от таблицы к дашборду
Требования к окружению
Для построения дашборда не нужен специализированный софт. Минимальный стек:| Компонент | Инструменты | Назначение |
|---|---|---|
| Трекинг находок | Jira, YouTrack, Kaiten | Тикеты с severity, dates, assignee |
| Визуализация | Confluence, Google Sheets, Grafana | Графики MTTR, coverage, trends |
| Источник данных | Pentest-отчёт + ретест | Первичные данные по findings |
| Хранение истории | Git-репозиторий или wiki | Квартальные снимки для trend analysis |
Критическое условие: каждая находка - отдельный тикет с полями Severity, Found Date, Status, Resolved Date, ATT&CK Technique ID. Без этих полей MTTR и coverage считаются вручную, а вручную - значит никогда.
Шаблон квартального отчёта для CISO
Структура, проверенная на практике - не длиннее трёх страниц. Если длиннее - CISO не дочитает, CFO не откроет.Страница 1 - Executive Summary. Risk Reduction в рублях (Breach Risk до и после). Количество Critical/High: найдено, закрыто, осталось. MTTR по severity: факт vs SLA.
Страница 2 - Операционные метрики. Attack Surface Coverage - что тестировали, что нет. ATT&CK Coverage Map - тактики и техники текущего квартала. Vulnerability Density Trend - график за 4+ кварталов. Remediation Rate по severity.
Страница 3 - Рекомендации и бюджет. Gaps в coverage: какие тактики ATT&CK не покрыты. Estimated cost закрытия gaps в следующем квартале. ROI текущего квартала в сравнении с предыдущими.
Измерение зрелости кибербезопасности: уровни программы
Cobalt описывает четырёхуровневую модель зрелости пентест-программ, и она хорошо ложится на реальность. На первом уровне тестирование ad hoc - для compliance или по запросу клиента: здесь достаточно отслеживать количество Critical и базовый Remediation Rate. На втором появляются процессы и инструменты, добавляются MTTR и Test Cadence. На третьем подключается автоматизация и consistent cadence - включаются ATT&CK Coverage и Vulnerability Density Trends. На четвёртом - кросс-функциональные инициативы, continuous risk scoring и полная интеграция с DevSecOps-пайплайном.Попытка внедрить метрики четвёртого уровня в компании первого - гарантированный провал: нет ни данных, ни процессов для их наполнения. Начинать стоит с трёх показателей (Critical Found, MTTR Critical, Remediation Rate) и наращивать по мере роста зрелости. Я это видел раз пять - приходит новый CISO, рисует дашборд на 20 метрик, через квартал половина пустая, через два - дашборд забыт.
По NIST Cybersecurity Framework v2.0, функция IDENTIFY (ID.AM-01 - инвентаризация активов) - фундамент для любых метрик coverage. Без актуального реестра активов Attack Surface Coverage невозможно посчитать: нельзя определить процент покрытия, если неизвестно общее количество. Функция DETECT (DE.AE-01 - baseline сетевых операций) критична для метрик false positive rate: без established baseline сигналы не с чем сравнивать.
Когда я начинал строить систему метрик, казалось, что главная сложность - формулы. Формулы тривиальны. Сложность в другом: заставить организацию собирать данные системно. Remediation Rate невозможно посчитать, если dev-команда не заводит тикеты на каждую находку. MTTR невозможно отследить, если в Jira нет поля Resolved Date. ATT&CK Coverage бессмысленна, если scope пентеста определяется не по модели угроз, а по принципу «потестируйте вот этот сайт».
По моему опыту, 80% компаний, заказывающих пентесты, не имеют ни одной метрики ремедиации. Отчёт уходит в PDF, PDF уходит в папку, через год приходит новый пентестер и находит те же самые находки. Это не security validation - это ритуал. Причём дорогой ритуал. И проблема здесь не техническая, а организационная: ни одна формула ROI не заработает, пока между пентест-командой и dev-командой нет SLA на remediation. Три метрики (Critical Found, MTTR Critical, Remediation Rate), один дашборд в Google Sheets, один квартальный срез. Через два квартала появится trend - а trend единственное, что убеждает CFO выделить бюджет на следующий год без двухчасовой дискуссии. Если хочешь отработать построение такой системы на практике - на WAPT эту связку «пентест → метрики → обоснование» разбирают в модуле по отчётности с реальными кейсами.
