Saldırı Yolu Analizi (Attack Path Mapping)
CVSS'i 4.3 olan bir zafiyet, sizi üç adımda Domain Admin'e taşıyabilir. Artık tek tek puanlara değil, yollara bakma vakti.
Bir önceki yazıda CVSS'in tek başına yeterli olmadığından bahsetmiş, EPSS ve KEV'in gerçek istismar olasılığına göre önceliklendirmeye nasıl yardımcı olduğunu anlatmıştık. Skorları doğru okudunuz, KEV listesini kontrol ettiniz, EPSS'i yüksek çıkan zafiyetleri P0 kuyruğuna aldınız. Peki CVSS'i 4.3, EPSS'i %2, KEV listesinde hiç yer almayan bir zafiyete ne oldu? Muhtemelen "düşük öncelikli, sırası gelince bakarız" dediniz ve geçtiniz. Saldırgan da tam olarak bunu umuyordu.
Gerçek ihlallerin büyük kısmı tek bir "kritik" CVE üzerinden değil, tek başına önemsiz görünen birkaç bulgunun zincirlenmesiyle gerçekleşir. Bir phishing maili, unutulmuş bir yerel yönetici yetkisi, yeniden kullanılmış bir servis hesabı parolası, gözden kaçmış bir grup ilkesi (GPO) vs. Bunların hiçbiri tek başına CVSS 9 değildir, çoğunun zaten bir CVE numarası bile yoktur. Ama art arda geldiklerinde saldırgan, üç dört adımda organizasyonun en kritik varlığına -crown jewel'ine- yürüyebilir. CTEM'in beş aşamalı döngüsünde (Scoping, Discovery, Prioritization, Validation, Mobilization) bu zincirleme gerçeği görünür kılmanın adı Saldırı Yolu Analizi'dir (Attack Path Mapping).
Saldırı Yolu Analizi (Attack Path Mapping) Nedir?
Saldırı Yolu Analizi; ortamdaki varlıklar (kullanıcı, makine, servis hesabı, cloud kaynağı, uygulama) arasındaki ilişkileri bir graf olarak modelleyip, düşük yetkili bir girişten başlayan bir saldırganın organizasyonun en kritik varlığına kaç adımda ve hangi yollardan ulaşabileceğini gösteren yaklaşımdır. Soru artık "bu zafiyet ne kadar tehlikeli?" değil, "bu zafiyet beni nereye götürürdür?"
Bu bakış açısı aslında yeni değil. Kırmızı takımlar (red team) ve pentester'lar yıllardır bunu yapıyoruz. Test esnasında bir key/hash/password ya da bir sistemden bir shell elde edilir. Ele geçirilen bu bilgiler ile olabildiğince en üst noktaya (Genelde AD Hesabı ele geçirme/oluşturma) gidilmeye çalışılır. Attack Path Mapping'in farkı, bunu tek seferlik bir pentest egzersizi olmaktan çıkarıp; ortam her değiştiğinde -yeni bir kullanıcı eklendiğinde, bir GPO düzenlendiğinde, bir cloud rolüne yeni bir izin verildiğinde- otomatik olarak yeniden hesaplanan, sürekli bir modele dönüştürmesidir.
Neden Tek Tek Zafiyetlere Bakmak Yetmiyor?
Geleneksel bir tarayıcı -ya da bir önceki yazıda konuştuğumuz EPSS/KEV modeli- her zafiyeti kendi başına, izole bir şekilde skorlar. Bu, tek bir bulgunun tehlikesini anlamak için gayet işe yarar. Ama saldırganlar zafiyetleri izole değerlendirmez; onları birer Lego parçası gibi görür ve birbirine geçirir. Bir bulgunun CVSS'i düşük olabilir çünkü tek başına hiçbir şeye yol açmaz - ama başka bir bulguyla birleştiğinde bambaşka bir sürece dönüşür. Bu birleşimi ve tetiklenen bu zafiyetleri hiç bir zafiyet tarama aracı gösteremez, çünkü tarayıcı sizin ortamınızdaki ilişkileri değil, sadece yazılım sürümlerini bilir.
Basit bir senaryo kuralım. Bir çalışan phishing mailindeki eki açıyor, makinesi ele geçiriliyor. Bu makinede "geliştiriciler için normal" diye not düşülmüş bir yerel yönetici yetkisi var - CVSS puanı olmayan bir yapılandırma tercihi. Yerel yönetici yetkisiyle bellekteki kimlik bilgileri okunuyor ve orada, unutulmuş bir entegrasyon için tanımlanmış bir servis hesabının bilgisi çıkıyor. O hesabın tek başına dikkat çekici bir yanı yok; ama bir grup ilkesini düzenleme yetkisi var. GPO üzerinden Domain Admin grubuna bir üyelik ekleniyor ve son adımda üretim veritabanına bağlanılıyor.
Beş adım. Hiçbiri tek başına CVSS 9.8 değil - çoğunun zaten CVSS puanı yok. Ama sonuç tam bir domain ele geçirme senaryosuna dönüşüyor. Geleneksel bir tarama raporunda bu bulgular birbirinden uzakta, tekil olarak veya farklı önceliklerde görünür. Attack Path Mapping bunları aynı grafın üzerinde, birbirine bağlı düğümler olarak gösterir - aşağıdaki gibi:
Grafın Anatomisi: Node, Edge, Chokepoint, Blast Radius
Yukarıdaki diyagramı okumak için birkaç terimi netleştirelim - bunlar Attack Path Mapping'in ortak dili:
Node (Düğüm): Bir varlık - kullanıcı, makine, servis hesabı, cloud rolü, uygulama. Graftaki her nokta bir varlığı temsil eder.
Edge (Kenar): İki varlık arasındaki ilişki ya da yetenek - "RDP ile bağlanabilir", "GenericWrite yetkisine sahip", "bu role assume edebilir". Her edge, saldırganın atabileceği bir sonraki adımdır.
Attack Path (Saldırı Yolu): Bir giriş noktasından crown jewel'e kadar art arda dizilen edge'lerin oluşturduğu yol.
Chokepoint (Darboğaz): Çok sayıda farklı yolun üzerinden geçtiği kritik düğüm. Kapatıldığında düzinelerce yolu aynı anda çökertir.
Blast Radius (Etki Alanı): Bir varlık ele geçirildiğinde oradan erişilebilecek tüm varlıkların toplamı.
Crown Jewel: Kaybedilmesi organizasyonu gerçekten sarsacak varlık - üretim veritabanı, domain controller, kaynak kod deposu, ödeme sistemi.
Chokepoint Neden Altın Değerinde?
Orta ölçekli bir organizasyonda bile genelde yüzlerce, kimi zaman binlerce potansiyel saldırı yolu bulunur. Hepsini tek tek kapatmaya çalışmak, geleneksel zafiyet yönetiminin kabusun aynı senaryosudur. Asıl önemli olan, çok sayıda yolun kesiştiği birkaç düğümdür.
Yukarıdaki diyagramdaki Servis Hesabı düğümü gözükmektedir. Bu tek düğüm, bu senaryoya özel olmayabilir - ortamdaki elli farklı saldırı yolunun da ortak paydası olabilir. Mesela "Tüm Personel" grubuna yanlışlıkla verilmiş bir GenericWrite yetkisi olabilir. O tek yetkiyi geri almak, elli yolu aynı anda kapatır. Bu, CTEM'in Prioritization aşamasına tam oturan bir mantık: "1000 zafiyeti mi yamalayayım, yoksa 3 chokepoint'i mi kapatayım?" sorusunun cevabı artık nettir.
MITRE ATT&CK ile Saldırı Yollarını Etiketlemek
Bir saldırı yolundaki her edge, aslında bilinen bir saldırgan davranışına karşılık gelir. Burada devreye MITRE ATT&CK giriyor. Grafınızdaki her edge'i bir ATT&CK tekniğiyle etiketlediğinizde iki şey kazanırsınız: SOC, kırmızı takım ve yönetimin aynı ID üzerinden konuştuğu ortak bir dil, ve "bu adımı gerçekten yakalayabilir miyiz?" sorusuna somut yanıt veren bir tespit haritası.
Yukarıdaki senaryoyu bu gözle bakarsak şöyle bir sonuç çıkacaktır:
Adım | Teknik | ATT&CK ID | Tespit Durumu |
Phishing ile ilk erişim | Phishing | T1566 | Email gateway'de genelde loglanıyor |
Yerel yönetici ile kimlik bilgisi okuma | OS Credential Dumping | T1003 | EDR varsayılan kural açıksa alarm üretir |
Servis hesabıyla GPO değişikliği | Domain Policy Modification | T1484 | Çoğu ortamda loglanmıyor — kör nokta |
GPO üzerinden Domain Admin üyeliği | Valid Accounts | T1078 | Kimlik doğrulama logu var, davranışsal analiz yoksa fark edilmez |
Domain Admin ile veritabanına bağlanma | Remote Services | T1021 | Ayrıcalıklı erişim izleniyorsa yakalanır |
Zincirin en zayıf halkasına dikkat edin: bir GPO değişikliği. Teknik olarak "saldırı" bile sayılmayabilir, bir yönetici de aynı işlemi yapabilir. Saldırganlar tam olarak bunu seviyor: tespit açığı olan, "normal" görünen adımları tercih ediyorlar. Bir SOC için asıl kazanım, grafın hangi edge'lerinin görünürlük açığı olduğunu önceden bilmektir - saldırı olduktan sonra değil.
Attack Path Risk Skorlaması: CVSS + EPSS + KEV + Merkezilik
Geçen yazıda konuştuğumuz EPSS ve KEV burada da devrede - ama artık tek bir CVE'ye değil, yoldaki her adıma uygulanıyor. Bir saldırı yolunun gerçek risk seviyesini belirlerken sorduğumuz sorular şunlar:
Bu yol crown jewel'e kaç adımda ulaşıyor? (Uzaklık)
Yoldaki en kolay istismar edilebilir adımın EPSS'i ne kadar yüksek? (Olabilirlik)
Yoldaki herhangi bir adım KEV listesinde mi? (Kanıtlanmış istismar)
Bu yol bir chokepoint'ten mi geçiyor, yoksa tekil/izole bir yol mu? (Etki alanı)
Yoldaki adımların kaçı mevcut tespit kontrollerinizin kör noktasında? (Görünürlük)
Bu beş soruyu birleştirdiğinizde, CVSS'in tek başına asla veremeyeceği bir öncelik tablosu ortaya çıkıyor:
Durum | Öncelik | Aksiyon |
Chokepoint + crown jewel'e ≤2 adım + yolda KEV'li bir teknik | ACİL (P0) | Yolu derhal kes, chokepoint'i izole et |
Chokepoint ama crown jewel'e uzak (4+ adım), EPSS düşük | YÜKSEK (P1) | Öncelikli planla, chokepoint önce kapatılır |
Tekil yol, chokepoint değil, KEV'de yok, EPSS düşük | ORTA (P2) | İzleme listesine al, periyodik gözden geçir |
Tekil yol + zaten iyi izlenen bir adım | DÜŞÜK (P3) | Mevcut kontrolle yetin, kaynak ayırma |
Dikkat ederseniz burada CVSS hâlâ tabloda - ama artık tek yargıç değil, beş kriterden sadece biri. Yalnız başına yüksek bir CVSS artık alarm zilini çalmıyor; onu çalan, o CVSS'in bir chokepoint üzerinde, crown jewel'e yakın bir yolda oturup oturmadığı.
Geleneksel Önceliklendirme ile Graf Tabanlı Önceliklendirme
İki yaklaşımı yan yana koyduğumuzda fark daha da netleşiyor:
Özellik | Geleneksel (Zafiyet Bazlı) | Graf Tabanlı (Attack Path) |
Birim | Tekil CVE / bulgu | Uçtan uca yol |
Temel Soru | "Bu zafiyet ne kadar kritik?" | "Bu zafiyet beni crown jewel'e ne kadar yaklaştırır?" |
Kapsam | Yazılım açıkları | CVE + yanlış yapılandırma + identity + izinler |
Önceliklendirme Birimi | Puan (CVSS/EPSS) | Yol + düğüm merkeziliği (chokepoint) |
Çıktı | Yama listesi | Kesilecek ilişki/yetki listesi + yama listesi |
Identity ve Cloud: Modern Saldırı Yollarının Gerçek Kaynağı
Bir önceki yazıda CTEM'in sadece CVE'lere değil, yanlış yapılandırmalara, sahipsiz varlıklara ve kimlik yönetimi risklerine de baktığından bahsetmiştik. Attack Path Mapping'in en çok karşılık bulduğu yer tam olarak burası. Sahada görülen gerçek şu: ihlallerin büyük kısmı bir 0-day'den değil, zaten var olan, yetkilendirilmiş ama gereğinden geniş bırakılmış ilişkilerden besleniyor.
Saldırı Yolu Analizine Başlamak İçin İlk Adımlar
Bunu bir sonraki pentest'e ya da bir sonraki bütçe dönemine ertelemeden başlamak için üç adım yeterli:
Crown Jewel'lerinizi Gerçekten İsimlendirin: "Her şey kritiktir" demek, hiçbir şeyin kritik olmadığını söylemekle aynı şeydir. İş etkisine göre gerçek 3-5 varlığı yazın.
Kapsamı Identity ve Yapılandırmaya Genişletin: Sadece CVE taramasıyla yetinmeyin; AD ilişkilerini, cloud IAM rollerini, servis hesabı izinlerini de envantere dahil edin - saldırı yolunun hammaddesi burada.
Chokepoint'leri Periyodik Değil, Sürekli Yeniden Hesaplayın: Ortam her değiştiğinde graf yeniden çizilmeli. Yılda bir kez yapılan bir "attack path analizi", CTEM'in ruhuna aykırıdır.
Sonuç olarak Attack Path Mapping, güvenlik ekiplerinin sonsuz bir zafiyet listesiyle boğuşmak yerine saldırganın gerçekten yürüyebileceği yollara odaklanmasını sağlıyor. Tek bir CVSS puanına değil, o puanın hangi ilişkiler zincirine bağlandığına bakmak - CTEM'i bir "liste kapatma" egzersizinden çıkarıp gerçek bir risk azaltma disiplinine dönüştüren de tam olarak bu bakış açısı.