“Большинство аналитиков в ИБ ищут корреляции, но реальная безопасность, это про причинно-следственные связи. Мы видим всплеск атак после обновления, но обновление ли стало причиной? Мы запрещаем USB, и инциденты падают, но падение — следствие запрета или просто сезонный спад? Causal inference, это не статистический метод, а способ мышления, который заставляет перестать верить первым найденным закономерностям и начать задавать правильные вопросы к данным, которых у тебя никогда не будет в идеальном эксперименте.”
Почему корреляции в данных ИБ вводят в заблуждение
Типичный пайплайн анализа в Security Operations Center выглядит так: сбор логов, агрегация, поиск аномалий и корреляционных правил. Найденная связь между событием A и инцидентом B интерпретируется как причинно-следственная: «A приводит к B». Это фундаментальная ошибка, которая стоит компаниям миллионов рублей на ложных срабатываниях или, что хуже, на пропущенных реальных угрозах.
Observational data, это данные, собранные в процессе обычной работы, а не в контролируемом эксперименте. В ИБ это все логи, алёрты, данные от EDR, сетевые flow. В них невозможно выделить «контрольную группу», на которую не воздействовал исследуемый фактор. Все события переплетены, на них влияют скрытые переменные (confounders). Например, всплеск сетевого сканирования (событие A) и последующая утечка данных (инцидент B) могут быть не связаны напрямую. Их могла вызвать третья, неучтённая переменная — например, массовый выход сотрудников на удалёнку с небезопасных устройств, что одновременно упростило сканирование и увеличило риск утечки.
Действуя на основе ложной причинности, команда ИБ может начать «лечить симптомы»: ужесточать правила межсетевого экрана для блокировки сканирования, в то время как корень проблемы — в политике удалённой работы. Ресурсы тратятся, угроза остаётся.
От корреляции к причинности: базовые концепции
Causal inference, это набор методов, позволяющих оценить эффект воздействия (treatment effect) по наблюдательным данным, максимально приблизив анализ к условиям рандомизированного контролируемого испытания.
Ключевые концепции, которые необходимо понимать:
- Потенциальные исходы (Potential Outcomes): Для каждого объекта (пользователя, хоста, сессии) существует два потенциальных состояния: Y(1) — исход, если на объект было оказано воздействие (например, применён патч), и Y(0) — исход, если воздействия не было. Фундаментальная проблема causal inference в том, что мы наблюдаем только один из этих исходов в реальности.
- Confounders (Смешивающие переменные): Это переменные, которые влияют и на вероятность получения воздействия, и на итоговый исход. В ИБ типичный confounder — «критичность актива». Более критичные серверы (например, с базой данных) и чаще патчатся (получают воздействие), и являются более привлекательной целью для атак (исход). Простая корреляция между патчем и последующей атакой будет ложной.
- Граф причинных связей (Causal Graph): Визуальный инструмент для отображения предполагаемых причинно-следственных отношений между переменными. Узлы — переменные, направленные рёбра — причинное влияние. Построение такого графа — первый и самый важный шаг, требующий предметных знаний в ИБ.
Методы causal inference, применимые в ИБ
После построения причинного графа и идентификации confounders можно применять методы для «очистки» данных от их влияния.
Стратификация (Stratification) и Matching
Классический подход — сравнить объекты, которые максимально похожи по всем confounders, но различаются по наличию воздействия. Если в данных есть 1000 серверов, можно для каждого запатченного сервера найти «близнеца» — незапатченный сервер с аналогичной ОС, критичностью, местом в сети и временем работы. Затем сравнить частоту инцидентов в этих парах. На практике чистый matching на высокоразмерных данных ИБ сложен, но идея лежит в основе более продвинутых методов.
Инструментальные переменные (Instrumental Variables)
Метод для случаев, когда воздействие измерено с ошибкой или есть неучтённые confounders. Требуется найти «инструмент» — переменную, которая влияет на вероятность получения воздействия, но не влияет на исход напрямую, а только через воздействие. В ИБ примером может служить корпоративная политика: приказ о тотальном обновлении ПО в определённый день (инструмент) влияет на установку патча (воздействие), но сам по себе приказ не делает сервер более уязвимым (исход). Это сложный, но мощный метод для анализа эффективности политик безопасности.
Разрывный дизайн (Regression Discontinuity Design)
Элегантный метод, использующий чёткий порог для получения воздействия. Допустим, правило ИБ предписывает принудительный сброс паролей для всех учётных записей с оценкой риска выше 75 баллов. Сравнивая инцидентность у записей с оценкой 74 и 76 баллов (то есть находящихся прямо по разные стороны порога), можно оценить чистый эффект от принудительного сброса, так как эти две группы в среднем идентичны по всем другим параметрам. Этот метод хорошо подходит для анализа эффективности правил DLP или систем скоринга рисков.
Разностно-разностный метод (Difference-in-Differences)
Классический подход для оценки эффекта изменений во времени. Требуется контрольная группа, на которую изменение не повлияло. Например, чтобы оценить эффект от внедрения нового WAF в одном дата-центре, нужно сравнить динамику атак в этом ДЦ (обрабатываемая группа) и в другом, аналогичном ДЦ без нового WAF (контрольная группа) до и после внедрения. Разница в разностях этих показателей и будет оценкой эффекта.
Практический кейс: оцениваем эффективность нового правила в SIEM
Команда внедрила в SIEM новое корреляционное правило, которое генерирует алёрт при одновременной failed-аутентификации с трёх разных хостов на одну учётную запись за 5 минут. Через месяц статистика показывает: после включения правила количество регистрируемых инцидентов типа «Брутфорс» выросло на 15%. Руководство делает вывод: правило эффективно, оно выявляет скрытые атаки.
Causal inference ставит этот вывод под сомнение. Возросшее число инцидентов, это causal effect правила или просто более тщательный учёт? Применяем концепцию потенциальных исходов. Для каждого потенциального брутфорс-инцидента в период до внедрения правила мы не знаем, был бы он обнаружен старыми методами (Y(0)). После внедрения — мы детектируем больше (Y(1)). Но чтобы оценить реальный эффект, нужно понять: эти новые алёрты — реальные атаки, которые раньше пропускались (истинный положительный эффект), или это шум, ведущий к усталости аналитиков?
Здесь можно применить упрощённый разностно-разностный подход. Нужно выбрать метрику, на которую правило влиять не должно, но которая коррелирует с активностью атакующих. Например, количество блокировок на уровне сетевого IPS для известных сканеров брутфорса. Если график роста алёртов SIEM точно повторяет график роста блокировок IPS после внедрения правила, это косвенно говорит о том, что правило действительно ловит больше атак в более «шумный» период. Если же рост алёртов SIEM идёт вразрез с данными IPS, скорее всего, мы наблюдаем эффект избыточного детектирования.
Ограничения и сложности применения в российской регуляторике
Внедрение causal inference упирается не только в технические, но и в организационные барьеры, особенно в контексте требований ФСТЭК и 152-ФЗ.
- Качество и полнота данных: Методы требуют учёта ключевых confounders. Если в логах нет атрибута «критичность актива» или «владелец системы», построить адекватную модель невозможно. Требования регуляторов к составу регистрируемых событий (например, приказы ФСТЭК) задают базовый минимум, но для причинного анализа его часто недостаточно. Необходима доработка процессов логирования.
- Временные ряды и стационарность: Многие ИБ-процессы нестационарны (например, активность атак в конце квартала). Методы вроде Difference-in-Differences чувствительны к этому. Нужны продвинутые подходы к предобработке временных рядов, что редко является компетенцией команды ИБ.
- Интерпретируемость для проверяющих: Отчёт для ФСТЭК, построенный на сложных причинных моделях, будет сложно объяснить. Регулятор мыслит в парадигме выполнения формальных требований («установлены средства защиты»), а не оценки их причинного эффекта («насколько эти средства снизили реальный риск»). Нужно готовить упрощённые, но методологически корректные выжимки.
- Этический аспект и A/B-тестирование: Золотой стандарт causal inference — рандомизированный эксперимент. Но как этично проводить A/B-тест в безопасности? Оставить одну группу серверов без патча для чистоты эксперимента нельзя. Это накладывает фундаментальные ограничения и делает наблюдательные данные единственным источником.
С чего начать внедрение подхода
Переход от корреляционного мышления к причинному, это эволюция, а не революция. Начать можно с малого.
- Картирование ключевых процессов: Выберите 2-3 критических процесса защиты (например, реагирование на фишинг, управление уязвимостями, анализ инсайдерских угроз). Для каждого нарисуйте предполагаемый причинный граф на доске. Что на что влияет? Где могут быть скрытые переменные?
- Аудит данных: Проверьте, какие из переменных из ваших графов реально есть в ваших логах и SIEM. Определите самые большие пробелы.
- Пилотный квази-эксперимент: Возьмите один исторический кейс — например, внедрение DLP-системы. Попробуйте применить метод разностно-разностей, подобрав в качестве контрольной группы подразделение, где внедрение прошло позже или иным образом. Оцените, насколько ваша первоначальная оценка эффективности системы совпадает с результатом causal-анализа.
- Интеграция в расследования: При разборе каждого крупного инцидента задавайте не только вопросы «что?» и «когда?», но и «почему мы так решили?». Был ли наш вывод о причине основан на временной последовательности (post hoc) или мы исключили влияние сторонних факторов?
Causal inference не даст магической кнопки для предотвращения всех атак. Но этот подход заставляет смотреть на данные ИБ не как на поток событий для корреляции, а как на сложную систему, где каждое наблюдение — результат множества переплетённых причин. В условиях, когда ресурсы на безопасность всегда ограничены, понимание реальной, а не кажущейся эффективности мер становится критически важным для обоснования инвестиций и построения защиты, которая работает, а не просто отчитывается.