Bir olayı incelemek için SIEM'e ihtiyacınız yok. Doğru logların açık olması, en az altı ay saklanması, kurcalanmaya karşı korunması ve her makineye tek tek giriş yapmadan aranabilmesi yeterli.
Aşağıdaki altı kategori bizim kendi gruplamamızdır, bir standart değildir. NCSC'nin güvenlik amaçlı loglamaya giriş rehberindeki üç tabloyu yeniden düzenliyor, OWASP rehberinden uygulama loglamasını ve Microsoft'un dokümantasyonundan Microsoft 365 ayrıntılarını ekliyoruz.
Sorulardan yola çıkın
Log kaynaklarını, bir olayın ilk saatlerinde size sorulacak sorulara göre seçin. NCSC bu soruları genel hatlarıyla şöyle çerçeveliyor: Ne oldu, etkisi nedir, bundan sonra ne yapmalıyız, iyileştirme işe yaradı mı ve güvenlik kontrollerimiz çalışıyor mu? NCSC'nin tabloları bunları, mesai dışında kimin uzaktan giriş yaptığı veya belirli bir bağlantıya kimin tıkladığı gibi somut sorulara ayırıyor. Bir logun hangi soruya hizmet ettiğini söyleyemiyorsanız, sırası daha sonra gelir.
Asgari set
| Kaynak | Yanıtladığı soru | Nereden gelir |
|---|---|---|
| Kimlik ve uzaktan erişim | Kim, nereden, ne zaman giriş yaptı? İnternete açık servislerde başarısız denemeler oldu mu? | Active Directory, LDAP, ADFS, VPN, uzak masaüstü ve VDI logları |
| E-posta | Buna benzer bir mesajı kimler aldı ve bağlantıya kim tıkladı? | SMTP sunucuları, MS Exchange, e-posta tarama cihazları, bulut sağlayıcı API'leri |
| Uç noktalar ve sunucular | Bu çalıştırılabilir dosya çalıştı mı, bu dosya mevcut mu, bir ana makinede olağandışı bir şey oldu mu? | Windows EVTX, Syslog, Microsoft Sysmon, host agent'ları |
| Güvenlik duvarı, DNS ve proxy | Herhangi bir sistem şüpheli bir IP ya da alan adıyla konuşuyor mu? | Güvenlik duvarı veya netflow logları, DNS logları, web proxy logları |
| Web sunucusu ve uygulama | Kullanıcı ne yaptı ve sonuç ne oldu? | Uygulama kodu, web sunucusu |
| Varlıklar ve değişiklikler | Bu IP hangi cihazdaydı, ne değişti, bu sunucunun sahibi kim? | DHCP, router, güvenlik duvarı ve switch logları, bir CMDB |
Bazı ayrıntılar neyi topladığınızı değiştirir. Güvenlik duvarında NCSC, toplanan logların Network Address Translation'ı hesaba katması gerektiğini söylüyor; böylece hem iç hem de dış IP kaydedilir. DNS logları kullanıcının tıkladığı alan adını gösterir ama tam URL'yi göstermez. Bu nedenle web proxy'niz yoksa onları daha zayıf bir alternatif olarak değerlendirin.
Ücretsiz Microsoft Sysmon dahil host agent'ları süreç bilgisi, DNS sorgu olayları, dosya sistemi değişiklikleri ve dosya hash'leri üretebilir. Ancak yalnızca kurulup yapılandırıldıkları yerleri kapsarlar. Bu yüzden gölge BT, ağ cihazları, desteklenmeyen işletim sistemleri ve zararlı yazılımın agent'ı devre dışı bıraktığı makineler karanlıkta kalır.
Web sunucusu logları, uygulama loglaması değildir. Kullanıcının kimliğini, rollerini ve bir eylemin sonucunu uygulama bilir; altyapı cihazları çoğu zaman bilmez.
Microsoft 365
Microsoft 365 kullanıyorsanız, herhangi bir şey satın almadan önce Microsoft Purview'a bakın. Audit (Standard), uygun aboneliğe sahip kuruluşlarda varsayılan olarak etkindir. Yine de arama yetkilerini Purview portalında veya Exchange Online PowerShell'deki Search-UnifiedAuditLog cmdlet'i ile atamanız gerekir.
Standard sürüm kayıtları 180 gün tutar. 17 Ekim 2023'ten önce oluşturulan kayıtlar yalnızca 90 gün tutulmuştu. Audit (Premium) ise Microsoft Entra ID, Exchange, OneDrive ve SharePoint kayıtlarını varsayılan olarak bir yıl saklar.
Premium ayrıca Exchange Online'daki MailItemsAccessed etkinliğinde SensitivityLabel özelliğini sağlar. Sistemin bu olayları üretmesi için kullanıcıların Premium lisansa ihtiyacı vardır; bu yüzden lisans konusunu bir olay yaşanmadan önce netleştirin.
Saklama ve koruma
NCSC, olay sorularınızı yanıtlayan loglar için en az 6 ay saklamayı öneriyor. Ayrıca M-Trends 2018'in ortalama tespit süresini 101 gün olarak bulduğunu belirtiyor ve bütçeniz elveriyorsa daha uzun saklamanızı söylüyor.
Yerel loglar bu süreye kimse fark etmeden yetişmeyebilir. Her birini açıp en eski kaydın tarihine bakın. Altı aydan yeniyse log, hedefinizi karşılamak için fazla küçük ya da fazla yoğun olabilir; bu yüzden yapılandırılmış boyut veya saklama ayarını da kontrol edin.
Sisteme sızan herkesin logları değiştirmek için bir nedeni vardır. Bu yüzden loglama servisine herhangi bir yönetici arayüzüne gösterdiğiniz özeni gösterin. Logları kimin okuyabildiğini, kimin yazabildiğini ve bir değişikliği fark edip etmeyeceğinizi sorun. OWASP, uygulama logları için somut önlemler sunuyor:
- Dosya tabanlı logları, işletim sisteminden ve kullanıcı tarafından üretilen içerikten ayrı bir bölüme koyun; dizinler ve dosyalar üzerinde sıkı izinler uygulayın.
- Logları web üzerinden erişilebilen konumların dışında tutun. Bu kaçınılmazsa erişimi kısıtlayın ve logları HTML yerine düz metin olarak sunun.
- Bir veritabanına loglama yaparken yalnızca log verisi yazmak için kullanılan, çok kısıtlı izinlere sahip bir hesap kullanın.
- Güvenli bir aktarım üzerinden standart bir olay formatı kullanın; örneğin TLS üzerinden syslog mesaj formatı.
Yalnızca fayda sağladığı yerde merkezileştirin
NCSC, merkezi ve merkezi olmayan loglamayı gerçek bir tercih olarak ele alıyor. Merkezi bir depo, inceleme sırasında her makineyi tek tek ziyaret etmenizi önler ve eklenen her kaynakla daha da yararlı hale gelir. Logları yerinde bırakmak ise zaten aranabilir olduklarında ve yeterince uzun süre tutulduklarında işe yarar. NCSC'nin örneği bulut e-posta servisleridir; orada logları dışarı çekmek nadiren maliyetini karşılar.
Küçük bir ekip için makul bir ayrım şudur: uç nokta, sunucu, güvenlik duvarı ve VPN loglarını merkezileştirin, iyi hizmet veren bulut servislerini olduğu yerde bırakın. Windows'ta Windows Event Forwarding, istemcilerden merkezi bir depoya logları güvenli biçimde gönderir.
NCSC ayrıca merkezi olmayan bir modelin zamanla yavaş yavaş bozulabileceği konusunda uyarıyor. Her kaynağın hâlâ log üretip üretmediğini doğrulamayı birine düzenli bir görev olarak verin ve bunun kim olduğunu yazılı hale getirin.
Nereden başlamalı
- NCSC tablolarındaki somut soruları alın; örneğin mesai dışında kimin uzaktan giriş yaptığı ya da bu bağlantıya kimin tıkladığı. Her biri için yanıtı verecek sistemi belirleyin.
- Her kaynak için nerede saklandığını, ne kadar süre tutulduğunu ve kimin okuyup değiştirebildiğini kaydedin. Altı aydan kısa olan her şeyi gündeme getirin.
- Varsayılan ayarları kontrol edin. Bir kaynak asgari ayrıntıda log tutuyorsa, daha fazlasını yakalamak için yapılandırmayı değiştirin. Microsoft 365'te Audit'in açık olduğunu doğrulayın ve arama yetkilerini atayın.
- Uç nokta, sunucu, güvenlik duvarı ve VPN loglarını, yazma erişimi kısıtlanmış tek bir depoya iletin; bunun için Windows Event Forwarding veya TLS üzerinden syslog kullanın.
- Bir tatbikat yapın: şüpheli bir IP adresi ve bir phishing e-postası konu satırı seçin, soruları yalnızca loglardan yanıtlamayı deneyin. Önce takıldığınız kaynağı düzeltin.
- Tatbikatı kendi bünyenizde yapamıyorsanız, yardım için bir olay müdahale ekibine veya yönetilen bir güvenlik hizmeti sağlayıcısına başvurun.
