CrowdStrike: как один контент-апдейт рвёт глобальную операционную ткань
Разбор инцидента июля 2024 года и что он говорит об операционной устойчивости бизнеса.
19 июля 2024 года компания CrowdStrike выпустила плановое обновление контента для своего агента Falcon - файл конфигурации, регулирующий логику обнаружения угроз. Не обновление ядра, не новый драйвер, не изменение кода - файл данных. Через несколько часов около 8,5 миллиона машин под управлением Windows показали синий экран смерти и перестали загружаться.
Упали авиакомпании, больницы, банки, телерадиовещание, логистические операторы. Не потому что их атаковали. Потому что обновление, которое должно было защищать, уронило операционную систему.
Что произошло технически
Агент Falcon работает на уровне ядра операционной системы - это обязательное условие для глубокого мониторинга угроз. Контент-файл, загруженный с серверов CrowdStrike, содержал некорректную конфигурацию, которая вызвала обращение к недопустимой области памяти. Результат - немедленный краш ядра.
Проблема усугублялась тем, что машины уходили в цикл перезагрузок и не могли загрузиться нормально. Ручное исправление требовало физического доступа к каждой машине или загрузки в безопасном режиме - что в случае с виртуальной инфраструктурой означало работу через консольный доступ к гипервизору.
Масштаб восстановления оказался кратным числу поражённых машин. Никакой автоматизации не было: каждая машина требовала ручных действий.
Почему это стало возможным
Модель распространения агентов безопасности устроена так, что они обновляются немедленно и повсеместно - иначе они бесполезны против быстрых угроз. Эта же модель означает, что дефект в обновлении немедленно распространяется на весь парк.
CrowdStrike контролирует значительную долю корпоративного рынка защиты конечных точек. Когда один продукт охватывает большую часть критической инфраструктуры разных компаний - инцидент у вендора становится инцидентом у всех одновременно.
Здесь нет злого умысла. Есть архитектурная концентрация риска. Единая точка обновления плюс глубокий доступ к ядру плюс высокий охват - это системное уязвимое место, которое существовало до инцидента. Инцидент его просто проявил.
Что это значит для операционной устойчивости
Первый вывод: зависимость от агентов безопасности уровня ядра - это операционный риск, который надо явно моделировать. Не потому что агенты плохие. Потому что любой компонент с такими правами и таким охватом при отказе даёт системный ущерб.
Второй вывод: "кольцевое развёртывание" - поэтапный выкат обновлений на часть парка перед развёртыванием на всё - это стандартная практика для критических компонентов. После этого инцидента вопрос "как мы управляем кольцами развёртывания для средств защиты" должен быть в повестке любого CTO и CISO.
Третий вывод: план восстановления должен быть рассчитан на сценарий, при котором машины не загружаются и не отвечают по сети. Это требует другой логики, чем обычный incident response.
Вопросы, которые стоит задать сейчас
Если вы руководитель или отвечаете за операционную устойчивость, вот набор проверочных вопросов:
- Какие компоненты в вашей инфраструктуре обновляются автоматически без стейджинга?
- Сколько машин вы сможете восстановить руками за один рабочий день при массовом сбое загрузки?
- Есть ли у вас консольный доступ к виртуальным машинам в обход операционной системы?
- Насколько вы концентрированы на одном вендоре безопасности - и есть ли у вас план B?
- Покрывает ли ваш план непрерывности сценарий "защитный инструмент сам стал причиной сбоя"?
CrowdStrike отреагировал быстро и выпустил fix в течение часов. Но для восстановления инфраструктуры нужны были не часы, а дни. Разрыв между скоростью fix и скоростью восстановления - это и есть операционный риск.