DLP'de Yanlış Alarm (False Positive) — Nasıl %5 Altında Tutulur?

DLP yazılımı kullanmaya başlayan şirketlerin #1 şikayeti: “her şeyi engelliyor, çalışanlar işini yapamıyor”. Bu yanlış alarm (false positive) problemidir. İyi bir DLP %5 altı false positive ile çalışır; kötüsü %30+‘lara çıkar ve nihayetinde kapatılır.

False positive nedir?

DLP’nin “hassas veri” diye yanlış işaretlediği aslında zararsız içerik. Örnekler:

• Stock photo dosya adı: “IMG_12345678901.jpg” → 11 hane → TC kimlik sandı
• Test verisi: “12345 67890 12345 6789” → kredi kartı sandı (Luhn geçer)
• E-posta imzasındaki telefon → her gönderim flag oldu

False positive olmadan DLP olmaz, ama %5+‘a çıkarsa gerçek alarm kaybolur (alarm fatigue).

Neden olur?

5 ana sebep:

1. Sadece regex kullanan DLP: regex bağlam görmez. “Sipariş no: 12345678901” cümlesinde 11 hane var ama TC değil. Regex bunu ayırt edemez.

2. Türkçe NER eksikliği: yabancı DLP’ler “Mehmet” kelimesinin Türk ad olduğunu bilmez. İngilizce NER modeli “Mehmet”i organization olarak işaretler, yanlış kategoriye sokar.

3. Bağlam görmezden gelme: Outlook imzasındaki telefon her e-postada flag olur. Aslında “her zaman var, sızıntı değil” bağlamı eksik.

4. Çok sıkı politika: “1 telefon numarası bile yeter” deyince her e-posta flag olur (imza, müşteri yanıtı, vb.).

5. Test/demo verisi: development PC’lerinde fake data var, prod gibi flag olur.

Ölçüm

False positive oranı:

FP oranı = (Yanlış alarm sayısı) / (Toplam alarm sayısı)

Tipik dağılım:

• Kötü DLP: %30-50 FP
• Orta DLP: %10-20 FP
• İyi DLP: %3-7 FP
• Mükemmel DLP: %1-3 FP

%10+ varsa kullanıcılar 1-2 hafta içinde DLP’yi sabote eder (manuel kapatma, agent kill, bypass).

Azaltma teknikleri — 8 yöntem

1. 3 katmanlı pipeline kullan

Sadece regex → %30+ FP. Regex + NER + sözlük kombinasyonu → %5 altı.

VeritaDLP pipeline’ı zaten 3 katmanlı (Regex → BERT NER → TÜİK sözlük). Her katman önceki katmanın yanlışlarını düzeltir.

2. Algoritma doğrulaması yap

11 hane = TC değildir; mod-10 check digit geçerse TC’dir.

• TC kimlik: mod-10
• Kredi kartı: Luhn algoritması
• IBAN: mod-97
• VKN: mod-10

Bu doğrulamayı yapan DLP %50 az FP üretir.

3. Bağlam pencereleri tanımla

PII çevresindeki kelimelere bak:

• “TC: 12345678901” → muhtemelen gerçek TC
• “Sipariş no: 12345678901” → muhtemelen sipariş kodu

Önündeki/arkasındaki 10 kelime bağlam sağlar.

4. Adres/imza istisnası

Outlook signatura, sales pitch dosyaları, footer’lar → ayrı liste tutup atla.

Şablonu:

exception_zones:
  - email_signature_block
  - file_footer_last_500_bytes
  - filename_metadata

5. Threshold ayarla (sayım eşiği)

“1 TC kimlik bile yeter” yerine “10+ TC kimlik”. Tek bir referans büyük olasılıkla normal yazışma; toplu liste sızıntı şüphesidir.

6. Tenant özel sözlük (allowlist)

Şirket terimleri kendi sözlüğüne eklensin:

• Müşteri firma adları
• Proje kodları (örn. “AY-2026-001”)
• İç sistem kullanıcı adları

Bu kelimeler PII olarak işaretlenmez.

7. Departman bazlı politika

Pazarlama: e-postada müşteri TC olması doğal (yanıt verir). Block etme. Muhasebe: Excel’de toplu TC listesi → block.

Aynı politika herkese uygulanmaz.

8. User feedback loop

Kullanıcı “bu false positive, sızıntı değil” işaretleyebilmeli. Bildirim audit log’a düşer, politika ekibi 7 günde 1 review yapar, politikayı ayarlar.

Pratik örnek — 30 günlük FP azaltma yolculuğu

Hafta 1: Default politika ile başla, FP oranı %22 (kötü).

Hafta 2: Sayım threshold 1 → 5 yap. FP %22 → %14.

Hafta 3: 3 katmanlı pipeline aktif (regex + NER + sözlük). FP %14 → %8.

Hafta 4: Departman bazlı politika (pazarlama/muhasebe ayrı). FP %8 → %4.

1 ay sonra: FP < %5, alarmlara güven artar, kullanıcı şikayet %80 azaldı.

Yaygın 2 yanlış

Yanlış 1 — “FP olmasın diye politikayı gevşetelim”. Sonuç: gerçek sızıntı kaçar. Yanlış cevap.

Yanlış 2 — “Her flag manuel inceleme”. 200 PC’li ofiste günde 1000 alarm gelir. Manuel inceleme imkansız. Önce FP azaltılır, sonra kalan alarmlar manuel.

VeritaDLP yaklaşımı

VeritaDLP’de FP azaltma 4 mekanizma ile sağlanır:

1. 3 katmanlı pipeline (Regex + Türkçe BERT NER + TÜİK sözlük)
2. Algoritma doğrulama (TC mod-10, Luhn, IBAN mod-97)
3. Bağlam penceresi (PII öncesi/sonrası 10 kelime)
4. Tenant özel sözlük (Custom dictionary yükleme)

Pilot şirketlerimizde 30 gün sonunda FP oranı %3-5 aralığında oturur.

Sonuç

False positive DLP’nin kaderi değil, tasarım kararı. 3 katmanlı pipeline + algoritma doğrulama + departman bazlı politika kombinasyonu %5 altına çekmek mümkündür.

Bir DLP demo’sunda mutlaka kendi şirket verinizle test edin — vendor demo’da kontrollü veri kullanır, gerçek FP oranı görmek için POC zorunludur.