Kapsamı ve Log Kaynaklarını Belirleme

Kimlik doğrulama logları, hesapların normal kullanımından sapmaları erken fark etmek için güçlü bir başlangıç noktasıdır. İncelemeleri yalnızca yetkili olduğunuz sistemlerde, kurum politikalarına ve yürürlükteki mevzuata uygun biçimde yürütün. Logları tek başına kesin ihlal kanıtı olarak değil, diğer güvenlik sinyalleriyle birlikte değerlendirin.

Öncelikle aşağıdaki kaynakları envantere ekleyin:

• VPN, uzaktan erişim ağ geçidi ve güvenlik duvarı kayıtları
• Linux SSH ve kimlik doğrulama günlükleri; Windows oturum açma ve hesap yönetimi olayları
• Bulut kimlik sağlayıcısı, çok faktörlü doğrulama ve tek oturum açma kayıtları
• Yönetici işlemleri, parola değişiklikleri, yeni hesap ve yetki atama olayları
• Uç nokta, uygulama ve ayrıcalık yönetimi kayıtları

Her kaynağın saat dilimini, zaman senkronizasyonunu, saklama süresini ve merkezi log sistemine aktarım durumunu doğrulayın. Saat farkları, olayların sırasını yanlış yorumlamaya neden olabilir. Kritik sistemlerde zaman senkronizasyonunu ve log bütünlüğünü düzenli olarak kontrol edin.

Normal Davranış İçin Karşılaştırma Tabanı

Bir uyarının anlamlı olabilmesi için kullanıcı, cihaz, ağ ve zaman bağlamı birlikte incelenmelidir. Tek başına başarısız oturum açma sayısı yeterli kanıt değildir; bakım çalışmaları, yanlış yapılandırılmış uygulamalar veya seyahat eden kullanıcılar benzer izler oluşturabilir.

Başlangıçta şu bilgileri düzenli olarak çıkarın:

• Kullanıcının olağan çalışma saatleri ve kullandığı cihazlar
• Kurumsal ağlar, VPN çıkışları ve beklenen coğrafi bölgeler
• Yönetici hesaplarının görev, ekip ve onay ilişkileri
• Servis hesaplarının beklenen kaynakları, uygulamaları ve işlem türleri

Bu taban sabit bir kural değil, düzenli olarak gözden geçirilen bir referanstır. Yeni ofis, vardiya düzeni veya uygulama devreye alındığında istisnaları gerekçesi, sahibi ve sona erme tarihiyle belgeleyin.

Savunma Odaklı Tespit Senaryoları

Aşağıdaki örüntüler mevcut kayıtlar üzerinden risk işareti üretmek için kullanılabilir:

• Kısa zaman aralığında aynı hesap için farklı kaynaklardan başarısız denemeler ve hemen ardından başarılı giriş
• Bir hesabın daha önce görülmeyen cihaz, ağ veya zaman diliminden kullanılması
• Çok faktörlü doğrulama reddetmelerinin artması ya da beklenmedik bir onayla sonuçlanması
• Devre dışı bırakılmış, süresi dolmuş veya servis niteliğindeki hesaplarla etkileşim
• Başarılı yönetici oturumundan hemen sonra olağandışı yetki, politika veya hesap değişikliği

Her uyarıda kullanıcı adı, hesap rolü, kaynak sistem, zaman, cihaz bilgisi, sonuç, ilgili olay kimliği ve güvenilir bağlamı birlikte gösterin. Hassas verileri gereksiz yere kopyalamayın; erişimi rol tabanlı olarak sınırlandırın.

Örnek Analist Notu


Triage, Doğrulama ve Yanlış Pozitif Yönetimi

Bir uyarı geldiğinde önce kaydın bütünlüğünü, zamanını ve kaynak sistemini doğrulayın. Ardından kullanıcıdan veya sorumlu ekipten işlemin beklenen bir faaliyet olup olmadığını, ilgili değişiklik talebi ya da bakım kaydı bulunup bulunmadığını teyit edin. Kimlik doğrulama olayını uç nokta, VPN, uygulama ve yetki değişikliği kayıtlarıyla ilişkilendirin.

Risk değerlendirmesinde şu soruları kullanın:

• Hesap ayrıcalıklı mı veya hassas verilere erişebiliyor mu?
• Başarılı giriş sonrasında yetki, parola, MFA veya güvenlik ayarı değişmiş mi?
• Aynı kaynak başka hesapları da hedefleyen olağandışı bir örüntü gösteriyor mu?
• Kayıtlar eksik, değiştirilmiş veya merkezi sisteme gecikmeli mi ulaşmış?
• Olay, bilinen bir bakım, seyahat veya otomasyon faaliyetiyle açıklanabiliyor mu?

Yanlış pozitifleri azaltmak için kuralları sessizce gevşetmek yerine açıklanmış istisnalar, süreli izinler ve değişiklik kayıtları kullanın. İstisnaların sahibi, gerekçesi, kapsamı ve sona erme tarihi belirli olmalıdır.

Olay Sonrası Müdahale ve Sertleştirme

Yetkisiz kullanım şüphesi doğrulanırsa kurumun olay müdahale planına ve gerekli onaylara göre ilerleyin. Duruma bağlı olarak oturumları sonlandırmayı, parolayı yenilemeyi, MFA kaydını yeniden doğrulamayı, tokenları iptal etmeyi ve etkilenen cihazı izole etmeyi değerlendirin. Kanıtları korumadan logları silmeyin veya sistem üzerinde kontrolsüz değişiklik yapmayın.

Kalıcı iyileştirmeler için:

• Yönetici hesaplarında güçlü MFA ve ayrı yönetim hesapları kullanın.
• Kullanılmayan hesapları, eski erişim anahtarlarını ve kalıcı ayrıcalıkları düzenli olarak gözden geçirin.
• Logları merkezi, erişim kontrollü ve bütünlük kontrolleri bulunan bir ortamda toplayın.
• Uyarıların doğrulanma süresini, yanlış pozitif oranını ve kritik sistem kapsamasını ölçün.
• Olay sonrasında eksik sinyalleri, iyileştirilmesi gereken kontrolleri ve sorumluları kayıt altına alın.

İyi bir triage süreci yalnızca alarm üretmez; erişim yönetimi, log kalitesi ve sistem sertleştirmesini ölçülebilir biçimde geliştirir.