SIEM korelasyonu: günlüklerden anlamlı alarma

Kaynak kalitesi, ortak alanlar, zaman penceresi ve müdahale adımlarıyla ölçülebilir bir SIEM korelasyon kuralı tasarlamak.
SIEM ortamında çok sayıda olay toplamak, aynı ölçüde görünürlük elde edildiği anlamına gelmez. Bir alarmın işe yaraması için olayın neden önemli olduğunu ve analistin bundan sonra ne yapacağını açıklaması gerekir. Korelasyonu bu karar zincirinin bir parçası olarak değerlendiriyorum.
Kurala bir soru ile başlayın
Temsili sorumuz şu olsun: Bir kullanıcıda tekrarlanan başarısız oturum açma girişimlerinin ardından başarılı erişim görülüyor mu ve bu erişim beklenmeyen bir bağlam taşıyor mu? Sadece başarısız girişim sayısına bakmak, hatalı parola kullanan normal bir uygulamayı da sürekli alarma dönüştürebilir.
Kuralın amacı, ilgili varlıklar, kullanılacak günlük kaynakları ve hangi davranışın kapsam dışında olduğu yazılır. Kullanıcı adı normalizasyonu, cihaz kimliği ve olay zamanı aynı biçimde yorumlanmıyorsa korelasyon güvenilir olmaz. Toplama gecikmesi ile olayın gerçekleşme zamanı birbirinden ayrılmalıdır.
Veri kalitesi ilk kontroldür
Kaynakların saat eşitlemesi, günlüklerin düzenli gelmesi ve ayrıştırılmış alanların doğruluğu sınanır. Günlük göndermeyi bırakan bir sistemin sessiz kalması, güvenlik durumunun iyi olduğunu göstermez. Kaynak sağlığı için ayrı bir izleme kuralı gerekir.
Deneme verisi kontrollü olarak üretilir ve kaynak olaydan SIEM ekranına kadar izlenir. Bu aşamada olay kaybı, farklı kullanıcı gösterimleri ve saat dilimi farkları kaydedilir. Yanlış alanla eşleştirilen bir kural, sözdizimi doğru olsa bile yanlış sonuç üretir.
Güvenilir günlük02
Bağlam ve korelasyon03
İnceleme ve müdahale
Zaman penceresi ve gruplama
Sorgunun çalışma aralığı ile geriye bakış süresi birlikte tasarlanır. Microsoft Sentinel belgeleri de zamanlamayı, eşik değerlerini, varlık eşlemesini ve olay gruplamayı kural tasarımının ayrı bileşenleri olarak açıklar. Buradaki yöntem ürün bağımsızdır; örnek belirli bir SIEM kurulumunun beyanı değildir.
Aynı kullanıcıya ait yinelenen alarmlar tek inceleme altında toplanabilir; ancak aşırı bastırma yeni bir olayı görünmez kılabilir. Sabit bir eşik bütün kurumlara uymaz. İş saatleri, servis hesapları ve uygulama davranışı dikkate alınarak geçmiş veride kontrollü deneme yapılmalıdır.
Alarmın sonuna müdahale adımını ekleyin
Alarm; ilgili kullanıcıyı, kaynağı, zaman aralığını, tetikleyen koşulu ve doğrulama bağlantılarını içermelidir. Analistin ilk kontrolü ile olayın yükseltileceği durumlar kısa ve açık yazılır. Otomatik hesap kapatma gibi etkili işlemler, doğrulanmış koşullar ve yetkili süreç olmadan bağlanmamalıdır.
İzlenecek ölçüler yalnızca alarm sayısı değildir. İnceleme için gereken süre, doğrulanmış olay oranı ve eksik bağlam nedeniyle geri dönen kayıtlar da değerlendirilir. Kural değişiklikleri sürümlenir; istisnalar sahip ve bitiş tarihiyle yönetilir.
Uygulama kontrol listesi
- Kaynak sağlığı ve zaman alanları doğrulandı mı?
- Kural kontrollü veriyle tetiklendi mi?
- Alarmın sahibi ve ilk müdahale adımları belli mi?
Bu yazı kişisel bir teknik yöntem notudur. Senaryolar temsili ve anonimdir; herhangi bir kurumda yaşanmış belirli bir olayın kaydı değildir. Ürün adımları, kurulu sürüm ve yetkili değişiklik süreciyle birlikte değerlendirilmelidir.
Resmî kaynaklar ve ileri okuma
Teknik kaynak kontrolü: 1 Kasım 2026. Belgelerdeki sürüm ve kapsam ayrımları uygulama öncesi yeniden kontrol edilmelidir.
Okumaya devam edin

Güvenlik duyurusunu doğrulamak: CVE iddiasından uygulanabilir yama planına
Duyuru metnini kopyalamadan ürün, etkilenen sürüm, yapılandırma ve resmî düzeltme bilgisini doğrulayın.

Nessus bulgusundan düzeltme kanıtına: rapor nasıl eyleme dönüştürülür?
Plugin çıktısı, tarama yetkisi ve yeniden test kapsamını kullanarak ölçülebilir düzeltme kaydı hazırlayın.
