CVE’ler Neden Bir Teşvik Sorunudur?


YORUM

Yirmi yıl önce, ekonomist Steven Levitt ve New York Times muhabiri Stephen Dubner şunları yayınladılar: ucube ekonomi, Ekonomik ilkeleri çeşitli sosyal olaylara uygulayan. Temelde, insanların nasıl karar verdiklerini anlamak için hangi teşviklere yanıt verdiklerini dikkate almanın çok önemli olduğunu savundular. Çeşitli sosyolojik örnekler aracılığıyla, teşviklerin çoğu zaman nasıl öngörülemeyen sonuçlara yol açabileceğini, çoğu durumda asıl amaca aykırı olduğunu gösteriyorlar.

Siber güvenlik alanında hepimizin karşı karşıya kaldığı büyüyen bir sorun bağlamında bu istenmeyen sonuçlardan bazılarını düşünüyordum: Yaygın güvenlik açıkları ve maruz kalmalar (CVE’ler) olarak takip edilen yazılım güvenlik açıklarının hızla artan bir dalgası nasıl raporlanıyor ve korunuyor. Geçen yıl bir gördüm 28.902 yayınlanmış CVE rekoru – veya her gün yayınlanan neredeyse 80 güvenlik açığı – 2022’ye göre %15’lik bir artışı temsil ediyor. Bu yazılım kusurlarından bazıları gerçek bir maliyeti temsil ediyor; güvenlik kuruluşlarının üçte ikisi ortalama bir maliyet bildiriyor 100.000’den fazla güvenlik açığından oluşan birikimve bu aşırı yoğunluk nedeniyle bunların yarısından daha azına yama yapabildiklerini tahmin ediyoruz. Yayınlanan CVE’lerdeki artış yalnızca bir ölçümdür; çünkü tüm güvenlik açıkları bir CVE almaz ve kararlar yazılım satıcısına bırakılır. Bazı durumlarda yazılımdaki bir güvenlik açığı giderilir ve CVE düzenlenmez.

Bu rakamlara bakıldığında, çok sayıda güvenlik açığının, günümüzde yazılım güvenliğinin durumuyla ilgili ciddi bir soruna işaret ettiği düşünülebilir. Ancak rakamların kendisi hikayenin tamamını anlatmıyor. CVE’lerin artan sayısı iki faktörden kaynaklanmaktadır: Güvenlik açıklarını keşfetme konusunda daha iyiye gittik ve CVE’lerin oluşturulmasını ve takip mekanizmalarını yöneten yeterli güvenlik önlemi bulunmuyor. Özellikle teşvik yapısı DSÖ Rapor edilen güvenlik açıklarını doğru veya yanlış bir şekilde belirleme ve önem derecesini belirleme amacına yönelik olup olmadığı da dikkate alınmalıdır. Dolayısıyla şu soruyu sormakta fayda var: Siber güvenlik ekosistemindeki teşvik yapısı, güvenlik açıklarının raporlanmasını ve ele alınmasını ne şekilde etkiliyor?

Yanlış Hizalanmış Teşvikler

CVE’lerin atandığı ve puanlandığı sistem yaygın olarak kullanılıp kabul edilse de, bazı sorunları da yok değil. 1999 yılında MITRE tarafından kurulan CVE sistemi, yazılım güvenlik açıklarının tanımlanması ve kataloglanması için standartlaştırılmış bir yöntem sunarak güvenlik sektörü için güvenilir bir takas merkezi olarak hizmet vermektedir. CVE’ler, ticari ve açık kaynaklı yazılımlarda bulunan güvenlik zayıflıkları için benzersiz tanımlayıcılar sağlayarak, kuruluşların ve yazılım satıcılarının güvenlik açıklarını etkili bir şekilde önceliklendirmesine ve azaltmasına olanak tanır ve böylece tehdit aktörlerinin bu kusurlardan yararlanma fırsatını azaltır.

Bununla birlikte, CVE’lerin atanması ve puanlanmasının ardındaki teşvik mekanizmaları, bu sistemin etkinliğini zayıflatabilecek önemli zorluklardan da yoksun değildir. Bu zorluklardan bazıları şunlardır:

  • İtibar için oyun: Siber güvenlik topluluğu içindeki itibar veya “nüfuz” arayışı, bazı güvenlik araştırmacılarının CVE sistemiyle oynamasına yol açtı. Tanınma veya profesyonel ilerleme arzusundan kaynaklanan güvenlik açıklarını keşfetme ve bildirme motivasyonu, bazen gönderimlerin niteliğinden ziyade niceliğine odaklanılmasıyla sonuçlanır; bu da sistemi karmaşıklaştıran ve dikkati daha fazla bilgiden uzaklaştıran önemsiz veya kritik olmayan sorunların raporlanmasına yol açabilir. ciddi güvenlik açıkları.

  • Sorumsuzluk: CVE’leri anonim olarak veya güvenlik açığı iddiasını destekleyen minimum kanıtla dosyalama yeteneği, sorunlu olabilecek bir şeffaflık katmanı ortaya çıkarır. Anonimlik araştırmacıları koruyabilirken aynı zamanda hatalı, abartılı ve hatta kötü niyetli olarak yanıltma veya zarar verme niyetinde olabilecek başvurulara da kapı açar. Bu sorumluluk eksikliği, CVE veri tabanının bütünlüğünü tehdit eder ve sisteme olan güveni sürdürmek için sıkı doğrulama süreçlerini gerektirir.

  • Yanlış metriğin ölçülmesi: Güvenlik açıklarının ciddiyetini gösteren sayısal bir puan sağlayan Ortak Güvenlik Açığı Puanlama Sistemi (CVSS), gerçek riskle korelasyon eksikliği Gerçek dünya ortamlarındaki güvenlik açıklarından kaynaklanır. Çünkü CVSS puanı Belirli bir bağlamda bir güvenlik açığının sömürülebilirliğini veya etkisini her zaman doğru bir şekilde yansıtmasa da, yüksek puanlı güvenlik açıklarının gereğinden fazla ilgi görebileceği ve belirli ortamlardaki daha kritik, sömürülebilir kusurların sıklıkla önceliklendirilmediği durumları giderek daha fazla görüyoruz.

