Doğru Telemetri, Doğru Format, Doğru Tier, Doğru Maliyet

Her Güvenlik Ekibinin Karşılaştığı Senaryo

Senaryo tanıdık. Yılın belirli bir döneminde SIEM yenileme teklifi gündeme gelir. Hacim geçen yıla göre yüzde kırk artmıştır; lisans GB/gün üzerinden fiyatlanırken bütçe aynı seviyede kalmıştır. Toplantıda log kaynakları
hacimlerine göre sıralanır ve en yüksek hacme sahip kaynakların karşısına aynı soru çıkar: Hangilerini SIEM'den çıkarabiliriz?

İlk tepki genellikle aynıdır: yüksek hacimli kaynakların bir bölümü kapatılır.

Önce proxy log'ları çıkarılır. Ardından firewall'ın allow kayıtları gelir. Son olarak DNS query'leri gündeme gelir: milyarlarca satır üretilmektedir ve bunların hangisinin gerçekten kullanıldığı net değildir. Hedeflenen fatura seviyesine ulaşılır ve çeyrek kapanır.

Altı ay sonra bir olay bildirimi gelir. Eldeki tek iz, Mart ayında bir kullanıcı makinesinin çözdüğü bir domain'dir. O sorgunun gerçekleşip gerçekleşmediği artık doğrulanamaz; çünkü DNS kaynağı Ocak ayında devre dışı bırakılmıştır. İncelenecek bir tablo, çalıştırılacak bir sorgu yoktur; geriye yalnızca "bilmiyoruz" yanıtı kalır. Bu kararların temelinde gözden kaçan önemli bir ayrım vardır: SIEM'e gönderilmeyen log daha sonra geri getirilebilir; hiç toplanmayan log ise geri getirilemez. İlki bir yönlendirme kararıdır, ikincisi kalıcı bir görünürlük kaybıdır.

Dolayısıyla doğru soru "neyi toplamayalım?" değil, "hangi veri nerede tutulmalı?" sorusudur. Bu kararın, veri ortama girdiği anda verilmesi gerekir.

Temel Yaklaşım: Verinin Tutulabileceği 3 katman

Bu ayrımı somutlaştırmak için basit bir benzetme işe yarar: bir ofise her sabah gelen posta.

Postanın bir bölümü doğrudan masanıza gelir; çünkü kısa süre içinde işlem görmesi gerekir. Bir başka bölüm erişilebilir bir dolapta tutulur; gerektiğinde hızlıca bulunur, ancak çalışma alanını gereksiz yere meşgul etmez. Geri kalan bölüm ise bodrumdaki kutulara kaldırılır. Buradaki depolama maliyeti düşüktür ve hiçbir içerik gereksiz yere elden çıkarılmaz.

Her zarfın önce masaya ulaşması iki sonuç doğurur: daha büyük bir çalışma alanı için ek maliyet oluşur; daha önemlisi, gerçekten incelenmesi gereken birkaç mesaj yüzlerce gereksiz mesajın arasında kaybolur. Böylece zaman, üretken çalışmadan çok ayıklamaya harcanır.

Telemetride de benzer bir durum söz konusudur. Tüm veriyi SIEM'e göndermek yalnızca maliyetli değil, aynı zamanda gereksiz veri yükü oluşturan bir yaklaşımdır. Gereksiz event'ler index'lenir, aramaları yavaşlatır, false positive üretme ihtimalini artırır ve nöbetçi analistin odağını gereksiz yere böler.

Bir mektubun masaya ait olmaması, çöpe gönderilmesi gerektiği anlamına gelmez. Ancak bir log kaynağı SIEM'de yer bulamadığında verilen karar çoğu zaman tam olarak budur.

Telemetrinin de benzer biçimde üç farklı katmana ihtiyacı vardır. Bir ortamın telemetrisi "hangi iş yüküne hizmet ediyor?" sorusuyla değerlendirildiğinde üç temel ihtiyaç alanı ortaya çıkar.

Sürekli ihtiyaç. Ortamın sağlığı, alerting, dashboard ve SLO takibi için kullanılan; sürekli göz önünde tutulması gereken veridir. Çoğu ortamda toplam hacmin yalnızca yüzde 1–2'sini oluşturur.

Zamana bağlı ihtiyaç. Support, troubleshooting, root cause analysis ve compliance kontrollerinde kullanılan veridir. Canlı olarak izlenmez; gerektiğinde olay sonrasında geriye dönük olarak sorgulanır. Ortam içindeki payını yaklaşık yüzde 30 olarak kabul edebiliriz.

Arşivleme ihtiyacı. Regulatory archiving ve forensic inceleme amacıyla saklanan veridir. Buraya akışın tamamı alınabilir; çünkü bir kaydın saklanması için sürekli olarak sorgulanabilir olması gerekmez.

