SIEM Kurulumu: EPS, Lisans Modeli ve Saklama Boyutlandırma

SIEM projeleri genellikle yanlış sayıyla kapanıyor: bağlanan kaynak sayısı. Oysa satın alma kararını belirleyen üç sayı başkadır - saniyedeki olay sayısı (EPS), olay başına bayt ve saklama penceresi. Bu üçü ölçülmeden alınan her teklif, birbiriyle karşılaştırılamayan birimlerle fiyatlanıyor; sonra lisans tavanı aşıldığında ya log kısılıyor ya da bütçe dışı taşma faturası geliyor. Bu yazı EPS'ten günlük hacme, oradan otuz günlük sıcak depolamaya ve lisans modelinin kırılma noktasına giden aritmetiği kuruyor, sonunda da o aritmetiği ayakta tutacak bakım yükünü FTE cinsinden hesaplıyor.

Baştan bir ayrım yapmak gerekiyor. Türkiye'de birçok ihale şartnamesi log yönetimi ile SIEM arasındaki farkı yazmıyor; ikisi aynı satırdan isteniyor. Log yönetimi 5651 sayılı Kanun kapsamındaki trafik bilgilerinin saklanmasını ve gerektiğinde sorgulanabilmesini sağlar. SIEM bunun üzerine korelasyon, kural yönetimi ve alarm katmanı ekler. Aynı hacmi iki farklı amaç için ölçüyorsunuz: biri saklama yükümlülüğü, diğeri tespit süresi. Bütçeyi belirleyen de ikincisi oluyor, çünkü arama hızı ve sıcak depolama maliyeti orada başlıyor.

Bu metnin omurgası ölçülebilir beş kalem: günlük hacim, tepe/ortalama oranı, saklama katmanlarının dağılımı, bakım saati ve yanlış pozitif yükü. Hepsi aynı yöntemle kuruluyor: önce birim tanımı, sonra aritmetik, sonra o aritmetiğin hangi iddiayı taşıyamayacağı.

Satın alma sorusu "kaç EPS" değil, "hangi soruya kaç saniyede cevap"

SIEM dört soruyu hızlı cevaplamak için alınır: kim yaptı, ne değişti, ne dışarı çıktı, ne neyle konuştu. Bu dört sorunun her biri farklı bir kaynak sınıfına yaslanır ve farklı bir hacim üretir. Kimlik kaynakları az hacim, yüksek değer üretir; çevre güvenlik duvarının reddettiği her paketi loglayan yapılandırması ise yüksek hacim, düşük değer üretir. Bir kurumda log hacminin yüzde kırkının güvenlik açısından neredeyse hiçbir şey söylemeyen bir akıştan geldiğini görmek nadir değil.

Bu yüzden kapasite planlaması bir envanter sayımıyla değil, bir soru listesiyle başlıyor. On ile on beş arasındaki soruyu yazın, her soruya hangi kaynağın cevap verdiğini işaretleyin, sonra o kaynakların hacmini ölçün. Ters sırayla gidildiğinde - önce elde ne varsa bağlanıp sonra soru sorulduğunda - ortaya çıkan tablo genellikle şu oluyor: kırk kaynak bağlı, dört sorudan ikisi cevaplanamıyor, lisans tavanının yüzde sekseni harcanmış.

Kapasite kararının bir de sahibi olmalı. Aynı ölçümü üç farklı taraf farklı sayılarla yapıyor: ağ ekibi cihaz arayüzündeki göstergeyi okuyor, uygulama ekibi dosya boyutunu ölçüyor, tedarikçi ise teklif tablosundaki "tahmini" satırı kullanıyor. Üç sayı da doğru olabilir, çünkü üçü farklı şeyi ölçüyor: saniyedeki mesaj, günlük sıkıştırılmış dosya ve lisans birimi. Karşılaştırılabilir tek yol, hepsini aynı birime çevirmek.

Lisansa girmeden önce ölçülecek üç sayı

Ölçüm protokolü kısa: on dört gün, beş dakikalık kovalar, hafta içi ve hafta sonu ayrı. On dört gün çarpı günde 288 kova, 4.032 ölçüm noktası eder. Bu sayı, tek bir günün ortalamasının neden yetersiz olduğunu da gösteriyor: 4.032 kovanın yarısı ortalamanın üstünde, yani ortalamaya göre alınan bir lisans tanımı gereği günün yarısında tavanı aşıyor. Tavanı ortalamaya değil, ölçülen tepe değere ve üstüne eklenen büyüme payına göre koymak gerekiyor.

Ölçülecek	Nasıl ölçülür	Yanıltıcı olan	Lisans kararına etkisi
Ortalama EPS	14 gün, 5 dk kova, hafta içi/hafta sonu ayrı	Tek günün ortalaması; ay sonu ve kampanya haftaları	Günlük hacmi ve depolamayı belirler
Tepe EPS	5 dk kovaların p99 değeri, günlük tepe ile birlikte	Cihaz arayüzündeki "anlık" değer	EPS bazlı lisans tavanını belirler
Olay başına bayt	Üretici başına ortalama; syslog başlığı dahil	Ham dosya boyutunun olay sayısına bölünmesi	EPS ile GB/gün arasındaki köprü
Kaynak sayısı ve değişim hızı	Aylık eklenen/kaldırılan kaynak; bulutta ölçekleme aralığı	Bugünkü envanter	Cihaz başına lisanslanan modellerde tavan
Saklama penceresi	Kaynak sınıfı başına; arama ve arşiv ayrı	Tek bir "iki yıl" rakamı	Depolama katmanlarının dağılımını belirler

