Vendor risk для kernel-mode агентов: что мы сделали после CrowdStrike

Месяц прошёл с того момента, как мы разобрали механику сбоя CrowdStrike и пересмотрели внутренний регламент обновлений. Но после двух первых постов осталось ощущение незавершённости: мы говорили про CrowdStrike конкретно, а не про класс проблемы в целом. Инцидент показал - проблема не в одном вендоре, а в том, что kernel-mode агентов как категория годами жили вне нормальной vendor risk-матрицы.

Мы это исправили. Провели аудит и теперь фиксируем, что из этого получилось.

Почему именно kernel-mode

Принципиальная разница между агентом, который работает в userspace, и агентом, который живёт в ring 0 - это цена ошибки. Если падает userspace-процесс, у системы ещё есть шанс. Если ошибка в kernel-mode драйвере - хост ложится целиком, часто без возможности нормальной загрузки.

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

Стандартный набор, который вылезал в инвентаризации:

• EDR/EPP-агенты - CrowdStrike Falcon, Carbon Black, Kaspersky EDR, Dr.Web и прочие. Почти все работают с kernel-mode компонентами для перехвата системных вызовов.
• Агенты мониторинга с kernel-модулями - ряд решений для мониторинга производительности и трассировки также используют kernel-модули для доступа к данным на уровне ОС.
• Агенты управления конечными точками - некоторые системы управления конфигурацией и compliance-контроля тоже имеют компоненты на уровне ядра.
• VPN-клиенты и сетевые агенты - особенно те, которые реализуют сплит-туннелирование или deep packet inspection на уровне ядра.

Суммарно на некоторых хостах набиралось до пяти-шести таких компонентов. Каждый из них потенциально может повторить историю CrowdStrike.

Что именно аудировали

Мы смотрели на каждый kernel-mode агент по одному и тому же набору вопросов.

Первое - механизм обновления. Автоматическое или ручное? Если автоматическое - что именно обновляется автоматически: только сигнатуры/контент, или и сам агент? Есть ли у вендора staged rollout на стороне вендора, и если есть - насколько он реально работает после истории с CrowdStrike?

Второе - возможность задержки со стороны клиента. Можно ли зафиксировать версию агента и не получать автообновления? Можно ли задержать контент-обновления - не только версии бинаря? Что говорит лицензионное соглашение: есть ли требование обязательно держать последнюю версию?

Третье - поведение при ошибке. Что происходит с хостом, если агент упал или получил дефектное обновление? Умеет ли агент падать аккуратно (fail-safe), или тянет за собой ядро? Какой у вендора SLA на исправление критических багов в агенте?

Четвёртое - восстановление. Какой сценарий восстановления хоста, если агент положил систему? Требует ли физического доступа или можно решить удалённо?

Результаты по вендорам - разные. Не будем называть имена публично, но общий паттерн такой: чем старше и крупнее вендор, тем больше гибкости в управлении обновлениями он даёт. Относительно новые игроки нередко вообще не предусматривают возможности задержать content-обновления - архитектурно это просто не заложено.

Что прописали в политиках

По итогам аудита для каждого kernel-mode агента зафиксировали политику задержки и процедуру тестирования. Единого решения нет - оно зависит от конкретного продукта, но шаблон общий.

Для агентов, где задержка технически возможна:

• Версионные обновления агента - минимум семь дней выдержки в staging перед раскаткой в прод.
• Контент-обновления (сигнатуры, правила детектирования, конфигурационные файлы) - разрешить автообновление только для staging-группы, на прод - вручную с задержкой 24-48 часов после наблюдения.
• Для хостов КИИ или тех, где падение критично - дополнительный этап: обновление сначала на резервный экземпляр, наблюдение, потом основной.

Для агентов, где задержка невозможна:

• Зафиксировать этот факт как явный риск в документации.
• Убедиться, что для хостов с этим агентом есть workable сценарий восстановления без физического доступа (snapshot перед обновлением, iDRAC/IPMI, KVM, доступ к гипервизору).
• Рассмотреть вендорскую альтернативу, которая даёт контроль над обновлениями, если это критичный класс хостов.

Процедура тестирования в staging:

Staging-группа для агентов - это не просто «несколько тестовых машин». После истории с CrowdStrike мы настаиваем на том, что staging должен быть репрезентативным: те же версии ОС, та же нагрузка, те же смежные агенты. Иначе staging-проверка даёт ложное ощущение безопасности.

Во время окна наблюдения смотрим: нагрузка CPU/RAM на хосте, стабильность процессов агента, отсутствие новых kernel-сообщений в системных логах, отсутствие новых алертов в SIEM, связанных с хостом.

Что оказалось неочевидным

Несколько наблюдений, которые удивили в процессе.

Вендоры стали заметно охотнее отвечать на вопросы про процедуры обновлений - инцидент CrowdStrike явно поставил это в повестку у всей отрасли. Там, где раньше sales-команды уходили в сторону от «технических деталей», теперь охотнее соединяют с инженерами.

Вопрос «как агент ведёт себя при дефектном обновлении» нередко заводит вендора в тупик. Это честный ответ на вопрос о зрелости продукта.

Часть агентов, которые формально числились «с автообновлением», на практике давно не обновлялись - просто потому что инфраструктура была закрыта, и агент не мог достучаться до серверов вендора. Это отдельный риск, уже в другую сторону.

Где сейчас

Аудит закончен, политики зафиксированы. Следующий шаг - убедиться, что они реально применяются, а не лежат мёртвым грузом в документации. Запланировали проверку соответствия через три месяца: пройдёмся по тем же хостам и посмотрим, где политика выдерживается, а где уже появились исключения без документирования.

Это небыстрая работа. Зато теперь у нас есть ответ на вопрос «а что вообще работает с привилегиями ядра на наших серверах» - и этот ответ не «наверное что-то для безопасности».