SIEM Nedir? Nasıl Çalışır, Hangi Sorunları Çözer?

SIEM nedir?

SIEM, iki eski ürün kategorisinin birleşimidir: logları toplayıp saklayan güvenlik bilgi yönetimi (SIM) ve olayları gerçek zamanlı izleyen güvenlik olay yönetimi (SEM). Bugünkü SIEM platformları bu ikisini tek bir çalışma alanında birleştirir ve üzerine tehdit istihbaratı, risk puanlama ve olay yönetimi ekler.

Bir kurumda güvenlikle ilgili kayıtlar onlarca farklı yerde oluşur: güvenlik duvarı bağlantıları, Active Directory oturum açmaları, web sunucusu erişim logları, VPN, e-posta ağ geçidi, bulut denetim kayıtları. Her biri farklı biçimde ve çoğu zaman farklı saat ayarıyla yazılır. SIEM bu kayıtları bir araya getirir ve tek bir soruyu cevaplanabilir kılar: “Şu anda ortamımızda olağandışı ne oluyor?”

SIEM hangi sorunları çözer?

• Dağınık görünürlük — Her sisteme ayrı ayrı bağlanıp log aramak yerine tüm kaynaklar tek ekrandan sorgulanır.
• Tek başına anlamsız olaylar — Bir başarısız giriş önemsizdir; aynı IP’den yüzlerce deneme ve ardından başarılı bir giriş ise saldırı örüntüsüdür. SIEM bu bağlantıyı kurar.
• Geç fark edilen saldırılar — Kurallar ve anomali tespiti, saldırıyı haftalar sonra bir denetimde değil, gerçekleşirken görünür kılar.
• Kanıt ve uyumluluk — Logların merkezi ve bütünlüğü korunmuş biçimde saklanması, denetimlerde ve olay sonrası incelemelerde kanıt sağlar.

NIST’in log yönetimi rehberi SP 800-92, kurumların log üretimi, saklanması ve analizi için bir altyapı ve süreç kurmasını önerir ve SIEM yazılımını bu altyapının analiz katmanında ele alır. Yani SIEM, log yönetiminin yerine geçmez; onun üzerine kurulur. Birçok SIEM buna ek olarak kullanıcı ve varlık davranış analitiği (UEBA) sunar: her hesabın ve sistemin olağan davranışını öğrenir, bu normalden sapmaları kural yazılmamış olsa bile işaretler.

SIEM nasıl çalışır? Toplama, normalizasyon, korelasyon, uyarı

SIEM dört temel adımda çalışır: logları kaynaklardan toplar, ortak alanlara ayrıştırıp normalize eder, kurallar ve modellerle olaylar arasında ilişki kurar ve önemli bulduklarını analiste uyarı olarak sunar. Bu adımların kalitesi, uyarıların kalitesini doğrudan belirler.

Toplama

Ağ cihazları ve Linux sistemleri genellikle syslog (RFC 5424) ile log gönderir; Windows olay günlükleri ve uç nokta verileri için agent kullanılır; bulut ve SaaS servislerinden loglar API ile çekilir. Burada iki şey kritiktir: tüm kaynaklarda saat senkronizasyonu (NTP) ve kapsamın eksiksiz olması. Toplanmayan log analiz edilemez.

Normalizasyon

Bir güvenlik duvarı kaynak adresi src, bir diğeri srcip, Windows ise IpAddress olarak yazar. Normalizasyon bunları tek bir alana eşler; böylece “bu IP hangi sistemlerde görüldü?” sorusu tek sorguyla cevaplanır.

raw:
Oct 23 08:41:12 web01 sshd[2211]: Failed password for root from 203.0.113.45 port 52114

normalized:
event    = auth_failure
user     = root
src_ip   = 203.0.113.45
src_port = 52114
host     = web01
app      = sshd

Korelasyon ve uyarı

Korelasyon kuralı birden fazla olayı zaman ve ortak alanlar üzerinden bağlar; örneğin “5 dakika içinde aynı kaynak IP’den 20’den fazla başarısız giriş ve ardından başarılı giriş”. Kurala uyan olaylar önem derecesiyle bir uyarı üretir. İyi bir SIEM’de her uyarı, onu tetikleyen ham loglara kadar izlenebilir olmalıdır.

