SIEM, güvenlik operasyonlarının merkezinde duran olay tespiti, korelasyon soruşturma süreçlerini arada yürüten kritik katmandır. Ancak sahada gözlemlediğimiz tablo şunu gösteriyor: pek çok kurumda SIEM, doğru beslenmesi gereken analiz platformu olmaktan çıkıp, her türlü logun olduğu gibi boşaltıldığı toplama noktasına dönüşmüş durumda. yaklaşım hem maliyetleri hem analist iş yükünü hızla büyütüyor. Maliyet tartışmasına girmeden önce, sorunun aslında nerede başladığına bakmak gerekiyor.
SIEM maliyetlerindeki artışı genellikle lisans veya ücretlendirme tartışmasına indirgeriz. Oysa asıl mesele teknik mimaridedir. Cloud, endpoint, identity, firewall, EDR, proxy, DNS, VPN, SaaS uygulama loglarının her biri kendi içinde katlanarak büyüyor. Tek başına EDR ajanı günde milyonlarca event üretebilir; reverse proxy katmanı ya DNS çözümleyici, normal trafikte bile devasa hacimlerde kayıt oluşturur. kaynakların ham verisi hiçbir ön işlemden geçmeden doğrudan SIEM’e aktarıldığında, ingestion hacmi gerçek güvenlik değeriyle orantısız biçimde şişer.
Sorunu derinleştiren birkaç teknik etken. Birincisi, tekrar eden (duplicate) düşük değerli event’lerin ayrıştırılmadan saklanması: aynı bağlantı için tekrar tekrar üretilen “allow” kayıtları, periyodik heartbeat mesajları veya bilgi amaçlı (informational) event’ler çoğu zaman saklama değeri taşımaz. İkincisi, yanlış retention indeksleme politikaları. Her logun aynı sıcaklıkta aynı süre boyunca indekslenmesi, çoğu SIEM’in maliyet modelinde doğrudan depolama işleme yüküne dönüşür.
Belki en kritik etken normalizasyon eksikliğidir. Normalize edilmemiş, alanları (field) tutarsız event yapıları detection rule yazımını, korelasyonu investigation süreçlerini zorlaştırır. Aynı kavramın farklı kaynaklarda farklı isimlerle gelmesi — örneğin kullanıcı kimliğinin logda user, diğerinde account_name, başka birinde src_user olarak görünmesi — analisti her sorguda manuel eşleştirmeye zorlar. Sonuçta analist, gürültü içinde anlamlı sinyali aramak için daha fazla zaman harcar. Yani maliyet yalnızca faturaya değil, MTTD MTTR gibi operasyonel metriklere yansır.
SIEM’den Önce: Telemetry Pipeline Katmanınoktada mimari sadeleşme öneriliyor: logların SIEM’e ulaşmadan önce geçtiği telemetry pipeline katmanı. katman, ham veriyi olduğu gibi iletmek yerine onu işleyerek değer kazandırır SIEM’in yalnızca analiz değeri olan veriyle beslenmesini sağlar.
Tipik pipeline işlevleri sırayla ya ihtiyaca göre üstlenir:
- Toplama (collection): Heterojen kaynaklardan, agent’lı veya agent’sız biçimde log alımı.
- Parsing: Yapısal olmayan ham metnin alanlara ayrıştırılması.
- Filtering: Düşük değerli veya gürültülü event’lerin kaynağa en yakın noktada elenmesi.
- Normalization: Alan adlarının değer formatlarının ortak şemaya (örneğin OTel semantic conventions veya kurum içi veri modeli) hizalanması.
- Enrichment: Event’e GeoIP, asset bilgisi, kullanıcı bağlamı veya threat intel eşleşmesi gibi ek bağlam eklenmesi.
- Masking/redaction: KVKK benzeri regülasyonlar gereği hassas alanların maskelenmesi veya temizlenmesi.
- Deduplication: Tekrar eden kayıtların tekilleştirilmesi.
- Buffering: Ağ kesintisi veya hedef yavaşlığında veri kaybını önleyen disk/bellek tamponlaması.
- Routing multi-destination forwarding: Verinin içeriğine göre farklı hedeflere yönlendirilmesi.
yapının en kritik kazanımı, çok hedefli (multi-destination) yönlendirmedir. Yüksek güvenlik değeri taşıyan kritik loglar SIEM’e iletilirken; compliance amacıyla saklanması gereken ancak gerçek zamanlı analizi gerekmeyen düşük öncelikli loglar object storage, data lake veya arşiv tarafına yönlendirilebilir. Böylece “sıcak” analiz katmanı “soğuk” saklama katmanı ayrışır her veri kendi gerçek değerine uygun maliyetle tutulur.
Community Commercial Yaklaşımların Dengeli Kullanımıpipeline katmanını kurarken birden fazla araç değerlendirilebilir ekosistem son dönemde belirgin biçimde olgunlaştı.
NXLog tarafında dikkat edilmesi gereken nokta var: NXLog Community Edition uzun yıllardır yaygın kullanılan log toplama aracı olsa artık yalnızca ara sıra bakım güncellemesi alıyor üretici, ürün ailesini NXLog Platform yeni nesil agent etrafında konumlandırıyor. Pratikte anlama gelir: Community Edition temel log toplama, parse etme, dönüştürme SIEM’e yönlendirme senaryolarında hâlâ işlevsel başlangıç noktasıdır, ancak uzun vadeli kritik kurulumlarda sürüm yaşam döngüsünü göz önünde bulundurmak gerekir. Enterprise/commercial tarafta ise binlerce agent’ı merkezi web konsolundan yönetebilme, gelişmiş modül desteği profesyonel destek gibi avantajlar öne çıkar.
manzarayı tamamlayan başka açık /community araçlar Fluent Bit, düşük tüketimiyle özellikle Kubernetes container ortamlarında öne çıkar. OpenTelemetry Collector, log/metric/trace verisini ortak standartta toplayıp işleme konusunda giderek endüstri ortak paydasına dönüşüyor. Vector ise yüksek performanslı dönüştürme routing senaryolarında değerlendirilebilen başka seçenek.
Burada “en iyi” ya “tek doğru” araçtan söz etmek yanıltıcı. Teknik karar; kurumun log kaynaklarına, regülasyon ihtiyacına, ekip yetkinliğine, mevcut SIEM mimarisine operasyonel olgunluğuna göre verilmelidir. Çoğu olgun kurumda gerçek mimari, tek aracın değil, araçların farklı katmanlarda arada kullanıldığı hibrit yapının üzerine kuruludur.
Gerçek Hayattan Use Case’lerWindows Event. Tüm event akışını SIEM’e basmak yerine yalnızca güvenlik açısından anlamlı event ID’lerini (örneğin oturum açma, yetki yükseltme, hesap değişiklikleri) iletmek; bilgi amaçlı tekrar eden event’leri pipeline katmanında filtrelemek hem hacmi hem gürültüyü ciddi biçimde azaltır.
VPN identity korelasyonu. Başarısız VPN giriş denemeleri normalize edilip ortak kullanıcı kimliği alanına hizalandığında, identity dizin (directory) loglarıyla korelasyona hazır hale gelir. Böylece kısa sürede çok sayıda başarısız denemenin ardından gelen başarılı giriş gibi şüpheli erişim örüntüleri SIEM tarafında çok daha hızlı yakalanır.
Kubernetes/container logları. Ham container çıktısı tek başına analist için anlam taşımaz. Pipeline katmanında pod, namespace service metadata’sı enrichment yapıldığında, SIEM’e ulaşan her satır hangi iş yüküne ait olduğu bağlamıyla gelir soruşturma süresi belirgin biçimde kısalır.
DNS logları. Tüm ham DNS verisini SIEM’e aktarmak yerine; suspicious domain eşleşmeleri, NXDOMAIN spike’ları veya threat intel eşleşmeleri önceliklendirilerek iletilebilir. Geri kalan hacimli veri, ihtiyaç halinde geriye dönük araştırma için arşiv/data lake tarafında tutulabilir.
SonuçSIEM’e daha fazla veri göndermek her zaman daha iyi görünürlük anlamına gelmez. Çoğu zaman daha az ama normalize edilmiş, bağlamı zenginleştirilmiş doğru hedeflenmiş veri; analist verimliliğini, detection kalitesini operasyonel sürdürülebilirliği artırır. yüzden SIEM maliyet optimizasyonu yalnızca bütçe konusu değil; veri mühendisliği, güvenlik operasyonları mimari yönetişim konusudur. Telemetry pipeline katmanı, üç disiplini birbirine bağlayan teknik zemindir. SIEM’i optimize etmenin ilk adımı, SIEM’e ne gönderdiğimizi sorgulamaktır.
