Merhaba,
"SIEM'de 2000 kuralımız var" demek coverage demek değildir. MITRE ATT&CK ile detection coverage haritası, hangi tekniklerde kör olduğunuzu gösterir. Bu yazıda küçük bir SOC'un Excel/Spreadsheet ile bile yapabileceği pratik yöntemi anlatıyorum.
ATT&CK'ı ne kadar derin kullanmalı?
Enterprise matrisinde yüzlerce teknik var. Hepsini yeşile boyamak hedef değil. Önce kurumunuza uygun tehdit modeli: ransomware, BEC, içeriden tehdit, tedarik zinciri... Sonra ilgili tactic/technique alt kümesi.
Basit harita nasıl kurulur?
Satırlar: Technique ID (ör. T1003.001). Sütunlar: Veri kaynağı (process, auth, dns, proxy, endpoint), Kural var mı?, Test edildi mi?, Son test tarihi, Sahip.
Renk:
- Yeşil: tespit var + son 90 günde test edildi
- Sarı: kural var ama test yok / yüksek FP
- Kırmızı: veri var, kural yok
- Gri: veri yok (önce telemetri)
Veri kaynağı gerçekliği
Kural yazmadan önce telemetri var mı bakın. Process Command Line yoksa "suspicious powershell" kuralı hayaldir. Windows'ta en azından:
- Security 4624/4625/4688
- Sysmon 1/3/7/11 (mümkünse)
- DNS / proxy log
- Kimlik sağlayıcı (AD / Entra) audit
Atomik test ile doğrulama
Red Canary Atomic Red Team gibi kontrollü testler (yalnız kendi lab/izinli ortam) kuralın gerçekten tuttuğunu gösterir. Test sonrası:
Kod:
# Örnek düşünce: T1059.001 PowerShell
# 1) Atomik testi labda çalıştır
# 2) SIEM'de alarm geldi mi?
# 3) Gelmediyse: telemetri mi eksik, kural mı yanlış?Önceliklendirme
- Kritik varlıkları etkileyen teknikler
- Son 12 ayda sektörünüzde görülen teknikler
- Kolay kazanım: telemetrisi hazır, kuralı basit olanlar
Yaygın kör noktalar
- Living-off-the-land (LOLBins) — imza ile zor
- Bulut yönetim düzlemi (Azure/AWS API) — endpoint odaklı SOC kaçırır
- Mac/Linux endpoint telemetrisi eksikliği
- E-posta kimlik doğrulama loglarının SIEM'e gelmemesi
Kaynaklar
- MITRE ATT&CK resmi site
- ATT&CK Navigator (katman dosyası paylaşımı)
- Atomic Red Team
- SigmaHQ (kural fikirleri)
Siz coverage'ı Navigator ile mi, yoksa servis kataloğuyla mı yönetiyorsunuz? Küçük ekip deneyimleri özellikle değerli.
Navigator katmanı paylaşımı
ATT&CK Navigator JSON katmanını ekipler arası paylaşmak, Excel renginden daha taşınabilirdir. Her major detection eklenince katmanı güncelleyin; çeyreklik gözden geçirmede kırmızı tekniklerden 3 tanesini yeşile çekme hedefi koyun.
Threat-informed defense
Sektörünüze ait tehdit raporlarındaki technique ID'leri haritaya "priority" olarak işaretleyin. Genel matris yüzdesi yerine "bu çeyrek ransomware zinciri coverage" KPI'sı yönetime daha anlamlı gelir.
Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.
Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.
Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.
Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.
Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.
Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.
Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.
Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.
Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.
Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.
Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.
Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.
Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.
Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.
Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.
Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.
Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.