Сім уроків, які варто винести з історії з CrowdStrike

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Невдале оновлення програмного забезпечення від CrowdStrike стало причиною глобального ІТ-збою 19 липня. Як наслідок, «зависли» 8,5 млн комп’ютерів по всьому світі. Про внутрішнє розслідування в CrowdStrike ми вже розповідали тут, а сьогодні натомість пропонуємо розглянути сім правил, що допоможуть уникнути такої ситуації.

1. Монокультури небезпечні

Коли всі покладаються на одну систему, можуть виникнути неприємності.

За приблизними підрахунками Microsoft, постраждало менше одного відсотка всіх комп’ютерів з Windows. Але ці цифри не відображають всієї картини.

За даними 6sense.com, CrowdStrike є компанією № 1 у сфері безпеки кінцевих точок бізнесу з більш ніж 3500 клієнтами. Це може здатися невеликою цифрою, але вона містить кожну четверту компанію, яка використовує захист кінцевих точок. Це, як правило, великі компанії.

2. Поганий код — небезпечний код

Згідно з однією з популярних теорій, запропонованих на X Евіс Дреновою (генеральним директором NeoSync, компанії, що займається інструментами для розробників), першопричиною катастрофічного оновлення безпеки програми Falcon Sensor була помилка нульового покажчика в коді на C++. CrowdStrike, схоже, заперечує це.

3. Забезпечення якості є абсолютно необхідним

Ця проблема була в CrowdStrike. Як команда QA компанії випустила це оновлення — це питання, яке, ймовірно, призведе до того, що багато людей будуть звільнені найближчим часом.

4. Поетапне розгортання дозволяє уникнути катастрофи

Пов’язана з цим виробнича проблема полягає в тому, що багато організацій одночасно розгортають свої оновлення у всіх своїх системах.

5. Аварійне відновлення та резервні копії є обов’язковими

Це очевидно, але варто мати план аварійного відновлення та надійні резервні копії.

«Я розмовляв з кількома ІТ-директорами та громадськими організаціями, які розглядають можливість запуску протоколів відновлення з резервної копії замість того, щоб вручну завантажувати кожен комп’ютер у безпечний режим, знаходити шкідливий файл CrowdStrike, видаляти його і перезавантажуватися в звичайну Windows, — сказав Ерік О’Ніл, експерт з питань безпеки, у своїй заяві для преси. — Компанії, які не інвестували в рішення для швидкого резервного копіювання, застрягли в пастці 22».

6. Посилений моніторинг та реагування на інциденти потрібні

Глобальний масштаб збою підкреслює потребу в передових інструментах моніторингу та надійних планах реагування на інциденти. Повинні бути встановлені системи моніторингу та оповіщення в режимі реального часу, щоб виявляти проблеми під час їх виникнення.

ІТ-команди мають розробляти детальні плани реагування на інциденти з чіткими протоколами для швидкої ідентифікації, ізоляції та вирішення проблем. Ці плани містять аналіз першопричин та аналіз після інцидентів для постійного вдосконалення стратегій реагування.

7. Будьте готові до наступного разу

Інцидент з CrowdStrike/Windows є суворим нагадуванням про те, що навіть рутинне технічне обслуговування може призвести до значних збоїв, якщо ним не керувати належно. Він підкреслює взаємопов’язаний характер сучасних ІТ-систем і далекосяжні наслідки збоїв у широко використовуваному програмному забезпеченні.

Зробивши висновки з цієї події та впровадивши надійні стратегії управління ризиками, ІТ-команди можуть краще підготуватися до подібних інцидентів та пом’якшити їх наслідки в майбутньому.

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
1. Монокультури небезпечні

це про що, взагалі?

2. Поганий код — небезпечний код
3. Забезпечення якості є абсолютно необхідним

Звісно, але скільки за це згодні платити?
Думаю, більшість буде згодна на подібні факапи що дня, а ніж інвестувати 50% прибутку у якісніший (та дорожчий) код.

4. Поетапне розгортання дозволяє уникнути катастрофи

Можливо — зменьшити, але не уникнути. До того ж — усе могло впасти і через тиждень після апдейту — поетапне розгортання тут зовсім не допоможе.

5. Аварійне відновлення та резервні копії є обов’язковими

І що робити з резервною копією, якшо девайс впав і не відповідає (бо поганий драйвер не дає завантажитись)? Як накатити бекап на зламаний девайс?

6. Посилений моніторинг та реагування на інциденти потрібні

Потрібно, але не допоможе.

7. Будьте готові до наступного разу

Авжеж.

Зробивши висновки з цієї події та впровадивши надійні стратегії управління ризиками, ІТ-команди можуть краще підготуватися до подібних інцидентів та пом’якшити їх наслідки в майбутньому

Але ж треба робити правельні висновки.

Підписатись на коментарі