Yanlış pozitifin gerçek maliyeti

Yeni analistin ilk refleksi kuralı geniş yazmaktır. Mantık şudur: kaçırmaktansa fazladan yakalayayım. Kulağa doğru gelir, ama uygulamada vardiyayı öldürür.

Günde 400 alarm üreten kural, kimsenin okumadığı bir kuraldır. Bu derste gürültünün bedelini sayıyla ölçeceksin. Önce alarm yükünü analist saatine çevireceksin. Sonra kararları dört kutulu bir tabloya yerleştirip kesinliği hesaplayacaksın.

Ardından kuralı geçmiş veride deneyip daraltacak, triyaj notunu yazacak ve istisnaları kayıt altına alacaksın. Amaç sessiz bir kural değil, güvenilir bir kuraldır. Güvenilir kuralın alarmı çaldığında analist onu ciddiye alır.

Hesabı somut yap. Bir alarmı incelemek ortalama altı dakika sürer.

Kural günde 80 yanlış alarm üretiyorsa bu 480 dakikadır, yani tam bir analist vardiyası. Bu maliyeti göz kararıyla tahmin etmek yanıltır. Analistin kafasında dört yüz alarm çok görünür, ama vardiyaya kaç saat çıkardığını kimse hesaplamaz. Oysa hesap basittir: alarm sayısını inceleme süresiyle çarparsın, sonucu saate çevirirsin.

Kâğıt üstünde küçük görünen bir kural, gerçekte bir kadronun günlük kapasitesini yiyebilir. Sayı yazıya dökülmeden tartışma hissiyatla sürer. Sayı ortaya çıkınca konuşma değişir: kural daraltılır, sahibi belli olur, karar tarihiyle kaydedilir.

Asıl maliyet dakikalar değildir, alarm yorgunluğudur. Sürekli boş alarm gören analist zamanla hepsine aynı gözle bakar. Gerçek olay geldiğinde de onu aynı refleksle kapatır. Kaçırılan olayların çoğunun arkasında bu vardır.

Büyük veri sızıntılarının bir kısmında alarm aslında üretilmişti. Sorun tespit değil, alarmın yığının içinde kaybolmasıydı. Bu yüzden gürültüyü azaltmak çoğu zaman yeni kural yazmaktan daha değerlidir.

Yeni kural bir alarm daha ekler. Gürültülü bir kuralı düzeltmek ise öteki bütün alarmların duyulmasını kolaylaştırır. Vardiya lideri olarak ilk işin, en çok alarm üreten beş kuralı bulup her birinin gerçek bulgu oranına bakmaktır.

Her alarm kapanırken bir etikete düşer. Etiketi doğru seçmek için iki soruyu ayrı sor.

Kural tetiklendi mi? Etkinlik gerçekten kötü amaçlı mı? İki sorunun cevabı dört kutu üretir.

Kural tetiklendi ve olay kötüyse gerçek pozitiftir. Kural tetiklendi ama etkinlik zararsızsa yanlış pozitiftir. Kural sustu ve etkinlik zararsızsa gerçek negatiftir.

Kural sustu ama saldırı vardıysa yanlış negatiftir. En pahalı kutu budur, çünkü onu kimse görmez. SOC ekipleri bu tabloya beşinci bir kapanış etiketi ekler: zararsız gerçek pozitif (benign true positive).

Kural doğru davranışı yakalamıştır ama etkinlik yetkilidir. Sızma testi ekibinin parola denemesi buna örnektir.

                     Etkinlik kötü amaçlı      Etkinlik zararsız
Kural tetiklendi     Gerçek pozitif (TP)        Yanlış pozitif (FP)
Kural sustu          Yanlış negatif (FN)        Gerçek negatif (TN)

Ek kapanış etiketi: Zararsız gerçek pozitif
  Kural doğru davranışı yakaladı, etkinlik yetkiliydi (sızma testi, planlı bakım).

Zararsız gerçek pozitifi yanlış pozitiften ayırmak önemlidir. Yanlış pozitif kuralın hatasıdır ve kural düzeltilir. Zararsız gerçek pozitifte kural doğru çalışmıştır; düzeltilecek şey süreçtir. Sızma testi önceden bildirilmediyse sorun iletişimdedir.

Tabloyu doldurunca kesinliği hesaplarsın. Kesinlik (precision), alarmların yüzde kaçının gerçek olduğunu söyler: TP / (TP + FP). Duyarlılık (recall) ise gerçek saldırıların yüzde kaçını yakaladığını söyler: TP / (TP + FN).

