Контроль над обновлением on-prem продуктов в контексте инцидента с CrowdStrike. В комментах к посту про переосмысление облачных агентов Алексей Лукацкий спрашивает: "а причем тут облачные агенты? У онпрем такого не может случиться?"
Я вижу 2 момента. Начнём с контроля над обновлением.
Если решение о функциональном обновлении компонентов продукта (включая агенты) принимает клиент и у него есть возможность протестировать новую версию, то в случае проблемы с агентом а-ля BSODStrike:
🔹 Её можно было бы обнаружить во время раскатки агентов на тестовой группе активов. 👷♂️
🔹 Её можно было бы переждать, если не обновляться сразу, а посмотреть недельку не всплывёт ли что-нибудь в других компаниях. 😏
Но это только если контроль над обновлением продукта со стороны клиента предусмотрен и выполняется. Если же в настройках продукта стоит галка "устанавливать все обновления автоматически" и "обновлять все агенты автоматически", то тогда здесь преимуществ онпрема не будет. 🤷♂️
Уведомление: Какие меры предлагает CrowdStrike, чтобы BSODStrike не повторился? | Александр В. Леонов
Уведомление: Ещё одним аспектом инцидента с CrowdStrike является то, что Windows хосты сломало не функциональное обновление агента, а обновление "контента обн
Уведомление: No Boot - No Hacker! | Александр В. Леонов
Уведомление: Компрометация ИБ вендора облачного продукта с агентами в контексте инцидента с CrowdStrike | Александр В. Леонов