SIEM, SOC & Log Yönetimi Çözümü

Bir güvenlik ürünü kurmak "görmeyi" garanti etmez. Firewall, EDR, Active Directory, sunucular ve uygulamalar günde milyonlarca kayıt üretir; bu kayıtlar tek merkezde toplanıp ilişkilendirilmezse saldırının izleri dağınık log dosyalarında kaybolur. Bu sayfa; log yönetimi, SIEM ve SOC alımını planlayan bilgi işlem ve bilgi güvenliği ekipleri için çözümün kapsamını, teknik şartname maddelerini ve seçim kriterlerini araştırma aşamasında ele alır.

Çözüm neyi kapsar?

SIEM/SOC bir tek ürün değil, birbirini besleyen bir zincirdir: kaynaklardan log toplama → normalize/zenginleştirme → korelasyon ve kural (use-case) yönetimi → alarm → SOC analistinin triyajı ve müdahalesi. Aşağıdaki tablo, bir kurumun gerçekte neye ihtiyacı olduğunu ayırt etmesine yardımcı olur; birçok kurum tümünü değil, doğru katmanı satın almalıdır.

Log hacmi ve saklama: bütçeyi belirleyen matematik

SIEM lisansı ve depolama maliyeti doğrudan log hacmine bağlıdır; bu yüzden mimariyi kurmadan önce hacmi kestirmek gerekir. Kaba bir hesap:

Günlük ham log (GB) ≈ EPS × ortalama olay boyutu (byte) × 86.400 ÷ 1.000.000.000

Örnek (yaklaşık): 5.000 EPS ve olay başına ~500 byte için günde ≈ 216 GB ham log oluşur. Tipik %85 sıkıştırma sonrası ≈ 32 GB/gün diske düşer; 1 yıllık saklamada bu ≈ 12 TB eder. Bu neden önemli? Çünkü lisans modeli EPS ise ani trafik artışında (ör. DDoS, tarama) EPS tavanını aşıp alarm kaybı yaşayabilirsiniz; GB/gün ise gürültülü kaynakları filtrelemek doğrudan tasarruf demektir. Şartnameye ölçeklenebilirlik ve pik EPS davranışı maddesi eklemek bu riskleri önler.

Korelasyon ve use-case yönetimi

SIEM'in değerini kural setinin kalitesi belirler. İyi bir kurulumda kurallar rastgele değil, tanınmış bir tehdit modeline göre yazılır: MITRE ATT&CK teknikleri (ör. T1110 Brute Force, T1078 Valid Accounts, T1048 Exfiltration) use-case'lere haritalanır. Kurallar çoğunlukla üretici-bağımsız Sigma formatında yazılıp SIEM sorgusuna çevrilebilir; bu, üretici değiştirdiğinizde tespit mantığını sıfırdan yazmaktan kurtarır. Kritik ölçüt yanlış pozitif (false positive) oranıdır: aşırı alarm, analistlerde "alarm yorgunluğu" yaratır ve gerçek olay kaçar. Bu yüzden devreye alma (tuning) ve düzenli use-case gözden geçirme, kurulumun kendisi kadar önemlidir.

Rakamlarla: görünürlük neden bütçe kalemi?

SIEM/SOC yatırımının gerekçesi iki sayının arasındaki mesafede saklıdır: saldırının başladığı an ile fark edildiği an. IBM Cost of a Data Breach 2025'e göre bir ihlali tespit edip kontrol altına almak küresel ortalamada 241 gün sürüyor — dokuz yılın en düşük değeri olmasına rağmen hâlâ sekiz aya yakın bir karanlık dönem. Aynı raporda küresel ortalama ihlal maliyeti 4,44 milyon dolar. Tehdit tarafında Verizon DBIR 2025, fidye yazılımının ihlallerin %44'ünde görüldüğünü ölçüyor (önceki yıl %32). Merkezî log yönetimi ve iyi ayarlanmış korelasyon, bu karanlık dönemi kısaltmanın bilinen en sistematik yoludur; tespit süresi kısaldıkça hem hasar hem maliyet küçülür.

Sektörden örnek (model analizi): Target (2013)

SIEM literatürünün en çok ders çıkarılan kamuya açık olaylarından biri, 2013'te ABD perakende zinciri Target'ın yaşadığı ihlaldir. ABD Senatosu Ticaret Komitesi'nin "Kill Chain" analiz raporuna (2014) göre şirketin saldırı tespit sistemi, zararlı yazılımın kurulumunu ve veri dışarı çıkarma girişimini otomatik uyarılarla işaretledi; ancak bu uyarılara zamanında aksiyon alınmadı ve yazılımın zararlıyı otomatik silme özelliği devre dışıydı. Sonuç: on milyonlarca ödeme kartı verisi dışarı çıktı.

Bu olay bizim projemiz değildir; Senato raporundan bir model analizidir. Çıkarılacak ders, SIEM alımlarının en az konuşulan gerçeğidir: tespit teknolojisi tek başına yetmez. Alarm üretmek ile alarma aksiyon almak arasındaki boşluğu; triyaj prosedürleri, sahiplik ataması, tuning disiplini ve 7/24 izleme kapatır. Şartname yazarken "ürün şu alarmı üretebiliyor mu?" sorusu kadar "bu alarm kimin ekranına, hangi prosedürle, hangi sürede düşecek?" sorusu da tanımlanmalıdır — aksi hâlde en pahalı SIEM bile yalnızca kayıt tutan bir tanık olur.

SOC operasyon modeli: roller ve akış

