Alarm yorgunluğu, bir gece vardiyasında yüzlerce “olası port taraması” bildirimini tek tek kapatan analistin, aynı listenin ortasındaki tek bir “olağandışı DNS sorgu hacmi” kaydını da refleksle kapatmasıyla somutlaşır. O kayıt aslında bir komuta kontrol kanalının (C2, command and control) düzenli sinyal trafiğiydi; saldırgan sekiz gün boyunca ağ içinde serbest dolaştı. Olay sonrası incelemede kimse “tespit yoktu” diyemedi, çünkü tespit vardı — sadece dört yüz alarmın arasında görünmez hale gelmişti.

Bu tablo teknoloji eksikliğinden değil, kural setinin yıllar içinde denetimsiz büyümesinden doğar. Her yeni ürün kendi hazır kural paketini getirir, her denetim bulgusu için bir kural daha eklenir, hiçbir kural da kaldırılmaz. Sonuçta SIEM konsolu, saldırıyı gösteren bir gösterge paneli olmaktan çıkıp arşiv haline gelir. Kural setini sadeleştirmek, tespit kabiliyetinden feragat etmek anlamına gelmez; aksine hangi kuralın hangi saldırgan davranışını kanıtladığını bilerek kalanı budamak demektir.

Alarm yorgunluğu bir kapasite değil, tasarım sorunudur

Ekip büyütmek gürültüyü azaltmaz, sadece gürültüyü bölüşür. Günde 3.000 alarm üreten bir kurulum, analist sayısı ikiye katlandığında kişi başına 1.500 alarm üretmeye devam eder ve karar kalitesi yine düşer. Asıl sorun, alarmların çoğunun bir eylem gerektirmemesidir: teyit edilemeyen, bağlamı olmayan, sahibi belirsiz bildirimler.

Sağlıklı bir tespit tasarımında her kuralın üç sorusu yanıtlıdır: Bu kural tetiklendiğinde analist ne yapacak? Yanıt “bakıp kapatacak” ise o kural bir alarm değil, olsa olsa bir zenginleştirme verisidir. İkincisi, bu kural hangi saldırgan tekniğini kanıtlıyor? Üçüncüsü, kural yanlış tetiklendiğinde bunu kim, hangi sürede fark edecek? Olgun kurumlar bu üç soruyu bir tespit mühendisliği disiplini haline getirir; sürecin kurgulanmasında kurumsal siber güvenlik danışmanlığı desteği almak, kural envanterini kurum dışından bakan bir gözle gözden geçirmeyi kolaylaştırır.

Kural setinizin şiştiğini gösteren ölçülebilir işaretler

Sezgi yerine sayıya bakın. Aşağıdaki eşikler mutlak doğrular değil, çoğu kurumda hızlı teşhis sağlayan pratik göstergelerdir:

• Kapatılan alarmların büyük çoğunluğu “yanlış pozitif” veya “beklenen davranış” etiketiyle sonlanıyorsa kural mantığı değil, kural varlığı sorgulanmalıdır.
• Tek bir kural toplam alarm hacminin kayda değer bir dilimini üretiyorsa, o kural bir tespit değil bir sayaçtır.
• Son altı ayda hiç gerçek olayla ilişkilenmemiş kurallar, gerekçesi yazılı değilse aday budama listesindedir.
• Alarmların vardiya devrine sarkma oranı artıyorsa kuyruk büyümesi başlamış demektir.
• Aynı olayı farklı isimlerle üç ayrı kural bildiriyorsa korelasyon değil, çoğaltma yapılıyordur.

Gürültüyü kaynağında kesmek: veri kalitesi ve kapsam hijyeni

Kötü kuralın altında çoğu zaman kötü log yatar. Zaman damgaları farklı saat dilimlerinde gelen, varlık envanteriyle eşleşmeyen, kullanıcı kimliği taşımayan kayıtlar üzerine kurulan hiçbir kural güvenilir olamaz. Sadeleştirmeye kuraldan değil veriden başlamak gerekir.

• Log kaynaklarını kritiklik sırasına koyun: kimlik doğrulama, uç nokta telemetrisi, dizin hizmeti, güvenlik duvarı ve proxy, bulut yönetim düzlemi.
• Her kaynağın alan eşlemesini (field mapping) doğrulayın; kullanıcı, ana bilgisayar ve süreç adı alanları boş geliyorsa kural yazmadan önce bunu düzeltin.
• Varlık envanterini tespit platformuna bağlayın; sunucu mu istemci mi olduğu bilinmeyen bir makinede “olağandışı” tanımı yapılamaz.
• Test, geliştirme ve zafiyet tarama kaynaklarını etiketleyin; bunları susturmak yerine ayırın, çünkü saldırgan da test ağını kullanır.

