# Vaka İncelemesi: Yeni Bir EDR Politikası Nasıl Yanlış Pozitif Fırtınasına Dönüştü?

- Bağlantı: https://musti.org/vaka-incelemeleri/vaka-incelemesi-crowdstrike-yanlis-pozitif-firtinasi/
- Yayımlanma: 2026-09-23T23:51:09+03:00
- Yazar: mmutlu

🎧 Bu yazıyı dinleyebilirsiniz

Tarayıcınız ses oynatmayı desteklemiyor.

_📌 Bu vaka incelemesi, alanımda sıkça karşılaşılan bir sorun örgüsüne dayanan **
temsili bir anlatımdır** — belirli bir şirketi, kişiyi veya tarihi olayı tanımlamaz.
Gerçek mesleki deneyimlerimden ilham alan, öğretici amaçlı bileşik (composite) bir
örnektir._

## Durum

Bir güvenlik olayı sonrası (harici bir tedarikçide yaşanan bir ihlal haberinin ardından),
yönetim daha sıkı bir uç nokta güvenlik duruşu talep etti. CrowdStrike Falcon’da
davranışsal tespit politikalarını “Agresif” seviyeye çektim. İlk 48 saat içinde **
helpdesk’e gelen destek talebi sayısı üç katına çıktı** — muhasebe ekibinin makro
içeren Excel dosyaları, IT ekibinin PowerShell scriptleri ve hatta bazı meşru yazılım
güncellemeleri bloke edilmeye başlamıştı.

## İlk Baskı: Geri Al mı, Israrcı mı Ol?

Kullanıcı şikayetleri arttıkça, en kolay çözüm politikayı eski haline döndürmek 
olurdu. Ama bu, güvenlik iyileştirmesinin tamamen boşa gitmesi anlamına gelirdi.
[EDR’ın temel değer önerisinin](https://musti.org/crowdstrike/crowdstrike-falcon-nedir-uc-nokta-guvenligi-edr/)
davranışsal tespit olduğunu biliyordum — soru, bunu nasıl “gürültüsüz” hale getireceğimdi.

## Sistematik Yaklaşım: Kör Sıkılaştırma Yerine Veri Odaklı Ayar

Politikayı tamamen geri almak yerine, üç adımlı bir yaklaşım izledim:

 * **1. Sınıflandırma:** Son 48 saatteki tüm tespitleri (bloklananlar dahil) kategorilere
   ayırdım — gerçek tehdit, bilinen meşru araç (yanlış pozitif), belirsiz.
 * **2. İstisna listesi, kural gevşetme değil:** Yanlış pozitif olarak doğrulanan
   meşru araçlar (örneğin muhasebenin kullandığı imzalı bir makro aracı) için genel
   politikayı gevşetmek yerine, **spesifik, dar kapsamlı istisnalar** tanımladım.
   Bu, genel güvenlik duruşunu korurken sürtünmeyi noktasal olarak azalttı.
 * **3. Kademeli devreye alma:** Kalan agresif kuralları, tüm şirkete aynı anda 
   değil, önce BT ekibinin kendi cihazlarında bir hafta test ederek kademeli olarak
   yaygınlaştırdım.

## Zor Bir Karar: Hangi Riski Kabul Ediyoruz?

Bu süreçte öğrendiğim en önemli şey, EDR ayarlamanın aslında bir **risk kabul kararı**
olduğuydu. Her istisna, teorik olarak küçük bir güvenlik açığı anlamına geliyordu.
Bu yüzden her istisnayı güvenlik ekibi ve ilgili departman yöneticisiyle birlikte,
gerekçesini belgeleyerek onayladım — tek taraflı bir BT kararı değil, ortak bir 
risk değerlendirmesi haline getirdim.

## Sonuç

İki hafta içinde helpdesk talepleri normal seviyesine döndü, ancak davranışsal tespit
politikası “Agresif” seviyede kaldı — sadece belgelenmiş, dar kapsamlı istisnalarla
birlikte. Bir sonraki güvenlik denetiminde, hem sıkı politikanın hem de gerekçelendirilmiş
istisna listesinin varlığı olumlu değerlendirildi.

## Çıkarım

Güvenlik ile kullanılabilirlik arasındaki gerilim EDR’a özgü değil, ama bu vaka 
bana şunu öğretti: “sıkılaştır” ile “kullanılamaz hale getir” arasındaki fark, çoğunlukla**
istisna yönetiminin ne kadar disiplinli yapıldığında** yatıyor. Kör bir geri adım
yerine veriye dayalı, noktasal ayarlama, hem güvenliği korudu hem de operasyonel
sürtünmeyi ortadan kaldırdı.

_İlgili yazı: [CrowdStrike Falcon’a giriş](https://musti.org/crowdstrike/crowdstrike-falcon-nedir-uc-nokta-guvenligi-edr/)_