Ölçümün bir de negatif tarafı var: bir kaynağın üretmediği log. Ölçüm sırasında her kaynağın son olay zaman damgasını kaydedin. On dört günün sonunda hiç olay üretmemiş bir kaynak, kapasite tablosunda sıfır satırı olarak görünür ve kimse ona bakmaz - oysa o satır, projenin en pahalı kör noktası.

EPS'ten GB/güne: 450 baytlık olayın günlük karşılığı

Köprü tek bir formül: günlük ham hacim = EPS x olay boyutu (bayt) x 86.400 / 1.000.000.000. 450 bayt, syslog başlığı, zaman damgası ve anahtar-değer alanları eklenmiş tipik bir güvenlik duvarı ya da kimlik doğrulama olayı için makul bir orta değer; kendi ölçümünüzde bu sayı 250 ile 1.200 bayt arasında değişebilir ve modeli iki katına çıkarabilir.

EPS (450 bayt)	Veri hızı	Günlük olay	Ham GB/gün	Dizinli (2,2x)	Sıkıştırılmış (8:1)	30 gün sıcak
500	0,2 MB/s	43,2 milyon	19,4 GB	43 GB	5,3 GB	160 GB
2.000	0,9 MB/s	172,8 milyon	77,8 GB	171 GB	21,4 GB	642 GB
5.000	2,2 MB/s	432 milyon	194,4 GB	428 GB	53,5 GB	1,6 TB
20.000	9,0 MB/s	1,73 milyar	777,6 GB	1,71 TB	213,8 GB	6,4 TB
60.000	27,0 MB/s	5,18 milyar	2,33 TB	5,13 TB	641,5 GB	19,2 TB

Tabloda dikkat edilmesi gereken sütun sonuncusu değil, üçüncü ile dördüncü arasındaki fark. 5.000 EPS'te günde 432 milyon olay üretiliyor; bu sayı tek başına bir anlam taşımıyor çünkü hiçbir analist 432 milyon satıra bakmıyor. Anlam taşıyan şey, o 432 milyon olaydan kaçının bir kurala çarptığı ve kaç uyarı ürettiği. Kapasite planlaması bu yüzden iki katmanlı: hacim lisansı belirliyor, uyarı yükü insan kaynağını belirliyor. İkincisini kırmızı takım ölçüm protokolünde kurduğumuz analist hesabıyla birleştirmek gerekiyor: günde 200 uyarı, analist-saat başına 10-12 triyaj ile 16,7-20 saat, yani 2,08-2,5 FTE. Tek bir 7/24 nöbet koltuğu ise yılda 8.760 saat / 1.600 verimli saat = 5,47 FTE.

Bu iki katmanın ayrı hesaplanması, ihale şartnamelerindeki en yaygın hatayı da açıklıyor: "SIEM lisansı + 1 SOC analisti" satırı. Lisans, 432 milyon olayın hacmini satın alıyor; bir analist ise o hacimden çıkan uyarıların yalnızca küçük bir bölümünü triyaj edebiliyor. Aradaki fark ne lisansla ne de eğitimle kapanıyor; ya kural sayısı düşürülerek ya da kapsam daraltılarak kapatılıyor.

Tepe/ortalama oranı: lisans tavanını kim ödüyor

Ortalama ile tepe arasındaki fark, lisans modelinin sessiz vergisi. Aşağıdaki profil 24 saatlik gerçekçi bir kurumsal gün: gece düşük, mesai başlangıcında kimlik doğrulama fırtınası, öğle arasında düşüş, öğleden sonra ikinci tepe.

Saat aralığı	Süre	EPS	Olay katkısı
00:00-07:00	7 saat	900	22,7 milyon
07:00-09:00	2 saat	4.200	30,2 milyon
09:00-12:00	3 saat	6.800	73,4 milyon
12:00-13:00	1 saat	3.900	14,0 milyon
13:00-18:00	5 saat	6.400	115,2 milyon
18:00-20:00	2 saat	2.600	18,7 milyon
20:00-24:00	4 saat	1.300	18,7 milyon
Toplam	24 saat	ortalama 3.392	293,0 milyon

Ortalama 3.392, tepe 6.800: tepe/ortalama oranı 2,0. Günün 10 saati 4.000 EPS'in üstünde. Şimdi iki tavanı karşılaştırın. 5.000 EPS tavanlı bir lisans ölçülen ortalamanın 1,47 katı; yani kullanılmayan kapasite için ödeme yapılıyor ve buna rağmen 09:00-12:00 arasında tepe değerin yalnızca yüzde 73,5'inde kalınıyor, o üç saatte bir sıçrama tavanı aşabilir. 7.000 EPS tavanlı lisans güvenli, ama ölçülen ortalamanın iki katından fazlasını ödüyor. Doğru soru "hangi tavan" değil, "tavan aşıldığında ne oluyor".

Taşma davranışının üç biçimi var ve üçü farklı şeyi bozuyor. Kısma: tavan aşıldığında platform gelen olayı atıyor - tam da olay anında kanıt kaybı, üstelik sessizce. Geciktirme: olay kuyruğa alınıyor, gecikme büyüyor; 40 dakika gecikmeli bir alarm müdahale süresi değil, arşiv kaydı. Taşma fiyatlaması: hacim geçiyor, bütçe öngörülemez oluyor; kampanya haftasında gelen fatura planlanmamış bir kalem. Şartnameye yazılacak cümle kısa: tavan aşıldığında hacim kısılmayacak ve geciktirilmeyecek, aşım süresi ile miktarı aylık raporlanacak, ek bedel varsa birim fiyatı sözleşmede yazılı olacak.