Yanlış negatifi bilmeden duyarlılığı ölçemezsin. Bu yüzden duyarlılığı, tekniği kendi lab ortamında yeniden üreten mor takım testleriyle ölçersin. Kesinlik ise vaka kayıtlarından her hafta çıkar.

Kural: PowerShell kodlanmış komut (son 30 gün)

Önce : 2.460 alarm, incelemede 75 gerçek
       Kesinlik    = 75 / 2.460 = %3
       Günlük yük  = (2.460 / 30) x 6 dk = 82 x 6 = 492 dk

Sonra: 125 alarm, incelemede yine 75 gerçek
       Kesinlik    = 75 / 125 = %60
       Günlük yük  = (125 / 30) x 6 dk = 4,2 x 6 = 25 dk

Hesabı satır satır oku. Önceki hâlde 2.460 alarmın yalnız 75'i gerçektir, kesinlik yüzde üç civarındadır. Otuz güne bölünce günde 82 alarm eder. Altı dakikalık incelemeyle bu 492 dakikalık bir yüktür.

Kural daraltıldıktan sonra alarm sayısı 125'e iner. Gerçek bulgu sayısı değişmemiştir, bu yüzden kesinlik yüzde altmışa çıkar. Günlük yük de yaklaşık 25 dakikaya düşer.

Kritik ayrıntı şudur: gerçek bulgu sayısı aynı kaldı. Daraltma tek bir gerçek olayı kaçırsaydı kazanç tartışmalı olurdu. Bu yüzden daraltmayı hep bilinen gerçek olayları içeren geçmiş veride sınarsın.

Kuralı daraltmanın üç yolu vardır. Bilinen normali dışarıda bırakırsın. Eşiği yükseltirsin. Ya da iki koşulu birleştirirsin.

Üçüncüsü en güçlüsüdür, çünkü tek başına masum iki olay birlikte anlam kazanır. Eski kural aynı hesaba on dakikada beşten fazla hatalı girişi sayıyor ve günde seksen civarı alarm üretiyordu. Parolasını art arda yanlış yazan herkes bu alarma düşer. Saldırganın izi ise farklıdır: kısa sürede çok sayıda farklı hesabı dener, sonra aynı kaynaktan içeri girer.

Sigma'da sayma ve olay zincirleme ayrı bir korelasyon kuralıyla yazılır. Temel kural tek olayı tarif eder. Korelasyon kuralı onu name alanıyla çağırır, sayar ya da sıraya koyar. Aşağıdaki dört belgelik zincir eski kuralın yerini alır.

title: Cok Hesap Denemesinin Ardindan Basarili Giris
id: 5c1a7e3d-2b4f-4d6a-9e8c-0f1b2a3c4d5e
status: test
correlation:
    type: temporal_ordered
    rules:
        - cok_hesap_denemesi
        - basarili_giris
    group-by:
        - IpAddress
    timespan: 10m
level: high
---
title: Tek Kaynaktan Cok Hesaba Hatali Giris
id: 8d2f6a10-4b3c-4e21-9a55-7c1e0b9d3f42
name: cok_hesap_denemesi
correlation:
    type: value_count
    rules:
        - hatali_giris
    group-by:
        - IpAddress
    timespan: 10m
    condition:
        field: TargetUserName
        gte: 10
---
title: Hatali Windows Girisi
id: 2a7c9e51-6f0d-4b8a-8e3f-5d1b4c6a7e90
name: hatali_giris
logsource:
    product: windows
    service: security
detection:
    secim:
        EventID: 4625
    condition: secim
---
title: Basarili Windows Girisi
id: 7f3e1d2c-8b9a-4c5d-a6e7-f8091a2b3c4d
name: basarili_giris
logsource:
    product: windows
    service: security
detection:
    secim:
        EventID: 4624
    condition: secim

Dosyayı aşağıdan yukarı oku. En alttaki iki temel kural tek olay tarif eder: hatali_giris 4625'i, basarili_giris 4624'ü seçer. Ortadaki value_count kuralı, aynı IpAddress için on dakikada kaç farklı TargetUserName görüldüğünü sayar.

Sayılacak alan condition altında field anahtarıyla, eşik de gte: 10 ile yazılır. En üstteki temporal_ordered kuralı iki olayın aynı kaynakta ve bu sırayla gelmesini ister. generate: true yazmazsan temel kurallar ayrı sorguya dönüşmez, yalnız korelasyonların sorgusu çıkar.

