Etkin kurtarma seçenekleri oluşturmak ekosistem direncini artıracaktır
Geçtiğimiz hafta, Temmuz ayında meydana gelen CrowdStrike olayıyla ilgili olarak ABD kongresinde yapılan bir oturumda şirket yöneticilerinden biri politika belirleyicilerin sorularını yanıtladı. Tartışma sırasında ilgimi çeken bir nokta, gelecekte bu büyüklükteki olayların bir tür otomatik sistem kurtarma yöntemiyle önlenebileceği önerisiydi.
Olayın teknik detaylarına ve nasıl önlenebileceğine girmeden, bu öneri temel bir soruyu akla getirmektedir: Otomatik kurtarma üçüncü taraf yazılım satıcısının sorumluluğunda mı olmalıdır yoksa bu, işletim sisteminin (OS) esnekliği ile ilgili daha geniş bir sorun olarak mı çerçevelenmelidir. Yani işletim sistemi üçüncü taraf bir uygulama ile iş birliği içinde bir tür otomatik kurtarma süreci başlatmalı mıdır?
Kendi kendini iyileştiren bir sistem
Mavi ekrana (BSOD) neden olan yıkıcı bir önyükleme hatası, cihazda yüklü olan uygulamalarla birlikte kullanıcıya çalışan bir işletim sistemi sunmak için gereken yazılımı cihaz yükleyemediğinde ortaya çıkar. Örneğin, yazılım yüklendiğinde veya güncellendiğinde tetiklenebilir; bu örnekte, cihazın önyükleme işlemi sırasında çağrılan bozuk / kötü bir güncelleme dosyası, sonuçta iyi belgelenmiş küresel bir BT çöküşüne neden olan mavi ekranı tetikledi.
Güvenlik uygulamaları gibi bazı yazılımlar, ‘çekirdek modu’ olarak bilinen düşük seviyeli erişim gerektirir. Bu seviyedeki bir bileşen arızalanırsa BSOD olası bir sonuçtur. Cihazı yeniden başlatmak aynı BSOD döngüsüne neden olur ve bu döngüyü kırmak için uzman müdahalesine ihtiyaç duyarsınız. (Elbette BSOD, yazılımın çalışması için daha kısıtlı bir ortam sağlayan ‘kullanıcı modunda’ da meydana gelebilir).
Şimdi, çekirdek modundan bahsetmek sizi yanılttıysa durumu daha açık hale getirmek için bir benzetme kullanmama izin verin: Benzinli bir arabanın motorunu düşünün. Motor, yakıt-hava karışımını ateşlemek için bir kıvılcıma ihtiyaç duyar, bu da bujinin devreye girdiği yerdir. Düzenli bir bakım programında bujilerin değiştirilmesi gerekir, aksi takdirde motor beklendiği gibi çalışmayabilir. Bir tamirci arabanın kaputunu açar ve yeni bujileri takar. Anahtar çevrilir (veya çalıştırma düğmesine basılır) ve motor çalışır (çalışmadığı zamanlar hariç). Bu olayda yazılım açısından kabaca buna benziyor.
Şimdi şu soru ortaya çıkıyor: Bu senaryo için bir otomatik kurtarma mekanizması oluşturmak buji üreticisinin sorumluluğunda mı olmalı? Yazılım bağlamında, üçüncü taraf satıcı mı sorumlu olmalıdır? Yoksa tamirci kaputu tekrar açmalı, kullanılmış ve çalıştığı bilinen bujilere geri dönmeli ve aracı önceki çalışma durumunda yeniden çalıştırmalı mıdır?
Benim görüşüme göre kurtarma süreci, ilgili üçüncü taraf yazılımdan (veya bujilerden) bağımsız olarak her koşulda aynı olmalıdır. Bujiler (yazılım) tamircinin (işletim sistemi) bilgisi olmadan güncellendiği ve değiştirildiği için gerçekte durum elbette benim benzetmemden biraz daha karmaşık. Yine de bu benzetmenin konuyu görselleştirmeye yardımcı olacağını umuyorum.
İşletim sistemi tarafından yönetilen kurtarma durumu
Bir üçüncü taraf yazılım paketi her güncellendiğinde ve cihazın temel işleyişinde bir ayarlama yaptığında işletim sistemine kaydolmak için önyükleme işlemi sırasında gerekli olan yeni veya değiştirilmiş bir dosya yüklerse dosya veya durum üzerine yazılmak yerine bir kopyası oluşturulur. Teorik olarak, bir sonraki açılışta cihaz BSOD durumuna düşerse ilk görev olarak cihazın bir önceki açılışta doğru başlatılıp başlatılmadığı kontrol edilebilir ve kullanıcıya güncellemeyi kaldırarak değiştirilen dosyayı veya durumu önceki sürümle kurtarma seçeneği sunulabilir. Aynı senaryo çekirdek moduna erişimi olan tüm üçüncü parti yazılımlar için de kullanılabilir.
İşletim sistemi tarafından yönetilen bu tür bir kurtarma için halihazırda bir örnek bulunmaktadır. Yeni bir ekran sürücüsü yüklendiğinde ancak önyükleme işlemi sırasında doğru şekilde başlatılamadığında hata yakalanır ve işletim sistemi otomatik olarak varsayılan bir duruma geri döner ve tüm ekranlarla çalışan çok düşük çözünürlüklü bir sürücü sunar. Bu senaryonun siber güvenlik ürünleri için geçerli olmadığı açıktır çünkü varsayılan bir durum yoktur ancak güncellemeden önce önceki bir çalışma durumu olabilir.
Tüm üçüncü taraf yazılımlar için işletim sisteminde yerleşik bir kurtarma seçeneğinin bulunması, her bir yazılım satıcısının kendi çözümünü geliştirmesine bel bağlamaktan daha etkili olacaktır. Elbette, mekanizmanın çalışmasını ve kötü niyetli kişiler tarafından istismar edilmemesini sağlamak için işletim sistemi ve üçüncü taraf yazılım satıcıları arasında istişare ve iş birliği yapılması gerekecektir.
Böyle bir çözüm geliştirmek için gereken ağır işleri (gereğinden fazla) basitleştirmiş olabileceğimi de kabul ediyorum ancak yine de binlerce yazılım geliştiricinin kendi sistem kurtarma yöntemlerini oluşturmaya çalışmasından daha sağlam olacaktır. Nihayetinde bu, sistem direncini artırma ve hatalı CrowdStrike güncellemesinin tetiklediği gibi yaygın kesintileri önleme yolunda uzun bir yol kat edebilir.
