“Труднее всего измерять и объяснять успех системы, когда она просто работает.”

Как измерить то, чего не произошло (prevented attacks)?

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

Почему это проблема

В управлении безопасностью, особенно в условиях регуляторных требований (ФСТЭК, 152-ФЗ), принято ориентироваться на инциденты: их количество, серьёзность, время реагирования. Эти метрики — следствие того, что защита не сработала полностью. Успешная защита, которая предотвратила инцидент, остаётся вне системы измерений. Это создаёт парадокс: чем лучше работает система защиты, тем меньше «осязаемых» результатов она демонстрирует для традиционной отчетности. Руководитель видит пустую диаграмму инцидентов и может прийти к выводу, что затраты на безопасность не приносят видимого эффекта.

Что можно измерять

Прямое измерение предотвращённых атак невозможно — мы не можем знать детали попытки, которая была остановлена на ранней стадии. Но мы можем измерять деятельность системы защиты, которая непосредственно приводит к предотвращению.

Активные действия защиты

• Блокированные запросы: количество попыток подключения, запросов к API или транзакций, которые были отклонены системами WAF (Web Application Firewall), межсетевыми экранами или фильтрами на уровне приложений. Важно разделять их по типу (например, SQL-инъекции, попытки подбора паролей, сканирование портов).
• Остановленные процессы: записи в журналах антивирусных средств или EDR (Endpoint Detection and Response) об изоляции или удалении вредоносных файлов до того, как они смогли выполнить свою функцию.
• Отклонённые операции: события систем контроля доступа (IAM), когда пользователь или сервис пытался выполнить действие вне своих полномочий, и система отказала.

Сигналы и предупреждения

Системы мониторинга и SIEM (Security Information and Event Management) генерируют алёрты различного уровня серьёзности. Не каждый алёрт означает успешную атаку, но каждый представляет собой обнаруженную угрозу или отклонение от нормы. Метрика здесь — количество обработанных алёртов с классификацией (например, «высокая угроза — блокировано автоматически», «низкая угроза — требует анализа»). Это показывает «рабочую нагрузку» защиты.

Как превратить данные в показатель

Собрать события — первый шаг. Чтобы оценить эффективность, нужно связать эти события с потенциальным ущербом.

Моделирование угроз и оценка риска

Для каждого типа блокированного действия (например, попытка SQL-инъекции) можно определить типовый сценарий развития успешной атаки и оценить возможный ущерб в денежном или репутационном выражении. Это не точная цифра, а оценка на основе вероятности и известных случаев. Например:

Тип предотвращённого действия	Потенциальный сценарий успешной атаки	Оценка потенциального ущерба (в условных единицах)
Блокированная попытка подбора пароля к CRM	Утечка данных клиентов, остановка продаж	Высокий
Отклонённая попытка выполнения команды на сервере из недоверенного источника	Заражение сервера, доступ к внутренней сети	Критический

Суммирование таких оценок по категориям за период (месяц, квартал) даёт «виртуальный предотвращённый ущерб». Этот показатель можно сопоставить с затратами на соответствующий элемент защиты.

Тенденции и снижение активности угроз

Если в течение времени количество блокированных попыток определённого типа снижается, это может указывать на два явления: либо угроза стала менее активной (например, после закрытия уязвимости в популярном ПО), либо система защиты стала более эффективной на ранних этапах, и атакующие перестают тратить ресурсы на эту цель. Мониторинг таких тенденций — индикатор долгосрочной эффективности.

Пример для технической реализации

Рассмотрим систему защиты веб-приложения, где WAF и мониторинг логинов являются ключевыми элементами.

1. Сбор данных. WAF предоставляет журнал событий с детализацией:

timestamp, source_ip, request_url, rule_id, action (BLOCK/ALLOW), threat_category

Система контроля логинов записывает:

timestamp, username, source_ip, login_result (SUCCESS/FAILURE), failure_reason

2. Агрегация и классификация. Создаётся скрипт или конфигурация в SIEM, которая ежедневно агрегирует события по категориям:

# Пример агрегации для отчёта
SELECT threat_category, COUNT(*) as blocked_attempts
FROM waf_logs
WHERE action = 'BLOCK' AND date = CURRENT_DATE
GROUP BY threat_category;

3. Связь с рисками. Для каждой категории (например, «SQL Injection», «Credential Stuffing») назначается вес риска (например, 5 — критический, 3 — высокий, 1 — средний). Показатель «предотвращённый риск» за день рассчитывается как сумма blocked_attempts * weight по всем категориям.

Интеграция с регуляторными требованиями

В требованиях ФСТЭК и 152-ФЗ акцент часто делается на наличии средств защиты и их корректной работе. Доказательство работы этих средств может частично базироваться на представлении таких метрик предотвращения. Например, требование о контроле доступа можно сопроводить не только описанием политик, но и статистикой: «Система контроля доступа ежедневно отклоняет X попыток выполнения операций вне установленных полномочий, что предотвращает потенциальные нарушения конфиденциальности данных». Это превращает абстрактное требование в количественно измеряемый процесс.

Психологический и управленческий аспект

Переход от культуры реагирования на инциденты к культуре предотвращения требует изменения восприятия. Для этого метрики предотвращения должны быть:

• Регулярными: появляться в еженедельных или ежемесячных отчетах вместе с метриками инцидентов.
• Сравнительными: показывать динамику («в этом месяце предотвращено на 15% больше попыток критического класса, чем в прошлом»).
• Связанными с бизнес-целями: объяснять, как предотвращение конкретной угрозы поддерживает непрерывность бизнес-процесса или сохранение репутации.

Это создаёт понимание, что защита, это непрерывный активный процесс, а не пассивный набор инструментов, которые «молчат» до момента провала.

Ограничения и ложные сигналы

Не все блокированные действия являются реальными атаками. Часть может быть ложными положительными срабатываниями (например, блокировка легитимного запроса из-за строгой политики WAF) или автоматизированным сканированием без злого умысла. Поэтому важно:

• Периодически проводить анализ срабатываний и корректировать правила для уменьшения ложных positives.
• Разделять в отчетах «предполагаемые атаки» и «автоматическое сканирование/фоновый трафик».
• Не использовать количество блокировок как единственный показатель эффективности, это может привести к чрезмерно агрессивным политикам, которые нарушают нормальную работу.

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