QRadar & SIEM

QRadar False Positive: Yanlış Alarm İnceleme ve Kural Tuning

QRadar’da false positive, güvenlik kuralının beklenen veya yetkili bir etkinliği tehdit olarak işaretlemesidir. Amaç yalnızca alarm sayısını azaltmak değil, aynı zamanda gerçek tehditleri görmeye devam etmektir. Tuning kararı offense içindeki ham olay ve varlık bağlamı doğrulandıktan sonra verilmelidir.

İncelemeye Nereden Başlanır?

  1. Offense’i tetikleyen kuralı ve ilgili zaman aralığını belirleyin.
  2. Normalize alanları payload ile karşılaştırın.
  3. Kaynak/hedef varlık, kullanıcı, olay türü ve tekrar sıklığını inceleyin.
  4. Etkinliğin planlı bakım veya onaylı bir süreç olduğunu sorumlu ekiple doğrulayın.
  5. Aynı davranışın başka sistemlerde görülüp görülmediğini araştırın.

Temsili Log Örneği: Başarısız Giriş

Aşağıdaki olay eğitim amacıyla kurgulanmıştır. Gerçek müşteri logu veya QRadar’ın birebir payload biçimi değildir.

time=2026-10-08T10:00:00Z source=192.0.2.10 destination=192.0.2.20 user=lab_backup action=login result=failed

Bu kayıt tek başına brute force saldırısını kanıtlamaz. Yanlış parola kullanan bir servis de benzer olaylar üretebilir. Beklenen servis davranışı, hedef sayısı, hesabın kullanım amacı ve başarılı girişlerle ilişkisi kontrol edilmelidir. “Bilinen kaynak IP” tek başına bütün etkinliğe güvenmek için yeterli değildir.

Kural Koşulu mu, İstisna mı?

Yanlış alarmın sebebi eksik bağlam olabilir: kural beklenen bir iş akışını ayırt etmiyor veya olay alanı yanlış ayrıştırılıyor olabilir. Önce sebebi düzeltin. İstisna gerekiyorsa yalnızca doğrulanan kullanıcı, varlık ve davranış kapsamını hedefleyin; sahibi, gerekçesi ve gözden geçirme tarihini kaydedin.

False Positive Building Block’larında Dikkat

IBM dokümantasyonuna göre FalsePositive: False Positive Rules and Building Blocks kuralıyla eşleşen olay veya akışlar diğer CRE kurallarını atlayabilir. Bu nedenle geniş bir istisna başka tehdit senaryolarını da etkileyebilir. Kural zinciri ve bağımlılıkları değerlendirilmeden bütün bir kaynağı istisnaya almak uygun değildir.

Değişiklik Sonrası Doğrulama

  • Doğrulanan normal etkinlik için alarm davranışını kontrol edin.
  • Benzer görünen şüpheli bir laboratuvar senaryosunun hâlâ tespit edildiğini doğrulayın.
  • Payload ve normalize alanların değişmediğini kontrol edin.
  • Değişiklik öncesi/sonrası sonucu ve geri dönüş adımını kaydedin.
  • Geçici istisnayı planlanan tarihte yeniden değerlendirin.

Resmî Kaynaklar

İlgili Rehberler

Ayberk Kurtuluş

IBM QRadar, SIEM ve ağ güvenliği üzerine Türkçe teknik rehberler hazırlıyorum. Bu blogda log analizi, korelasyon kuralları ve SOC süreçlerini ele alıyorum.

İlgili Makaleler

Başa dön tuşu