Modern dünyada güvenlik açığı yönetiminin amacı göz önüne alındığında, yeni teknolojilere olan büyük geçişi ve bu farklı paradigmalar ve ortamlar (örneğin bulut) dahilinde riski nasıl yönettiğinizi anlamak zorunludur. Yama ağı güvenliği, bulut ortamları için aynı şekilde geçerli değildir ve çok az bulut sağlayıcısı, güvenlik açıklarına Ortak Güvenlik Açıkları ve Etkilenme (CVE) tanımlayıcıları atar.
Yalnızca bu CVE tabanlı yapı üzerinden konuşan güvenlik açığı yönetimi ekipleri için bulut hizmetlerinde CVE’lerin bulunmaması önemli bir zorluktur. Buluta özgü güvenlik açıkları her hafta haberlerde yer alırken, bulut hizmeti sağlayıcılarının CVE tanımlayıcılarını (veya buna benzer bir şeyi) kullanması gerekip gerekmediği sorusu her zamankinden daha alakalı.
Bulut hizmetleri risk ve güvenlik açığı yönetiminin rolünü nasıl etkiler?
Bu tartışmanın neden yapılması gerektiğini anlamak için bulut hizmetlerinin güvenlik açığı yöneticilerinin rolünü nasıl değiştirdiğini düşünün. Geleneksel bir ağda, güvenlik açığı analisti altyapıya yama uygulanmasından sorumludur. Ancak bulut hizmetiyle kuruluş altyapıyı yönetmediğinden yama yönetimi bulut hizmeti sağlayıcısına devredilir. Bu, güvenlik açığı ekibinin sorumluluğunun yama yönetiminden konfigürasyon yönetimine geçtiği anlamına geliyor.
Konfigürasyon yönetimi, bir organizasyonun kontrol edilebilir risklerinin büyük kısmının yattığı yerdir. Açıkçası bulutta hala çok fazla risk var, ancak güvenlik açığı yönetimi ekibi artık bunu kontrol etmiyor. Bunun elbette bazı artıları ve eksileri var. Bunun avantajı, bulut sağlayıcısının güvenlik riskinin büyük kısmını ve güvenlik açıklarını düzeltme çalışmasını üstlenmesidir. Öte yandan, güvenlik açığı yöneticileri kendilerini, kuruluşlarının altyapısının güvenliği üzerinde çok az kontrole sahip oldukları veya hiç kontrollerinin olmadığı yeni bir bölgede buluyorlar.
Yapılandırma yönetiminin önemini ve bulut hizmetleri için bir CVE tanımlayıcısının haklı olup olmadığını gösteren kötü şöhretli örneklerden biri MongoDB’nin varsayılan parola yapılandırma sorunlarıdır. Buradaki soru, varsayılan konfigürasyonun bir CVE tanımlayıcısına sahip olup olmaması gerektiğidir? Eğer bu bağımsız bir yazılımda gerçekleşmiş olsaydı, büyük olasılıkla bir CVE’ye sahip olurdu. Ve bu yanlış yapılandırma yüz binlerce sunucuyu etkiledi.
İşte bu tartışmadaki diğer önemli nokta da şu: Bulut pek çok farklı yerde oldukça kopyalanabilir. Bir Terraform dağıtım yapılandırması tek bir bulut ortamında bozulursa büyük olasılıkla bir kuruluşun tüm bulut ortamında çoğaltılacaktır. Bunun anlamı açıktır; buluttaki güvenlik açıkları büyük ölçekte güvenlik sorunlarına yol açabilir.
CVE eksikliği güvenlik açığı yönetimini nasıl etkiler?
İlginç bir şekilde, bulut sağlayıcıları CVE kimliklerini atayabiliyor ancak çoğu bunu yapmıyor, bu da güvenlik açığı analistlerini zor durumda bırakıyor. CVE’ler, potansiyel risklerin belirlenmesi ve belirli güvenlik açıklarının giderildiğinden emin olmak için izlenebilmesi ve analiz edilebilmesi açısından büyük fayda sağlar.
Ortak bir tanımlayıcı olmadan, güvenlik açığı analistleri, aşağıdakiler gibi belirsiz uyarılara dayalı yanlış yapılandırmaların izini sürmek gibi çoğunlukla karmaşık ve sinir bozucu bir görevle uğraşmak zorundadır: yanlış yapılandırılmış S3 klasörüve sürekli değişen isimler (büyük ölçüde yanlış yapılandırılmış S3 klasörü). Bu sürecin sonuca varması haftalar hatta aylar alabilir; ya iyileştirme ya da riskin kabul edilmesi.
CVE ne alır?
Bu tartışmanın nüanslarından biri, geleneksel anlamda bir kırılganlığın ne olduğudur? Peki CVE ne alır? İmza anahtarının Çinli bilgisayar korsanları tarafından çalındığı ve kötüye kullanıldığı Microsoft olayını düşünün. Anahtarın çalınmasına neden olan saldırı bir CVE olmasa da, hatalı anahtar doğrulaması kesinlikle bir CVE tanımlayıcısını hak eden bir güvenlik açığı gibi görünüyor. En azından güvenlik açığı analistlerinin risklerini anlamalarına yardımcı olacaktır.
Belki de bulut hizmetlerinde bir CVE tanımlamanın anahtarı budur: Bir CVE tanımlayıcısı, güvenlik analistlerinin kuruluşları riskleri hakkında bilgilendirebilecek veya eğitebilecek ve/veya bu riski azaltmak için harekete geçebilecek eylemlerde bulunmasına yardımcı olacak mı? Evetse, bir CVE tanımlayıcısı alır.
CVE değilse ne?
CVE’nin asıl amacı, benzersiz güvenlik açıklarını doğru bir şekilde tanımlamanın ve bilgileri sektör genelinde hızlı bir şekilde iletmenin bir yolunu sağlamaktır. Ancak bulut güvenlik açıkları söz konusu olduğunda benzersiz bir tanımlama sistemi yoktur ve sektördeki yaygın yanlış yapılandırmalar hakkında konuşulacak çok az yer vardır.
Kuruluşlar, bulut güvenliği için bir dizi standart geliştiren İnternet Güvenliği Merkezi (CIS) gibi uyumluluk çerçevelerini kıyaslamaya bakıyor. Ayrıca, NIST 800-171 ve 800-53 gibi hükümet tarafından geliştirilen standartlar da vardır, ancak bunlar geniş çerçevelerdir ve bu ihtiyaca yönelik değildir.
Ayrıca, bulut kaynaklarındaki yanlış yapılandırmaların tespitini ve düzeltilmesini otomatikleştiren Bulut Güvenliği Duruş Yönetimi (CSPM) satıcılarına da bakabiliriz. Hepsi kendi tanımlama standartlarını geliştirdiler. Ancak bir kuruluş çoklu bulut stratejisini benimsemişse ve birden fazla CSPM aracı kullanıyorsa bunları bir arada birleştirmenin yolu yoktur.
Peki bu bizi nereye bırakıyor? Sektör olarak, buluttaki yanlış yapılandırmalardan daha tanımlı ve eyleme geçirilebilir bir şekilde bahsedebilmemiz için benzersiz bir tanımlayıcıya sahip olmamız gerekiyor gibi görünüyor. Belki de bulut için CVE’dir. Buna ortak bulut güvenlik açığı numaralandırması (CCVE) veya benzer bir şey diyebiliriz.
Bu sürümde bir analistin “Mongo DB’de varsayılan şifre” gibi belirsiz bir uyarı yerine “CCVE 1-1.2” uyarısı alabileceğini ve bunun “Amazon S3 klasörlerinde varsayılan şifre” anlamına geldiğini bildiğini hayal edin. Bu düzeyde ayrıntı ve standart tanım, bu yanlış yapılandırmayı takip etmek ve düzeltmek için iş akışını büyük ölçüde basitleştirecektir.
Bulut hizmetleri için CVE benzeri bir tanımlayıcının teşviki nedir?
Araştırma, tipik bir kuruluşun bir ay içinde ortamlarındaki güvenlik açıklarının yalnızca yüzde 10’unu düzeltebildiğini buldu. Bu hızda, kuruluşlar büyük miktarda açık güvenlik açığı birikimiyle karşı karşıyadır. Bu güvenlik açığı borcu her yıl büyümeye devam ediyor. Mali borcun aksine, kırılganlık borcu nedeniyle iflas ilan edemezsiniz. İleriye giden tek yol, sorunu düzeltmek veya görmezden gelmek ve en iyisini ummaktır.
Her güvenlik açığının izini sürmek ve düzeltmek zaten bir yukarı yönlü mücadeledir. Belki de buluta özgü CVE’den ilham alan tanımlama, sektörün bu sorunları takip etme ve düzeltme görevini kolaylaştırmak için atabileceği bir adımdır. Değilse, daha iyi bir çözüm bulmak için açık bir tartışmanın zamanı gelmiştir. Çünkü kolektif kırılganlık borcumuz birikmeye devam ediyor ve çok geçmeden hepimizin riskin ne kadar fazla olduğunu sormamız uzun sürmeyecek.