Oranlar kurumdan kuruma değişebilir. Güvenlik ağırlıklı ortamlarda detection için ayrılan bölüm daha yüksek, uygulama ağırlıklı ortamlarda ise daha düşük olabilir. Ancak değişmeyen temel nokta şudur: sürekli izlenen veri en küçük bölümü oluştururken, aynı zamanda birim maliyeti en yüksek katmanda tutulur. Bu üç ihtiyaç, verinin sırayla geçtiği aşamalar değildir; event sisteme ulaştığı anda hangi ihtiyaca hizmet ettiği belirlenir.

Şekil 1 — Kaynak verisi bir kez alınır. Kron Telemetry Pipeline her event'i işleyerek, kullanım amacına uygun katmana yönlendirir.

SIEM, detection ve alarm üretimi için kullanılan, en yüksek maliyetli katmandır. Log management, aranabilirliğin ve operasyonel incelemenin merkezinde yer alan daha ekonomik katmandır. Object storage ise raw verinin uzun süre tutulduğu, en düşük birim maliyete sahip arşiv katmanıdır.

Tablonun en önemli satırı ilkidir. Tiering'i yalnızca bir retention politikası olarak ele almak doğru değildir. Veri, SIEM'in doksan günlük süresi dolduğu için ikinci katmana taşınmaz; daha ilk andan itibaren hangi ihtiyaca
hizmet ediyorsa o katmana yönlendirilir. SIEM'de altı ay sonra bulamadığınız kayıtların çoğu, altı ay önce de orada değildi; çünkü hiçbir correlation kuralı onları gerektirmiyordu.

Tier 1: SIEM Bir Detection Motorudur, Arşiv Değildir

SIEM'i pahalı yapan temel unsurlar diskten çok indexing, correlation ve lisans maliyetleridir. Dolayısıyla sisteme gönderilen her byte için belirli bir detection kabiliyetinin maliyeti de ödenir. Bu nedenle temel soru "veri burada ne kadar kalsın?" değil, "buraya hangi veri gönderilmeli?" sorusudur.

Ölçüt tek bir soruya indirgenebilir: Bu event'i bir kişi izleyecek mi?

Yanıt hayırsa, hacmin önemli bir bölümü tahmin edilenden daha büyük olabilir. Bu veri üzerinde bir kural, dashboard veya arama çalışmıyor; ancak veri yine de index'leniyor, lisanslanıyor ve saklanıyor. Böyle bir durumda ihtiyaç daha kısa bir retention değil, başlangıçtan itibaren farklı bir katmana yönlendirmedir.

Üç temel müdahale, detection kabiliyetinden ödün vermeden hacmi azaltabilir. Kron Telemetry Pipeline bu müdahaleleri event akışı üzerinde, SIEM'e ulaşmadan önce uygulayarak veri hacmini kontrollü biçimde azaltır.

Gürültünün filtrelenmesi. Machine account'ların saniyeler arayla tekrarlayan logon/logoff çiftleri, altyapının health check'leri, firewall'ın allow kayıtları veya başarılı DNS yanıtları gibi event'ler çoğu zaman tek tek incelenmez. Kron Telemetry Pipeline'daki filtreleme kurallarıyla bu tür veriler SIEM'den çıkarılabilir; gerektiğinde alt katmanlarda saklanmaya devam eder.

Atmak yerine özetlemek. Bazı event'ler tek başına sınırlı değer taşırken toplu hâlde anlamlı bilgi üretebilir. Beş dakikada oluşan dört yüz bin allow kaydı, source-destination-port kırılımında birkaç bin satıra indirilebilir. Kron Telemetry Pipeline bu hacmi aggregation ile özetleyip sayaçları ve byte toplamlarını koruyabilir; böylece hacim anomalisi arayan bir kural, ham satırları saymak yerine hazır özeti okuyabilir. Aynı yaklaşım metrik
üretimine kadar taşınabilir: "host başına dakikada başarısız logon" gibi bir değer, binlerce log satırı yerine tek bir ölçüm olarak tutulabilir.

Kullanılmayan alanları ayıklamak. Bir kaydın önemli bir bölümü taşınması gerekmeyen metadata, tekrarlanan hostname alanları, boş alanlar, yapılandırılmış veriyi saran envelope veya ham payload'ın parse edilmiş kopyasından oluşabilir. Kron Telemetry Pipeline alan seçimiyle bu gereksiz alanları SIEM'e göndermeden ayıklayabilir.

Normalization da benzer bir rol üstlenir. Event'leri OCSF/ECS gibi ortak bir şemaya oturtmak veya LEEF/CEF'e çevirmek, parse yükünü SIEM'in üzerinden alır. Daha önemlisi, kural geliştiren kişinin farklı vendor'ların "source IP" alanını farklı adlandırma biçimlerini bilmesine gerek bırakmaz.

