SIEM Kuralı Yazarken Yaptığım 5 Büyük Hata ve Öğrendiklerim

Gece saat 02:40. Telefonun PagerDuty uyarısıyla yataktan nasıl fırladığımı dün gibi hatırlıyorum. Nöbetçi analist bendim ve ekranda panik halinde 140'tan fazla Kritik: LSASS Bellek Dökümü Tespiti uyarısı akıyordu. Gözlerimi ovuşturup VPN bağlantısını kurdum. Kırmızı alarm selini görünce soğuk terler dökmeye başladım; ortamda bir fidye yazılımı yayılıyor olabilirdi. Ancak logların derinine indiğimde acı gerçekle yüzleştim: Her gece 02:30'da çalışan meşru yedekleme yazılımı, rutin bir işlem için lsass.exe bellek alanına dokunuyordu. Tespiti tetikleyen kuralı ise tam iki gün önce bizzat ben yazıp canlıya almıştım.

O gece saatlerce alarm kapattım, müşteriye yanlış alarm (false positive) açıklaması geçtim ve ertesi gün ekibin önünde kurduğum kuralın neden patladığını anlattım. SOC kariyerimde beni gerçekten büyüten anlar, sessizce gururlandığım başarılı tespitler değil; bu tarz kural yazım hatalarıyla yüzleştiğim anlar oldu.

1. Kapsamı Kaçırıp Her Şeye Joker Karakter (Wildcard) Basmak

Mesleğin ilk dönemlerinde bir tehdidi kaçırmama korkusuyla tespit mantığını aşırı geniş tutuyordum. Örneğin PowerShell üzerinden çalıştırılan zararlı bir komutu yakalamak istediğimde, komut satırı parametresine doğrudan powershell.exe -enc yazıp geçiyordum.

Bunun sonucunda ne mi oldu? Sistem yöneticilerinin rutin otomasyonlar için kullandığı meşru, kodlanmış (encoded) PowerShell betikleri günün her saati vardiya ekranımıza düşmeye başladı. Tehlikeyi kaçırmama arzusuyla joker karakterleri (*) bol keseden kullanmak, arkasında devasa bir gürültü denizi bırakıyor.

Daha da kötüsü, gelişmiş saldırganlar bu yüzeysel kuralları atlatmayı çok iyi biliyor. Bir komut satırı parametresini -EncodedCommand yerine -e veya -enc şeklinde kısaltarak yazmak ya da tırnak işaretleriyle obfuscation yapmak bu tarz kuralları anında etkisiz kılar. Artık biliyorum ki; wildcard kullanırken tespit uzayını daraltmak, gereksiz joker karakterlerden kaçınmak ve parametre varyasyonlarını kapsayacak düzenli ifadelere (regex) odaklanmak gerekiyor.

2. Süreç Ağacını (Process Tree) Görmezden Gelmek

O bahsettiğim gece yarısı felaketindeki hatam tam olarak buradaydı. MITRE ATT&CK matrisindeki T1003.001 (OS Credential Dumping: LSASS Memory) tekniğini tespit etmek istemiştim. Sysmon loglarında TargetImage değeri C:\Windows\System32\lsass.exe olan ve erişim hakkı 0x1000 veya 0x1F0FFF olan her olaya uyarı verecek bir kural yazmıştım.

Kaçırdığım şey şuydu: lsass.exe bellek alanına kimin, hangi üst süreç (Parent Process) üzerinden eriştiğini denetlememiştim. Antivirüs yazılımları, EDR ajanları, yedekleme servisleri ve Windows'un kendi iç bileşenleri gün içinde defalarca bu bellek alanıyla etkileşime girer.

Yalnızca hedef sürece (Target Process) odaklanıp ata süreci (ParentImage veya SourceImage) sorgulamamak kuralı çöp eder. Bir cmd.exe veya powershell.exe içinden mi LSASS erişimi isteniyor, yoksa yetkili bir güvenlik servisinden mi? Tespiti değerli kılan şey hedefin kendisi değil, o hedefe ulaşan yolun anormalliğidir. Bugün yazdığım kurallarda Windows Event ID 4688 (Process Creation) veya Sysmon Event ID 1 incelerken mutlaka ParentCommandLine ve sürecin çalıştırıldığı kullanıcı yetki seviyesini (Integrity Level) denkleme dahil ediyorum.

