Siber güvenlikte bir dönüm noktası olan CrowdStrike başarısızlığı, yılın en önemli hikayesi ve potansiyel olarak on yılın en etkili hikayelerinden biri olarak duruyor. Dünya çapındaki Windows işletim sistemlerine gönderilen kusurlu güncelleme, kritik makineleri (tahmini 8,5 milyon) çökertti ve önümüzdeki aylar, hatta yıllar boyunca etkisini gösterecek küresel bir BT kesintisine yol açtı.
Ve benim gibi bu alanda 30 yıllık deneyime sahip bir siber güvenlik danışmanı, bu CrowdStrike olayında müşterilere gerçek zamanlı olarak yardımcı olan biri için bu konu üzerine şimdiden mürekkep çeşmeleri dökülmüş olsa da, pek çok makalenin şu konuya odaklandığını görüyorum: aynı birkaç nokta tekrar tekrar. Evet, şimdi ne olduğunu, nasıl olduğunu, CrowdStrike ve rakiplerinin böyle bir durumun bir daha yaşanmaması için neler yapacağını öğreniyoruz.
Ancak başarısızlığın ve sonuçlarının pek çok ilginç yönü geniş çapta bilinmiyor veya önemli ölçüde tartışılmıyor. Bunlar, yaşananların aydınlatıcı yönlerini aydınlatıyor ve sektörümüz bu olaya önümüzdeki yıllarda tepki vereceğinden, bundan çıkaracağımız derslerin, gelecekteki olayların etkisini azaltmak amacıyla yöneticilerin ve siber güvenlik/BT profesyonellerinin uygulaması gerekli olacaktır. .
“Güvenilir Sağlayıcı” Bitti
İlk olarak, bu tür bir olaya ilişkin risk hesabı, bu noktadan itibaren siber güvenlik ve risk yönetimi uzmanları için farklı olacaktır. Bu tür riskleri artırmalıyız; yazılımın hack veya sosyal mühendislik saldırısından değil, güvenilen bir sağlayıcıdan gelmesi. Ortaklara, hatta güvenlikten sorumlu olanlara bile, mutlak bir cezasızlıkla güvenmenin günleri sona erdi.
Bunun yerine siber güvenlik güncellemelerini diğer yazılım güncellemeleri gibi ele almalıyız. Bu, BT sürecinin sonunda daha fazla esneklik uygulamak ve dağıtımdan önce daha kapsamlı ve zorunlu testler yürütmek anlamına gelir. Artık hiçbir iş ortağımıza ücretsiz geçiş hakkı veremiyoruz ve güncellemelerini iletemiyoruz. Öyle olmayacağını umsak da CrowdStrike senaryosunun yeniden gerçekleşebileceğini varsaymalıyız.
Fırsatçı Sömürücüleri Hazırlayın
CrowdStrike hatasının herhangi bir parçanın bir hack veya kötü niyetli eylemden kaynaklandığına dair hiçbir kanıt olmasa da (bunu yazdığım sırada), işler ters gittiğinde kötü aktörlerin sahneye çıkıp durumu düzeltmeye çalışacağı gerçeği ortadadır. durumun avantajı. Ortalama bir insanın “mavi ekranlı” iş bilgisayarıyla uğraşırken hissettiği kafa karışıklığı, hayal kırıklığı ve çaresizlik gerçektir. Bu olaydan çok kısa bir süre sonra, soruna hızlı bir çözüm olduğunu iddia eden kötü amaçlı bir dosya ortalıkta dolaşmaya başladı; ancak “CrowdStrike düzeltmesi” olarak adlandırılan şey, mantıklı eylemlerin yerini çaresizliğin alması nedeniyle normalden daha fazla insana ulaşan bir kötü amaçlı yazılımdan başka bir şey değildi.
Bu tür bir durum (güvenilir bir sağlayıcının yaygın bir kesintinin kaynağı olması) daha önce radarımızda olmasa da, şimdi öyle. Bu olaylar sırasında tüm çalışanların hazırlıklı olması ve neyin protokol olup olmadığını bilmesi gerekir. Her seviyedeki çalışanlar için her zaman daha fazla siber güvenlik eğitimi vardır ve bu eğitimler CrowdStrike başarısızlığından alınan dersleri de içermelidir. Şimdi başlayın; Bir sonraki olayın ekibinizin öğrenme eğrisinin başlangıcı olmasına izin vermeyin.
Tedaviye Bir Bakış: Düzeltmeyi Uygulamak
Bazıları yanıtların ve düzeltmelerin kapsamının nasıl göründüğünü merak ediyor olabilir. Elbette hepimiz, havayollarının ve önemli sağlık kuruluşlarının kesintinin hemen ardından yaşadığı mücadelenin sayısız yeniden anlatımını okuduk. Ancak dünya çapındaki küçük ve orta ölçekli işletmeler ve yerel yönetimler de aynı acıyı yaşadı. Merkezi ofislerde bile makineleri tekrar çalışır hale getirmek manuel ve zahmetli bir işti, çünkü bir düzeltme çalıştırıp onu devre dışı bırakacak sunucular da kapalıydı.
Uzaktan dağıtılan cihazların sayısı göz önüne alındığında (son yıllarda hepimiz uzaktan çalışmaya yönelik daha esnek bir yaklaşımdan hoşlandığımızdan) düzeltmeler daha karmaşıktı. Bazı durumlarda bu düzeltmeler kullanışsız ya da aşırı derecede tuhaftı. BT personeli bazı yerlerde kapı kapı dolaşarak makineleri teker teker tamir ediyordu. Şehirlerde bazı kuruluşların çalışanlarına iş bilgisayarlarını üzerinde çalışmak üzere merkezi bir konuma getirmeleri söylendi. Bazen BT, insanlara telefonla düzeltmeleri anlatmak zorunda kalıyordu. Bir akrabasının dizüstü bilgisayarındaki sorunları telefonla gidermesine yardım etmeye çalışan herkes, bu sürecin ne kadar verimli olmaktan uzak olduğunu bilir.
Hatta bazı durumlarda kuruluşların temel güvenlik hijyeninin en temel kurallarından bazılarını çiğnediğini bile gördük. Bir düzeltmenin uygulanmasına yönelik komut dosyası içeren flash sürücülerin ülke çapında postalandığını duydum. CrowdStrike, düzeltme uygulamalarımızın teknik gelişmişliği konusunda bizi birkaç on yıl geriye götürdü.
Siber Güvenlik Araçları; N+1 Artıklık
Artık yalnızca “güvenilir sağlayıcımıza” güvenemeyeceğimiz için süreçlerimizi ve araçlarımızı yakından değerlendirmemiz gerekiyor. Elinizdeki tüm siber güvenlik araçlarından en iyi şekilde yararlanmanızı öneririm. Bazı BT departmanları çakışan yazılım güvenliği özelliklerini devre dışı bırakır; ancak bu bir hatadır! Daha fazla süreç çalıştırmak ek bir iştir, ancak bu ekstra güvenlik öngörüsü, bir istismarın doğrulanması ve hatta diğer siber güvenlik araçları tarafından tanımlanmayan tamamen farklı bir saldırı yüzeyinin tespit edilmesi için bir “kontroller ve dengeler” olarak yararlı olabilir.
Örneğin, kuruluşların aynı veri seti veya veritabanı üzerinde farklı yazılım programlarından birden fazla güvenlik açığı kontrolü çalıştırdığını gördüm; sonuçlar kesinlikle aynı olmuyor. Siber güvenlik araçları kusurludur ancak birden fazla aracın kullanılması risklerin azaltılmasına yardımcı olabilir. Farklı siber güvenlik sistemlerinin merceğinden bilgi toplamak ve bu verileri, bütünsel bir analizin daha bilinçli kararlar verebileceği tek panelli bir kontrol paneline odaklamak çok önemlidir.
Kuruluşlar, güvenlik önlemlerinde N+1 yedekliliği etkinleştirmeye çalışmalıdır. “N+1 Artıklık” kavramı, sistemin sürekli çalışmasını sağlamak için gereken her “N” bileşen için fazladan bir “+1” bileşenin bulunduğu sistem tasarım ilkesini ifade eder. Siber güvenlik bağlamında bu, birincil çözüm kadar etkili bir yedek siber güvenlik çözümüne sahip olmak anlamına gelir.
Bununla birlikte, bazı şirketlerin güncelleme politikalarını uyarladıklarını ve gelen yamalar için n-1 veya nadir durumlarda n-2 modeline geçtiklerini görmemiz mümkün. Bu güncellemelerin kendileri olası riskleri temsil ettiğinden, benzer felaketle sonuçlanan hataların kişinin kendi şirketi tarafından değil başkaları tarafından keşfedilmesini sağlamak için bir güncelleme döngüsü beklemek konusunda bir tartışma var. Elbette bu, şirketlerin bilinen güvenlik açıklarıyla daha uzun süre yaşamak zorunda kalacağı anlamına geliyor ancak kötü bir güncellemenin olası kesintisinden kaçınılarak bu durum hafifletilebilir. Elbette, n-1 zaman diliminde hangi yamaların yapılabileceği ve hangilerinin o kadar kritik olduğu ve bunların derhal güncellenmesi riskinin alınması gerektiği konusunda durum bazında olması gerekebilir. Her şirket kendi politikasını belirlemeli ve kendisine uygun yaklaşıma karar vermelidir.
Sırada Ne Var? Olay Müdahale Planınızı Gözden Geçirin
Şirketiniz bu kesintiyi atlattıktan sonra olay müdahale planınızı yeniden değerlendirmek için daha iyi bir zaman olamaz. Tüm BT departmanları, CrowdStrike olayına verdikleri tepkinin etkinliğini gözden geçirmek için bir toplantı yapmalı ve aşağıdaki gibi sorular sormalıdır:
- Açık roller, sorumluluklar ve politikalar oluşturulmuş mu?
- Mevcut plan yazıldığı gibi uygulandı mı? Değilse neden?
- İletişim planı en son ne zaman güncellendi?
- Doğru kişilere doğru sırayla bilgi verildi mi?
- Şiddeti ve etkiyi değerlendirmek için triyajdan kim sorumludur?
- Geri yüklenen sistemleri kim izliyor ve tüm eylemlerin etkinliğini kim belgeliyor?
- Olay müdahale planı burada tartışılan “güvenilir sağlayıcı” senaryosunu doğru şekilde hesaba katacak şekilde güncellendi mi?
Her yeni olayda planı yeniden değerlendirin ve herhangi bir zayıf noktayı veya güncelliğini yitirmiş bilgiyi detaylandırmak için masa üstü alıştırmalar yaparak planı taze ve güncel tutun. Unutmayın, masa üstü değerlendirmenin amacı, bir kuruluşun hazırlıklılığını ve gerçekçi senaryolara karşı tepkisini test etmektir. Güçlü ve zayıf yönleri analiz etmek için eylem sonrası incelemenin yapıldığı bir bilgilendirme, yani sıcak yıkama yapmak önemlidir.
Sonuç: Dönün ve Hazırlanın
CrowdStrike olayı beklenmedik olabilir ancak gelecekte benzer bir olayın yaşanması kuruluşları hazırlıksız yakalamamalı. “Güvenilir” bir ortağın bu tür bir başarısızlığa uğramasının bir yerde, bir ara tekrar gerçekleşeceği varsayımıyla hareket etmemiz gerekiyor. Bir sonraki olaya hazırlanmak için BT’nin siber güvenlik güncellemelerini standart yazılım yamalarında olduğu gibi ele alması gerekiyor. Bu yerleşik prosedürleri takip etmek, güncelleme notlarının gözden geçirilmesi, bir test ortamının oluşturulması ve güncellemenin uygulanması, dağıtım için gerekli onayın alınması, dağıtımın kademeli olarak yapılması ve ilgili tüm paydaşların bilgilendirilmesi anlamına gelir.
Dijital ekosistemimiz birbirine fazlasıyla bağlı. Yazılım güncellemelerine dokunulmadan güvenmek, diğer yamalar ve güncellemeler için atılan prosedür adımlarını atlatmak, kırılgan BT ortamımızı kaosa sürüklemeye devam edecek. Yazılım güncellemelerine “sağduyu filtresini” uygulayın; şeytan ayrıntıda, kaos ise koddadır.
Reklam