Kural setini sadeleştirmenin adım adım yol haritası

1. Envanter çıkarın. Tüm aktif kuralları tek tabloda toplayın: ad, kaynak, son 90 gündeki tetiklenme sayısı, gerçek olayla eşleşme sayısı, sahibi.
2. Sınıflandırın. Her kuralı “müdahale gerektirir”, “araştırma başlatır”, “yalnızca zenginleştirme” ve “ölü” olarak işaretleyin. Yalnızca ilk iki sınıf analiste alarm olarak düşmelidir.
3. Yüksek hacimli ilk on kuralı ele alın. Gürültünün büyük kısmı genellikle küçük bir kural kümesinden gelir; buradan başlamak en hızlı kazanımı verir.
4. Kaldırmadan önce daraltın. Kuralı silmek yerine kapsamını netleştirin: hangi varlık grubunda, hangi saatte, hangi kimlik türü için anlamlı?
5. İstisnaları merkezî ve süreli tanımlayın. Her istisnanın gerekçesi, sahibi ve son kullanma tarihi olsun; süresiz istisna kalıcı kör noktadır.
6. Değişikliği izleyin. Her sadeleştirme sonrası iki hafta boyunca alarm hacmi, doğrulama oranı ve kaçırılan tespit belirtilerini karşılaştırın.
7. Sürüm yönetimine alın. Kural değişikliklerini kod deposunda tutun; kim, ne zaman, hangi gerekçeyle değiştirdi sorusu her zaman yanıtlanabilir olsun.

MITRE ATT&CK ile kapsama haritası çıkarmak

Budama işleminin en büyük riski, gürültüyü azaltırken görünürlüğü de azaltmaktır. Bunu önlemenin yolu, kuralları MITRE ATT&CK matrisi üzerine oturtmaktır. Her kuralı bir veya birkaç tekniğe eşleyin; ardından hangi taktik sütunlarının boş kaldığına bakın.

Pratikte sık karşılaşılan tablo şudur: kimlik bilgisi erişimi ve kalıcılık sütunlarında onlarca kural birikirken, yanal hareket (lateral movement) ve veri sızdırma sütunları neredeyse boştur. Yani kurum en gürültülü alanı fazlasıyla, en kritik alanı ise eksik izler. Kapsama haritası, budama kararlarını “hangi kural çok bağırıyor” yerine “hangi teknik kanıtsız kalıyor” sorusuna dayandırır.

Tekil alarmdan olaya: korelasyon ve risk skorlaması

Analist alarmları değil olayları incelemelidir. Aynı kullanıcı, aynı makine veya aynı saldırı zinciri etrafında toplanan alarmlar tek bir vaka olarak açılmalıdır. Bir oltalama tıklaması, ardından gelen şüpheli süreç ve otuz dakika sonraki dizin sorgusu ayrı ayrı ikinci öncelikli üç alarmken, birleştiklerinde birinci öncelikli tek bir olaydır.

Risk skorlaması yaparken statik önem derecesi yerine bağlamı çarpan olarak kullanın:

• Varlık kritikliği: Alarm bir ödeme uygulaması sunucusundan mı, toplantı odası ekranından mı geliyor?
• Kimlik yetkisi: Etkilenen hesap standart kullanıcı mı, ayrıcalıklı yönetici mi?
• Davranışın nadirliği: Bu işlem kurumda her gün yüzlerce kez mi görülüyor, yoksa ilk kez mi?
• Zincir örtüşmesi: Aynı varlık veya kimlik etrafında son 24 saatte başka sinyal üretildi mi?

Bu yaklaşım, aynı teknik alarmın bir stajyer dizüstünde ile bir alan yöneticisi hesabında farklı ele alınmasını sağlar.

Sadeleştirmenin MTTD ve MTTR üzerindeki etkisi nasıl ölçülür

Kural budamanın başarısı “alarm sayısı azaldı” cümlesiyle kanıtlanmaz; azalma zaten hedeflenen şeydir. Ölçmeniz gereken, tespit ve yanıt sürelerinin ne yönde değiştiğidir.