SIEM ile log yönetimi arasındaki fark nedir?

Log yönetimi logları toplar, saklar ve aranabilir kılar; SIEM ise bu logları güvenlik gözüyle analiz eder. Kısacası log yönetimi “ne oldu?” sorusuna, SIEM “bu tehlikeli mi?” sorusuna cevap verir.

Hangisine önce ihtiyacınız var?

Henüz logları merkezi olarak toplamıyorsanız ilk adım log yönetimidir: kaynakları bağlamak, saatleri senkronize etmek, saklama süresini belirlemek. Loglar düzenli akmaya başladıktan sonra en kritik birkaç saldırı senaryosu için korelasyon kuralları eklemek, SIEM’e geçişin en sağlıklı yoludur. İki işlevi aynı platformda sunan çözümler bu geçişi veri taşımadan yapmanızı sağlar.

Pratikte iyi bir SIEM, sağlam bir log yönetimi altyapısının üzerine kurulur: loglar eksik ya da yanlış ayrıştırılmışsa korelasyon da yanlış sonuç verir. Log yönetimini ayrıntılı olarak log yönetimi nedir yazımızda anlatıyoruz. Yasal saklama yükümlülüğü olan kurumlar için arşiv tarafı ayrıca önemlidir; Türkiye’deki yükümlülükleri 5651 loglama rehberinde ele aldık.

SIEM ve SOC arasındaki ilişki nedir?

SOC (güvenlik operasyon merkezi) insanlardan ve süreçlerden oluşan ekiptir; SIEM ise bu ekibin ana çalışma aracıdır. SIEM uyarıyı üretir, SOC analisti onu doğrular, araştırır ve müdahale eder.

SIEM olmadan bir SOC onlarca konsolu ayrı ayrı izlemek zorunda kalır; SOC olmadan bir SIEM ise kimsenin bakmadığı uyarılar üretir. Bu yüzden bir SIEM projesinin başarısı, aracın özelliklerinden çok uyarıların kim tarafından ve hangi süreçle ele alınacağının net olmasına bağlıdır.

• Seviye 1 analist — SIEM uyarılarını sınıflandırır, yanlış pozitifleri ayıklar, gerçek olayları yükseltir.
• Seviye 2–3 analist — SIEM’de geriye dönük arama yapar, olayın kapsamını ve kök nedenini çıkarır.
• Tespit mühendisi — Korelasyon kurallarını yazar, ortama göre ayarlar ve gürültüyü azaltır.
• Tehdit avcısı — Kural tetiklenmesini beklemeden, hipotezlerle SIEM verisinde saldırı izi arar.

Bir uyarının yaşam döngüsü genellikle şöyledir: SIEM uyarıyı üretir, Seviye 1 analist doğrular ve gerekiyorsa bir olay (incident) kaydı açar, Seviye 2 analist kapsamı çıkarır, müdahale tamamlandığında olay kapatılır ve gerekiyorsa kural ayarlanır. Bu döngünün her adımının SIEM üzerinde iz bırakması, hem ekibin hızını ölçmeyi hem de denetimde kanıt sunmayı kolaylaştırır.

SOC’un rollerini, süreçlerini ve kurum içi ile hizmet olarak SOC arasındaki farkları SOC nedir yazımızda ayrıntılı anlattık. Olay müdahalesinin genel çerçevesi için NIST’in SP 800-61 Rev. 3 yayını iyi bir başlangıç noktasıdır.

SIEM ile hangi saldırılar tespit edilir?

SIEM en güçlü olduğu yerde, birden fazla logda iz bırakan saldırıları yakalar: kaba kuvvet ve parola püskürtme, ele geçirilmiş hesaplar, yetki yükseltme, webshell ve fidye yazılımı öncesi hazırlık adımları. Aşağıdaki örnekler MITRE ATT&CK tekniklerine göre eşleştirilmiştir.

Örneğin kaba kuvvet senaryosu için yazılmış basit bir korelasyon kuralı, mantık olarak şuna benzer:

when   count(event = auth_failure) >= 20
       group by src_ip
       within 5 minutes
followed by  event = auth_success  from same src_ip  within 10 minutes
then   alert severity = high  "Brute force followed by successful login"

