Zafiyet puanlama sistemi CVSS 4.0’ın en yeni versiyonu karşınızda! Sürüm 3 (2015’te piyasaya sürüldü) arasındaki uzun bir aradan sonra, Kasım 2023 itibarıyla sürüm 4.0 resmi olarak yayında. Versiyon 3’ü tekrar tekrar temel alarak, teorik olarak güvenlik açıklarını puanlama, algılama ve kategorilere ayırma şeklimizi geliştirecek birkaç farklılık vardır.
Sürüm 3.0’da sorun neydi?
Sürüm 3.0 ve genel olarak CVSS, bir güvenlik açığının “etkisini” ölçmede oldukça iyi olmasına rağmen, “istismar edilebilirliğini” puanlamada pek iyi değildi. Yararlanabilirlik, son kullanıcılarla etkileşimler, tehdit aktörünün beceri seti ve yetenekleri ve söz konusu sistemin kurulumu gibi unsurlar dikkate alındıktan sonra bir güvenlik açığından yararlanma olasılığını ifade eder.
CVSS 3.0’a yönelik diğer eleştiriler de aynı derecede geçerliydi. Siber tehditlere odaklanılması nedeniyle, fiziksel güvenlik riskleri CVSS çerçevesine ya da çeşitli teknoloji yığınlarına veya tedarik zincirlerine sahip karmaşık birbirine bağlı sistemlere pek uymuyordu.
Buna ek olarak, CVSS’ye entegre edilen parametrelerin çoğu her zaman subjektif olarak yorumlanmıştır (farklı analistler farklı puanlar verirler) ve CVSS’nin neden değişim için haykırdığı açıktır.
Ne değişti?
Saldırı karmaşıklığı – sürüm 3.0’da, saldırı karmaşıklığı parametresi ikiliydi ve iki seçeneğe ayarlıydı: yüksek veya düşük – arada bir şey yok – ve tamamen öznel yoruma açıktı.
Sürüm 4.0’da bu iki parametreye ayrılmıştır: saldırı karmaşıklığı ve saldırı gereksinimleri.
Saldırı karmaşıklığı parametresi ne yazık ki değişmemiş olsa da, saldırı gereksinimleri, saldırının başarılı olması için mevcut olması gereken önkoşul dağıtım ve yürütme koşullarını ortaya koymaktadır; örneğin: bir web sunucusunun belirli bir yapılandırma ayarı, belirli bir kod bağımlılığının varlığı , vesaire.
Bu, saldırının başarılı olması için aşılması gereken güvenlik kontrolleriyle (örneğin, arabellek taşmaları için ASLR, WAF’ler vb.) ilgili olan saldırı karmaşıklığından farklıdır.
Bu hoş bir değişiklik çünkü saldırının hem defans hem de hücum tarafı açısından başarılı olması için gerekliliklere daha fazla derinlik kazandırıyor.
Kullanıcı etkileşimi – Sürüm 3.0’da bu da ikili koşuldu: evet veya hayır. Her türlü kullanıcı etkileşimini içeren saldırılar için bu durum, saldırının başarılı olması için neyin gerekli olduğunu yanlış temsil ediyordu. Örneğin, bir kullanıcının kendisini kötü amaçlı bir siteyi ziyaret etmeye zorlayacak bir URL içeren kimlik avı e-postası alması tekil bir eylemdir, ancak kullanıcının bir eki indirip ardından açması gereken bir eylem birden fazla eylemdir; ancak her ikisine de aynı şekilde davranılır. 3.0 sürümünde.
Sürüm 4.0’da bu üç parametreye ayrılmıştır: yok, pasif ve aktif. Pasif, kullanıcının güvenlik mekanizmalarını aktif olarak bozmasını gerektirmeyen etkileşimleri ifade eder; örneğin, depolanmış bir siteler arası komut dosyası (XSS) içeren bir web sitesini ziyaret eden bir kullanıcı, pasif bir etkileşimdir.
Etkin, ilgili açılır pencereler ve istemlerle birlikte bir dosyayı iş istasyonuna yerleştirirken veya indirirken yaşanabilecekler gibi, kullanıcının açılır pencere istemlerini kapatma/bu istemlerle etkileşimde bulunma etkileşimini içerir. Sürüm 3.0 “ya hep ya hiç” yaklaşımına sahip olduğundan bu hoş bir eklentidir: Bir kullanıcının 4 veya 5 kez etkileşimde bulunmasını talep ettiyseniz, bu, bir kullanıcının bir URL’ye tek bir tıklama yapmasıyla aynı şekilde ele alınırdı.
Puanlamayı kolaylaştırmak için diğer parametrelerde ve ifadelerde başka küçük değişiklikler de var, ancak bunlar birincil olanlardır.
CVSS 4.0 pratikte
CVSS 4.0’ın herhangi bir şeyi değiştirip değiştirmediğini görmek için birkaç örneği inceleyelim.
CVSS3 kapsamında, yeni bir Avo (açık kaynak Ruby on Rails yönetici paneli oluşturma çerçevesi) XSS güvenlik açığı (CVE-2023-34103) 5,4 (orta) puan alıyor. Sürüm 4.0 bunu 4.8’e düşürüyor; hafif bir düşüş ama yine de orta seviyede, esas olarak kullanıcı etkileşimi parametresine bağlı.
Uzaktan kod yürütmeye (RCE) yol açan bir kusur gibi daha ciddi bir şeye ne dersiniz?
Atlassian’ın Asset Discovery aracısındaki bir RCE olan CVE-2023-22523, CVSS3 kapsamında 8,8 (Yüksek) puan alır. Bu güvenlik açığı belirli bir yapılandırma/aracı kurulumu gerektirdiğinden, sürüm 4.0’da bu 7.8’e (Yüksek) düşer.
Her ikisinde de bunlar uzak ağ tabanlı senaryolardır. Palo Alto’daki CVE-2023-3282 ayrıcalık yükseltme güvenlik açığı gibi yerel erişim gerektiren bir şeyi aldıysanız, puanlar daha büyük ölçüde farklılık gösterir.
Bunun nedeni, bu güvenlik açığının belirli yerel koşulların mevcut olmasını gerektirmesidir (daha önce sürüm 3.0 kapsamında dikkate alınmamıştı), ayrıca sistemin kendisi üzerinde doğrudan etki yerine daha fazla ayrıcalık ve müteakip sistem etkileri. Sürüm 3.0’da 6,7’lik bir puanla bu, CVSS4’te 4,9’a değişiyor; bu, eldeki sorunu daha iyi temsil eden büyük bir düşüş.
Kapanıyor
Genel olarak, CVSS’nin işletmelerin güvenlik açıklarını bir bakışta değerlendirmesine yardımcı olması ve böylece düzeltmeleri etkili bir şekilde önceliklendirebilmesi gerekiyor. Yeni sistemin bazı kayda değer iyileştirmeleri var ve muhtemelen yeterince ileri gitmediğine inanıyorum, ancak şirketlerin hangi güvenlik açıklarının kendilerine zarar verebileceğini ve hangilerini başka bir zamana bırakabileceklerini bilmeleri için sömürülebilirliğin daha iyi bir temsilini sağlıyor.
Geriye kalan tek soru, bugün kullandığımız araçlarda bundan faydalanabilmemiz için bu yeni puanlama sisteminin güvenlik satıcıları tarafından ne kadar hızlı uygulanacağıdır.