Üç lisans modeli ve her birinin kırılma noktası

Türkiye piyasasında karşılaşılan üç model var: EPS, günlük GB ve cihaz/varlık. Üçü de aynı ürünü farklı bir değişkene bağlıyor, dolayısıyla üçü de farklı bir davranışı ödüllendiriyor.

Model	Neyi fiyatlıyor	Nerede kırılıyor	Hangi kurumda doğru	Sözleşmede sorulacak
EPS tavanı	Anlık işleme hızını	Mevsimsel tepe; cihaz yazılım güncellemesi sonrası log patlaması	Hacmi yıl içinde düz seyreden, tepe/ortalama oranı 2'nin altında olan kurum	Ölçüm 5 dk ortalama mı, 1 sn tepe mi? Aşımda ne oluyor?
Günlük GB	Saklanan ve işlenen hacmi	Yüksek hacimli ama yüksek değerli kaynaklar (proxy, DNS, akış); kısma başlıyor	Kaynak hacmi dalgalı, saklama katmanı ayrı satın alınan kurum	Ham mı sıkıştırılmış mı sayılıyor? Dizin dahil mi?
Cihaz / varlık	Kapsamdaki uç noktayı	Konteyner, VDI ve otomatik ölçekleme; aynı iş yükü 200 "cihaz" oluyor	Sabit uç nokta sayısı olan, bulut kullanmayan kurum	Konteyner pod'u cihaz sayılıyor mu? Kapatılan cihaz lisansı düşüyor mu?

Modellerin hiçbiri diğerinden üstün değil; üstün olan, sizin ölçtüğünüz profile uyan model. Ölçüm yapılmadan verilen kararın tipik sonucu şu: tepe/ortalama oranı 2 olan bir kurum EPS modelinde tavanı tepeye göre alır, ortalamanın iki katını öder; aynı kurum GB modelinde gürültülü kaynağı kapatarak faturayı yarıya indirir ve farkında olmadan "ne dışarı çıktı" sorusunun tek kaynağını kaybeder. İkinci senaryo daha pahalı, çünkü tasarruf edilen para lisans kaleminde, kaybedilen şey ise bir olayı bir hafta boyunca açıklayamamak.

İki teklifi karşılaştırmak: ortak birim TL/GB-gün

Bir EPS tavanı ile bir GB tavanı yan yana konduğunda fiyat karşılaştırması yapılamıyor, çünkü birimler farklı. Çözüm basit: her iki teklifi de tavanın günlük hacme karşılığını hesaplayıp TL/GB-gün birimine indirmek. Aşağıdaki iki teklif varsayımsaldır, pazar fiyatı iddiası değildir; yöntemi göstermek için kurulmuş bir çifttir. Ölçülen yük her ikisinde de aynı: ortalama 3.392 EPS, 450 bayt, günde 131,9 GB.

Kalem	Teklif A (EPS tavanı)	Teklif B (GB tavanı)
Tavan	5.000 EPS = 194,4 GB/gün	200 GB/gün = 5.144 EPS
Yıllık bedel	480.000 TL	540.000 TL
Tavanda TL/GB-gün	6,76 TL	7,40 TL
Ölçülen yükte TL/GB-gün	9,97 TL	11,22 TL
Tavanın ölçülen yüke oranı	1,47x	1,52x
Aşımda davranış	Tepe saatte kısma (09:00-12:00 arası risk)	45 TL/GB ek bedel, kısma yok
Tepe günü maliyeti	264,4 GB istek, 194,4 GB işlenir: 70 GB kayıp	+64,4 GB x 45 TL = 2.897 TL
Yılda 12 tepe gün	840 GB kayıp, 0 TL	34.767 TL ek bedel

Tabloyu okumanın doğru yolu şu: A, ölçülen yükte GB başına yüzde 12,5 daha ucuz - yılda 60.000 TL - ama bu indirimi tepe saatlerde veri kaybıyla ödüyor. 12 tepe günde 840 GB kayıp, olay başına 450 baytla yaklaşık 1,87 milyar olay eder. Bir fidye yazılımı olayının ilk üç saati tam olarak o pencerede geçiyorsa, 60.000 TL'lik indirim olayın kronolojisini kurulamaz hâle getiriyor. Karar bu yüzden "hangisi ucuz" değil, "hangi hatayı taşıyabilirim" sorusuna dönüşüyor; aynı mantığı fidye yazılımı sonrası veri kurtarma akışında da kurmak gerekiyor, çünkü orada eksik saat doğrudan geri dönüş süresine yazılıyor.

Saklama katmanları: 30 sıcak, 180 ılık, 730 soğuk

Saklama maliyeti tek bir sayı değil, üç katmanın dağılımı. Katmanları mutlak fiyatla değil göreli endeksle kurmak daha dürüst, çünkü donanım ve bulut fiyatları kurumdan kuruma değişiyor; aşağıdaki endeksler sıcak katmanı 1,00 kabul ediyor. Önemli olan mutlak sayı değil, politikaların birbirine oranı.

Katman	Tipik pencere	Arama davranışı	Göreli birim maliyet	Hangi soruya hizmet eder
Sıcak	30 gün	Saniyeler; tam metin ve alan araması	1,00	Şu anda ne oluyor
Ilık	180 gün	Dakikalar; sınırlı alan, gecikmeli arama	0,35	Geçen ay ne oldu, eğilim ne
Soğuk	730 gün	Saatler; nesne deposundan geri yükleme	0,06	Denetim, hukuki talep, karşılaştırma

Bu endekslerle dört saklama politikasının toplam maliyeti şöyle çıkıyor (30 günlük sıcak-only politika = 1,00):

