YORUM
Geçen ay, CVE (Ortak Güvenlik Açıkları ve Etkilenmeler) programının 25. yılı kutlandı. Eylül 1999’da piyasaya sürüldü. CVE’lerin olmadığı bir dünyayı hayal etmek zor. CVE programı popüler hale gelmeden önce “güvenlik açığı yönetimi” faaliyetlerinin çoğu, uzaktan taramalardan elde edilen sürüm numaralarının eşleştirilmesine ve bulguları doğrulamak için İnternet’in karanlık yerlerinde bulunan şüpheli istismarların yürütülmesine dayanıyordu. Güvenlik açığı takibi konusunda uzun bir yol kat ettik. Ancak yolculuğumuz tehlikelerle dolu ve hâlâ üstesinden gelmemiz gereken birçok zorluk var:
Hacim: Her yıl oluşturulan çok sayıda CVE’ye ayak uydurmak için numaralandırma formatını artırmak ve CNA’ları (CVE Numaralandırma Yetkilisi) atamak zorunda kaldık, bu da sorumluluğu dağıttı ve tutarlı olmayı zorlaştırdı.
Tarih takibi: Belirli durumlarda, CVE’ler cari yılda verilecektir ancak atamada bir önceki yıl bulunacaktır. Bazen bunun nedeni, CNA’ların gelecekte kullanılmak üzere önceden atanmış CVE’ler olmasıdır. Ancak bu, CVE veritabanındaki güvenlik açıklarının yıllara göre izlenmesini ve analiz edilmesini hatalı hale getirebilir. Bu nadir fakat sorunlu bir durumdur çünkü güvenlik uygulayıcılarının bunun daha eski bir güvenlik açığı olduğuna inanmasına neden olur ve bazıları buna dikkat etmeyebilir.
Serbest piyasa: Bazı kurallar ve engeller olsa da çoğunlukla herkes CVE alabilir. İnsanların bir güvenlik açığını gizlemeye çalışmasını önlemek için CVE’lerin oluşturulmasını sınırlamamamız önemli olsa da, serbest piyasa konsepti sorunlara neden oldu. GitHub depolarında önceden düzeltilen hatalara dayanarak yüzlerce CVE oluşturma sürecini otomatikleştiren kişilerin yakın zamanda raporları var.
Güvenlik açıklarına yönelik resmi izlemenin oluşturulması sektör için çok büyük bir öneme sahip olsa da, 2005 yılına kadar bir önem derecesi atamaya başlamamıştık. CVSS. Bu da aşağıdaki gibi zorluklardan muaf değildir:
Subjektif puanlama: Herkes kullanarak bir güvenlik açığı puanlayabilir CVSS ve sonuçları yayınlayın. Kontrol ve dengeye ihtiyacımız var. Hatayı bulan güvenlik araştırmacıları, ciddiyetin yazılımı oluşturan satıcıdan farklı olduğuna inanıyorsa, her iki puanı da görebilmemiz gerekir.
Yalnızca güvenlik açığını yansıtır: Ortamınız için puanı özelleştirmek ve telafi edici kontrolleri dikkate almak için CVSS’yi kullanabilseniz de çoğu kullanıcı yalnızca yayınlananlara göre hareket edecektir. Çoğu zaman güvenlik açıkları, yazılımın sahibi olan CNA tarafından puanlanır ve onun teşvikleri, güvenlik açıklarını yüksek düzeyde puanlamak değildir.
CVSS’nin birden fazla sürümü: CVSS sürüm 1’in 2005 yılında piyasaya sürülmesinden bu yana, Kasım 2023’e kadar birbirini takip eden üç sürüm yayımlandı. Önceki bir sürümle puanlanan bir CVE girişi, en son sürüme güncellenmeyebilir. Güvenlik araştırması ortamındaki değişiklikler veya güvenlik açığıyla ilgili yeni bilgiler nedeniyle CVSS puanlarının da güncellenmesi gerekir. Bu değişikliklerin gerçekleşmesi durumunda takip edilmesi zor olabilir.
Şimdi Ne Yapıyoruz?
Amaçları kuruluşların riske dayalı bilinçli kararlar almasına yardımcı olmak olan bu programların her birinin artıları ve eksileri olduğu göz önüne alındığında, ilk önce neyi yamalamamız gerektiğini nasıl bileceğiz? Birçoğu tek bir mekanizmaya, muhtemelen CVSS’ye güvenecek, sihirli bir sayı seçecek ve bu sihirli sayının üzerinde puan alan her şeyi yamalayacak. Sorun şu ki, bu kırılganlık dünyasına ilişkin çok sınırlı bir bakış açısıdır. Yamalanması gereken her şey yüksek bir CVSS puanına sahip olmayacak, hatta bu konuda düşük bir puana sahip olmayacaktır. MITRE ATT&CK, CISA KEV ve EPSS gibi yukarıdaki çerçevelerden birini veya birkaçını takip etmeyi seçebiliriz. Bunları tek tek takip etmek zor olabilir ve büyük resmin parçalarını kaçırırsınız. Yalnızca CISA KEV’e yama yaptıysanız, güvenlik açıkları ve CVE’lerle ilgilenmeyen seçkin saldırgan tekniklerini kaçırırsınız. Karma bir yaklaşım kötü bir fikir değildir, ancak yalnızca kuruluşunuzun dışındaki rehberliğe güvenmek, Magic 8 Ball’u sallayıp bunu yama yapmak için rehber olarak kullanmaya eşdeğerdir.
Konu yama olduğunda en önemli şey kuruluşunuz üzerindeki etkisidir. En iyi tavsiyem, işinizin en kritik kısımlarını belirlemek, bunları sistemlere ve uygulamalara bağlamak, önce bunlara yama yapmak ve bu sistemlere mümkün olduğunca çok yama yapmaktır.
Çözüm
Çoğu zaman insanların işten çıkarıldığını duyuyorum güvenlik açıkları Bu, “Bugün bu güvenlik açıklarına kimse saldırmıyor”, “Ulus devlet düzeyindeki saldırıların hedefi değilim” ve “Bir saldırganın zaten sistemde olması gerekir” gibi çeşitli nedenlerle yıkıcı olabilir. Akıllı bir saldırgan grubu başarılı olmaya kararlı olduğunda bunların hiçbirinin önemi yoktur. Saldırı yüzeyinizdeki her zayıf noktayı hedef alacaklar: donanım, ürün yazılımı ve yazılım, çıplak donanımdan buluta kadar. İşletim öncesi sistem saldırıları, bir saldırganın temel kart yönetim denetleyicisine (BMC) erişim sağlaması ve sonsuz bir yeniden başlatma döngüsüne neden olması gibi durumlarda, sistemi kalıcı olarak hasar görebilir veya çalışmaz hale getirebilir. Kötü niyetli aktörler, düşük seviyeli ürün yazılımı saldırıları yoluyla donanıma kalıcı zarar verebilir. Saldırganlar, İşletim Sistemi korumalarını atlamak, sistemde kalıcı olmak (bir türlü ortadan kaybolmayan fidye yazılımlarını düşünün) ve saldırganların gizlenmesine izin vermek için Birleşik Genişletilebilir Ürün Yazılımı Arayüzünü (UEFI) kullanabilir. Bu noktada artık her türlü güvenlik açığı istismara açıktır.
Güvenlik açıklarının giderilmesi karmaşık bir süreçtir ve binlerce sisteme bir yamanın mı yoksa binlerce yamanın mı uygulanacağı kararının verilmesinde çeşitli faktörler rol oynar. Bu görev ne kadar karmaşık olursa olsun, geliştirmeye devam etmemiz gereken bir şeydir, aksi takdirde saldırganlar büyük fayda sağlayacaktır. Ah, Magic 8 Ball’u da bırak lütfen.
