Yanlış Pozitif Bataklığı: Alarm Yorgunluğuyla Başa Çıkmak

Gece yarısını çoktan geçmişti, saat 02:40 suları. Vardiyanın altı saatini geride bırakmışım, göz kapaklarım ağırlaşıyor. Ekranda bir anda turuncu renkli beş yeni uyarı belirdi. Bir finans kullanıcısının bilgisayarında arka arkaya tetiklenen powershell.exe süreçleri. İçimden refleks olarak 'Yine bilgi işlem ekibinin rutin envanter taramasıdır' dedim. Birkaç gün önce de benzer bir seri gelmiş ve yanlış alarm çıkmıştı. Detaylı komut satırı parametrelerine bakmadan, alarmı kapatma tuşuna doğru fareyi kaydırdım. Tam o anda durdum. İçimdeki bir ses 'Bir saniye, detaylara bak' dedi. Komut satırını açtığımda karşıma çıkan tablo, rutin bir tarama değildi.

Göz Alışkanlığının Getirdiği Tehlikeli İhmal

O gece ucuz atlattığım olay, meslek hayatımın en net kırılma noktalarından biri oldu. Alarm yorgunluğu (alert fatigue) dediğimiz illet, tam olarak böyle çalışıyor. Günde yüzlerce, bazen binlerce yanlış alarmı inceledikten sonra beyin otomatiğe bağlıyor. Bir noktadan sonra ekranınızdaki uyarılara analist gözüyle değil, bitirilmesi gereken bir angarya gözüyle bakmaya başlıyorsunuz.

Geçmişte yaptığım büyük bir hatayı açıkça itiraf edeyim: Birkaç ay önce, benzer bir gürültü dalgası sırasında Windows Event ID 4688 (Süreç Yaratma) kayıtlarına düşen bir uyarıyı yüzeysel inceleyip 'False Positive' olarak kapatmıştım. Sistemde çalışan betik son derece sıradan görünüyordu. Ancak üç saat sonra aynı makineden etki alanına (domain controller) doğru sıçrama denemesi tespit edildi. Derinlemesine incelediğimde, saldırganın bellek enjeksiyonu (Process Injection - MITRE ATT&CK T1055) tekniğini kullandığını ve kendini yasal bir Windows sürecinin arkasına gizlediğini gördüm. O gün, 'Zaten sürekli gelen alarm' mantığının bir güvenlik analistinin yapabileceği en ölümcül hata olduğunu anladım.

Gürültüyü Kesmek: Kural İnce Ayarı (Tuning) Nasıl Yapılır?

Alarm yorgunluğuyla mücadelenin ilk adımı, insan toleransını zorlamak değil; SIEM ve EDR tarafındaki kuralları sürekli olarak yontmaktır. Ham tespit kuralları genellikle geniş kapsamlı yazılır ve ortamınıza uyarlanmadığı sürece sizi gürültüye boğar. Yanlış pozitif bataklığından çıkmak için uyguladığım somut kural iyileştirme adımları şunlar:

• Ata-Oğul Süreç İlişkisini Bağlama Oturtmak: cmd.exe veya powershell.exe tek başına tehlikeli değildir. Onu başlatan üst süreç (Parent Process) kritik önem taşır. Eğer explorer.exe üzerinden bilinmeyen bir Powershell çalışıyorsa bu bir şüphedir. Ancak ebeveyn süreç yetkili bir dağıtım aracıysa (örneğin SCCM agent), kuralı doğrudan genel PowerShell kullanımına değil, ebeveyn-çocuk ilişkisine göre daraltmak gerekir.
• Bölüm ve Rol Bazlı İstisnalar Tanımlamak: Yazılım geliştirme ekibindeki bir mühendisin bilgisayarında net.exe veya whoami komutlarının çalışması çoğu zaman iş akışının parçasıdır. Fakat aynı komut bir insan kaynakları personelinin bilgisayarında koşturuluyorsa durup bakmak gerekir. Kuralları tüm kuruma tek bir şablon olarak uygulamak yerine, kullanıcı gruplarına göre esnetmek gürültüyü en az %40 azaltır.
• Zaman Pencereleri Kurmak: Gece saat 03:00'te çalışan bir yedekleme betiği ile mesai saatleri içinde çalışan betiğin risk skoru aynı olamaz. Kurallara zaman matrisi ekleyerek mesai dışı şüpheli hareketlerin önceliğini yükseltip, mesai içindeki bilinen davranışları alt seviye uyarılara dönüştürebilirsiniz.

Analiz Sürecini Sistemleştirmek

Kuralları iyileştirmek kadar, alarm geldiğinde izlenen yolu standartlaştırmak da yorgunluğu azaltır. Bir uyarının karşısına geçtiğimde artık şu sırayı hiç aksatmadan uyguluyorum:

Öncelikle Sysmon Event ID 1 (Process Creation) veya EDR konsolundaki süreç ağacına bakıyorum. Süreç hash değeri bilinen yasal bir dosyaya mı ait? Komut satırında -EncodedCommand veya -e gibi gizleme (obfuscation) parametreleri var mı? İkinci adımda, olaya karışan IP adresinin veya alan adının itibarını kontrol ediyorum. Son aşamada ise ilgili kullanıcının son 24 saatteki hareket geçmişini tarayarak bunun münferit bir olay mı yoksa bir zincirin parçası mı olduğunu doğruluyorum.

Bu adımları bir oyun planı (playbook) haline getirip otomasyon araçlarına (SOAR) devrettikçe, ekrana düşen ve insan dokunuşu gerektiren alarm sayısı hissedilir derecede azaldı. Artık günde 500 anlamsız uyarı yerine, gerçekten bakılması gereken 15-20 kaliteli alarm ile ilgileniyorum.

Analist İçin Hayatta Kalma Tavsiyesi

Vardiya sırasında dikkatinizin dağıldığını, olayları derinlemesine incelemek yerine hızla kapatma eğiliminde olduğunuzu hissettiğiniz an, alarm yorgunluğu sınırına çarpmışsınız demektir. Böyle anlarda ekrandan 5 dakika uzaklaşmak, bir bardak su almak veya başka bir ekip arkadaşıyla olay üzerine iki dakika konuşmak zihni sıfırlar. Güvenlik Operasyon Merkezi'nde en pahalı araçlar bile bir analistin dikkatinin yerini tutamaz. Unutmayın, saldırganlar sistemlerinize girmek için sizin yorulmanızı ve o 'rutin' uyarılardan birini daha sorgulamadan kapatmanızı bekliyor.