«Нам нужно оценить эффективность меры безопасности, но провести чистый эксперимент не выходит — мешают этика, бизнес-процессы или доступ к данным. Quasi-experimental designs — это способ обойти эти ограничения, получив хоть какие-то обоснованные выводы там, где классические методы заходят в тупик. Это не про идеал, а про практическую работоспособность в условиях ограничений.»
В чем проблема классического A/B-тестирования в безопасности
В идеальном мире, чтобы оценить новую сигнатуру для межсетевого экрана, её внедряют на половине серверов случайным образом и сравнивают инциденты в двух группах. Это рандомизированное контролируемое исследование — золотой стандарт доказательности. Но в реальной инфраструктуре выделить случайную группу серверов под «контроль» без новой сигнатуры часто невозможно. Решение должно применяться ко всей сети сразу, потому что рисковать половиной активов, оставляя её уязвимой, недопустимо с точки зрения выполнения требований регуляторов.
Ещё сложнее с организационными мерами. Как рандомизированно обучить новому процессу реагирования только часть сотрудников SOC? Это внесёт хаос в работу и нарушит внутренние регламенты. Этические и операционные ограничения делают чистые эксперименты редким исключением, а не правилом в корпоративной безопасности.
Суть квазиэкспериментальных дизайнов
Квазиэкспериментальные дизайны — это семейство методологий, которые позволяют оценивать эффект вмешательства (intervention) без полной рандомизации. Вместо случайного распределения они используют существующие группы или временные периоды для сравнения. Их сила не в идеальной чистоте, а в применимости там, где другие методы не работают. Они отвечают на вопрос: «Что изменилось после нашего действия, если учесть другие влияющие факторы?».
В контексте информационной безопасности вмешательством может быть что угодно: развёртывание нового DLP-решения, изменение политик паролей, запуск программы обучения по фишингу или внедрение нового стандарта конфигурации.
Разрыв во времени: дизайн прерывистых временных рядов
Один из самых мощных дизайнов для оценки мер безопасности — анализ прерывистых временных рядов (Interrupted Time Series, ITS). Его логика проста: вы собираете данные по ключевому показателю (например, количество успешных фишинговых атак в месяц) за длительный период до вмешательства и после него. Затем смотрите, изменился ли тренд или уровень показателя в момент внедрения меры.
Представьте, что вы внедрили новую систему фильтрации входящей почты. На графике количества фишинговых писем, дошедших до пользователей, до внедрения виден стабильный или растущий тренд. После «разрыва» — момента внедрения фильтра — тренд должен резко измениться. Важно анализировать именно изменение тренда, а не просто сравнение средних «до» и «после», чтобы исключить влияние сезонности или других долгосрочных факторов.
[ИЗОБРАЖЕНИЕ: График с двумя осями: по вертикали — количество инцидентов, по горизонтали — время. Вертикальной линией отмечен момент внедрения меры. До линии виден восходящий тренд, после линии — резкий спад и стабилизация на низком уровне.]
Разновидности ITS-дизайна
- Простой ITS: Одна группа, одно вмешательство. Подходит для оценки глобальных мер, внедряемых на всей инфраструктуре.
- Контролируемый ITS: Есть группа, получившая вмешательство, и «контрольная» группа, которая его не получила, но за которой также ведётся наблюдение во времени. Контрольная группа помогает отфильтровать эффекты, общие для всей среды (например, общий рост кибератак в отрасли). Найти такую группу сложно, но иногда её роль могут играть подразделения компании, где внедрение провели позже, или даже внешние статистические данные по индустрии.
Дизайн «разность разностей»
Метод Difference-in-Differences (DiD) — ещё один краеугольный камень для оценок. Он требует наличия двух групп: «лечебной» (где вмешательство было) и контрольной (где его не было), а также данных за периоды до и после вмешательства.
Эффект считается так: вы смотрите, как изменился показатель в лечебной группе после вмешательства по сравнению с её состоянием до. Затем вычитаете из этого изменения то, как изменился показатель в контрольной группе за тот же период. Эта «разность разностей» и будет оценкой эффекта от вашего действия, очищенной от общих для обеих групп временных трендов.
Пример: в одном дата-центре (лечебная группа) внедрили новую систему мониторига сетевой аномалии, а в другом (контрольная группа) оставили старую. Количество обнаруженных сетевых сканирований в лечебной группе упало на 40% после внедрения. Но в контрольной группе оно тоже упало, скажем, на 10% — возможно, из-за общих мер или снижения активности злоумышленников. Реальный эффект от системы оценивается не в 40%, а в 30% (40% — 10%).
[ИЗОБРАЖЕНИЕ: Таблица с четырьмя ячейками: Лечебная группа до/после, Контрольная группа до/после. Строками показаны средние значения ключевого показателя. Ниже формула расчёта эффекта: (Лечебная_после — Лечебная_до) — (Контрольная_после — Контрольная_до).]
Дизайн на основе регрессионного анализа
Когда группы нельзя выделить чётко, но есть данные по множеству единиц (сотрудников, серверов, филиалов) с разными характеристиками и временем внедрения мер, используют дизайны на основе регрессии. Например, регрессионный дизайн с фиксированными эффектами.
Вы строите статистическую модель, где зависимая переменная — это ваш показатель безопасности (например, факт компрометации учётной записи), а ключевая независимая переменная — факт применения к этой единице вмешательства (например, прошёл ли сотрудник новый тренинг). Модель при этом «контролирует» все постоянные во времени характеристики единиц (фиксированные эффекты) и общие временные тренды. Это позволяет изолировать эффект вмешательства.
Такой подход часто используется при анализе данных из SIEM-систем или систем управления уязвимостями, где по каждому активу есть история событий, применённых патчей и изменений конфигураций.
Практические шаги для внедрения оценки
- Определите вмешательство и гипотезу: Чётко сформулируйте, что вы меняете (внедряете, отключаете) и какой именно эффект ожидаете увидеть на конкретном метрике. Например: «Внедрение двухфакторной аутентификации для административных учёток (вмешательство) снизит количество успешных компрометаций таких учёток (метрика) на 70% за квартал».
- Выберите подходящий дизайн: Задайте себе вопросы. Можно ли выделить контрольную группу? Есть ли данные за достаточно долгий период до внедрения? Если нет контрольной группы, но есть длинные временные ряды — подойдёт ITS. Если есть две схожие группы, но нет рандомизации — рассмотрите DiD.
- Соберите и подготовьте данные: Это самый сложный этап. Потребуются данные по выбранной метрике за периоды до и после вмешательства. Для DiD и регрессионных дизайнов нужны данные по всем единицам в группах. Источниками могут быть логи IDS/IPS, SIEM, тикеты в системе инцидентов, отчёты сканеров уязвимостей.
- Проведите анализ: Используйте статистические пакеты или даже продвинутые возможности современных BI-инструментов, которые поддерживают анализ временных рядов и базовые регрессионные модели. Важно не просто построить график, а проверить статистическую значимость обнаруженных изменений.
- Интерпретируйте результаты с осторожностью: Квазиэксперимент не доказывает причинно-следственную связь абсолютно. Он показывает корреляцию, которая с высокой долей вероятности обусловлена вашим вмешательством, если дизайн был выбран верно и учтены основные смешивающие факторы. Всегда озвучивайте ограничения метода в своих выводах.
Ограничения и подводные камни
Главная опасность квазиэкспериментов — смешанные факторы. Эффект, который вы приписываете своему новому межсетевому экрану, на самом деле мог быть вызван одновременным обновлением операционных систем на серверах. В дизайне DiD критически важно выполнение предположения о параллельных трендах: в отсутствие вмешательства изменение показателя в лечебной и контрольной группе должно быть одинаковым. Проверить это строго до вмешательства нельзя, можно лишь строить предположения на основе данных за предыдущие периоды.
Другая проблема — угрозы внутренней валидности. К ним относится, например, «эффект истории», когда на результат влияет внешнее событие (масштабная вирусная атака), совпавшее по времени с вашим вмешательством. Или «эффект созревания», когда показатель меняется сам по себе со временем (например, снижение количества инцидентов из-за общего роста квалификации команды).
Как это связано с требованиями регуляторов
ФСТЭК России и 152-ФЗ не предписывают конкретных методов оценки эффективности мер защиты. Однако они требуют обоснованности принимаемых мер и оценки их адекватности. Предоставление отчётности регулятору, основанной на данных квазиэксперимента, выглядит существенно убедительнее, чем субъективные утверждения вроде «мероприятие проведено, угрозы нейтрализованы».
Например, при проверке выполнения требования о регулярном обучении персонала вы можете представить не только акты о проведении тренингов, но и ITS-анализ, демонстрирующий устойчивое снижение количества успешных фишинговых атак на сотрудников после запуска новой учебной программы. Это превращает формальное выполнение требования в управленческий KPI с измеримым результатом.
Подход, основанный на данных и квазиэкспериментах, смещает фокус с проверки наличия документов на проверку реальной эффективности построенной системы защиты. Это соответствует современному тренду в регуляторике на внедрение risk-based подходов.