Politika	Toplam endeks	1,00'e oran	Yorum
30 gün sıcak, arşiv yok	30,0	1,00x	En ucuz; 31. gün hiçbir şey kanıtlanamaz
30 sıcak + 180 ılık + 730 soğuk	136,8	4,56x	24 kat saklama, 4,6 kat maliyet
90 sıcak + 730 soğuk	133,8	4,46x	Ilık katman olmadan aynı toplam
730 gün tamamı sıcak	730,0	24,33x	En pahalı; arama hızı için ödenen bedel

Tablodaki en kullanışlı satır üçüncüsü: 90 gün sıcak artı arşiv, üç katmanlı politikanın toplamına neredeyse eşit. Yani ılık katmanı kurmanın gerekçesi para değil, arama hızı. Bu, şartname tartışmalarında sık karışan bir noktayı düzeltiyor: "arşiv var, o zaman ılık katmana gerek yok" cümlesi bütçe açısından doğru, operasyon açısından yanlış - arşivden geri yükleme saatler sürdüğü için olay müdahalesi sırasında kullanılamıyor. Toplam politika maliyetinin yalnızca yüzde 21,9'u ilk 30 günde; geri kalanı, kimsenin bakmadığı ama hukuken gerekli olan kuyrukta.

Dizin ve sıkıştırma: ham bayt ile yerleşen bayt aynı şey değil

Teklif tablolarındaki "GB" üç farklı şeyi gösterebiliyor: ham bayt, dizinlenmiş bayt ve sıkıştırılmış bayt. Aradaki fark, satın alınan disk miktarını iki katına çıkarabilecek kadar büyük. Ölçümümüzde ham hacim 194,4 GB/gün; tipik bir arama altyapısı bu hacmi yaklaşık 2,2 katına şişirip dizinliyor, sonra 8:1 oranında sıkıştırıyor.

Aşama	Katsayı	Günlük (5.000 EPS)	30 gün sıcak	Not
Ham olay akışı	1,0x	194,4 GB	5,8 TB	Kablo üzerindeki hacim
Ham + dizin	2,2x	428 GB	12,8 TB	Alan aramasının bedeli
Sıkıştırma 4:1	0,55x	107 GB	3,2 TB	Metin ağırlıklı kaynaklarda alt sınır
Sıkıştırma 8:1	0,28x	53,5 GB	1,6 TB	Tekrarlı syslog alanlarıyla elde edilir
Olay boyutu 900 bayt	2,0x	388,8 GB ham	3,2 TB sıkıştırılmış	Alan zengin kaynaklarda gerçek durum

Bu tablodan çıkan iki karar var. Birincisi, sözleşmede "GB" tanımını yazmak: ham mı, sıkıştırılmış mı, dizin dahil mi. Aynı yük üç tanımla 1,6 TB ile 12,8 TB arasında görünüyor - aradaki fark satın alma bedelini doğrudan belirliyor. İkincisi, sıkıştırma oranının garanti edilmemesi: 4:1 ile 8:1 arasındaki fark, otuz günlük sıcak katmanı iki katına çıkarıyor. Yeni bir kaynak sınıfı (örneğin JSON formatında zenginleştirilmiş akış kayıtları) eklendiğinde sıkıştırma oranı düşüyor ve kapasite sessizce tükeniyor.

Bu yüzden boyutlandırma tek seferlik değil. Üç ayda bir ölçülmesi gereken üç şey var: gerçekleşen sıkıştırma oranı, dizin büyümesi ve yeni eklenen kaynakların olay boyutu. Üçü de izlenmezse, teklif tablosunda 1,6 TB olan sıcak katman bir yıl içinde 4 TB'lik bir disk talebine dönüşüyor ve kimse nedenini açıklayamıyor.

Ayrıştırıcı bakımı bir FTE satırıdır

Lisans ve depolama tartışması bittiğinde geriye kalan şey, sistemi ayakta tutan saatler. Bu saatler ihale şartnamesinde genellikle "eğitim ve destek" başlığı altında tek satıra sıkıştırılıyor; gerçekte ise ayrıştırıcı bakımı, kural bakımı ve ayarlama toplantılarından oluşan bir yıllık yük.

Model 62 kaynak üzerine kurulu. Ayrıştırıcıların yılda yaklaşık dörtte biri log formatı değişikliği nedeniyle bozuluyor - üretici güncellemesi, alan adı değişikliği, yeni bir modül açılması. Her bozulma ortalama 6 saatlik teşhis ve düzeltme demek: 62/4 = 15,5 olay x 6 saat = 93 saat.

İş kalemi	Hesap	Yıllık saat
Ayrıştırıcı onarımı	62 kaynak x 1/4 format değişimi x 6 saat	93
Kural bakımı	140 kural x 4 çeyrek x 25 dakika	233
Ayarlama toplantısı	52 hafta x 1,5 saat	78
Toplam çalışma yükü		404 saat
FTE karşılığı	404 / 1.720 verimli saat	0,24 FTE
İlk kurulum (tek seferlik)	62 x 3 saat ayrıştırıcı + 140 x 2 saat kural	466 saat = 58 iş günü

404 saat, bir kişinin dörtte biri. Kulağa küçük geliyor, ama bu sayının iki özelliği var. Birincisi, bölünemiyor: 93 saatlik ayrıştırıcı onarımı yıl boyunca rastgele dağılmış, çoğu kez olay müdahalesinin tam ortasına düşüyor - format bozulduğunda kör kalan kaynak, tam da o gün bakılan kaynak. İkincisi, bu saatler SOC analistinin saatlerinden farklı bir yetkinlik istiyor: regex, alan eşlemesi, kaynak üreticisinin dokümantasyonu. Aynı kişiye hem triyaj hem ayrıştırıcı bakımı yüklenirse, olay yoğun haftalarda ilk düşen kalem ayrıştırıcı bakımı oluyor ve bozuk ayrıştırıcı bir sonraki olaya kadar fark edilmiyor.

