Kurumsal ortamlarda SIEM maliyeti çoğu zaman lisans kaleminden değil, kontrolsüz büyüyen telemetry akışından patlar. Uygulamalar, altyapı servisleri, güvenlik duvarları, uç cihazlar ve bulut servisleri aynı havuza ölçüsüz veri akıttığında iki sorun aynı anda doğar: kritik olayların bulunması zorlaşır ve operasyon ekibi gereksiz veriyi taşımak için sürekli bütçe savunur. Sampling stratejisi bu yüzden yalnızca maliyet düşürme tekniği değildir; güvenlik görünürlüğünü koruyan mimari karardır.
Sampling neden yanlış anlaşılıyor?
Sampling çoğu ekipte “daha az log gönder” şeklinde ele alınır. Bu yaklaşım tehlikelidir, çünkü hangi olayların güvenlik, hangi olayların operasyon, hangi olayların adli analiz için gerekli olduğu sınıflandırılmaz. Sonuçta ya kritik veri kaybolur ya da gerçekten işe yaramayan veri tutulmaya devam eder.
Doğru yaklaşım, telemetry akışını önce sınıflandırmaktır:
- Güvenlik açısından zorunlu olaylar
- Operasyonel hata ve kapasite olayları
- Yüksek hacimli ama düşük değerli debug veya access olayları
- Yasal saklama gerektiren kayıtlar
Bu ayrım yapılmadan sampling kararı almak, veri mimarisini körleştirmek anlamına gelir.
Hangi veriler asla örneklenmemeli?
Her veri seti aynı değerde değildir. Aşağıdaki sinyaller genellikle tam saklama gerektirir:
- Kimlik doğrulama ve yetkilendirme olayları
- Ayrıcalıklı erişim yükseltmeleri
- Politika ihlali ve reddedilen erişim kayıtları
- Kritik altyapı değişiklikleri
- Üretim ERP veya finans sistemlerindeki yönetimsel işlemler
Özellikle başarısız girişler, rol değişiklikleri ve güvenlik politikası kararları daha sonra olay korelasyonunda temel veri olur. Bunları örneklemek, olay inceleme zincirini kırar.
Nerede agresif sampling yapılabilir?
En büyük hacim genelde access log, health check ve tekrar eden başarı kayıtlarından gelir. Burada bağlamsal sampling uygulanabilir:
- Sağlıklı servislerden gelen
200erişim loglarının yüzde 1 ila 5’i tutulur - Aynı kullanıcı aracısından gelen tekrarlı probe istekleri gruplanır
- Kubernetes readiness veya liveness çağrıları ayrı hatta yönlendirilir
- CDN veya WAF üzerinde zaten tutulan veriler uygulama katmanında tekrar saklanmaz
Bu yöntemde amaç veri kaybetmek değil, aynı bilginin çok sayıda kopyasını azaltmaktır.
Mimari karar noktaları
Kurumsal SIEM sampling stratejisi oluştururken dört tasarım sorusu kritik hale gelir.
1. Karar ingestion öncesinde mi, sonrasında mı verilecek?
Ingestion öncesi sampling maliyet avantajı sağlar ama yanlış karar geri alınamaz. Ingestion sonrası karar daha esnektir fakat ham veri katmanı için ek depolama ister. Yüksek regülasyonlu yapılarda kısa süreli ham veri tamponu çoğu zaman daha güvenlidir.
2. Kural kaynağı kim olacak?
Sampling kuralları sadece SOC ekibinin kararıyla yönetilmemelidir. Ağ, platform, uygulama ve uyumluluk tarafı ortak karar vermezse kritik kullanım durumları atlanır.
3. Olay önceliği nasıl kodlanacak?
Kaynaklar critical, important, routine gibi bir telemetri öncelik alanı üretirse yönlendirme ve saklama politikaları sadeleşir.
4. Geri besleme nasıl toplanacak?
SOC analistlerinin en sık aradığı ama bulamadığı olay tipleri düzenli raporlanmazsa sampling politikası giderek körleşir.
Uygulanabilir bir referans model
Sahada iyi çalışan model genellikle üç katmanlıdır:
hot: Kimlik, güvenlik kontrolü ve olay müdahalesi için gereken veri. Tam saklama.warm: Operasyon ve kapasite analizleri için gereken veri. Seçici sampling.cold: Ham veya regülasyon amaçlı arşiv. Ucuz depolama, yavaş erişim.
Bu modelde telemetry üreticisi değil, merkezi pipeline hangi verinin nereye gideceğini belirler. Böylece uygulama ekipleri her servis için farklı log politikası yazmak zorunda kalmaz.
ERP ve kurumsal çekirdek sistemler için özel durum
ERP tarafında düşük hacimli ama yüksek etkili olaylar bulunur. Yetki atamaları, batch job tetiklemeleri, kritik tablo export işlemleri veya entegrasyon kullanıcılarının beklenmeyen erişimleri mutlaka tam saklanmalıdır. Burada sampling yapılacak alanlar genelde teknik başarı loglarıdır; iş etkisi yüksek kayıtlar değil.
Bu ayrımı yapabilmek için iş akışını bilen mimarlar ile güvenlik ekiplerinin aynı tablo üzerinde çalışması gerekir. Aksi halde ERP telemetry’si ya gereğinden fazla tutulur ya da en önemli olaylar sadeleştirme sırasında kaybolur.
Sonuç
Kurumsal SIEM için sampling stratejisi, log azaltma projesi değil görünürlük tasarımıdır. Hangi sinyalin olay müdahalesi, hangi sinyalin kapasite yönetimi, hangi sinyalin yalnızca arşiv değeri taşıdığı netleştirildiğinde hem maliyet hem analist verimliliği iyileşir. En doğru başlangıç noktası, “hangi logları keselim” sorusu değil, “hangi kararları bu veriye dayanarak veriyoruz” sorusudur.