3. Kuralı Geçmiş Veride (Historical Data) Test Etmeden Canlıya Almak

Yeni bir tehdit istihbaratı raporu yayımlandığında veya ekiple yeni bir tespit fikri geliştirdiğimizde heyecanla kuralları SIEM ortamında aktif etmek isteriz. Eskiden kuralı kurgular kurgulamaz canlıya alırdım. Bu, fırtınalı denize pusulasız açılmaktan farksızdır.

Bir kural yazıldığında yapılması gereken ilk iş, o kuralı geçmiş 30 veya 90 günlük log kümesi üzerinde (Historical Search / Backtest) çalıştırmaktır. Eğer yazdığınız kural son 1 ay içinde 5.000 defa tetiklendiyse, ortamınızda ya devasa bir ihlal vardır ya da çok daha yüksek ihtimalle kuralınız hatalıdır.

Geçmiş veri testi bize baseline, yani ortamın normal davranış çizgisini verir. Kurumdaki özel yazılımların, bakım zamanı çalışan görevlerin veya sistem yöneticilerinin alışkanlıklarının nasıl log ürettiğini görürüz. Artık yazdığım her yeni tespiti önce bir süre izleme modunda tutuyor, tarihsel log sorgulamasıyla yanlış pozitif oranını sıfıra yakın seviyeye çekmeden asla SOC vardiya ekranına düşürmüyorum.

4. Gösterge (IoC) Avcılığı ile Davranış (TTP) Tespiti Arasındaki Farkı Unutmak

SOC'taki ilk aylarında bir tehdit aktörünün kullandığı zararlı dosya hash değerini (MD5/SHA256) veya IP adresini alıp derhal SIEM'e statik alarm kuralı olarak eklerdim. Birkaç hafta sonra o alarmın bir daha hiç çalışmadığını görünce güvende olduğumuzu sanırdım.

Bu en büyük yanılsamalardan biridir. Saldırgan dosyanın tek bir baytını değiştirdiğinde hash değişir. Yeni bir C2 (Command and Control) sunucusuna geçtiğinde IP adresi geçersiz kalır. Statik göstergelere (IoC) dayalı kural yazmak, dinamik bir tehdide karşı kâğıttan kalkan tutmaktır.

Öğrendiğim en kritik ders; Piramidin tepesine, yani TTP (Taktik, Teknik ve Prosedür) tespitine odaklanmaktır. Saldırganın IP adresini aratmak yerine, bir sürecin beklenmedik bir port üzerinden dışarıya şifreli trafik açması mantığına (T1071 - Application Layer Protocol) kural yazmalısınız. Hak yükseltme tespiti yaparken belirli bir aracın adını aratmak yerine, T1055 (Process Injection) davranışını görünür kılacak Sysmon ve Windows güvenlik loglarına kural geliştirmelisiniz.

5. Dokümantasyonu İhmal Etmek

Altı ay önce yazdığınız bir SIEM kuralı alarm ürettiğinde, kuralın detayına bakan analist arkadaşınız kuralın ne anlatmak istediğini anlamıyorsa orada ciddi bir operasyonel aksama var demektir. Kural başlığına sadece "Şüpheli İşlem Tespiti" yazıp açıklama kısmını boş bıraktığım dönemler oldu. Alarm ekrana düştüğünde nöbetçi analist kuralın neyi amaçladığını veya ilk müdahale adımlarının (Playbook) ne olduğunu bilemiyordu.

Şimdi yazdığım her SIEM kuralına şu yapıyı standart olarak ekliyorum:

• MITRE ATT&CK Eşleşmesi: İlgili teknik ID'si (Örn: T1059.001) ve taktik adı.
• Mantık Özeti: Kuralın tam olarak neyi aradığı (Örn: PowerShell'in Net.WebClient ile doğrudan script indirme davranışı).
• Bilinen İstisnalar: Ortamda tespit edilen meşru kaynaklar ve bilinen false-positive durumları.
• Analist Müdahale Adımı: Alarm düştüğünde incelenmesi gereken ilk log alanları ve karantina adımları.

SIEM kuralı yazmak, statik bir kod yazıp kenara çekilmek değildir; yaşayan, sürekli bakım isteyen ve ortamın dinamiklerine göre evrilen bir süreçtir. Hata yapmak bu işin doğasında var, önemli olan o hataları gürültüye dönüşmeden önce tespit edip kuralları olgunlaştırmaktır.