Şartnameye yazılacak karşılığı: ayrıştırıcı bakımı için yıllık asgari saat taahhüdü ve bozulma tespit süresi. "Ayrıştırıcı bozulduğunda kaç saat içinde düzeltilir" sorusunun cevabı sözleşmede yoksa, pratikte cevap "bir sonraki olayda" oluyor.

Kural envanteri: 140 kuralın yıllık bedeli ve dağılımı

Kural sayısı bir olgunluk göstergesi değil; kuralın ürettiği uyarı ile bakım saatinin oranı gösterge. 140 kuralın günde 500 uyarı ürettiği bir kurulumda kural başına ortalama 3,57 uyarı düşüyor - ama dağılım ortalama etrafında değil. Uyarıların yüzde 78'i 12 kuraldan geliyor: o 12 kural kural başına günde 32,5 uyarı üretiyor, kalan 128 kural ise toplamda 110 uyarı, yani kural başına 0,86.

Kural grubu	Kural sayısı	Günlük uyarı	Kural başına	Yıllık bakım (25 dk x 4)	Triyaj yükü/gün
Gürültülü 12 kural	12	390	32,5	20 saat	26,0 saat
Orta grup	48	88	1,83	80 saat	5,9 saat
Sessiz grup	80	22	0,28	133 saat	1,5 saat
Toplam	140	500	3,57	233 saat	33,4 saat

Tablodaki asimetri kararın kendisi: 12 kural, yıllık bakım saatinin yüzde 8,6'sını alıp triyaj yükünün yüzde 78'ini üretiyor. Bu 12 kuralı kapatmak yanlış cevap, çünkü çoğu gerçek bir davranışı yakalıyor. Doğru cevap, üç aşamalı bir ayar: eşiği yükseltmek (örneğin 5 dakikada 20 başarısız oturum yerine 10 dakikada 40), tekrar bastırma (aynı kullanıcı, aynı kaynak, aynı kural için 30 dakikalık pencere) ve bağlam eklemek (kimlik doğrulama uyarısını yalnızca ayrıcalıklı hesap veya yeni cihaz koşuluyla üretmek). Üçünün toplam etkisi tipik olarak yüzde 60-75 aralığında uyarı azaltması; aynı 140 kural, aynı kapsam, üçte biri kadar gürültü.

Yanlış pozitif oranı bir maliyet kalemidir

Yanlış pozitif oranı genellikle bir kalite metriği olarak konuşuluyor; oysa doğrudan bir FTE kalemi. Hesap basit: günlük uyarı sayısı çarpı yanlış pozitif oranı çarpı triyaj süresi. Analist-saat başına 15 uyarı triyajı, yani uyarı başına 4 dakika kabul edelim.

Yanlış pozitif oranı	Günlük gürültü	Günlük triyaj	Yıllık saat	FTE
%92	460	1.840 dk = 30,7 saat	11.193	6,51
%85	425	1.700 dk = 28,3 saat	10.342	6,01
%70	350	1.400 dk = 23,3 saat	8.517	4,95
%92'den %70'e fark	-110	-7,3 saat	-2.677	-1,56

Yirmi iki puanlık bir yanlış pozitif azaltması 1,56 FTE kazandırıyor. Bu, ayarlama çalışmasının neden bir "iyileştirme projesi" değil bir kapasite yatırımı olduğunu gösteriyor: yarım FTE'lik bir ayarlama emeği, bir buçuk FTE'lik triyaj yükünü siliyor. Aynı aritmetiği tespit oranı tarafında kurmak da mümkün - tespit oranı protokolünde kullandığımız güven aralığı mantığı, burada "yüzde 92 yanlış pozitif" iddiasının 500 uyarıda ne kadar oynak olduğunu da gösteriyor: 500 uyarıda 40 puanlık fark, ölçüm hatasından değil, gerçek değişimden geliyor.

Buradaki tuzak, yanlış pozitifi düşürmenin yanlış yolla yapılması. Eşiği yükselterek gürültüyü azaltmak kolay, ama aynı eşik gerçek pozitifin de bir kısmını kesiyor. Bu yüzden ayarlama sonrası iki sayı birlikte raporlanmalı: uyarı sayısı ve kural başına yakalanan gerçek olay sayısı. Yalnızca birincisini raporlayan bir SOC, altı ay içinde sessiz ve mutlu bir panele sahip oluyor.

Sessiz kaynak: log akmayı bıraktığında kim fark ediyor

Kapasite tablosunun en tehlikeli satırı sıfır. Bir kaynak log göndermeyi bıraktığında iki şey oluyor: o kaynakla ilgili alarmlar susuyor, ve "alarm yok" durumu "sorun yok" olarak okunuyor. Bu, saldırganın en ucuz hamlesi - log gönderimini kesmek için özel bir yetenek gerekmiyor, ajanı durdurmak ya da portu kapatmak yeterli.

Çözüm kalp atışı izleme: her kaynak için beklenen olay sayısı aralığı tanımlanır ve bu aralığın dışına çıkıldığında uyarı üretilir. 62 kaynak, 5 dakikalık yoklama ile günde 17.856 kontrol demek - bu bir insan işi değil, platformun kendi işi, dolayısıyla lisans kapsamında sorulması gereken bir yetenek.

