SIEM Maliyet Optimizasyonu: Daha Fazla Log Değil, Daha Akıllı Telemetry Pipeline

SIEM, güvenlik operasyonlarının merkezinde duran ve olay tespiti, korelasyon ile soruşturma süreçlerini bir arada yürüten kritik bir katmandır. Ancak sahada gözlemlediğimiz tablo şunu gösteriyor: pek çok kurumda SIEM, doğru beslenmesi gereken bir analiz platformu olmaktan çıkıp, her türlü logun olduğu gibi boşaltıldığı bir toplama noktasına dönüşmüş durumda. Bu yaklaşım hem maliyetleri hem de 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 ve uygulama loglarının her biri kendi içinde katlanarak büyüyor. Tek başına bir EDR ajanı günde milyonlarca event üretebilir; bir reverse proxy katmanı ya da DNS çözümleyici, normal trafikte bile devasa hacimlerde kayıt oluşturur. Bu 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 var. Birincisi, tekrar eden (duplicate) ve 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 ve indeksleme politikaları. Her logun aynı sıcaklıkta ve aynı süre boyunca indekslenmesi, çoğu SIEM’in maliyet modelinde doğrudan depolama ve işleme yüküne dönüşür.

Belki de en kritik etken normalizasyon eksikliğidir. Normalize edilmemiş, alanları (field) tutarsız event yapıları detection rule yazımını, korelasyonu ve investigation süreçlerini zorlaştırır. Aynı kavramın farklı kaynaklarda farklı isimlerle gelmesi — örneğin kullanıcı kimliğinin bir 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 ve MTTR gibi operasyonel metriklere de yansır.

SIEM’den Önce: Telemetry Pipeline Katmanı

Bu noktada mimari bir sadeleşme öneriliyor: logların SIEM’e ulaşmadan önce geçtiği bir telemetry pipeline katmanı. Bu katman, ham veriyi olduğu gibi iletmek yerine onu işleyerek değer kazandırır ve SIEM’in yalnızca analiz değeri olan veriyle beslenmesini sağlar.

Tipik bir pipeline şu işlevleri sırayla ya da 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 ve değer formatlarının ortak bir şemaya (örneğin OTel semantic conventions veya kurum içi bir 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 ve 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 ve multi-destination forwarding: Verinin içeriğine göre farklı hedeflere yönlendirilmesi.

Bu 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ı ile “soğuk” saklama katmanı ayrışır ve her veri kendi gerçek değerine uygun maliyetle tutulur.

Community ve Commercial Yaklaşımların Dengeli Kullanımı

Bu pipeline katmanını kurarken birden fazla araç değerlendirilebilir ve bu ekosistem son dönemde belirgin biçimde olgunlaştı.

NXLog tarafında dikkat edilmesi gereken bir nokta var: NXLog Community Edition uzun yıllardır yaygın kullanılan bir log toplama aracı olsa da artık yalnızca ara sıra bakım güncellemesi alıyor ve üretici, ürün ailesini NXLog Platform ile yeni nesil agent etrafında konumlandırıyor. Pratikte bu şu anlama gelir: Community Edition temel log toplama, parse etme, dönüştürme ve SIEM’e yönlendirme senaryolarında hâlâ işlevsel bir başlangıç noktasıdır, ancak uzun vadeli ve kritik kurulumlarda sürüm yaşam döngüsünü göz önünde bulundurmak gerekir. Enterprise/commercial tarafta ise binlerce agent’ı merkezi bir web konsolundan yönetebilme, gelişmiş modül desteği ve profesyonel destek gibi avantajlar öne çıkar.

Bu manzarayı tamamlayan başka açık kaynak/community araçlar da var. Fluent Bit, düşük kaynak tüketimiyle özellikle Kubernetes ve container ortamlarında öne çıkar. OpenTelemetry Collector, log/metric/trace verisini ortak bir standartta toplayıp işleme konusunda giderek bir endüstri ortak paydasına dönüşüyor. Vector ise yüksek performanslı dönüştürme ve routing senaryolarında değerlendirilebilen bir başka seçenek.

Burada “en iyi” ya da “tek doğru” araçtan söz etmek yanıltıcı olur. Teknik karar; kurumun log kaynaklarına, regülasyon ihtiyacına, ekip yetkinliğine, mevcut SIEM mimarisine ve operasyonel olgunluğuna göre verilmelidir. Çoğu olgun kurumda gerçek mimari, tek bir aracın değil, bu araçların farklı katmanlarda bir arada kullanıldığı hibrit bir yapının üzerine kuruludur.

Gerçek Hayattan Use Case’ler

Windows Event Log. 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ı ve tekrar eden event’leri pipeline katmanında filtrelemek hem hacmi hem gürültüyü ciddi biçimde azaltır.

VPN ve identity korelasyonu. Başarısız VPN giriş denemeleri normalize edilip ortak kullanıcı kimliği alanına hizalandığında, identity ve 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 ve service metadata’sı ile enrichment yapıldığında, SIEM’e ulaşan her satır hangi iş yüküne ait olduğu bağlamıyla gelir ve 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ş ve doğru hedeflenmiş veri; analist verimliliğini, detection kalitesini ve operasyonel sürdürülebilirliği artırır. Bu yüzden SIEM maliyet optimizasyonu yalnızca bir bütçe konusu değil; veri mühendisliği, güvenlik operasyonları ve mimari yönetişim konusudur. Telemetry pipeline katmanı, bu üç disiplini birbirine bağlayan teknik zemindir. SIEM’i optimize etmenin ilk adımı, SIEM’e ne gönderdiğimizi sorgulamaktır.