SIEM use-case nedir?
SIEM use-case, tespit edilmek istenen tehdit veya risk senaryosunu işletilebilir hale getirir. “Başarısız girişleri izle” gibi genel bir ifade yerine hangi kullanıcı, sistem, zaman aralığı ve eşikte alarm oluşacağı; hangi log alanlarının gerekli olduğu ve analistin ne yapacağı tanımlanır.
Olgun bir use-case kaydında amaç, risk senaryosu, veri kaynakları, mantık, kapsam, istisnalar, önem seviyesi, alarm zenginleştirmesi, inceleme adımları, sorumlu ekip, yanıt hedefi ve başarı ölçütü bulunur. Böylece kural yalnız SIEM yöneticisinin bildiği bir sorgu olmaktan çıkar, SOC tarafından yönetilen tespit ürününe dönüşür.
Korelasyon kuralı nedir?
Korelasyon, tek başına düşük anlam taşıyan olayları kullanıcı, IP, cihaz, uygulama veya zaman ilişkisi üzerinden birleştirir. Örneğin çok sayıda başarısız girişten sonra aynı hesaptan başarılı VPN bağlantısı ve kısa süre içinde ayrıcalıklı gruba üyelik görülmesi, tekil olaylardan daha yüksek risk gösterebilir.
Her use-case korelasyon gerektirmez. Kritik yönetici hesabının devre dışı bırakılması tek olayla alarm üretebilir. Korelasyon gerektiğinde sıra, eşik, zaman penceresi ve ortak alanlar açık olmalıdır. Çok geniş pencere ilgisiz olayları birleştirir; çok dar pencere yavaş saldırıları kaçırabilir.
Log toplamak neden tek başına yeterli değildir?
Logun SIEM'e gelmesi, tespit yapılabildiği anlamına gelmez. Zaman damgası yanlış, kullanıcı alanı boş, cihaz adı tutarsız veya olay türü ayrıştırılmamışsa kural güvenilir çalışmaz. Kaynak devreye alındığında bağlantı kadar alan eşleme, zaman senkronizasyonu, olay kapsamı ve veri kaybı izlenmelidir.
İkinci sorun amaçsız hacimdir. Debug kayıtları veya tekrarlayan ağ olayları lisans ve saklama maliyetini büyütürken analiste değer sağlamayabilir. Önce kritik varlıklar ve tehdit senaryoları seçilmeli, ardından bunları destekleyen loglar önceliklendirilmelidir. Veri kaynağı kapandığında ayrıca sağlık alarmı üretilmelidir.
Use-case tasarım süreci
- Riski tanımlayın: Kritik varlık, tehdit, olası saldırı yolu ve iş etkisini yazın.
- Veriyi eşleyin: Gerekli olayların hangi sistemde ve hangi alanlarla üretildiğini doğrulayın.
- Mantığı tasarlayın: Tekil olay, eşik, sıra veya çok kaynaklı korelasyon kararını verin.
- Test verisi oluşturun: Kontrollü senaryoyla kuralın çalıştığını ve gerekli kanıtı taşıdığını görün.
- Önceliklendirin: Varlık değeri, kullanıcı rolü, tehdit güveni ve olası etkiyi birleştirin.
- Playbook yazın: Analistin doğrulama, zenginleştirme, eskalasyon ve kapatma adımlarını tanımlayın.
- İyileştirin: False positive, kaçırılan olay ve müdahale sonuçlarıyla kuralı sürümleyin.
Active Directory ve başarısız login örnekleri
Active Directory için yalnız başarısız giriş saymak yoğun gürültü üretebilir. Aynı hesaptan farklı cihazlara deneme, bir kaynaktan çok sayıda kullanıcıya parola püskürtme, kilitlenme sonrası başarı, yeni yönetici hesabı, ayrıcalıklı gruba üyelik ve denetim politikasının değiştirilmesi farklı use-case'lerdir.
Servis hesapları, parola değişikliği sonrası eski kimlik bilgisi kullanan görevler ve zafiyet tarayıcıları normalden yüksek başarısızlık yaratabilir. Bunlar kör biçimde hariç tutulmamalı; sahip, kaynak cihaz ve beklenen davranışla sınırlandırılmalıdır. Domain controller logları, kimlik bağlamı ve kritik grup listeleri alarmı güçlendirir.
VPN, firewall ve mesai dışı erişim
VPN use-case'leri başarısız giriş, olağan dışı ülke veya IP, kısa sürede farklı konum, yeni cihaz, MFA hatası ve bağlantı sonrası kritik ağ erişimini ilişkilendirebilir. “Mesai dışı” tek başına saldırı değildir; vardiya, uzaktan çalışma, izin ve bakım pencereleri bilinmeden alarm sürekli gürültü üretir.
Firewall logları engellenen trafiğin yanında izin verilen kritik akışları da göstermelidir. Yeni internet yayını, yönetim portuna erişim, aynı kaynaktan tarama davranışı, DMZ'den iç ağa beklenmeyen geçiş veya kural değişikliği izlenebilir. NAT nedeniyle gerçek kaynak-hedef ilişkisini kuracak alanların korunması önemlidir.
EDR/XDR ve şüpheli PowerShell
PowerShell kurumsal yönetimde meşru olarak kullanılır; süreç adını görmek tek başına yeterli değildir. Kodlama veya gizleme parametreleri, internetten içerik indirme, Office uygulamasından başlama, yeni kalıcılık mekanizması ve ayrıcalıklı kullanıcı bağlamı riski artırabilir.
EDR/XDR; süreç ağacı, komut satırı, dosya, kayıt defteri ve ağ bağlantısı gibi uç nokta bağlamı sağlar. SIEM bu veriyi kimlik, proxy, DNS ve firewall olaylarıyla ilişkilendirebilir. Alarmın cihaz izolasyonu veya hesap engelleme gerektirip gerektirmediği playbook içinde koşullu tanımlanmalıdır.
DLP ve veri hareketi senaryoları
DLP alarmı; hassas veri türü, kanal, kullanıcı, hedef, dosya ve politika eylemi gibi bağlam taşır. Tek bir dosya aktarımı meşru olabilir; kısa sürede yüksek hacim, kişisel bulut hedefi, işten ayrılacak kullanıcı veya yeni takılan USB ile birleştiğinde öncelik değişir.
SIEM'in DLP kararını yeniden üretmesi gerekmez. Amaç, veri hareketini kimlik ve uç nokta olaylarıyla zenginleştirerek olayın gerçek riskini görmek ve ilgili veri sahibiyle doğru eskalasyonu yapmaktır. Gizlilik gereği alarm içeriğine erişim sınırlandırılmalıdır.
Windows ve Linux loglarında ortak tasarım
Windows olay kimlikleri ve Linux auth, audit veya sistem kayıtları farklı biçimlerdedir; fakat use-case mantığı ortak davranışa odaklanabilir. Yeni kullanıcı, ayrıcalık değişimi, başarısız giriş, servis oluşturma, görev zamanlama, log silme ve güvenlik kontrolünü durdurma iki platformda da izlenebilir.
Normalizasyon, kaynak alanlarını ortak kullanıcı, host, süreç ve eylem modeline dönüştürür. Ham olayın da saklanması inceleme için önemlidir. Kritik Linux sunucularında audit kapsamı yetersizse SIEM kuralı yazmak sorunu çözmez; önce doğru olay üretimi ve dosya bütünlüğü gibi kaynak kontrolleri yapılandırılmalıdır.
False positive ve alarm önceliği
False positive azaltmak alarmı sessize almak değildir. İş bağlamı eklemek, varlık kritikliğini kullanmak, servis hesaplarını ayırmak, eşikleri gerçek veriyle ayarlamak ve geçici istisnalara sahiplik/süre vermek gerekir. Her kapanan alarm için neden kodu tutulması, hangi kuralların en çok analist zamanı tükettiğini gösterir.
Öncelik yalnız kuralın sabit seviyesine bağlı olmamalıdır. Ayrıcalıklı hesap, kritik sunucu, bilinen kötü gösterge, başarılı saldırı adımı ve hassas veri etkisi puanı yükseltebilir. Alarmın yeterli kanıt, ilgili loglar ve önerilen ilk adımlarla gelmesi SOC işlem süresini kısaltır.
SOC operasyonu ve use-case yaşam döngüsü
SOC, alarmı alan ekibin ötesinde tespit içeriğini işleten süreçtir. Seviye 1 doğrulama, ileri inceleme, sistem/veri sahibi iletişimi, olay müdahalesi ve kural sahibinin geri bildirim döngüsü tanımlanmalıdır. Securebyt tarafından belirli bir SOC hizmeti sunulduğu bu rehberde iddia edilmemektedir.
Use-case'ler sahip, sürüm ve gözden geçirme tarihiyle kataloglanmalıdır. Yeni log kaynağı, altyapı değişikliği, tehdit bilgisi veya yaşanan olay kuralı güncelleyebilir. Çalışmayan, veri kaynağı eksik veya sürekli gürültü üreten kural için devre dışı bırakma yerine kök neden ve iyileştirme kararı kaydedilmelidir.
5651 kayıtları ile güvenlik loglarının amaç farkı
5651 bağlamındaki trafik kayıtları ve bütünlük süreçleri belirli hukuki ve kayıt amaçlarına yöneliktir. SIEM güvenlik izleme ise saldırı davranışını zamanında tespit etmek, ilişkilendirmek ve müdahaleyi desteklemek için farklı kaynak ve alanlara ihtiyaç duyar. Bir logun mevzuat kapsamında saklanması, güvenlik alarmı için yeterli olduğu anlamına gelmez.
Hukuki saklama yükümlülüğü, bütünlük, zaman damgası ve erişim koşulları ilgili uzmanlarla değerlendirilmelidir. Güvenlik ekibi ise use-case için gereken veri ayrıntısı, erişim yetkisi ve saklama süresini risk temelinde belirlemelidir. İki ihtiyacın aynı altyapıda karşılanması mümkün olsa da amaç ve kontroller dokümante edilmelidir.
Sık sorulan sorular
SIEM use-case nedir?
Belirli bir tehdit veya risk senaryosunun hangi loglarla, hangi koşullarda tespit edileceğini; alarmın önceliğini, sorumlusunu ve inceleme adımlarını tanımlayan işletilebilir tespit tasarımıdır.
Korelasyon kuralı ile tekil alarm arasındaki fark nedir?
Tekil alarm bir olay veya eşik üzerinden çalışabilir. Korelasyon kuralı ise farklı zaman, kullanıcı, cihaz veya kaynaklardaki birden fazla olayı ilişkilendirerek daha anlamlı bir saldırı örüntüsü arar.
SIEM için bütün logları toplamak gerekir mi?
Hayır. Öncelik, kritik varlık ve use-case için gerekli, kaliteli ve sürdürülebilir loglara verilmelidir. Değer üretmeyen yüksek hacimli veri maliyet ve gürültü oluşturabilir.
SIEM false positive nasıl azaltılır?
Varlık ve kullanıcı bağlamı eklemek, servis hesaplarını ayırmak, eşikleri veriye göre ayarlamak, kontrollü istisna tanımlamak ve kapatılan alarmların nedenlerini düzenli analiz etmek gerekir.
5651 logları SIEM güvenlik izleme için yeterli midir?
Hayır. 5651 kapsamındaki kayıt ve bütünlük ihtiyaçlarıyla güvenlik tespiti farklı amaçlara sahiptir. SIEM use-case'leri kimlik, uç nokta, ağ, uygulama ve veri güvenliği olaylarından yeterli bağlam gerektirir.
İlgili Hizmetler
Log envanteri, use-case kataloğu, korelasyon, alarm iyileştirme ve entegrasyon yaklaşımı için SIEM ve log yönetimi danışmanlığı sayfasını inceleyebilirsiniz.
← Tüm rehberlere dön
Use-case kataloğunuzu birlikte tasarlayalım
Kritik varlıklarınızı, tehdit senaryolarınızı ve mevcut log kalitesini değerlendirerek ölçülebilir bir SIEM iyileştirme planı oluşturalım.
İletişime geçin