Kaynak sınıfı	Beklenen (mesai içi)	Tolerans	Sessizlik süresi	Neden bu eşik
Güvenlik duvarı	4.200 EPS	%15	5 dakika	Hiçbir kurumsal ağ 5 dakika tamamen sessiz kalmaz
Etki alanı denetleyicisi	40 kimlik doğrulama/dk	%30	10 dakika	Gece düşük taban var, sıfır değil
VPN	90 oturum/saat	%50	60 dakika	Hafta sonu sıfıra yaklaşabilir
Uç nokta ajanı	1.400 istemci x 1 olay/saat	%10	30 dakika	İstemci sayısı bilinen bir sabit
Bulut denetim kaydı	600 olay/saat	%40	15 dakika	Toplu iş saatlerinde dalgalanır

Bu tablonun ikinci sütunu aslında bir envanter iddiası: 1.400 uç nokta varsa ve saatte 1.400 olay gelmiyorsa, ya istemcilerin bir kısmı ölü ya da toplama katmanı bozuk. Bu sayı, tedarikçi riski değerlendirmesinde de işe yarıyor: bir tedarikçinin uzaktan erişim ağ geçidinin sessiz kalması, sözleşmede tanımlı bir olay sayılıyor mu?

Kalp atışı izlemenin bir maliyeti var: yanlış sessizlik alarmı. Bakım penceresi, ağ değişikliği, istemci güncellemesi - hepsi meşru sessizlik üretiyor. Bu yüzden tolerans ve süre ayarı, sessizlik alarmını kapatmaya değil, bakım takvimiyle eşleştirmeye yönelik olmalı. Aksi hâlde ekip üçüncü haftada sessizlik alarmlarını kapatıyor ve izleme kâğıt üzerinde kalıyor.

Saklama süresi: 5651, 6698 ve "iki yıl" varsayımı

Türkiye'de log saklama tartışması neredeyse her zaman "iki yıl" rakamıyla başlıyor. Bu rakamın nereden geldiğini ayırmak gerekiyor, çünkü tek bir kaynaktan gelmiyor ve kaynaklar farklı şeyler söylüyor.

Dayanak	Kime uygulanır	Söylediği	Boyutlandırmaya etkisi
5651 sayılı Kanun md.5	Yer sağlayıcı ve erişim sağlayıcı	Trafik bilgilerinin yönetmelikte belirlenen süre boyunca saklanması; süre bir yıldan az, iki yıldan fazla olmamak üzere	Yalnızca hizmet sağlayıcıysanız bağlayıcı; kurum içi ağ için doğrudan uygulanmaz
6698 sayılı Kanun md.12	Veri sorumlusu	Verinin hukuka aykırı işlenmesini önlemek için teknik ve idari tedbirler	Süre değil, gerekçe yükümlülüğü; süre politikada tanımlanır
6698 md.4/2-d	Veri sorumlusu	Belirli, meşru ve ölçülü amaç; amaçla bağlantılı süre	Süreyi uzatmanın gerekçesini yazmak zorunlu
6698 md.9	Yurt dışına aktarım yapan	Aktarım şartları; yeterlilik kararı veya uygun güvenceler	Bulut SIEM'de saklama bölgesi seçimini belirler

Yani "iki yıl" bir kanun maddesi değil, bir uygulama alışkanlığı: 5651'in hizmet sağlayıcıya yüklediği yükümlülüğün kurum içi ağa taşınması. KVKK tarafında ise süre, amaçla bağlantılılık ilkesinden türüyor; süreyi uzatmanın gerekçesini yazmak zorundasınız. Pratik sonucu şu: 730 günlük bir saklama kararının arkasında "denetim ve olay incelemesi" gerekçesi olmalı ve bu gerekçe politikada yazılı olmalı. Gerekçe yoksa 730 gün savunulamıyor, gerekçe varsa 730 gün savunulabilir - ama bu kez de 730 günün maliyetini taşımanız gerekiyor.

Bu ayrım boyutlandırmada doğrudan para demek. Tablodaki üçüncü politika (90 gün sıcak + 730 gün soğuk) ile birinci politika (30 gün, arşiv yok) arasındaki fark 4,46 kat. Gerekçeyi yazmadan 730 güne çıkmak, her yıl ödenen ve kimsenin sorgulamadığı bir kalem üretiyor; gerekçeyi yazıp 90 güne inmek ise denetim sorusuna verilecek cevabı zayıflatıyor. Doğru hamle, kaynak sınıfına göre ayrıştırmak: kimlik ve yetki olayları uzun, ağ akışı kısa. Aynı yaklaşımı KVKK teknik tedbirler ve kanıt rehberinde kurduğumuz kanıt zinciriyle birlikte okumak gerekiyor - orada saklamanın kendisi değil, saklananın kanıt olarak değeri ölçülüyor.

Bulut SIEM ve yurt dışı aktarım: md.9 hangi soruyu soruyor

Yönetilen SIEM hizmetlerinin çoğu veriyi yurt dışındaki bir bölgede işliyor ve bu, KVKK md.9'un konusu. Soru "bulut olur mu" değil; hangi veri, hangi bölgede, hangi güvence ile. Ayrım kaynak sınıfına göre yapılıyor: ağ akışı ve sistem logu kişisel veri içerebilir (kullanıcı adı, IP, e-posta), kimlik doğrulama logu neredeyse her zaman içerir.

