CrowdStrike ve Güncelleme İhtiyacı Hakkında

19 Temmuz 2024 günü muhtemelen teknolojinin günlük hayatı yavaşlattığı önemli bir gün olarak hatırlanıp belki de ileride bir çok tercihi etkileyecek bir algının da altyapısını oluşturacağı kesin. Yazıya geçmeden önce sorunu çözen ve hala sorunu çözmek için emek harcayan herkese geçmiş olsun diyorum.

Etkinin başlangıcı

Benim açımdan ilgili gün ekipten arkadaşımın “küresel çapta BT sistemlerinde sorunlar oluştu” şeklinde ve içerisinde hiçbir teknik bilgi olmayan bir haber ile öğrendim. Tahminim muhtemelen 2024 Güneş Fırtınaları etkisi olabileceği idi. Ve aslında çok da önem vermedik.

Normalde BT alanında bu olayların çok içerisinde birisi olarak, çalıştığım kurum ve geliştirdiğimiz ürün genellikle on-premise altyapılarda kullanıldığı ve GNU/Linux sistemler üzerinde çalıştığımız için ortalığın alevlendiği dakikalarda herhangi bir etki görmeyip öğlen yemeğine kadar olağan toplantıdan dolayı hiç farkında bile olmadım. Öğleden sonra ise az çok bilgilerle yorum yapabilecek kıvama eriştim anca.

Peki ne olmuş?

Sonrasında duyduğumuz bir çok komplo teorisinin aksine anladığım kadarıyla klasik bir güncelleme hatasının, otomatik bir şekilde yaygınlaşması ile Windows sistemlerinde kritik bir sorunu oluşturması ve “Mavi Ekran” hatasına düşüp, en pratik şey olan yeniden başlatma ile sorundan kurtulanaması olmuş.

Sorunun ana kaynağı CrowdStrike firmasının Falcon isimli EDR güvenlik yazılımı. İlgili yazılımın GNU/Linux ve MacOS üzerinde de ajan servisleri olmasına rağmen ilgili güncelleme Windows sistemlerde etkili oldu. Ki muhtemelen EDR olarak da genellikle Windows sistemlerin güvenliğinin sağlanması için kullanıldığı da düşünülebilir.

Nedeni kabaca anlaşıldıktan sonra çözüm önerilerinden anladığımız kadarıyla CrowdStrike sürücülerinin bulunduğu klasörde “C-00000291" ile başlayan sys dosyalarının çağrılması ile sistemde bir kararsızlık oluşturuyor. Çözüm olarak silmenin yanında adının değiştirilmesi bile driver’ın klasör bazlı değil başka bir servis veya sürücüden aynı isimde çağrılması ile oluştuğunu göstermekte.

Sorumlu kim?

Öncelikle sıkı bir açık kaynak kodlu yazılım destekçisi olmama karşın olabildiğince objektif davranmaya çalışacağım. Sorumlu temel olarak CrowdStrike gibi gözükse de ilgili güncelleme ile işletim sistemi üzerinde sistemi kapatabilecek seviyede bir sorun oluşturması ile işletim sistemi de sorumluluktan pay alıyor. Fakat CrowdStrike Falcon’un EDR sisteminde sürücü geliştirdiği noktada yer aldığı için işletim sisteminin pek bir suçu da olmayabilir. Yani daha doğrusu aynı sorunun bir benzerini GNU/Linux sistem üzerinde “kernel modülü” veya “sürücü” geliştirme süreçlerinde de yaşanabilir.

Fakat Windows üzerinde sürücü geliştirme prosüdürlerine aykırı bir çalışma yapılmayıp, basit bir geliştirme sonucu bu etki oluştu ise biraz önce düşük diye belirttiğim payda Windows da yüksek bir oran alabilir.

Sorun nerede?

Hepsinin ötesinde yine felsefe olarak tartışacağım başka bir konuya da değinmek istiyorum. Sorumlu CrowdStrike da olsa Windows da olsa sorun yazılımların veya sürücü altyapısının test süreçlerinden geçmeden piyasaya sürülmesi mi, yeterince test edilmemesi mi yoksa kaçılamayacak bir senaryonun denk gelmesi midir?

