Security Chaos Engineering

«Алерт на создание публичного S3-бакета у нас настроен» — и я спрашиваю, когда его в последний раз проверяли. Чаще всего ответ: при настройке, год назад. Огромная доля контролей безопасности живёт в режиме «настроил и забыл»: их никто не проверяет до настоящего взлома, а к этому моменту сбор логов уже отвалился, правило алерта кто-то снёс при рефакторинге терраформа, а IAM-политику расширили «временно» полгода назад. Security Chaos Engineering — это chaos engineering, нацеленный на защиту, а не на надёжность: та же схема «гипотеза — инъекция — измерение», но объект другой: обнаружение, алертинг, авторизация, автоматическое исправление. Метод тот же, что в Chaos Engineering из Reliability Engineering. Вопрос другой. Не «остаётся ли система живой», а «срабатывает ли защита». Граница с Vulnerability Management проходит так: VM ищет уязвимости, SCE проверяет, что контроли, которые должны поймать их эксплуатацию, реально работают.

Что должен уметь

Главный навык на уровне L4 — формулировать security steady-state hypothesis и отличать «контроль настроен» от «контроль проверен». Пример гипотезы: «при создании security group с открытым 0.0.0.0/0:22 алерт срабатывает не позже чем через пять минут, а автоматика закрывает правило за десять». Если такого утверждения нет до эксперимента — это не SCE, а просто тыкание в прод. Я регулярно вижу, что команды путают SCE с pen test или red team; разница в том, что SCE — повторяемая проверка известных контролей по гипотезе, а не состязательный поиск неизвестного «как пролезть».

Понимает, что SCE — это проверка контролей безопасности через гипотезу, а не pen test и не red team; различает «контроль настроен» и «контроль проверен».
Проводит простой эксперимент вне прода: создаёт намеренно неверно настроенный ресурс — публичный бакет, открытый порт — и смотрит, сработает ли алерт.

Формулирует security steady-state hypothesis, запускает эксперимент в staging с явным blast radius, измеряет MTTD и факт срабатывания реакции, записывает находки.
Настраивает observability для безопасности, без которой эксперимент ничего не доказывает: телеметрия обнаружения, журнал аудита, дашборд по событиям безопасности. Это то же обязательное условие, что и observability перед chaos на надёжность.

Проектирует security game day или упражнение purple team: сценарии из threat model и MITRE ATT&CK, участвуют команды detection и response, измеряется MTTD/MTTR по событиям безопасности, по итогам — action items.
Связывает findings с vulnerability management и incident response: контроль, который не сработал, — это находка с владельцем и сроком, а не «интересное наблюдение».

L6+

Внедряет непрерывную проверку защиты: автоматические эксперименты в конвейере, регулярная имитация взломов, правила уровня организации, по которым состязательный эксперимент можно запускать безопасно.
Принимает стратегические решения: SCE в регулируемых средах (banking / healthcare / payments), баланс между непрерывной валидацией и риском задеть реальные системы, координация с SOC и регуляторными ограничениями.

Материалы

Книги

Kelly Shortridge, Aaron Rinehart — Security Chaos Engineering: Sustaining Resilience in Software and Systems (O’Reilly, 2023). Каноническая книга темы. Главный тезис: безопасность — это свойство сложной системы, и проверять её надо экспериментом, а не аудитом по чеклисту. Если читать одну вещь по SCE — эту.
Aaron Rinehart, Kelly Shortridge — Security Chaos Engineering (O’Reilly report, 2020). Короткий предшественник полноценной книги; хорош как первое знакомство за час, но раздавался через сайт Verica и сейчас со старых адресов не открывается — искать по названию.
Heather Adkins et al. — Building Secure and Reliable Systems (O’Reilly, 2020), главы про testing и continuous validation. Взгляд Google на проверку свойств безопасности в большой системе.

Статьи и доклады

Principles of Chaos Engineering. База метода, на которую SCE опирается; читать вместе с листом Chaos Engineering.
Aaron Rinehart — ChaoSlingr и зарождение SCE. История первого SCE-инструмента в UnitedHealth Group / Optum. Главный публичный кейс листа — см. ниже.
MITRE ATT&CK. База знаний по тактикам и техникам противника — основной источник сценариев для экспериментов.

Инструменты

Stratus Red Team (DataDog, OSS) — эмуляция атакующих техник в облаке, разложенная по MITRE ATT&CK; эксперименты мелкие и самодостаточные. По моим наблюдениям, сейчас это самый живой открытый вход в тему для облачной инфраструктуры.
Atomic Red Team (Red Canary, OSS) — библиотека небольших тестов по техникам ATT&CK: проверяют, видит ли их система обнаружения.
AWS Fault Injection Service — управляемый сервис хаос-экспериментов; часть сценариев годится и для проверки защиты: отключить сбор логов, сломать доступ по IAM.
Breach & Attack Simulation (BAS): AttackIQ, SafeBreach, Cymulate — коммерческие платформы непрерывной валидации контролей. Берут, когда нужен готовый каталог сценариев корпоративного уровня и отчётность для аудита.
ChaoSlingr — исторически первый инструмент SCE, инъекции событий безопасности в AWS. Сейчас фактически архивный: ценен как памятник идее, а не как рабочий инструмент. Единого доминирующего оркестратора здесь, в отличие от chaos на надёжность, пока нет — команды собирают связку сами.