Bütün bu işlemlerin temel koşulu aynıdır: filtreleme, silme anlamına gelmemelidir; verinin uygun katmana yönlendirilmesi anlamına gelmelidir. SIEM'e gönderilmeyen her event aynı anda alt katmanlara yazılmaya
devam eder. Bu koşul sağlanmadığında yapılan işlem, SIEM hacmini optimize etmekten çok kaynağı devre dışı bırakmaya yaklaşır.

Tier 2: Log Management — Telemetrinin Asıl Kullanım Katmanı

SIEM retention'ını doksan güne indirmek önemli bir maliyet avantajı sağlar; ancak bunun arkasında veri erişimi açısından bir boşluk olabilir. Bir analistin bu katmana başvurmasının iki temel nedeni vardır ve bunlardan
yalnızca biri zamanla ilgilidir.

İlki açıktır: vaka geçmişteki bir tarihe uzanır ve SIEM yalnızca son doksan günü saklar.

İkincisi daha sık karşılaşılan durumdur: bazı event'ler SIEM'e hiç gönderilmez. Bunun nedeni detection için gerekli olmamaları, ancak investigation sırasında kritik hâle gelebilmeleridir. Örneğin başarılı bir DNS yanıtı çoğu zaman bir detection kuralını tetiklemez. Buna karşın belirli bir makinenin geçmiş etkinliğini yeniden oluşturmak gerektiğinde ilk incelenecek kayıtlardan biri olabilir. Detection ile investigation aynı veri ihtiyacına sahip değildir; bu iki ihtiyacı tek bir katmanda karşılamaya çalışmak SIEM maliyetini gereksiz yere artırır.

Bu nedenle aranabilir bir ara katmana ihtiyaç vardır. Telemetrinin büyük bölümü burada tutulabilir ve maliyet,
SIEM'in gerektirdiğinin yaklaşık onda biri seviyesinde kalabilir. Kron Telemetry Pipeline, event'i ihtiyaca göre yönlendirirken bu katmandaki veriyi aranabilir ve yapılandırılmış biçimde bırakır.

Kron Data Store gibi columnar bir platform bu yaklaşımı ekonomik hâle getirir. Sorgu bütün kaydı diskten çekmek yerine yalnızca ihtiyaç duyduğu kolonları okur. Milyarlarca satır içinde az sayıda farklı değer içeren
vendor, action, severity ve log type gibi alanlar yüksek sıkıştırma oranlarına ulaşabilir. Saklanan alanların tamamı sorgulanabilir ve sonuçta yalnızca ihtiyaç duyulan kolonlar döndürülür.

Tier 3: System of Record

Üçüncü katmanın index'e ihtiyacı yoktur. Amacı, toplanan tüm verinin eksiksiz ve dokunulmamış bir kopyasını, gerekli süre boyunca mimarinin en düşük maliyetli depolama katmanında tutmaktır. Buradaki kopya, filtrelenmemiş raw veridir.

Compliance açısından gerekli olan uzun süreli retention, verinin geldiği hâliyle saklanması ve denetim sırasında belirli bir tarih aralığının teslim edilebilmesi bu katmanda karşılanır.

Bu yaklaşım üst katmanların görevini de netleştirir: SIEM detection için, log management ise hızlı arama ve investigation için konumlandırılır. Bu katmanlardan birinin aynı zamanda system of record gibi davranması beklenirse, arşivleme maliyeti daha pahalı bir detection katmanının maliyeti üzerinden ödenmiş olur.

Bir diğer temel ilke, bu katmana parse edilmiş veri yerine raw verinin yazılmasıdır. Vendor tarafındaki küçük bir firmware güncellemesi log formatını değiştirdiğinde parser sessizce hata vermeye başlayabilir. Fark edilene kadar geçen dönemi geri kazanmanın tek yolu, orijinal byte'ların hâlâ mevcut olmasıdır. Raw veriyi korumak, parser hatasının kalıcı bir görünürlük kaybına dönüşmesini önler.

Son olarak bu katman esas olarak aramak için değil, gerektiğinde içinden veri almak için tasarlanır. Bu bir eksiklik değil, düşük maliyetin temel nedenlerinden biridir.

Veriyi geri getirmek

Arşivin değeri, gerektiğinde doğru veriyi ne kadar isabetli biçimde geri çağırabildiğinizle ölçülür. Bunu iki tasarım kararı belirler: object'lerin key prefix ile nasıl isimlendirildiği ve replay mekanizmasının seçilen veriyi aynı pipeline üzerinden yeniden işleyip hedefe iletebilmesi. İkisi birlikte çalıştığında ilk aşamada verilen yönlendirme kararları geri döndürülemez olmaktan çıkar; bir soruşturma için arşivin tamamı değil, yalnızca ilgili prefix'ler seçilip pipeline içinde daraltılarak SIEM'e gönderilir.