• MTTD (ortalama tespit süresi): Saldırgan etkinliğinin başlangıcı ile ilk doğrulanmış alarm arasındaki süre. Sadeleştirme doğru yapıldıysa bu süre kısalır.
• MTTR (ortalama yanıt süresi): Doğrulamadan sınırlandırmaya kadar geçen süre. Kuyruk küçüldükçe düşer.
• Doğrulama oranı: İncelenen alarmların gerçek olayla sonuçlanma yüzdesi; sadeleştirmenin en dolaysız göstergesidir.
• Kapsama oranı: ATT&CK matrisinde en az bir kuralla izlenen teknik sayısının toplam hedef tekniklere oranı.
• Devir sarkması: Vardiya sonunda kapatılmamış alarm sayısı; kapasite dengesini gösterir.

Kural setini canlı tutmak: doğrulama ve purple team döngüsü

Sadeleştirme tek seferlik bir proje değildir. Kurum değiştikçe, yeni uygulamalar devreye girdikçe ve saldırgan teknikleri evrildikçe kural setinin yeniden ayarlanması gerekir. Bunun en güvenilir yolu, tespitleri gerçek saldırgan davranışına karşı sınamaktır.

Belirli sistemlerdeki teknik zafiyetleri bulmayı hedefleyen sızma testi genellikle bir-iki hafta sürerken, tespit ve yanıt kabiliyetini ölçen red team hizmeti iki ila altı haftalık bir kurgu ister; keşiften ilk erişime, yanal hareket ve yetki yükseltmeden hedef tamamlama ve raporlamaya kadar tüm zinciri kapsar. Çıktısı, hangi aşamada hangi alarmın ürediğini, hangisinin hiç üremediğini gösteren somut bir kayıttır. Kırmızı ve mavi takımın aynı masada oturduğu purple team oturumlarında bu bulgular kural revizyonuna dönüştürülür: susturulan teknikler yeniden kurala bağlanır, gereksiz kurallar gerekçesiyle kapatılır.

Sık sorulan sorular

Alarm yorgunluğu ile yanlış pozitif oranı aynı şey mi?

Aynı değil ama iç içedir. Yanlış pozitif, kuralın hatalı tetiklenmesidir; alarm yorgunluğu ise doğru tetiklenen ama eyleme dönüşmeyen alarmların birikmesiyle de oluşur. Bir kural teknik olarak doğru çalışıp yine de analiste hiçbir karar imkânı vermiyorsa yorgunluğa katkı yapıyordur.

Kural silmek denetimde sorun yaratır mı?

Gerekçesi belgelenmemiş silme sorun yaratır. ISO 27001 kapsamındaki bir kurumda beklenen şey kural sayısı değil, kararın kayıt altında olmasıdır: hangi kural neden kaldırıldı, yerine hangi kontrol geçti, kim onayladı. Sürüm yönetimi ve değişiklik kaydı bu soruların tamamını karşılar.

Sadeleştirme sırasında gerçek bir saldırıyı kaçırma riski nasıl yönetilir?

Kuralı doğrudan kapatmak yerine önce alarm üretmeyen “sessiz” moda alın ve iki hafta gözlemleyin. Bu sürede kuralın ürettiği kayıtları inceleyip gerçek bir sinyal taşıyıp taşımadığını görebilirsiniz. Kapsama haritasında o teknik başka bir kuralla da izleniyorsa risk belirgin biçimde azalır.

Küçük ekipler için hangi kural sayısı makuldür?

Sabit bir sayı vermek yanıltıcı olur; ölçü, ekibin bir vardiyada alarmları teyit edebilme kapasitesidir. Üç kişilik bir ekip için doğru sayı, günlük alarm hacminin incelenebilir düzeyde kalmasını sağlayan sayıdır. Kural sayısını değil, alarm başına harcanan ortalama süreyi ve devir sarkmasını takip edin.

Sonuç

Alarm yorgunluğunun çözümü daha fazla ekran, daha fazla kural veya daha fazla analist değil; her kuralın bir saldırgan davranışını kanıtladığı, her alarmın bir eylemi tetiklediği ve her istisnanın bir son kullanma tarihi taşıdığı disiplinli bir tespit mimarisidir. Kural envanterinizi çıkarıp ATT&CK kapsama haritanızla karşılaştırdığınız ilk gün, hangi kuralın sizi koruduğunu hangisinin yalnızca meşgul ettiğini görürsünüz — ve bu ayrımı yapmadan yapılan her yatırım gürültüyü satın almaktan öteye gitmez.

Bilgilendirme: Bu içerik genel bilgilendirme amaçlıdır; kurumunuzun risk profiline özel değerlendirme için uzman desteği alınmalıdır.