Selamlar, bu yazımda Splunk AI Toolkit ile Failed Login Anomali Tespiti ele alacağız. Şimdiden keyifli okumalar. 🙂  SIEM tarafında çoğu alarm sabit eşikler üzerinden çalışır. Örneğin 15 dakika içinde 50 başarısız oturum açma olayı oluşursa alarm üret gibi. Bu yaklaşım basit ve hızlıdır ancak her kurumun normal davranış profili aynı değildir. Bir ortam için 20 failed login olağan dışıyken başka bir ortamda bu değer günlük operasyonun parçası olabilir.

Splunk AI Toolkit ile bu problemi statik eşik yerine verinin kendi dağılımını öğrenerek ele almak mümkün. Bu yazıda Windows Security loglarındaki EventCode 4625 olaylarını kullanarak Smart Outlier Detection modeli oluşturacağız, modeli publish edeceğiz ve yeni veriye SPL üzerinden uygulayacağız.

1. AI Toolkit Üzerinden Smart Outlier Detection

AI Toolkit içerisinde outlier detection, forecasting, clustering ve prediction gibi farklı machine learning operasyonları bulunuyor. Bu çalışma için kullanacağımız özellik Smart Outlier Detection.

2. Experiment Oluşturma

AI Toolkit > Experiments bölümünden yeni bir experiment oluşturuyoruz. Experiment Type olarak Smart Outlier Detection seçiliyor. Örnek çalışma adı olarak failed_login_count kullanılabilir.

3. Veriyi Model İçin Hazırlama

Modelin ham Windows eventlerini doğrudan öğrenmesi yerine, önce analize uygun sayısal bir feature üretmemiz gerekiyor. Bu nedenle başarısız login olaylarını 15 dakikalık periyotlarda sayıyoruz.

index=windows EventCode=4625 earliest=-7d
| timechart span=15m count AS failed_login_count

Bu sorgu son 7 günlük EventCode 4625 verisini 15 dakikalık zaman kovalarına böler ve her zaman dilimi için failed_login_count alanını üretir.

4. Analiz Edilecek Alanı Seçme

Learn Data ekranında Field to analyze alanı olarak failed_login_count seçiyoruz. İlk modelde Split by fields alanını boş bırakmak, tüm ortam için tek bir genel davranış modeli oluşturmamızı sağlar.

5. Outlier Detection Modelini Çalıştırma

Detect Outliers çalıştırıldığında AI Toolkit, failed_login_count değerlerinin dağılımını inceler ve uygun dağılım modelini otomatik olarak seçebilir. Lab ortamındaki örnekte Auto seçimi sonucunda Beta dağılımı kullanıldı.

6. Model Sonuçlarını Yorumlama

Review Experiment ekranı yalnızca kaç outlier bulunduğunu göstermez; aynı zamanda modelin veri setini nasıl yorumladığını anlamamızı sağlayan istatistikleri de sunar.

Burada dikkat edilmesi gereken nokta, modelin çıktısını doğrudan saldırı olarak yorumlamamaktır. Outlier, normal davranıştan istatistiksel olarak sapmış bir gözlemi ifade eder. SOC tarafında bu sonuç, inceleme önceliği oluşturmak için kullanılabilir.

7. Modeli Operationalize Etme

Model sonuçları anlamlıysa Operationalize adımına geçiyoruz. Bu bölümde modeli publish etmek, alert oluşturmak veya model eğitimini zamanlamak mümkün.

8. Modeli Publish Etme

Modeli publish ederken anlaşılır bir isim kullanmak sonraki SPL aramalarında işleri kolaylaştırır.

failed_login_outlier_model

Publish sonrasında Models ekranından modelin oluştuğunu doğrulayabiliriz. Örneğimizde algoritma DensityFunction ve feature variable failed_login_count olarak görünmektedir.

9. Modeli Yeni Veriye Uygulama

Publish edilen model artık normal Splunk Search ekranında apply komutu ile kullanılabilir.

index=windows EventCode=4625 earliest=-7d
| timechart span=15m count AS failed_login_count
| apply failed_login_outlier_model

apply sonrasında modele ait ek alanlar üretilir. Bunlar, her zaman kovasının normal mi yoksa outlier mı olduğunu değerlendirmek için kullanılır.

10. Model Çıktısındaki Alanlar

11. Sadece Outlier Kayıtlarını Görüntüleme

IsOutlier alan adı parantez içerdiği için SPL içerisinde alan adını tek tırnak ile kullanmak en güvenli yöntemdir.

index=windows EventCode=4625 earliest=-7d
| timechart span=15m count AS failed_login_count
| apply failed_login_outlier_model
| where ‘IsOutlier(failed_login_count)’=1

SOC analisti için daha temiz bir çıktı üretmek istersek:

index=windows EventCode=4625 earliest=-7d
| timechart span=15m count AS failed_login_count
| apply failed_login_outlier_model
| where ‘IsOutlier(failed_login_count)’=1
| table _time failed_login_count “ProbabilityDensity(failed_login_count)” “BoundaryRanges”
| sort – failed_login_count

12. Alarm Mantığına Dönüştürme

Model stabil hale geldikten ve false positive davranışı gözlemlendikten sonra sonuç bir Splunk alert’e dönüştürülebilir.

index=windows EventCode=4625 earliest=-20m
| timechart span=15m count AS failed_login_count
| apply failed_login_outlier_model
| where ‘IsOutlier(failed_login_count)’=1
| table _time failed_login_count “ProbabilityDensity(failed_login_count)” “BoundaryRanges”

13. Production Ortamında Dikkat Edilmesi Gerekenler

Lab ortamında 15 dakikalık bucket ve 7 günlük veri ile hızlı bir POC yaptık. Production ortamında ise modelin sağlıklı sonuç vermesi için veri hacmine göre eğitim penceresi ve bucket boyutu belirlenmeli.

14. Modelin Yeniden Eğitilmesi

Kurum davranışı zaman içinde değişebilir. Kullanıcı sayısı, vardiya düzeni, uygulama sayısı veya saldırı yüzeyi değiştikçe eski baseline güncelliğini kaybedebilir. Bu nedenle ilk üretim geçişinde modeli birkaç gün gözlemlemek, ardından ihtiyaca göre haftalık veya periyodik retraining planlamak daha sağlıklı olur.

Sonuç

Bu çalışma ile Windows EventCode 4625 failed login verilerini statik bir eşik yerine geçmiş davranışa dayalı olarak analiz eden bir anomali modeli oluşturduk. Splunk AI Toolkit’in Smart Outlier Detection özelliği, DensityFunction algoritması ile verinin dağılımını öğrendi; modeli publish ederek SPL içerisinde apply komutuyla tekrar kullanılabilir hale getirdik.

En önemli kazanım, ’50 failed login olursa alarm üret’ gibi sabit bir kural yerine ortamın kendi normalini öğrenen ve normalden sapmayı işaretleyen bir yaklaşım elde etmek. Bu yaklaşım tek başına saldırı kararı vermez; ancak SOC analistinin dikkatini gerçekten sıra dışı davranışlara yönlendiren güçlü bir ek sinyal sağlar.