Boyutlandırma açısından bulut modelinin iki ek kalemi var. Birincisi, çıkış trafiği: günde 131,9 GB yükleme ayda yaklaşık 3,96 TB ediyor; bazı sağlayıcılar yüklemeyi ücretsiz, sorgu sonuçlarının indirilmesini ücretli sayıyor ve olay müdahalesi sırasında yapılan geniş aramalar bu kalemi şişiriyor. İkincisi, saklama bölgesi: aynı politikanın iki farklı bölgede iki farklı fiyatı olabiliyor, üstelik md.9 kapsamındaki güvence yükü de bölgeye göre değişiyor.

Pratik karar kuralı: kişisel veri içeren kaynaklar (kimlik, e-posta güvenliği, uç nokta) için bölge ve güvence sorusunu sözleşmede netleştirin; ağ akışı ve teknik sistem logları için hacim optimizasyonuna öncelik verin. Bu ayrım, e-posta güvenliği denetimi gibi kişisel veri yoğun kaynaklarda doğrudan md.9 tartışmasına dönüşüyor.

Bütünlük kanıtı: 432 milyon olayı imzalamanın ucuz yolu

Log saklamanın hukuki değeri, saklananın değiştirilmediğini kanıtlayabilmeye bağlı. Her olayı tek tek imzalamak teknik olarak mümkün, ama pahalı: 5.000 EPS'te günde 432 milyon imza demek, saniyede 20.000 imza hızıyla bile günde 6 saatlik işlemci yükü.

Ucuz yol, toplu damgalama: olaylar 5 dakikalık bloklara ayrılır, her bloğun özeti (kök hash) hesaplanır ve her kök, bir önceki kökü de içerecek şekilde zincirlenir. Günde 288 blok, yılda 105.120 imza. Tek bir olayın varlığını kanıtlamak için o olayın ait olduğu bloktaki 1,5 milyon olayın köküne giden yol - yaklaşık 21 hash - yeterli.

Yöntem	Günlük imza	Yıllık imza	İşlemci yükü	Kanıtladığı
Olay başına imza	432.000.000	157,7 milyar	Günde 6 saat (20 bin imza/s)	Her olayın tek tek bütünlüğü
5 dakikalık Merkle bloğu	288	105.120	Saniyeler	Blok içeriğinin ve sırasının değişmediği
Saatlik blok	24	8.760	Önemsiz	Aynı, ama 1 saatlik blokta 18 milyon olay

Buradaki tasarım kararı blok boyutu. Blok küçüldükçe kanıt güçleniyor (daha az olay aynı köke bağlı), imza sayısı artıyor. 5 dakika, çoğu kurum için doğru denge: bir olayın zaman çizgisini 5 dakikalık dilimlerle kanıtlamak yeterli, imza yükü ise önemsiz. Önemli olan nokta, zincirin dışarıda tutulması - kök hash'ler SIEM'in kendi veritabanında durursa, veritabanını değiştirebilen biri zinciri de yeniden üretebilir. Köklerin ayrı bir ortamda (WORM depolama ya da kurum dışı bir zaman damgası servisi) tutulması gerekiyor.

Kabul kriterleri: "kuruldu" ile "çalışıyor" arasındaki fark

Projenin kapanış toplantısında tartışılacak liste kısa olmalı. Aşağıdaki sekiz madde, bu yazıdaki aritmetiğin sözleşmeye dönüşmüş hâli; her biri ölçülebilir ve her biri teslimattan sonraki 30 gün içinde kanıtlanabilir.

#	Kriter	Ölçüm	Eşik
1	Ölçülmüş kapasite	14 gün, 5 dk kova, ortalama/p99/tepe	Üç sayı yazılı; lisans tavanı p99'un üstünde
2	Kaynak tamlığı	Envanterdeki kaynak / olay gönderen kaynak	%100; sessiz kaynak sayısı 0
3	Taşma davranışı	Tavan aşımı testi (yapay hacim)	Kısma yok, gecikme 60 saniyenin altında
4	Ayrıştırıcı doğruluğu	Alan eşlemesi testi, kaynak başına 20 örnek	Kritik alanlarda (kullanıcı, kaynak IP, eylem) %98
5	Kural performansı	Kural başına günlük uyarı	Hiçbir kural günde 40 uyarının üstünde değil
6	Sessizlik izleme	Kaynak sınıfı başına kalp atışı kuralı	62/62 kaynakta tanımlı
7	Saklama kanıtı	31., 181. ve 731. gün sorgu testi	Üç pencerede de sonuç dönüyor
8	Bütünlük	Blok kökü zinciri ve dış tutma	Kökler SIEM dışında; doğrulama betiği çalışıyor

Bu sekiz maddenin ortak özelliği, hiçbirinin "ekran görüntüsü" ile kanıtlanamaması. Hepsi bir sorgu, bir test ya da bir sayaç istiyor. Kabul toplantısında ekran görüntüsüyle geçen madde, altı ay sonra "neden çalışmıyor" sorusunun cevabı oluyor.

Aylık ölçülecek beş sayı

Kapasite planlaması yılda bir yapılan bir çalışma değil; aylık beş sayının takibi. Bu beş sayı, lisans yenileme görüşmesine girmeden önce elinizde olması gerekenler.

Sayı	Nereden	Ne zaman alarm	Hangi kararı besler
Ortalama ve p99 EPS	Toplama katmanı, 5 dk kova	p99, tavanın %80'ini geçtiğinde	Yenileme tavanı, büyüme payı
Sıkıştırma oranı	Depolama katmanı	8:1'den 5:1'e düştüğünde	Disk talebi, katman dağılımı
Günlük uyarı ve yanlış pozitif	Vaka yönetimi	Yanlış pozitif %85'in üstünde	Ayarlama bütçesi, FTE
Sessiz kaynak sayısı	Kalp atışı izleme	Sıfırdan farklı olduğunda	Kapsam doğruluğu, tedarikçi
Saklama penceresi testi	30/180/730 gün sorgu	Herhangi biri boş döndüğünde	Uyum kanıtı, arşiv doğrulama