SIEM'i değerli kılan, üzerinde çalışan operasyon modelidir. Olgun bir SOC'ta akış katmanlıdır: L1 analisti gelen alarmları triyaj eder — yanlış pozitifi kapatır, şüpheliyi yükseltir. L2 analisti olayı derinlemesine inceler: zaman çizelgesi kurar, etkilenen sistemleri belirler, müdahaleyi koordine eder. L3 / tehdit avcısı alarm beklemeden veri içinde proaktif arama yapar ve yeni tespit kuralları (use-case) geliştirir. Bunların yanında use-case yaşam döngüsü işler: yeni tehdit → kural taslağı (çoğunlukla Sigma formatında) → test → devreye alma → yanlış pozitif ölçümü → ayar veya emeklilik. Şartnamede bu döngünün araç desteği (kural sürümleme, test ortamı, MITRE ATT&CK eşlemesi) açıkça istenmeli; SOC hizmeti alınıyorsa rol ve vardiya yapısı sözleşmede tanımlanmalıdır.

Temsili proje kapsamı

Aşağıdaki kapsam temsilidir; gerçek bir projeyi değil, tipik bir SIEM/log yönetimi kurulumunun akışını gösterir. Gerçek kapsam; log kaynaklarınıza, mevzuat yükümlülüklerinize ve ekip yapınıza göre birlikte netleştirilir.

1. Keşif: log kaynağı envanteri, EPS/hacim kestirimi, 5651 ve KVKK yükümlülüklerinin hukuk birimiyle netleştirilmesi.
2. Mimari: toplama katmanı (collector/forwarder), saklama süreleri ve sıkıştırma planı, HA kurgusu, lisans modelinin hacme göre seçimi.
3. Kurulum ve entegrasyon: öncelikli kaynakların bağlanması (kimlik, uç nokta, ağ sınırı), normalize etme ve zaman damgası yapılandırması.
4. Use-case seti: MITRE ATT&CK eşlemeli başlangıç kural kütüphanesi, varlık kritikliğine göre önceliklendirme, runbook bağlantıları.
5. Tuning ve devir: yanlış pozitif azaltma döngüsü, raporlama panoları (MTTD/MTTR, kaynak kapsaması), ekip eğitimi ve işletim devri; isteğe bağlı yönetilen izleme.

Teknik şartnamede dikkat edilecekler

• Standart & format uyumu: Kaynak entegrasyonu için syslog, CEF, LEEF ve API tabanlı toplama zorunlu olmalı; ISO/IEC 27001 A.8.15 (kayıt tutma/loglama) ve NIST CSF Detect (DE)fonksiyonuyla hizalanmalı.
• Entegrasyon açıklığı: EDR→SIEM olay aktarımı ve SIEM→SOAR/bilet sistemi tetiklemesi açık API ile şart koşulmalı; kapalı, yalnız kendi ekosistemine çalışan çözümler ileride sizi kilitler.
• Veri sahipliği ve dışa aktarım (lock-in önlemi): Ham logların ve normalize verinin standart formatta (ör. sıkıştırılmış JSON/Parquet) tam dışa aktarımı sözleşmeye yazılmalı. "Veri bizde kalır ama dışarı alamazsınız" durumu kabul edilmemeli — üretici değiştirmeyi imkânsız kılar.
• 5651 & KVKK: Loglar yurt içinde saklanmalı ve bütünlükleri zaman damgasıyla güvence altına alınmalı; KVKK gereği kişisel veri içeren alanlar için maskeleme/erişim kısıtı tanımlanmalı.
• SLA — MTTD/MTTR: SOC hizmeti alınıyorsa ortalama tespit süresi (MTTD) ve ortalama müdahale süresi (MTTR) hedefleri, olay önem seviyesine göre (ör. kritik olay için MTTR ≤ 30 dk) sözleşmede sayısal olarak yer almalı.
• Kapsam: Kurulum, kaynak entegrasyonu, use-case kütüphanesi, tuning, eğitim ve devreye alma adımları net kalemlenmeli; "lisans verdik" ile "çalışır hâle getirdik" farkı yazıya dökülmeli.

Seçim kriterleri

1. Doğru katman: Yalnız 5651 uyumu mu, yoksa aktif tespit mi istiyorsunuz? İhtiyaç log yönetimiyse SIEM lisansına para bağlamayın.
2. Kaynak kapsama genişliği: Sahip olduğunuz cihaz/uygulamalar için hazır bağlayıcı (connector) var mı; yoksa özel geliştirme maliyeti nedir?
3. Kural taşınabilirliği: Use-case'ler Sigma/açık formatta mı; MITRE ATT&CK kapsamı ölçülebiliyor mu?
4. Ölçek ekonomisi: Hacim iki katına çıktığında lisans + depolama maliyeti nasıl artıyor (doğrusal mı, kademeli mi)?
5. Operasyon modeli: Kurum içi ekip, yönetilen SOC (MSSP/MDR) veya hibrit — hangisi mevcut olgunluğunuza ve bütçenize uyuyor?
6. Yapay zeka desteği: Modern SIEM/UEBA çözümleri anomali tespitinde makine öğrenmesi kullanır; imzasız (davranışsal) tespit yeteneğini bir rehberimizde veriyle ele alıyoruz.

Kurumunuzun log kaynaklarını, mevcut görünürlüğünü ve mevzuat yükümlülüklerini birlikte değerlendirip; önceliklendirilmiş bir SIEM/SOC yol haritası ve şartname taslağı çıkaralım. Aşağıdaki formdan ihtiyacınızı iletmeniz yeterli.