condition satırına | count() > 5 yazılan eski biçim, belirtimin 2.0 sürümüyle kalktı. Her arka uç her korelasyon türünü de çevirmez. Splunk arka ucunun 2.1.0 sürümü temporal_ordered için "not supported by backend" hatası verir, sırayı gözetmeyen temporal türünü ise çevirir. Zinciri üretime almadan önce geçmiş veride dene; aşağıdaki sorgular value_count mantığını Splunk ve KQL ile elle kurar.

# Splunk
index=wineventlog EventCode=4625 earliest=-30d@d latest=@d
| bin _time span=10m
| stats dc(TargetUserName) as hesap by _time IpAddress
| where hesap>=10
| stats count as alarm by IpAddress
| sort - alarm

# KQL (Microsoft Sentinel)
SecurityEvent
| where TimeGenerated > ago(30d) and EventID == 4625
| summarize hesap = dcount(TargetAccount) by bin(TimeGenerated, 10m), IpAddress
| where hesap >= 10
| summarize alarm = count() by IpAddress
| order by alarm desc

IpAddress        alarm
10.0.8.15           97
10.0.8.16            9
203.0.113.77         4

Buna geriye dönük deneme (backtest) denir. Soru basittir: kural son otuz günde çalışsaydı kaç alarm üretirdi ve kaçı bilinen gerçek olaylara denk gelirdi? Sorgu olayları on dakikalık kovalara böler, her kova ve kaynak için farklı hesap sayısını bulur, eşiği geçen kovaları kaynak başına toplar.

KQL'deki dcount bir tahmindir; bine kadar farklı değeri tam sayar, çok büyük kümelerde yüzde 0,8 civarında sapar. Tabloyu oku. Otuz günde 110 alarm çıktı, yani günde dört civarı.

Alarmların çoğu 10.0.8.15'ten geliyor. Varlık envanterine göre bu adres terminal sunucusudur; sabah onlarca kullanıcı aynı makineden oturum açar, bir kısmı parolasını yanlış yazar. 10.0.8.16 aynı kümenin ikinci sunucusudur. 203.0.113.77 ise dış adrestir; önce bu satırı incele.

Terminal sunucusunu tümden dışlama. İstisnayı davranışa bağla: bu kaynak, mesai başlangıcı, yirmi beşten az hesap. Böylece o makineden gelen gerçek bir püskürtme görünür kalır.

Alarmın yanına ne yapılacağını yaz. İyi bir alarm üç şey taşır: ne olduğu, neden önemli olduğu ve ilk kontrol adımı. Bu not yoksa her analist aynı soruları baştan sorar ve inceleme süresi iki katına çıkar.

Not bir kez yazılır, yüzlerce kez okunur. Triyaj notu da aynı mantıkla doldurulur, ama bu kez notu analist yazar. Dört bölümü vardır: ne oldu, neden önemli, ilk üç kontrol ve kapanış etiketi.

Kapanış etiketi karar tablosundan gelir. Etiket boş kalırsa kesinlik hesaplanamaz, kuralın sağlığı da ölçülemez. Aşağıda doldurulmuş bir not var.

Alarm         : Çok hesap denemesinin ardından başarılı giriş
Kaynak        : 10.0.8.23 (ws-satis-12)
Ne oldu       : 09:12-09:19 arasında 14 farklı hesaba hatalı giriş (4625).
                09:20'de satis04 hesabıyla başarılı ağ girişi (4624, LogonType 3).
Neden önemli  : Parola püskürtmesi tutmuş olabilir; satis04 artık saldırganın elinde olabilir.
İlk üç kontrol:
  1. satis04 için 09:20 sonrası 4624 ve 4688 olayları: nereye girdi, ne çalıştırdı?
  2. ws-satis-12 kimin makinesi, o saatte kullanıcı masasında mıydı?
  3. Aynı kaynakta önceki günlerde benzer desen var mı?
Kapanış       : Gerçek pozitif, olay kaydına dönüştü (OLY-2026-031)

Notu okuyan ikinci analist ne olduğunu, neden önemli olduğunu ve hangi kontrollerin yapıldığını hemen görür. Kapanış satırı da vakayı olay kaydına bağlar. Aynı alarm başka bir gün yanlış pozitif çıkabilir. O zaman kapanış satırına gerekçeyi yazarsın: kaynak bir kiosk bilgisayarıdır, vardiya değişiminde on dört çalışan sırayla giriş yaptı ve bazıları parolasını yanlış yazdı.