Öncelikle son önerinin doğru olabilmesi için tüm kullanıcıları değil, spesifik durumdaki kullanıcıları etkilemesi gerekirdi. Şimdilik yaygın duruma göre yaşanan sorun yaygın bir etki alanına sahip. Dolayısıyla istisna diye kabul edilebilecek bir senaryo değil.

Peki “doğru” test süreçlerinden geçmemesi mi yoksa “yeterince” test süreçlerine tabi olmaması mı? Bunu süreç ileride analiz edildiğinde veya firmanın içerisinde bugün analiz edilen yapının sonucunda cevap verileceği için şuan söylemek tahminden öteye gitmeyecektir.

Yine de konu hakkında felsefi düşünmek gerekirse bu şekilde bir sonucu doğurması için “doğru” test süreçlerinden geçmediği “yeterince” test edilmediğine daha baskın olduğunu düşünüyorum. Ve tam olarak bu noktada “doğru” test süreçlerinin sınırı ve kalitesinin neye göre belirleneceği kısmına girmek istiyorum.

Doğru test süreçleri!

Yazılım süreçleri içerisinde bana kalırsa en sıkıntılı kısım test süreçleri. Sadece yazılım olarak düşünmek de pek doğru değil, herhangi bir fiziki nesnenin de test süreçleri sıkıntılı olabilir.

Örneğin LEGO marka yapı bloklarının çok sağlam olduğunu biliyoruz. Muhtemelen onlarca çeşit test süreçleri sonucunda kaliteli bir malzemeden, belirli şartlarda oldukça disiplinli bir şekilde üretilmesi ile oluşuyordur. Rakip çin malı ucuz ürünler buna dikkat etmeyip oynanışta birbirine eklenmesinde zorluk, imkansızlık, yamuk ekleme vs gibi “yeterince” test edilmemesinden dolayı ucuz ama sorunlu bir ürün ortaya çıkabiliyor.

Fakat bir de üstün diye kabul edeceğimiz test koşulları sonrasında onlarca evde sorun yaşanmayan LEGO Parçaları, afacan bir çocuğun değişik bir nesneyle oynaması sırasında çatlayarak belki de kullanılmayacak bir hale gelmesine neden olabiliyor. İşte bu noktada bu parçanın çatlamaması için belki basit bir adım yapılabilecekken test edilmemesi veya bu senaryonun düşünülmemesi nedeniyle “doğru” test adımlarının kurgulanmamış olması olası.

Tabi hepsinin yanında evrimsel gelişime paralel olarak ürünün kullanım oranı ve yine bu orana benzer oranda test personeli ve personel kalitesi gibi kavramlar da çok önemli. Tekil bir örnek olmaması ve küresel bir problem oluşturmasından dolayı daha basit sorunların evrimsel süreçte elendiğini de göz önüne alarak yukarıda sorumluluk kısmındaki sorumluluk algısını hem işletim sisteminde hem de sürücü yazılımı geliştiren firmada “doğru” test yöntem veya adımlarının belirlenip belirlenmemesi de etkileyecektir.

Peki ya güncelleme?

Tüm bu adımlardan sonra “Çalışıyorsa dokunma!” diye bilinen felsefeye uygun bir şekilde her güncellemenin bir risk içerdiğini de unutmamak gerekiyor. Güncelleme çok basit bile olsa kontrollü olmadığı sürece büyük sorunlar doğurabiliyor. Özellikle kontrolün sınırının nerede başlayıp bittiği bilinmeyen durumlarda bu daha da sorun olabiliyor.

Güncellemeler genellikle güvenlik güncellemesi, hata düzeltme güncellemesi veya yeni özellik güncellemesi gibi sınıflandırılabilir. Özellikle güvenlik güncellemeleri daha hızlı yapılması gereksinimine karşın yukarıdaki örnekte bir sorumluluk da bu güncellemenin anlık yapılması olduğu görülüyor. Oysa ki sıralı bir güncelleme olsaydı yaşanacak sorun ilk yapanlar tarafından tespit edildikten sonra etkisi çok daha az olarak yansıyacağı kesindi.