Yönetim kurulları güvenlik ekiplerine üç net soru yöneltiyor: Kurum ne kadar güvende, gerçek maddi risk ne ve güvenlik durumu geçen çeyreğe göre daha iyi mi? Son değerlendirmeler, birçok CISO’nun bu sorulara net yanıt veremediğini gösteriyor; sorun veri yokluğu değil, verinin kimlik, uç nokta, bulut, SIEM ve SaaS araçları arasında parçalı kalması.
Bu tabloyu ele alan yeni bir rehber, klasik güvenlik raporlamasının yönetim kurulunun beklentisini neden karşılamadığını ve risk temelli raporlamanın nasıl kurulabileceğini anlatıyor. Doküman, kurumsal güvenlik ekiplerinin yıllardır sayıya dayanan ama iş riskini göstermeyen raporlar ürettiğini vurguluyor.
Aktivite sayıları artık soruya cevap vermiyor
Güvenlik raporları uzun süredir “kaç açık bulundu”, “kaç yama uygulandı”, “kaç uyarı kapatıldı”, “kaç oltalama simülasyonu geçildi” gibi ölçütlerle hazırlanıyor. Ancak bu metrikler ekiplerin ne kadar çalıştığını gösterse de kurumun gerçekten daha güvenli olup olmadığını ortaya koymuyor.
Bir yönetim kurulu üyesi, geçen çeyrekte binlerce bulgunun kapatıldığını duyduğunda şirketin daha güvende olup olmadığını anlayamıyor. “Hangi tehdide karşı, ne kadar daha güvenli?” sorusunun yanıtı çoğu zaman raporda yer almıyor.
Rehber, yönetim kurullarının esas olarak üç tür bilgi istediğini aktarıyor: erişilebilir risk alanları, bu riskin çeyrekten çeyreğe nasıl değiştiği ve bunun para cinsinden karşılığı. Başka bir deyişle faaliyet sayısı değil maruz kalınan alan, anlık görüntü değil eğilim, CVE listesi değil finansal etki isteniyor.
Kurumsal raporların güven kaybı yaşamasının nedeni de burada ortaya çıkıyor. Güvenlik ekipleri genellikle araçların ürettiği ham çıktıları birleştirmeden sunuyor ve farklı platformların birbirine bağlanan parçalarını tek bir saldırı yoluna dönüştüremiyor. Saldırganlar ise bu sınırları dikkate almıyor.
Rehberde yer alan örneğe göre tipik orta ölçekli ya da büyüyen bir şirket; kimlik sağlayıcısı, CSPM ya da CNAPP, uç nokta algılama, SIEM, açık tarayıcı ve çok sayıda SaaS uygulamasını birlikte kullanıyor. Her ürün kendi alanında doğru sonuç veriyor, fakat hiçbiri bu alanların nasıl birleştiğini tam olarak görmüyor.
Bu kopukluk, görünürde düşük riskli duran bulguları kritik bir saldırı yoluna dönüştürebiliyor. Bir taşeron hesabının proje bitmiş olsa da kimlik sağlayıcısında eski bir grup üyeliğini koruduğu senaryoda kimlik aracı bu hesabı düşük riskli görür. O grup, bulut ortamına OAuth entegrasyonu olan bir SaaS uygulamasına erişim açıyorsa SaaS güvenlik aracı entegrasyonu normal kabul eder. Entegrasyon geniş depolama izinlerine sahip bir servis hesabı üzerinden çalışıyorsa bulut duruş aracı bunu orta seviyede işaretler. O depolama alanı müşteri kayıtlarını barındırıyorsa veri sınıflandırma aracı hassas veri olduğunu bilir, fakat kimlerin ulaşabildiğini tek başına göremez.
Ortaya dört bulgu, dört araç ve dört orta seviye puan çıkıyor. Birlikte bakıldığında ise oltalanabilir bir hesaptan şirketin en hassas verisine uzanan kritik bir yol oluşuyor. Tek bir gösterge tablosu bu zinciri göstermediği için yönetim kurulu raporuna da girmiyor; çoğu zaman ancak bir olay yaşandığında fark ediliyor.
Eksik halka araç değil, araçlar arasındaki bağ
Rehber, şirketlerin sorunu yeni bir ürün satın alarak çözmeye çalıştığını, bunun da genellikle yalnızca yeni bir konsol, yeni bir dışa aktarma dosyası ve uzlaştırma tablosuna yeni bir sütun eklediğini söylüyor. CSPM ya da Zero Trust mimarisi gibi yatırımların önemli olduğu kabul ediliyor; ancak bunların her birinin belirli bir alana sıkıştığı, yönetim kurulunun sorduğu sorunun ise bu alanların dışına taştığı belirtiliyor.
Metinde bu açığı kapatmak için Siber Güvenlik Mesh Mimarisi, yani CSMA yaklaşımı öne çıkarılıyor. Gartner’ın da tanımladığı bu model, dağınık güvenlik araçlarını ortak bir zeka katmanı üzerinden birbirine bağlamayı amaçlıyor. Amaç, mevcut araçların yerine yenisini koymak değil; kimlik, erişim, varlık ve maruziyet verilerini tek bir grafik üzerinde ilişkilendirmek.
Rehbere göre bu yaklaşım, yönetim kurulunun sorduğu soruları doğrudan karşılayacak bir raporlama çerçevesi sunuyor. Yönetim kurulu “ne kadar güvendeyiz” diye sorduğunda, kritik varlıklara giden kalan yollar gösteriliyor. “Mali riskimiz ne” dendiğinde, bu yollar kullanılırsa oluşacak tahmini etki veriliyor. “İyileşme var mı” sorusuna ise geçen çeyreğe göre kaç saldırı yolunun kapatıldığı yanıtı veriliyor.
Yeni raporlama modeli için ilk adım, iş birimleriyle birlikte kurumun “krona mücevherlerini” tanımlamak olarak anlatılıyor. Müşteri veri depoları, ödeme sistemleri, PHI, kaynak kodu ve üretim altyapısı bu listeye dahil ediliyor. Rehber, bu listenin yalnızca güvenlik ekibi tarafından değil, iş sahipleriyle birlikte oluşturulmasını istiyor çünkü raporun dayanağı bu oluyor.
İkinci adımda, kurumda zaten çalışan araçlardan kimlik, bulut, uç nokta, SaaS ve zafiyet verilerinin tek bir ilişkisel görünümde birleştirilmesi öneriliyor. Burada hedef yeni sensör eklemek değil, tekrarları ayıklamak ve veriyi zenginleştirmek. Rehber, ajan gerektirmeyen ve API tabanlı entegrasyonların kurulum süresini kısalttığını, üretim ortamını da bölmediğini belirtiyor.
Üçüncü aşama, tek tek bulgular yerine gerçek saldırı yollarını haritalamak. Her kritik varlık için hangi kimliklerin, insan ya da insan dışı, oraya ulaşabildiği ve bu erişimin hangi yanlış yapılandırma ya da izin zinciri üzerinden geçtiği gösteriliyor. Dördüncü adımda önceliklendirme “blast radius”, yani etki alanı üzerinden yapılıyor. Bir müşteri verisine uzanan orta seviyeli yanlış yapılandırma, izole bir test sunucusundaki kritik bir CVE’den daha yüksek öncelik alabiliyor.
Bu yaklaşımda yama ya da açık puanı tek başına yeterli değil. Rehber, güvenlik ekiplerinin kapanacak olan şeyi, yani zincirin hangi bölümünü kopardıklarını esas alarak sıralama yapması gerektiğini aktarıyor.
Beşinci adımda maruziyet, finans ve risk ekipleriyle birlikte para cinsinden ifade ediliyor. Yönetim kuruluna artık “kaç zafiyet var” yerine “kaç dolar risk altındayız” diliyle gidiliyor. Metin, bu dilin yönetim kurullarının diğer risk kategorilerinde zaten kullandığı ortak dil olduğunu vurguluyor.
Son adım, eğilimi raporlamak. Geçen çeyrekte kritik varlıklara kaç saldırı yolu bulunduğu, bugün kaç yol kaldığı ve hangi düzeltme çalışmalarının bunları kapattığı gösteriliyor. Rehber bu sayede yatırım geri dönüşü sorusunun da doğrudan yanıtlandığını, mevcut güvenlik yığınının aslında neyi koruduğunun görülebildiğini söylüyor.
Belge, yapay zeka kullanımının bu kopukluğu daha da büyüttüğünü de kaydediyor. AI ajanları, insan dışı kimlikler, servis hesapları ve MCP bağlantılı araçlar çoğu kurum bunları envantere bile almadan sisteme ekleniyor. Her biri kendi erişimi olan yeni bir kimlik anlamına geliyor ve birçok güvenlik mimarisi bu erişimin nereye uzandığını haritalayacak şekilde tasarlanmadı.
Rehberin sonunda güvenlik liderlerine, bir sonraki yönetim kurulu döngüsünden önce “CISO için Güvenli Yönetim Kurulu Raporlama Rehberi”ni indirmeleri öneriliyor. Aynı içerikte, Mesh adı verilen birleşik zeka katmanının parçalı güvenlik yığınlarıyla çalışan kurumsal ekipler için kullanıldığı, mevcut araçlara ajan gerektirmeden bağlandığı ve kimlik, bulut, SaaS, uç nokta ile yapay zeka ortamlarındaki sinyalleri ilişkilendirerek uygulanabilir saldırı yollarını ortaya çıkardığı belirtiliyor. Rehbere göre bu yapı, tek tek hiçbir aracın tek başına sağlayamayacağı kurumsal bağlamı sunuyor ve ekiplerin neyin önemli olduğunu öne çıkarıp riski daha hızlı azaltmasına yardım ediyor.
Analiz metninin sonunda bunun bir katkı içeriği olduğu da belirtiliyor; içerik, yayımlanan materyalde yer alan bilgilerin yeniden derlenmiş hali olarak sunuluyor.