Best practices

Главный публичный кейс — ChaoSlingr в UnitedHealth Group / Optum (Aaron Rinehart, ~2017). Команда написала инструмент, который намеренно портил конфигурацию безопасности в AWS — например, открывал порт в security group — и смотрел, сработает ли detection. Результат, с которого началась вся область, оказался неприятным: контроли, про которые все были уверены, что они работают, регулярно не срабатывали — из-за дрейфа конфигурации, дыр в покрытии, сломанных правил. Урок здесь не «AWS небезопасен». Урок в том, что уверенность в работе защиты без эксперимента — это вера, а не знание. Аудит видит, что алерт настроен. SCE проверяет, что он стреляет.

Контроль валидируется эмпирически, потому что «настроен» и «работает» — разные состояния. Алерт, IAM-политика, auto-remediation проверяются инъекцией соответствующего события, а не чтением конфига: дрейф тихо ломает то, что работало при настройке, и аудит по чеклисту этого не видит, а эксперимент видит сразу.

Observability для безопасности — обязательное условие, а не «подтянем по ходу». Без телеметрии обнаружения и журнала аудита эксперимент нечем измерить, и «сработало или нет» превращается в вопрос веры. Порог готовности здесь ровно тот же, что и перед chaos на надёжность.

И третье, про которое забывают чаще всего: это purple team, а не скрытая атака на собственный SOC. Эксперимент анонсируется и согласуется с командой detection. Иначе либо впустую поднимется настоящее реагирование на инцидент, либо — что хуже — команда постепенно научится игнорировать «свои» алерты, и вы получите ровно ту дыру, которую собирались закрыть.

SCE — это не pen test и не red team. Pen test и red team состязательны, привязаны к моменту и ищут неизвестное: как сюда пролезть. SCE — повторяемая проверка известных контролей по явной гипотезе, в идеале автоматизированная и непрерывная. Они дополняют друг друга: pen test находит новый класс проблемы, а SCE превращает «мы это починили» в постоянно проверяемое утверждение. Путать их дорого — от SCE начинают ждать открытий, которых он не даёт.

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

Культурное условие — режим blameless, как и в chaos на надёжность. Эксперимент найдёт неработающий контроль, в этом весь его смысл. Но если не выстреливший алерт превращается в вопрос «кто сломал», петля обратной связи рвётся, и SCE сворачивают после первой же находки. Контроль, который не сработал, — это системная находка с владельцем, а не вина дежурного. Условия те же, что для chaos на надёжность: blameless-постмортем и культура, где найденная дыра считается успехом эксперимента, а не провалом команды.

Связанные листья

Chaos Engineering — родительский метод. Он проверяет, остаётся ли система живой, SCE — срабатывает ли защита. Гипотеза, blast radius, auto-abort и observability как пре-реквизит — общие.
Vulnerability Management — граница: VM ищет уязвимости, SCE проверяет, что контроли, ловящие их эксплуатацию, реально работают.
Threat Modeling — threat model даёт сценарии для экспериментов; SCE эмпирически проверяет, что заявленные меры защиты срабатывают.
Security Code Review — ревью ищет дефекты в коде до выката, SCE проверяет уже работающие контроли в проде. SCR живёт в соседнем L1 Secure Development — граница проходит по моменту: до выката или после.
Incident Response — security game day тренирует путь «заметили — среагировали» так же, как обычный chaos готовит команду к инцидентам надёжности; MTTD и MTTR — общие метрики.
Access Control & IAM — контроли IAM (обнаружение эскалации привилегий, аномального доступа) — типовая мишень для экспериментов.
Blameless Postmortem — находки разбираются в режиме blameless; это культурное условие внедрения, как и для chaos на надёжность.

Открытые вопросы

Коммерческая платформа против открытых инструментов (TBD) — когда хватает Stratus Red Team и Atomic Red Team, а когда нужна коммерческая платформа с каталогом и отчётностью. Внятной модели выбора по размеру и зрелости команды я не нашёл.
Непрерывная проверка защиты (TBD) — переход от разовых game day к автоматическим экспериментам в pipeline; модель зрелости этого перехода в хорошем публичном виде мне не попадалась.

Отдельно — регулируемые отрасли. Я не знаю, как корректно делать SCE в банке или в здравоохранении: инъекция событий безопасности упирается в регуляторные ограничения, а публичной практики почти нет. Тот же пробел, что и у обычного chaos engineering. Если есть опыт — расскажите PR’ом.