Контроль над обновлением on-prem продуктов в контексте инцидента с CrowdStrike

Контроль над обновлением on-prem продуктов в контексте инцидента с CrowdStrike

Контроль над обновлением on-prem продуктов в контексте инцидента с CrowdStrike. В комментах к посту про переосмысление облачных агентов Алексей Лукацкий спрашивает: "а причем тут облачные агенты? У онпрем такого не может случиться?"

Я вижу 2 момента. Начнём с контроля над обновлением.

Если решение о функциональном обновлении компонентов продукта (включая агенты) принимает клиент и у него есть возможность протестировать новую версию, то в случае проблемы с агентом а-ля BSODStrike:

🔹 Её можно было бы обнаружить во время раскатки агентов на тестовой группе активов. 👷‍♂️

🔹 Её можно было бы переждать, если не обновляться сразу, а посмотреть недельку не всплывёт ли что-нибудь в других компаниях. 😏

Но это только если контроль над обновлением продукта со стороны клиента предусмотрен и выполняется. Если же в настройках продукта стоит галка "устанавливать все обновления автоматически" и "обновлять все агенты автоматически", то тогда здесь преимуществ онпрема не будет. 🤷‍♂️

Далее

Контроль над обновлением on-prem продуктов в контексте инцидента с CrowdStrike: 4 комментария

  1. Уведомление: Какие меры предлагает CrowdStrike, чтобы BSODStrike не повторился? | Александр В. Леонов

  2. Уведомление: Ещё одним аспектом инцидента с CrowdStrike является то, что Windows хосты сломало не функциональное обновление агента, а обновление "контента обн

  3. Уведомление: No Boot - No Hacker! | Александр В. Леонов

  4. Уведомление: Компрометация ИБ вендора облачного продукта с агентами в контексте инцидента с CrowdStrike | Александр В. Леонов

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Captcha
captcha
Reload