SIEM'e Yazabileceğiniz Altı Korelasyon Kuralı: DAM ve Yönetişim Birlikte Ne Yakalar?

Önceki yazılarda fikri anlattık: DAM her şeyi görür, yönetişim katmanı izinli olanı bilir, ikisi birleşince alarm yazılabilir. Bu yazı işin mutfağı. Kuralları satıcıdan bağımsız mantık olarak yazıyoruz; kendi SIEM platformunuzun sözdizimine uyarlarsınız. Kurallara geçmeden önce dört ön koşul var. Bunlar sağlanmadan kural yazmak yanlış alarm fabrikası kurmaktır.

Başlamadan Önce Dört Şey

1. "Beklenen hesaplar" listesi. Her üretim sunucusu için izinli hesaplar: ürünün yürütme hesabı ve kurumun kendi uygulama hesapları. Ürünün hesabını rapor verir; uygulama hesaplarını kurum kendi listesine ekler.
2. Süzgeç. Yönetişim katmanından gelen başlangıç ve bitiş olayları sıradan (Notice) önemdedir. Eşiği Notice'in üstüne çıkarılmış ya da Denetim akışı kapatılmış bir SIEM bu olayları sessizce kaybeder ve kurallar yanlış alarm üretmeye başlar. Ürünün kurulum kontrol ekranı bu durumu ayrı bir satırda gösterir. Bu yazıdaki kurallar için SIEM eşiği (SiemMinSeverity) Notice ya da altında olmalıdır.
3. Saat. DAM, veritabanı sunucusu, yürütücü makine ve SIEM aynı saat kaynağına bağlı olmalı. Kuralların çoğu "±birkaç dakika" içinde eşleşme arar. Saat kayması yanlış alarmların ilk sebebidir.
4. Yanlış alarm listesi. Zamanlanmış işler, yedekleme hesapları, izleme sondaları "beklenen hesap" listesine ait olmalı ya da kural dışında tutulmalı.

K1. İzinsiz Hesapla Değişiklik

Mantık: Üretim sunucusunda DDL, DML ya da yetki komutu var ve hesap "beklenen hesaplar" listesinde yok. Ne yakalar: doğrudan erişim, paylaşılan hesap, unutulmuş yetki, tedarikçi hesabı. Dikkat: ilk gün yüzlerce alarm çıkabilir. Bu kural bir keşif aracıdır: çıkan alarmlar "hangi hesapları kapatmalıyız" listesini verir. Önce izleme modunda çalıştırın.

K2. Olay Olmadan Ürün Hesabı

Mantık: DAM'de ürünün yürütme hesabıyla işlem var, ama ±N dakika içinde SIEM'de başlangıç olayı yok. Ne yakalar: ürünün hesabının ve parolasının başka bir yerde kullanılması. Bu en sinsi durumdur: hesap "beklenen" listesinde olduğu için K1 onu görmez. Dikkat: N değeri yürütme süresine bağlıdır. Zamanlanmış işlerde başlangıç olayı planlanan saatte gelir.

K3. Sahte Ad

Mantık: Oturum adı ürünün ön ekiyle başlıyor (SQL Change Guard/), ama hesap yürütücünün hesabı değil ya da DAM'deki istemci adresi, eşleşen olaydaki yürütücü makine adıyla (executorHost) uyuşmuyor. Ne yakalar: ad taklidi. Uygulama adı bağlananın kendi beyanıdır; bir hesabı olan herkes aynı adı yazabilir. Bu kural adın tek başına kanıt olmadığını sisteme yazdırır. Dikkat: istemci adresi NAT ya da yük dengeleyici arkasındaysa adres executorHost ile eşleşmeyebilir. Bu durumda hesap ve olay eşleşmesine yaslanın.

K4. Pencere Dışı İşlem

Mantık: Ürünün hesabıyla işlem var, ama başlangıç ile bitiş olayı arasındaki pencerenin dışında. Ne yakalar: bir iş bittikten sonra aynı hesabın yeniden kullanılması. Dikkat: pencereye küçük bir tolerans ekleyin (birkaç saniye). Olay yazımı ile veritabanı işlemi aynı anda gerçekleşmez.

K5. Başlayan Ama Bitmeyen İş

Mantık: Başlangıç olayı var, N saat içinde ne bitiş ne başarısızlık olayı geldi. Ne yakalar: takılan yürütme, kesilen bağlantı, çöken servis. Bu kural güvenlik kadar işletme kuralıdır ve DBA ekibi için de değerlidir.

K6. Gözden Geçirilmeyen Acil Değişiklik

Mantık: Çalıştırma olayında isEmergency alanı true ve 24 saat içinde ChangeRequest.EmergencyReviewed olayı yok. Ne yakalar: kısaltılmış onayla giren ama ertesi gün kapanmayan acil işler. Dikkat: gözden geçirme olayı süzülemez, ama çalıştırma olayı sıradan önemdedir. Kural, SIEM eşiği (SiemMinSeverity) Notice ya da altındaysa çalışır; eşik yükseltilmişse çalıştırma olayı SIEM'e hiç ulaşmaz ve kural sessiz kalır.

Yanlış Alarmı Kuralın Parçası Yapın

Hiçbir kural ilk gün doğru çalışmaz. Üç alışkanlık işi kolaylaştırır:

• İzleme modu. Her kuralı önce alarm üretmeden, sadece sayı sayarak çalıştırın.
• Hesap sahibi. Listedeki her hesabın yanında bir sahibi olsun. K1 alarmının gideceği kişi belli olsun.
• Aylık gözden geçirme. "Beklenen hesaplar" listesi bir kez kurulup bırakılırsa üç ayda bozulur.

Sınır: Kuralı Ürün Yazmaz

Yönetişim katmanı SIEM kuralı üretmez. Kural kurumun kendi platformunda, kendi risk iştahıyla yazılır. Ürün üç şeyi verir: beklenen hesap raporu, oturum işareti ve başlangıç ile bitiş olayları. Kuralın kendisi sizin. Bu bilinçli: kuralı ürün yazsaydı kurum "izinli" tanımını kendi elinden çıkarmış olurdu.

Sık Sorulan Sorular

Bu kuralları yazmak için hangi ön koşullar gerekir?

Beklenen hesaplar listesi, başlangıç ve bitiş olaylarının süzülmemesi (SIEM eşiği Notice ya da altında), ortak bir saat kaynağı ve bir yanlış alarm listesi. Bunlar olmadan kural yanlış alarm üretir.

Oturum adı ürünün ön ekini taşıyorsa işlem güvenilir midir?

Hayır. Uygulama adı bağlananın kendi beyanıdır ve bir hesabı olan herkes aynı adı yazabilir. K3 kuralı adı tek başına kanıt saymaz: hesabı, DAM'deki istemci adresini ve olaydaki yürütücü makine adını (executorHost) birlikte karşılaştırır.

Gözden geçirilmeyen acil değişiklik kuralı ne zaman çalışmaz?

Çalıştırma olayı sıradan önemdedir. SIEM eşiği (SiemMinSeverity) Notice'in üstüne çıkarılmışsa çalıştırma olayı SIEM'e ulaşmaz ve kural sessiz kalır. Gözden geçirme olayı ise süzülemez.