Bu senaryoların ortak noktası, tek bir logun yetmemesidir. Kaba kuvvet tespiti kimlik doğrulama loglarını, webshell tespiti dosya ve web sunucusu loglarını, fidye yazılımı tespiti ise uç nokta, dosya ve yedekleme loglarını birlikte gerektirir. Tehdit istihbaratı eşleşmeleri (bilinen kötü amaçlı IP adresleri, TOR çıkış düğümleri, botnet altyapısı) ise bu uyarıların hangisine önce bakılacağını belirlemeye yardım eder. Dosya tarafındaki izleri FIM rehberimizde anlatıyoruz.

SIEM seçerken nelere bakılmalı?

SIEM seçiminde belirleyici olan; ürünün sizin ortamınızdaki logları ne kadar iyi toplayıp anlamlandırdığı, ekibinizin onu sürdürüp sürdüremeyeceği ve toplam maliyettir. Özellik listesinden çok, kendi loglarınızla yapılan bir deneme güvenilir bir ölçüttür.

1. Kaynak kapsamı — Kullandığınız güvenlik duvarı, sunucu, uygulama ve bulut servisleri için hazır ayrıştırıcı var mı? Yoksa özel ayrıştırıcı yazmak ne kadar kolay?
2. Normalizasyon kalitesi — Farklı kaynaklardaki aynı bilgi (kullanıcı, IP adresi) aynı alana düşüyor mu?
3. Tespit içeriği — Hazır korelasyon kuralları, kuralları kendi ortamınıza uyarlama imkânı, anomali tespiti ve tehdit istihbaratı entegrasyonu.
4. Araştırma deneyimi — Bir uyarıdan ham loga, ilgili olaylara ve zaman çizelgesine ne kadar hızlı ulaşılıyor?
5. Saklama ve bütünlük — Sıcak veri ve arşiv saklama süreleri, arşivlerin hash ve zaman damgasıyla korunması, yasal saklama gereksinimleri.
6. Ölçek ve mimari — Olay hacmi arttığında performans nasıl etkileniyor? Yüksek erişilebilirlik ve çok kiracılı (multi-tenant) yapı gerekiyor mu?
7. Yetkilendirme — Rol tabanlı erişim (RBAC), denetim kaydı ve farklı ekiplerin yalnızca kendi verisini görmesi.
8. Entegrasyonlar — Talep yönetimi, EDR, e-posta ve mesajlaşma araçlarıyla bağlantı; uyarının ekibin zaten kullandığı kanala ulaşması.
9. Lisans modeli ve toplam maliyet — Veri hacmine, cihaza veya kullanıcıya göre lisanslama; donanım, depolama ve işletme emeği dahil toplam maliyet.

Ekibinizin kural yazma kapasitesini de hesaba katın. Hazır kural kütüphanesi başlangıcı hızlandırır, ama her ortamın kendine özgü yönetim hesapları, tarama sistemleri ve iş saatleri vardır. Kuralların ne kadar kolay okunup değiştirilebildiği, ilk aydan sonra ürünün değerini belirleyen asıl etkendir.

Bulut SIEM mi, kurum içi SIEM mi?

Bulut SIEM altyapı yükünü sağlayıcıya bırakır ve hızlı başlar; kurum içi (on-premise) SIEM ise verinin konumu ve kontrolü üzerinde tam yetki verir. Seçimi çoğu zaman veri yerelliği, mevzuat, mevcut altyapı ve ekip kapasitesi belirler.

Hibrit model

Birçok kurum iki modeli birleştirir: logları kendi ağında toplayıp ön işler, analiz ve arayüzü bulutta kullanır ya da tersine, kritik logları kurum içinde tutup daha az hassas kaynakları buluta gönderir. Hangi yolu seçerseniz seçin, logların nerede saklandığı, kimin erişebildiği ve sözleşme bittiğinde verinin nasıl geri alınacağı baştan netleştirilmelidir.

KVKK ve sektörel düzenlemeler, kişisel veri içeren logların nerede işlendiğini bu kararın önemli bir girdisi haline getirir; bazı kurumlar logları kendi altyapısında tutmayı tercih eder. Logchase her iki modeli de destekler: Logchase SIEM bulutta hizmet olarak ya da kendi veri merkezinizde kurulu olarak çalışabilir.