Sorunun kapsamını tam olarak anlamak için şunu düşünün: bu son gönderi güvenlik araştırmacısı Dan Lorenc, şaşırtıcı bir şekilde 138 CVE’nin yayınlandığı tek bir günü özetliyor; bunlardan ikisine 9,8 ciddiyet puanı verildi ve bu da onları kritik öncelik olarak işaretledi. Ancak daha yakından incelendiğinde, kritik güvenlik açığı olarak adlandırılan bu güvenlik açığının aslında bir güvenlik açığı olmadığı ortaya çıkıyor. Aynı gün diğer 136 CVE’ye de girilmedi; bunların tümü, proje geliştiricileriyle iletişim kurulmadan sunuldu; onlar da bunu hemen onaylayacaklardı. Lorenc’in belirttiği gibi“1000 $’ına bahse girerim ki bu kişi, bunun gibi şeyler için eski taahhüt mesajlarını grep etme ve CVE’leri otomatik olarak dosyalama üzerine bir komut dosyası çalıştıran biridir.”

Peki daha fazla güvenlik açığı olduğu için mi daha fazla sayıda CVE görüyoruz? Yoksa bu sorunları keşfetmenin ve bildirmenin ödülleri ve takdirleri daha belirgin hale geldiği için mi?

CVE Raporlamasının Teşvik Yapısının Düzeltilmesi

Tıpkı bir politika yapıcının belirli teşvikler yaratarak veya kaldırarak vatandaş davranışını dürtükleyebilmesi gibi, biz de CVE raporlamasının teşvik yapısını, zayıf noktaların az çabayla rapor edilmesini engellemek için gözden geçirmeyi düşünmeliyiz. Doğru dengeyi kurmak için teşvik kollarını kullanabileceğimiz aşağıdaki yollardan bazılarını düşünün:

  • Miktardan ziyade kaliteyi ödüllendirin: Bildirilen güvenlik açıklarının yalnızca miktarına değil kalitesine ve etkisine de dayalı olarak ödüllerin uygulanması, araştırmacıları belirli bir ortamda tehdit oluşturan istismarlara odaklanmaya teşvik edecektir. Daha yüksek kaliteli gönderimlere odaklanan bir ödül sistemi, araştırmacıları potansiyel olarak geniş bir kullanıcı tabanını etkileyebilecek veya yaygın kesintilere ve veri ihlallerine neden olabilecek güvenlik açıklarına öncelik verme konusunda daha iyi motive edebilir.

  • Doğrulama ve hesap verebilirlik önlemlerini geliştirin: Çok az kanıt içeren isimsiz başvurular sorununu çözmek için kademeli bir doğrulama süreci oluşturulabilir. Bu süreç, araştırmacıların kimliğini korurken, bir CVE atanmadan önce bir güvenlik açığının varlığına ve potansiyel etkisine ilişkin daha kapsamlı kanıt gerektirecektir. Böyle bir önlem, hatalı veya yanıltıcı başvuru riskinin azaltılmasına yardımcı olacaktır.

  • Gerçek dünya riskini yansıtacak şekilde CVSS’yi yeniden tanımlayın: CVSS’nin gerçek dünyadaki riskleri ve güvenlik açıklarının istismar edilebilirliğini daha iyi yansıtacak şekilde yenilenmesi, belirlenen puanların önceliklendirme için daha doğru rehberlik sağlamasına yardımcı olacaktır. Girişimleri veya başarılı kullanımları deneyimlemiş kuruluşlardan gelen geri bildirim döngülerini dahil etmek, puanlama ölçümlerini iyileştirmenin böyle bir yolu olabilir. CISA KEV (Bilinen İstismar Edilen Güvenlik Açıkları) listesi bu yönde büyük bir adım olsa da, tüm güvenlik açıklarını temsil etmeyebilir. vahşi doğada istismar edilen güvenlik açıkları.

Teşvikler şüphesiz bireyleri ve kuruluşları güvenlik açıklarını bulmaya ve açıklamaya zaman ve kaynak ayırmaya motive etmede önemli bir rol oynamaktadır. Ancak, CVE raporlamasının mevcut durumunu rahatsız eden birçok konuyu doğru bir şekilde ele almak için teşviklerin insan davranışını şekillendirmede oynadığı önemli rolü yeniden düşünmemiz gerektiği açıkça ortaya çıktı. Bunu yapana kadar, CVE’ler için rekorların kırıldığı bir yıl daha görmeyi bekliyoruz.





Source link