Bir SIEM Alarmı BGYS’de Nasıl Kontrol Kanıtına Dönüşür?

SSH Üzerinden Yetkisiz Erişim Denemelerine Yönelik Bir PoC Çalışması

Bilgi güvenliği alanında SOC (Security Operations Center) ve BGYS (Bilgi Güvenliği Yönetim Sistemi) genellikle birbirinden ayrı disiplinler gibi ele alınır. SOC tarafı daha çok olaylara, alarmlara ve teknik tespitlere odaklanırken; BGYS tarafı riskler, kontroller ve denetim süreçleri ile ilgilenir.

Oysa pratikte bu iki alan birbirinden kopuk değildir. Doğru kurgulanmış bir SIEM alarmı, BGYS kapsamında somut bir kontrol kanıtı haline gelebilir.

Bu yazıda, Splunk üzerinde gerçekleştirdiğim bir PoC çalışması üzerinden, teknik bir alarmın bilgi güvenliği bakış açısıyla nasıl anlamlandırılabileceğini anlatacağım.

⚠️ Not: Bu çalışma tamamen lab ortamında ve eğitim amaçlı gerçekleştirilmiştir.

Bu yazının daha kısa versiyonu Siber Havadis’te de yayımlanmıştır. Kısa halini okumak isterseniz göz atabilirsiniz.

Senaryo: SSH Üzerinden Yetkisiz Erişim Denemeleri

Uzaktan erişim servisleri (SSH, RDP vb.), kurumlar için operasyonel açıdan vazgeçilmez olmakla birlikte, saldırganlar tarafından da sıkça hedef alınmaktadır. Özellikle zayıf parola politikaları veya yetersiz izleme mekanizmaları, bu servisleri hesap ele geçirme saldırılarına açık hale getirebilir.

Bu PoC kapsamında aşağıdaki senaryo kurgulanmıştır:

• Kali Linux sisteminden, Windows 10 istemci makinesine SSH üzerinden erişim denemeleri yapılmıştır.
• Kısa süre içerisinde birden fazla başarısız oturum açma denemesi gerçekleştirilmiştir.
• Denemeler Windows Security Event Log’larına yansımıştır.
• Loglar Splunk SIEM platformuna iletilmiş ve belirlenen eşik değer aşıldığında alarm üretilmiştir.
• Sonrasında, kontrollü ve tek bir başarılı giriş ile senaryo tamamlanmıştır.

Bu davranış, gerçek hayatta sıkça karşılaşılan credential guessing / yetkisiz erişim denemesi paternini temsil etmektedir.

PoC Ortamı

Çalışma aşağıdaki ortamda gerçekleştirilmiştir:

• Saldırgan Sistem: Kali Linux
• Hedef Sistem: Windows 10 (OpenSSH Server aktif)
• SIEM: Splunk Enterprise (Ubuntu üzerinde)
• Log Kaynağı: Windows Security Event Log

Üretilen Loglar

Yetkisiz erişim denemeleri sırasında Windows Security loglarında aşağıdaki olaylar gözlemlenmiştir:

• Event ID: 4625
• Açıklama: An account failed to log on
• Logon Type: 3 (Network logon — SSH)
• Kaynak IP: Kali Linux sistemine ait IP adresi

Bu olaylar, başarısız oturum açma girişimlerinin kanıt niteliğindeki teknik çıktılarıdır.

Kontrollü başarılı giriş sonrasında ise:

• Event ID: 4624
• Logon Type: 3

kaydı oluşmuş ve senaryonun tamamı loglara yansımıştır.

Splunk Üzerinde Tespit (SOC Perspektifi)

Splunk üzerinde, başarısız oturum açma denemelerini tespit etmek amacıyla aşağıdaki sorgu kullanılmıştır:

index=* source="WinEventLog:Security" EventCode=4625
| stats count by "Hesap Adı"
| where count > 3

Bu sorgu sayesinde:

• Aynı kullanıcı hesabı için
• Belirli bir zaman aralığında
• Üçten fazla başarısız giriş denemesi

tespit edildiğinde alarm üretilmesi sağlanmıştır.

