Bilgi güvenliği esasen bir bilgi risk yönetimi disiplinidir. Crowdstrike’ın neden olduğu küresel kesinti, birçok bilgi sistemini çalışmaz hale getirerek, planlanmamış ve uzun süreli kesinti nedeniyle birçok şirketin kritik iş bilgilerine erişmesini engelledi.
Erişilemezlik yalnızca bilgi sistemleri için değil, aynı zamanda ilgili bilgi işleme için de geçerliydi. Yalnızca bir bilgi riski olayı değildi, aynı zamanda bir bilgi güvenliği olayıydı. Ve risk olayının/bilgi güvenliği olayının etkisi operasyonel, finansal, itibar, yasal, teknolojik ve hatta düzenleyici açılardan yüksekti.
Bu Crowdstrike güvenlik olayı kesinlikle satıcılar ile müşterileri arasındaki dijital güvenin bozulmasını temsil ediyor. Peki bu güveni yeniden sağlamak için ne yapılması gerekiyor?
Yanlış
Test otomasyonu birçok kuruluşun rutin olarak başarısız olduğu bir alandır. Özellikle yeni başlayanlar için, testleri dahili olarak otomatikleştirmek ve ardından hataları düzeltmek için hızla güncellemeler yayınlamak alışılmadık bir durum değildir – esasen müşterilerini kalite güvencesi (QA) olarak kullanırlar.
Ancak son zamanlarda, daha fazla şirket bu uygulamayı ‘çevik metodolojilerinin’ bir parçası olarak veya CI/CD süreç verimliliğini artırmak ve işletmeyi hızla ölçeklendirmek için kullanıyor.
Gittikçe daha fazla sayıda güvenlik şirketi ‘İsviçre çakısı’ İşletmelerin devam eden bakım döngülerini devralıp, otomatik güncellemeler sağladıkları çözümlerdir.
Bununla ilgili potansiyel felaket, testlerin kısmen veya tamamen otomatikleştirildiği otomatik bir güncelleme gerçekleştiğinde ve otomatik test sistemleri tarafından tespit edilmeyen sorunlar olduğunda ortaya çıkar ve bu da kritik sektörlerdeki işletmelerde kitlesel kesintilere yol açarak kamu güvenliğini tehdit eder.
Doğru
Büyük bir güvenlik olayı yaşayan birçok şirket, başından itibaren tüm paydaşlarına karşı genel olarak şeffaf davranıyor; buna müşteriler, iş ortakları, çalışanlar ve yatırımcılar da dahil.
Örneğin Crowdstrike bu konuda sağlam bir iş çıkardı. Hatalı olduklarını kabul ettiler ve kendi ekipleri ve Microsoft ekipleriyle birlikte bir düzeltme geliştirmek için hızla çalıştılar. Crowdstrike’ın yönetici kadrosu da düzeltme ve kurtarma açısından yardım teklif eden birkaç müşteriye ulaşmada öncü oldu. Kapsamlı bir kök neden analizi (RCA) gerçekleştirdiler ve güvenlik kontrollerinin nerede başarısız olduğu konusunda bir nebze şeffaf oldular.
Şirket, insanlara, sürece ve teknolojiye yönelik iyileştirmeleri içeren bir eylem planı taahhüt etti. Ayrıca, özellikle olayın kritik sektörler üzerinde önemli bir etkisi olduğu göz önüne alındığında, artan düzenleyici müdahale ve denetime hazır görünüyorlar. Örneğin, Avrupa Birliği’nde (AB), Dijital Operasyonel Dayanıklılık Yasası (DORA), Ağ ve Bilgi Güvenliği (NIS2) Direktifi ve Siber Dayanıklılık Yasası gibi mevzuatlar, Crowdstrike’ın kanun koyuculara gelecekte bu tür olayların olmayacağına dair güvence vermesini talep edecektir.
Daha iyi ne yapabiliriz?
Gelecekte, kuruluşların iş sürekliliği yönetimi (BCM), felaket kurtarma, üçüncü taraf risk yönetimi (TPRM) ve olay yönetimi konularında iş dayanıklılığına daha fazla odaklanmaları gerekiyor.
Tedarik zinciri sorunları da dahil olmak üzere birden fazla senaryo için risk izleme ilk adımdır. Bunlar mevcut risk kayıtlarına, iş etki analizlerine (BIA’lar) ve risk ve kontrol öz değerlendirmelerine (RCSA’lar) eklenebilir.
Daha geniş risk tedavi planları, üçüncü taraf risk değerlendirmelerinde ürün güvenliği konusunda daha fazla inceleme, satıcı güncellemeleri için daha sıkı testler (evet, uç nokta tespit araçlarından gelen güncellemeler bile), mümkün olan yerlerde otomatik güncellemelerin devre dışı bırakılması, satıcı güncellemelerinin kademeli olarak dağıtılması, üçüncü taraf risklerini ele almak için olay kılavuzlarında ve felaket kurtarma planlarında güncellemeler ve siber güvenlik egzersizlerinde üçüncü taraf güvenlik olayları için risk simülasyonlarının dahil edilmesini kapsayabilir, ancak bunlarla sınırlı değildir.
Niel Harper, ISACA yönetim kurulu başkan yardımcısıdır.