Gerekçesiz kapanış, haftalık ölçümde anlamsız bir sayıya döner. Bu üç unsur eksikse ekip sınıflandırma anında da tökezler. Alarmın ne olduğunu bilmeyen analist bağlama değil, kısıtlı belleğine güvenir.

Somut bir vaka düşün. Muhasebe biriminde her ayın ilk iş günü toplu rapor betiği çalışır ve PowerShell alarmı yağdırır. Ekip iki ay bu alarmları elle kapatır.

Üçüncü ay gerçek bir makro saldırısı aynı saatte gelir ve aynı refleksle kapatılır. Doğru hamle alarmı susturmak değil, kök nedeni düzeltmektir: betik kodlanmış komut yerine imzalı bir betik dosyası olarak çalışabilir. Kök neden düzelene kadar dar bir istisna açarsın. Makineyi tümden istisnaya alma; saldırgan o makineyi bulduğu an kural kör olur.

Dışlamayı davranışa bağla: şu hesap, şu betik, şu saat aralığı. Her istisnanın bir kaydı ve son kullanma tarihi olsun: kim istedi, kim onayladı, neden ve ne zamana kadar. Tarih dolunca istisna düşer ve gerekçe yeniden sorulur. Gerekçesiz daraltma altı ay sonra kimsenin savunamadığı bir körlüğe döner.

istisna    : IST-2026-014
kural      : PowerShell kodlanmış komut
kapsam     : hesap=svc_rapor, betik=aylik_rapor.ps1,
             saat=ayın ilk iş günü 07:00-09:00, makine=ws-muhasebe-*
gerekçe    : Muhasebenin aylık rapor betiği kodlanmış komutla çalışıyor
isteyen    : Muhasebe BT sorumlusu
onaylayan  : SOC ekip lideri
başlangıç  : 2026-09-01
bitiş      : 2026-12-01 (kök neden düzelince erken kapanır)

Yanlış negatif de aynı masada durur. Gürültüyü keserken kuralı fazla daraltırsan gerçek saldırıyı kaçırırsın. Eşik yükseltmek bu yüzden hep bir takastır. Kaçırma maliyeti yüksek tekniklerde biraz gürültüye katlanmak akıllıca bir seçimdir.

Her daraltma kararından önce şu soruyu sor: bu değişiklik hangi gerçek saldırıyı görünmez yapar? Cevabı, tarihi ve kararı vereni kuralın notuna yaz. Alarmları önem düzeyine göre de ayır ve her düzeye bir süre sözü ver.

Yüksek düzey on beş dakikada, orta düzey aynı vardiyada incelenir, düşük düzeye haftada bir toplu bakılır. Söz verilmeyen düzey, pratikte hiç incelenmeyen düzeydir.

Kuralları yaşayan varlık say ve haftada bir kural sağlık panosuna bak. Pano kural başına üç sayı gösterir: haftalık alarm, gerçek pozitif oranı ve ortalama inceleme süresi. Çok alarm üretip az gerçek bulan kural daraltılmayı bekler. Hiç alarm üretmeyen kural ise ya ölüdür ya da kaynağı akmıyordur.

Dikkat et: sıfır alarmlı kural aşağıdaki tabloda hiç görünmez, çünkü stats yalnız var olan satırları sayar. Kaynağın akıp akmadığını ayrı bir sorguyla denetlersin. Aynı makine her gün aynı alarmı üretiyorsa sorun kuralda değil, o makinenin yapılandırmasında olabilir.

index=vaka_kayitlari earliest=-7d
| stats count as alarm
        count(eval(kapanis="gercek_pozitif")) as tp
        avg(inceleme_dk) as ort_dk by kural
| eval kesinlik = round(tp / alarm * 100, 1)
| sort - alarm

kural                          alarm    tp   ort_dk   kesinlik
Mesai disi VPN girisi            212     4      5.8        1.9
Cok hesap ardindan giris          19     8     14.2       42.1

# Sessiz kaynak denetimi
| tstats latest(_time) as son where index=wineventlog earliest=-30d by host
| eval sessiz_saat = round((now() - son) / 3600, 1)
| where sessiz_saat > 24

condition:
    gt: 5
# yerine
condition:
    gt: 10