Bu beş sayı bir arada tutulduğunda, SIEM tartışması "aldık mı almadık mı" ekseninden çıkıp kapasite yönetimine geçiyor. Sonraki adım genellikle tespit içeriğinin kendisi oluyor: hangi saldırı tekniğinin hangi kaynakla görülebildiği. O eşlemeyi DDoS azaltma rehberindeki katman ayrımıyla ve olay müdahale planındaki aşamalarla birlikte kurmak gerekiyor; SIEM bu üç metnin kesişiminde anlam kazanıyor.

Sık sorulan sorular

SIEM için kaç EPS yeter? Tek bir doğru sayı yok, çünkü EPS bir lisans birimi, bir gereksinim değil. Kendi ölçümünüzü yapın: 14 gün, 5 dakikalık kova, hafta içi ve hafta sonu ayrı. Lisans tavanını ortalamaya değil p99'un üstüne koyun. Tipik bir kurumsal profilde ortalama 3.392 EPS ile tepe 6.800 EPS arasındaki fark iki kat; ortalamaya göre alınan lisans günün yarısında tavanı aşıyor.

Günlük kaç GB log üretiyoruz, nasıl hesaplarım? Günlük ham hacim = EPS x olay boyutu (bayt) x 86.400 / 1.000.000.000. 5.000 EPS ve 450 bayt için 194,4 GB/gün çıkıyor. Bu sayıyı dizin katsayısıyla (yaklaşık 2,2x) çarpıp sıkıştırma oranına (tipik 8:1) bölerseniz gerçek disk ihtiyacını bulursunuz: 53,5 GB/gün, 30 gün için 1,6 TB.

EPS bazlı lisans mı, GB bazlı lisans mı? Ölçtüğünüz profile bağlı. EPS modeli anlık işleme hızını, GB modeli saklanan hacmi fiyatlıyor. Karşılaştırmanın tek yolu her iki teklifi TL/GB-gün birimine indirmek. Tepe/ortalama oranı 2'nin üstündeyse EPS modelinde kullanmadığınız kapasiteyi ödüyorsunuz; kaynak hacminiz dalgalıysa GB modelinde gürültülü ama değerli bir kaynağı kapatma baskısı başlıyor.

Logları kaç yıl saklamak zorundayız? 6698 sayılı Kanun tek bir süre yazmıyor; süre, amaçla bağlantılılık ilkesinden türüyor ve politikada gerekçelendirilmesi gerekiyor. "İki yıl" pratikte 5651 md.5'in hizmet sağlayıcılara yüklediği yükümlülüğün kurum içi ağa taşınmış hâli. 730 günlük bir kararın arkasında denetim ve olay incelemesi gerekçesi yazılı olmalı; yoksa süre savunulamıyor, var olduğunda ise maliyetini taşımanız gerekiyor.

Neden 30 gün sıcak, 180 gün ılık, gerisi arşiv? Çünkü maliyetin yüzde 78'i sıcak katmanda. Göreli endeksle 30 gün sıcak-only politika 1,00 ise, 30+180+730 politikası 4,56 kat, 730 gün tamamı sıcak ise 24,33 kat. 90 gün sıcak artı arşiv de 4,46 kat çıkıyor - yani ılık katmanın gerekçesi para değil, arama hızı.

Kaç kişilik ekip gerekir? İki ayrı hesap yapın. Triyaj: günlük uyarı x yanlış pozitif oranı x uyarı başına süre. 500 uyarı, %92 yanlış pozitif, 4 dakika triyaj = günde 30,7 saat, yani 6,51 FTE. Bakım: ayrıştırıcı onarımı, kural gözden geçirme ve ayarlama toplantıları 62 kaynak ve 140 kuralda yılda 404 saat, 0,24 FTE. İki sayı birbirinden bağımsız; biri azaltıldığında diğeri kendiliğinden düşmüyor.

Yanlış pozitif oranını düşürmek neden önemli? Çünkü doğrudan FTE. Oranı yüzde 92'den yüzde 70'e indirmek, aynı 500 uyarı hacminde yılda 2.677 saat kazandırıyor - 1,56 FTE. Bu, yarım FTE'lik bir ayarlama emeğinin bir buçuk FTE'lik triyaj yükünü silmesi demek. Ancak iki sayı birlikte raporlanmalı: uyarı sayısı ve yakalanan gerçek olay sayısı.

Bulut SIEM KVKK açısından sorun mu? Sorun "bulut" değil, md.9 kapsamındaki aktarım şartları ve verinin işlendiği bölge. Kimlik, e-posta güvenliği ve uç nokta kaynakları kişisel veri yoğun; ağ akışı ve teknik sistem logları daha az. Karar kuralı bu ayrımı izlemeli: kişisel veri yoğun kaynaklarda bölge ve güvence sözleşmede netleşsin, teknik loglarda hacim optimizasyonu öne çıksın.

Log bütünlüğünü nasıl kanıtlarız? Her olayı tek tek imzalamak gerekmiyor: 5.000 EPS'te bu günde 432 milyon imza ve 6 saatlik işlemci yükü demek. Olayları 5 dakikalık bloklara ayırıp her bloğun kök hash'ini bir öncekine zincirlemek günde 288 imza üretiyor. Kritik nokta köklerin SIEM dışında tutulması; aksi hâlde veritabanını değiştirebilen biri zinciri de yeniden üretir.