Son zamanlarda, siber güvenlik dünyası Ivanti Connect Secure VPN yazılımında keşfedilen bir dizi kritik güvenlik açığıyla sarsıldı. Bu devam eden güvenlik açığı sorunlarının ardından Ivanti, güvenlik açığı ifşalarını ele alış biçimi nedeniyle bilgi güvenliği topluluğunun üyelerinden eleştirilerle de karşı karşıya kaldı. Ivanti, bunları ayrı güvenlik açıkları olarak ifşa etmek yerine birden fazla güvenlik açığını tek bir kayıtlı Ortak Güvenlik Açıkları ve Maruziyetler (CVE) Kimliği altında gruplandırdı. Juniper, dört yerine yalnızca iki güvenlik açığı ifşa ettiği için benzer eleştirilerle karşı karşıya kaldı.
Bu senaryolar, doğru güvenlik açığı ifşasının önemini vurgulamaktadır. Bu makale, tutarsızlıkların güvenlik açığı giderme etkinliğini nasıl etkilediğini inceleyecek ve iyileştirme önerileri sunacaktır.
Güvenlik Açığı Açıklamalarındaki Yanlışlıklar ve Sonraki Riskler
Satıcılar, raporlama süreçlerini basitleştirmek, güvenlik açıklarının kamuya açıklanmasını en aza indirmek veya yazılımlarında çok sayıda bireysel güvenlik açığı olduğu algısını azaltmak gibi çeşitli nedenlerle kayıtlı güvenlik açıklarının sayısını azaltmayı tercih edebilirler.
Ancak, birden fazla güvenlik açığını tek bir kayıtlı CVE altında gruplamak kötü bir stratejidir çünkü kuruluşlar için CVE sorununu çözmek için geliştirme döngüsünde tam olarak hangi güvenlik açığının ele alınması gerektiği belirsizliğini korur. Bu, BT ekipleri arasında iletişim sorunlarına yol açabilir ve yamalanmamış güvenlik açıklarının potansiyel olarak gözden kaçırılmasına neden olabilir. Sonuç olarak, kuruluşlar için azaltma çabalarını karmaşıklaştırır, fark edilmeyen güvenlik açıkları riskini artırır ve satıcıya karşı suçlamalarla sonuçlanır.
Ivanti ve Juniper kamuoyu eleştirileriyle karşı karşıya kalsa da, güvenlik açığı ifşasını yanlış yönetmekten kaynaklanan zararın kritik olmadığını belirtmekte fayda var çünkü güvenlik açıklarını ifşa ettiler. Ancak, Microsoft’u ilgilendiren, belirli bir güvenlik açığının gizlendiği ve tehdit aktörlerinin bunu yıllarca istismar etmesine olanak tanıyan daha eski bir dava var.
Microsoft, Mayıs 2017’de, ilk keşfedildiği 2013 yılında kamuoyuna açıklamadan “EpMo” olarak bilinen güvenlik açığını sessizce düzeltti. Bu açıklama eksikliği, APT31’in (Çin’in Zirconium’una atfedilen) 2014 yılında bu açığı tekrarlayarak “Jian” açığını oluşturmasına ve en az 2015’ten beri kullanmasına olanak sağladı. Açık, Lockheed Martin’in Bilgisayar Olaylarına Müdahale Ekibi tarafından Microsoft’a bildirildi ve bu da Amerikan hedeflerine yönelik olası bir saldırı olduğunu gösteriyordu. Gecikmeli açıklama, APT31’in bu açığı yıllarca istismar etmesini sağladı. Bu örnek, kullanıcıların ve kuruluşların kendilerini olası tehditlere karşı korumak için gerekli önlemleri almasını sağladığı için, satıcılar tarafından güvenlik açıklarının zamanında ve şeffaf bir şekilde açıklanmasının önemini vurgular.
Güvenlik Açığı Yönetimiyle İlgili Diğer Sorunlar
Bazen satıcılar, yazılımlarında güvenlik açıkları tespit ettikten sonra, önceki sürümün herkese açık numarasını koruyarak yükseltmeyi yayınlarlar. Sonuç olarak, bir sistem yöneticisi için yerinde uygulamanın güvenlik açığı olup olmadığı veya yama yapılıp yapılmadığı belirsiz hale gelir. Bu tür durumlar genellikle halk tarafından fark edilmez, ancak bunlar gerçekleşir. Haziran 2023’te, Dell Commander 4.9.0’ın 7,1 NVD puanı ile CVE 2023-28071’e sahip olduğu bulundu. Şirket, dahili olarak A02 olarak işaretlenmiş yeni bir sürüm yayınladı, ancak Programlar ve Özellikler görünümünde görülebilen herkese açık sürüm numarasını değiştirmedi. İyi bir uygulama, güncellenen sürüme yeni bir numara atamak olacaktır.
Güvenlik Açıklarını Açıklamak İçin En İyi Uygulamalar
Yazılım satıcıları güvenlik açıklarını ifşa edip CVE’ler atadıklarında belirli kurallara uymalıdırlar. Öncelikle, CVE kimliklerini atamaktan ve CVE veritabanını sürdürmekten sorumlu olan CVE Numaralandırma Yetkilileri (CNA’lar) ile koordineli çalışmaları gerekir. Bu, güvenlik açığının CVE ataması için kriterleri karşılamasını sağlar.
Güvenlik açıklarını keşfeden kuruluşlar, bunları tedarikçiler, CERT’ler ve güvenlik açığı veri tabanları dahil olmak üzere ilgili taraflara bildirmeli ve tedarikçilerin kamuya açıklanmadan önce yamaları geliştirmeleri için zaman tanımalıdır.
CVE Kimlikleri talep etmek için belirlenen süreci takip etmek, güvenlik açığı hakkında doğru ve ayrıntılı bilgi sağlamayı gerektirdiği için çok önemlidir. Güvenlik açığını ifşa ederken, satıcılar, etkisi, etkilenen sürümler, olası saldırı vektörleri ve bilinen tüm hafifletmeler dahil olmak üzere net bir açıklama sağlamalıdır. Ortak Güvenlik Açığı Puanlama Sistemi (CVSS) puanı atamak, güvenlik açığının ciddiyetini ölçmeye yardımcı olur.
CVE kimliklerinin atanmasında hatalar kaçınılmazdır ve çözüm süreci girdilerin reddedilmesini, birleştirilmesini veya bölünmesini içerir. Kuruluşlar güncelleme kurallarına sıkı sıkıya uymalı, araştırma bir güvenlik açığını çürütürse CVE’leri reddetmeli, kötüye kullanıma neden olan yazım hatalarını düzeltmeli veya bir güvenlik açığı için birden fazla kimliği birleştirmelidir. Seçili CVE kimlikleri diğerlerinden bilgi içerirken, seçilmeyenler reddedilen açıklamalarla güncellenir. Birden fazla gerektiğinde tek bir CVE kimliği atandığında CVE’yi bölerek girdiyi birden fazla CVE girdisine bölün. Bu, farklı güvenlik açıklarının doğru ve ayrıntılı bir şekilde tanımlanmasını sağlamak için yapılır.
Satıcılar ayrıca, yeni yamalar, sürümler veya hafifletmeler ya da CVSS puanında yapılan değişiklikler gibi, geçerli olması durumunda sonraki güncellemeler hakkında da net bilgiler sağlamalıdır.
Sorumlu bir açıklama yapmak, istismar riskini en aza indirmek ve etkilenen kullanıcıların güvenliğini önceliklendirmek esastır. Son olarak, satıcılar güvenlik açığı açıklama uygulamasını yöneten yasalara uyumu sağlamalıdır.
Çözüm
Bana göre, satıcılar tüm ilgili bilgilerle birlikte güvenlik açıklarını ifşa etmekten çekinmemeliler. Müşterilerine karşı şeffaf olmak zorundadırlar. Bu yaklaşım daha güvenli uygulamalar ve daha net yama yönetimi süreçleriyle sonuçlanacaktır.
Yazar Hakkında
Mike Walters, Action1 Corporation’ın Başkanı ve kurucu ortağı – şirketin ürün stratejisini yönetiyor. Daha önce Netwrix Corporation’ın Eş CEO’su ve Kurucu Ortağı olan Michael, pazara giriş stratejisi, satış ve tanıtımdan sorumluydu. Netwrix’te Mike ve Alex çok başarılı bir siber güvenlik şirketi kurdular ve ardından ikisi de yeni bir CEO’ya geçtikten sonra Netwrix’ten ayrıldılar. Görünürlüğü ve kullanıcı davranışı analitiği platformuyla tanınan Netwrix, dünya çapında 10.000’den fazla müşterisiyle lider oldu. Mike, Laguna Beach, CA’da yaşıyor ve üç çocuğu var. Çevre korumayı önemseyen hevesli bir sörfçü ve hayırsever.
Mike’a şirketimizin web sitesi https://www.action1.com/team/ üzerinden online olarak ulaşılabilir.