Bu konuda detaylı bilgi için replay blogumuzu bu linkten okuyabilirsiniz.

Maliyet etkisi

Sayıları somutlaştırmak için ortalama 20 bin EPS ve event başına 500 byte üreten bir ortam düşünelim: günde yaklaşık 860 GB, ayda ise 26 TB raw telemetri oluşur.

Birinci yaklaşım: tüm veri SIEM'e. Günde 860 GB lisanslanır. Maliyet doğrudan hacimle büyüdüğü için retention süresini bütçe belirler ve pratikte doksan günün ötesine geçilemez. Bu sürenin dışında kalan veri tamamen kaybolur.

İkinci yaklaşım: veri ihtiyaca göre yönlendirilir. Gürültü filtrelenir, yüksek hacimli event'ler özetlenir ve kullanılmayan alanlar ayıklanır. SIEM'e ulaşan hacim günde yaklaşık 300 GB'a, yani üçte birine iner. Detection kabiliyetinden ödün verilmez; geri kalan veri silinmez, alt katmanlara yazılır.

Aradaki fark tek cümleyle özetlenebilir: SIEM lisans hacmi üçte birine inerken, verinin erişilebilir olduğu süre doksan günden yıllar seviyesine çıkar.

Alt katmanların yarattığı yük bu kazanımın yanında küçüktür. Log management katmanında on üç aylık veri sıkıştırma sonrasında 25–35 TB, object storage'da beş yıllık raw veri ise 160–200 TB disk alanına karşılık gelir. Hacim büyük görünse de bu katmanların birim maliyeti SIEM'in çok altındadır.

Oranı en anlaşılır biçimde şöyle ifade edebiliriz: SIEM'de 1 TB veri saklamanın maliyetiyle log management katmanında yaklaşık 10–20 TB, object storage'da ise 50–100 TB veri saklanabilir. Mutlak fiyatlar lisans modeline ve altyapıya göre değişir; değişmeyen taraf bu orandır.

Faturada doğrudan görünmeyen kazanımlar da önemlidir ve çoğu zaman doğrudan maliyet tasarrufundan daha yüksek değer yaratır. Daha az ingest eden bir SIEM, daha az node ve daha düşük indexing kapasitesi gerektirir. Aramalar hızlanır; normalize veriyle beslenen kurallar daha az false positive üretir. Analist zamanı, doğru katmanda tutulan verinin hızlı biçimde yanıtlayabildiği sorulara ayrılır. Upgrade pencereleri daha az riskli hâle gelir; buffering yapan bir pipeline, hedef sistem yeniden erişilebilir olduğunda biriken veriyi teslim edebilir.

Mevcut Yapıyı Bozmadan Devreye Almak

Tiering'e geçişte en sık yapılan hata, işe azaltmayla başlamaktır. Doğru sıra bunun tersidir: önce object storage katmanı filtreleme olmadan devreye alınır, azaltma ancak veri güvenli biçimde saklanmaya başladıktan sonra gündeme gelir ve SIEM retention'ı en sona bırakılır. Analistler log management katmanına güvenmeye başlamadan retention süresini kısaltmak, tiering projelerinin kurum içindeki güvenilirliğini en hızlı zedeleyen yaklaşımdır.

Kron Telemetry Pipeline paralel akışı desteklediği için ilk adım, mevcut SIEM akışına hiç dokunulmadan atılabilir: aynı event raw biçimde object storage'a yazılırken SIEM'e giden akış olduğu gibi kalır. Bu aşamada geri alınması gereken bir değişiklik yapılmaz. Sonraki adımlarda azaltma en gürültülü birkaç kaynakla sınırlı tutulur, yönlendirme kuralları version control altında saklanır ve geri çağırma mekanizması rutin iş akışının parçası hâline getirilir.

Sonuç

Tiering başlangıçta bir maliyet yönetimi yaklaşımı olarak ele alınır; ancak doğru uygulandığında veri yönetimi açısından daha kapsamlı bir modele dönüşür. Ekip, "bu kaynağı saklamaya değer mi?" sorusundan "bu veri hangi ihtiyaç için nerede tutulmalı?" sorusuna geçer. Böylece filtreleme, geri dönüşü olmayan bir kayıp değil, gerektiğinde yeniden değerlendirilebilen bir yönlendirme kararı olur. Retention süresini yalnızca lisansın izin verdiği dönem değil, regülasyonların ve soruşturma gereksinimlerinin zorunlu kıldığı süre belirler.

Hedef daha az veri değil, doğru yerde tutulan veridir. Kron Telemetry Pipeline bu kararı, ortama giren her event için tek bir control plane üzerinden, veri girişinin hemen ardından vermek üzere tasarlanmıştır.