SOC perspektifinden bakıldığında bu, oldukça standart bir “failed authentication detection” kuralıdır.

Bilgi Güvenliği (BGYS) Perspektifinden Değerlendirme

Bu noktada asıl önemli soru şudur:

“Bu alarm, bilgi güvenliği açısından neyi kanıtlıyor?”

BGYS bakış açısıyla değerlendirildiğinde bu PoC aşağıdaki unsurları ortaya koymaktadır:

Risk

• SSH üzerinden gerçekleştirilen yetkisiz erişim denemeleri sonucunda kullanıcı hesaplarının ele geçirilmesi

Tehdit

• Kimlik bilgisi tahmini (credential guessing)

Varlık

• Windows 10 istemci sistemi
• Kullanıcı hesapları

Kontrol

• Merkezi loglama
• Yetkisiz erişim denemelerinin SIEM üzerinden izlenmesi
• Belirli eşik değerlerde alarm üretilmesi

Kanıt

• Windows Event ID 4625 ve 4624 logları
• Splunk alarm çıktıları

Bu PoC, ilgili kontrolün yalnızca tanımlı olmadığını; sahada çalıştığını göstermektedir.

ISO/IEC 27001:2022 ile İlişkilendirme

Gerçekleştirilen çalışma, ISO/IEC 27001:2022 standardı kapsamında aşağıdaki kontrollerle ilişkilendirilebilir:

• A.5.15 — Access Control Yetkisiz erişim girişimlerinin tespit edilmesi
• A.8.16 — Monitoring Activities Güvenlik olaylarının izlenmesi ve analiz edilmesi
• A.8.15 — Logging Kimlik doğrulama faaliyetlerinin loglanması ve merkezi olarak toplanması.
• A.5.25 — Information Security Incident Management Yetkisiz erişim girişimlerinin erken aşamada tespit edilerek olay yönetim süreçlerine girdi oluşturması.

Ayrıca çalışma, ISO 27001’in temelini oluşturan PUKÖ (Planla–Uygula–Kontrol Et–Önlem Al) döngüsü ile uyumludur:

• Plan: SSH erişim riskinin tanımlanması
• Uygula: Loglama ve SIEM kuralının yapılandırılması
• Kontrol Et: Başarısız ve başarılı girişlerin analiz edilmesi
• Önlem Al: Alarm, müdahale ve iyileştirme adımlarının planlanması

Neden Bu Yaklaşım Önemlidir?

Bilgi güvenliği sadece teknik araçların kurulmasıyla sağlanamaz. Önemli olan, bu araçların ürettiği çıktıları doğru bağlamda yorumlayarak:

• Riskleri görünür kılmak
• Kontrollerin etkinliğini göstermek
• Denetim süreçlerine somut kanıt sunabilmektir

Bu PoC, SOC çıktılarının BGYS süreçlerine nasıl entegre edilebileceğine dair basit ama etkili bir örnek sunmaktadır.

Sonuç

Bu yazıda, Splunk üzerinde oluşturulan basit bir alarmın, bilgi güvenliği yönetim sistemi kapsamında nasıl kontrol kanıtına dönüştürülebileceğini ele aldım.

Bilgi güvenliği alanında fark yaratan nokta; yalnızca teknik olayları tespit edebilmek değil, bu olayları risk, kontrol ve denetim perspektifiyle değerlendirebilmektir.

Bu çalışmaya ait SIEM PoC dokümantasyonu GitHub reposu üzerinden paylaşılmıştır.

Okuduğunuz için teşekkür ederim.🙏

Bu çalışma tamamen kişisel bir lab ortamında, öğrenme ve kendimi geliştirme amacıyla gerçekleştirilmiştir. Yazı ile ilgili eksik gördüğünüz noktalar, geri bildirimleriniz veya farklı bakış açıları varsa yorumlarda paylaşmanız benim için çok kıymetli olacaktır.

Bilgi güvenliği alanında öğrenmenin ve gelişmenin, paylaşılan deneyimler ve karşılıklı geri bildirimlerle mümkün olduğuna inanıyorum. :))