9 Ekim 2003’teMicrosoft CEO’su Steve Ballmer, şirketin “öngörülebilirliği ve yönetilebilirliği artıracak bir düzey ekleyerek BT yöneticilerinin üzerindeki yükü azaltmak” için güvenlik yamalarını yalnızca ayda bir yayınlayacağını duyurdu.
Yirmi yıl sonra Microsoft, acil durumlar için ara sıra istisnalar dışında, güvenlik güncellemelerini her ayın ikinci Salı günü yayınlamaya devam ediyor ve Oracle ve Adobe gibi diğer birçok şirket de benzer kuralları izliyor.
Salı Yaması, risk yönetimini aylık bir randevuya dönüştürdü, ancak birçok yenilik gibi, krizden kuruldu. 2002’nin başında, dünyanın ilk siber kıyamet günlerinden ikisi olan Code Red ve Nimda’yı deneyimlemesinden kısa bir süre sonra Microsoft, güvenlik konusundaki felsefesini değiştirmeye karar verdi. Birkaç saat içinde yüzbinlerce makineye bulaşan iki solucan, yamaların mevcut olduğu güvenlik açıklarından yararlandı.
2000’den 2010’a kadar Microsoft’ta çalışan ve şu anda Sophos’ta tehdit araştırmalarından sorumlu üst düzey yönetici olan Christopher Budd, “Sorun yamaları oluşturmamamız değildi; sorun, insanların bunları yeterince hızlı dağıtmamasıydı” diyor. .
O zamanlar, 11 Eylül travması Kuzey Amerika’da aşikardı ve Microsoft içinde güvenlikle ilgili artan bir endişe vardı. 15 Ocak 2002’de Bill Gates ünlü mesajını gönderdi. Güvenilir Bilgi İşlem notumüşterileri ve sistemlerini korumanın önemini vurguluyor.
Güvenliği artırmanın bir yolu, yamaların teslim edilme şeklini değiştirmekti. Bu nedenle Microsoft, tahmin edilemeyecek şekilde, hazır olduğunda gönderilir esasına göre, haftada birkaç kez duyurmak yerine, müşterilerin her şeye ayak uydurmasını kolaylaştırmak için bunları bir araya getirmeye başladı.
Budd, fikrin ilk başta “sessiz bir pilot proje” olarak uygulandığını söylüyor. Ancak umut verici sonuçlar gösterdiği için kısa sürede resmiyet kazandı. bu ilk resmi Yama Salı 14 Ekim 2003’te yayınlanan rapor, beşi kritik olarak görülen yedi güvenlik açığı içeriyordu.
Salı Yaması’nın oluşturulmasına yardımcı olan Budd, “Salı, bunları sürdürülebilir bir şekilde sunabileceğimizi hissettiğimiz haftanın en erken günüydü” diyor.
Bu sabit program yaklaşımı, standart bir endüstri uygulaması haline geldi. Ancak buna giden yol her zaman pürüzsüz değildi.
Salı Yamasının İlk Günleri
Yıllar boyunca Microsoft, değişen tehditlere uyum sağlayarak güvenlik yamalarına yönelik yaklaşımını geliştirdi ve geliştirdi. Sasser ve Blaster gibi Code Red’i izleyen önemli solucanlar, Salı Yaması’nın büyümesine ve sonunda olgunlaşmasına yardımcı oldu.
Trustworthy Computing notundan sonra “aniden inanılmaz derecede önemli hale gelen” Budd ve Microsoft Güvenlik Yanıt Merkezi’ndeki meslektaşları, yama dağıtımı ve tespiti konusunda iyileştirmeler yapmaya çalıştı. Önemli başarılardan biri, yöneticilerin tarama yapmasına ve güvenlik güncellemelerine ihtiyaç duyan sistemleri belirlemesine olanak tanıyan araçlar oluşturmaktı – basit olmasına rağmen oyunun kurallarını değiştiren bir fikir.
Yamaları yayınlama sürecinin tamamı, özellikle Yama Salı’dan önceki Pazartesi günü, her şeyin kontrol edilmesi gereken kapsamlı bir çalışma gerektiriyordu. Güvenlik uzmanları uzun saatler geçirdiler, doğum günü partilerini kaçırdılar ve hatta eve gidecek zamanları olmadığı için Microsoft’un genel merkezinde duş aldılar.
Bültenlerin çıkışının hoparlörlerden patlayan müziklerle kutlanmasının nedeni budur.
2008 ile 2014 yılları arasında Microsoft’ta çalışan ve şu anda Trend Micro Zero Day Initiative’de tehdit farkındalığı başkanı olan Dustin Childs, “Bültenler yayınlandığında bizim için çok önemliydi” diyor.
Tipik olarak müzik, o bülten için yayın yöneticisi tarafından seçilirdi.
Childs, “Bir ay Klingon müziği olduğunu hatırlıyorum ama genellikle rock and roll’du” diyor.
Ara sıra, müzik durduktan hemen sonra, bazı yamalar istenmeyen sonuçlara neden olduğu için kaos başlardı. Şubat 2010’da binlerce müşterinin neredeyse anında mavi ekran bildirdiği dikkate değer bir olay yaşandı.
Redmond’daki güvenlik uzmanları mavi ekran sorununu duyduklarında, onu kopyalamaya çalıştılar ancak başarılı olamadılar. Daha iyi bir çözüm olmadığı için Microsoft, sorunu bildirmek için Dallas yakınlarındaki bir destek merkezini arayan bir müşterinin bilgisayarını satın aldı.
Childs, “Ve o bilgisayarı alır almaz, içinde bir rootkit kurulu olduğunu gördük,” diyor.
bu Alureon rootkit, Windows Çekirdeği ikili dosyalarında, sistemlerin kararsız olmasına neden olan değişiklikler yaptı. Şirket yamayı yeniden yayınladı ve sorunu düzeltti.
“Asıl komik kısım, rootkit’i yapanların bunu bizden daha hızlı anlaması ve 48 saat içinde yamadan kaçınmak için rootkit’lerini güncellemesiydi. [of the release],” diyor Childs. “Düzeltmek bir haftamızı aldı!”
Ve Yama Salı tarihinin tek tuhaf bölümü değildi. Örneğin Childs, bir Internet Explorer yamasının Güney Kore’de çevrimiçi bankacılığı çökerttiğini, bir Windows Media Player yamasının ise tüm ülkeyi iki kez bozduğunu hatırlıyor.
“Nedense Danimarka’daki sistemlerde mavi ekran verdi” diyor. “Dolayısıyla o yamayı geri çağırıp düzeltmemiz ve yeniden yayınlamamız gerekti. Ardından, hemen sonraki ay, aynı şey tekrar oldu. Danimarka’daki sistemlerde neyin spesifik olduğunu bilmiyorum.”
Bugün bile, yalnızca Microsoft tarafından değil, genel olarak yazılım şirketleri tarafından yayınlanan bazı yamalar, bunları yükleyenler için sinir bozucu olabilecek sorunlara neden olabilir. Childs, satıcıların bu düzeltmelerin güvenilirliğini artırması durumunda müşterilerin, başkalarının sorun yaşayıp yaşamadığını görmek için haftalarca veya aylarca beklemek yerine, bunları derhal uygulamaya daha istekli olabileceklerini savunuyor.
Bekleme yaklaşımını benimsemek, sistemlerini bilinen güvenlik açıklarına karşı savunmasız bıraktığı için riskli olabilir. Childs’ın kullanıcılara yamaları mümkün olan en kısa sürede uygulamalarını önermesinin nedeni budur. Ayrıca düşük kaliteli yamalara dikkat çekmelerini söyler.
Childs, “Satıcıları sorumlu tutalım” diyor. “İyi yamalar ürettiklerinden emin olalım.”
Microsoft’ta CISO yardımcısı Aanchal Gupta, şirketin yamalar için “kapsamlı testler” yaptığını söylüyor.
“Müşterilerimize herhangi bir yama yayınlamadan önce, yalnızca Microsoft içinde değil, titiz testlerden geçiyoruz. … [W]Ayrıca bir dizi beta testçimiz ve harici şirketlerimiz var ve yamaları halka açıklanmadan erkenden alıyorlar” diyor ve ekliyor: “Çevrelerinde benzersiz bir şey olup olmadığını test edip bize bildirebiliyorlar bu da yamanın çalışmamasına neden olabilir.”
Bugün Salı Yaması
Salı Yaması, hoparlörlerden Klingon müziğinin yükseldiği o ilk günlerden bu yana çok yol kat etti. Zamanla sürümler daha sessiz ve hatta otomatik hale geldi ve bazı kullanıcılar için görünmez hale geldi.
Geçtiğimiz on yılda Microsoft, süreci kolaylaştırmak için birkaç değişiklik yaptı. Örneğin, 2010’ların ortalarında, toplu güncellemeleri duyurdu, böylece örneğin beş yamayı kaçıran bir müşterinin, diğer yamalar dahil olduğu için yalnızca sonuncusunu uygulaması gerekiyordu. Şirket ayrıca makine tarafından okunabilen Güvenlik Güncelleme Kılavuzları’nı piyasaya sürdü; bu, büyük filo dağıtımlarına sahip kuruluşların otomasyona güvenebileceği anlamına geliyordu.
Ancak her değişiklik topluluk tarafından memnuniyetle karşılanmadı. Microsoft, güvenlik bültenlerini kaldırmaya ve bunları Güvenlik Güncelleştirmesi Kılavuzlarıyla değiştirmeye karar verdiğinde, müşteriler aldıkları bilgilerin daha az sezgisel olduğundan şikayet ettiler. 2020 sonbaharında teknoloji devi, güvenlik açıkları hakkında ayrıntılı bilgiler içeren yönetici özetlerini kaldırdığında benzer bir şey oldu. Bir kez daha sektördeki birçok kişi, karar verme süreçlerini zorlaştıran yeterli bilgi almadıklarını savundu.
Güvenlik araştırmacısı Claire Tills, bunun Microsoft’un aldığı “muhtemelen en yıkıcı” karar olduğunu söylüyor. “Bazı defans oyuncularının da bununla gerçekten sorun yaşadığını biliyorum.”
Daha yakın bir tarihte, 2022’de Microsoft, Windows Enterprise E3 ve E5 lisanslarına sahip müşteriler için güvenlik açıklarını ele alma sürecini kolaylaştırmayı vaat eden Autopatch’i duyurarak Salı Yamasını düzenli bir Salı yapma yolunda bir adım daha attı. Hareket, kuruluşların Microsoft’un yalanladığı bir söylentiye göre, bildiğimiz şekliyle Salı Yaması’nın ortadan kalkıp kalkmayacağını merak etmesine neden oldu.
Salı Yaması etrafındaki tanıtım gittikçe küçülüyor ve Yama Salı güvenlik açıklarının sayısı zirve yapmış olabilir. Özellikle “agresif bir yıl” olan 2020’de Tills 1.200 civarında sayarken, 2022’de 663 gördü.
“Güvenlik açığı türleri açısından, sürekli olarak ayrıcalık yükseltme ve uzaktan kod yürütme” diyor. “Arada bir, bilgi ifşalarında ve güvenlik özelliği bypass’ında zirveye ulaşacağız – bu ikisi de ortaya çıkıyor.”
Ancak, yamaları uygulama sürecini kolaylaştırmayı amaçlayan özelliklere rağmen, bu görev, özel bir teknik destek ekibini karşılayamayan küçük işletmeler için göz korkutucu olabilir. Gupta’nın bu istemcilere buluta geçmelerini önermesinin nedeni budur.
“O zaman tamamen işinize odaklanabilirsiniz ve sistemlere yama uygulama ve yönetme konusunda endişelenmenize gerek kalmaz” diyor. “Ayrıca insanları varsayılan yükseltmeleri devre dışı bırakmamaya teşvik ediyorum.”
Ancak, süreçleri otomatikleştirmeye doğru geçiş yaparken, güncellemeler için bir gün ayırmak artık geçerliliğini yitiriyor mu?
Salı Yaması Eski mi Oluyor?
Yirmi yıldır endüstrinin ayrılmaz bir parçası olan Salı Yaması olmadan bir siber güvenlik dünyasını anlamak zor. Bununla birlikte, tehditler daha karmaşık hale geldikçe ve jeopolitik daha değişken hale geldikçe, geleneksel Yama Salı modeli artık sistemleri güvende tutmak için yeterli olmayabilir.
Bu rekabetçi alanlar gibi karmaşık ortamlarda faaliyet gösteren veya Ukrayna gibi sıcak bölgelerde bulunan kuruluşlar, yama yönetimi söz konusu olduğunda hata yapmayı göze alamazlar. Rusya ile devam eden savaş sırasında birkaç kuruluşu koruyan siber güvenlik girişimi UnderDefense’in kurucusu ve CEO’su Nazar Tymoshyk, tehdit aktörlerinin genellikle “belirli bireyler veya kuruluşlar yerine teknik güvenlik açıklarını hedeflediğini” söylüyor.
“Teknoloji yığınlarındaki ya da güncel olmayan Web kaynaklarındaki yamalı güvenlik açıklarının kötüye kullanımı, hala %50’sini oluşturuyor. [Russia’s] Siber istihbarat operasyonlarında başarı” dedi.
Tymoshyk, Salı Yaması’nın hala gerekli olduğuna ve emekli edilmemesi gerektiğine inanıyor. Ancak kuruluşlar, altyapılarının boyutuna ve karmaşıklığına ya da kullandıkları yazılım ve sistem türlerine bağlı olarak ek yama rutinleri benimseyerek bunun üzerine inşa etmelidir.
Tenable’da kıdemli personel araştırma mühendisi olan Satnam Narang da, rutinler kuruluşların güvenlik odaklı bir kültür geliştirmesine yardımcı olabileceğinden, Yama Salı’nın canlı tutulmasından yana.
“Her hafta insanlar sokağımızdaki çöpleri almaya geliyor ve bunun her hafta belirli bir günde olduğunu biliyoruz” diyor. “Salı Yaması’nın değerli bir kaynak olmasının nedeni, her ay belirli bir günde gerçekleşmesi ve bu nedenle kuruluşların bu güvenlik açıklarını yamalamak için gereken zamanı ayırmasına olanak sağlamasıdır.”
Narang, kaotik bir yama sistemi çalışmayabilir, çünkü güvenlik ekipleri zaten bunalmış durumda. Votiro’nun CTO’su ve kurucusu Aviv Grafi de aynı fikirde. Grafi, “Zaman çok önemlidir ve güvenlik ekiplerine günlerini geri almaları için daha fazla zaman kazandıran teknolojilerden ve yazılımlardan yararlanmaya odaklanmamız gerekiyor” diyor.
Güvenlik araştırmacıları, sürekli yama döngülerinin ve otomatik güncellemelerin bazı durumlarda kurumsal düzeyde her zaman mümkün olmayabileceğini de ekliyor. Nucleus’ta çözüm mimarı olan David Farquhar, “Bir sorun olması durumunda, büyük kuruluşların sistemleri bilinen bir duruma geri döndürebilmeleri gerekir ve bu da planlama gerektirir” diyor.
Salı Yaması, birçok kuruluşun rutinlerinde çok önemli bir unsurdur, ancak buna rağmen tahmin edilemez olabilir. Geçmiş yıllar, yapısının önceden uyarı yapılmadan değişebileceğini göstermiştir. Tills, “Yama Salı çok temel ve çok sağlam gelse de, bir şapka damlasında değişebilir,” diyor. “Salı Yaması’nın sonu birçok kuruluş için felaket gibi gelebilir.”
Ancak şimdilik, Microsoft’un programı çalışır durumda tutacağı görülüyor. Gupta, “Salı Yaması’nın yakında ortadan kalkması konusunda endişelenmem,” diyor.