- Bir kullanıcı hesabıyla gece saatlerinde giriş yapılmış.
- Kısa süre sonra ayrıcalıklı yetki kullanılmış.
- Bir sunucudan diğerine bağlantı kurulmuş.
- Ardından çok sayıda dosya erişilmiş ve dışarıya yüksek miktarda veri aktarılmış.
Sabah olduğunda güvenlik ekibine şu soru soruluyor: “Ne oldu?” İkinci soru daha zor: “Bunu nereden biliyoruz?” Siber olay incelemesinin temel problemlerinden biri tam olarak budur.
Bir saldırı gerçekleştiğinde saldırganın bütün hareketlerini doğrudan görmeyiz. Çoğu zaman elimizde olayın bıraktığı dijital izler bulunur. Bunlar:
- Oturum kayıtları,
- İşletim sistemi olayları,
- Güvenlik duvarı kayıtları,
- VPN kayıtları,
- DNS sorguları,
- Uygulama logları,
- Veri tabanı kayıtları,
- EDR telemetrisi,
- Ağ akış bilgileri,
- Bulut denetim kayıtları
olabilir. Bu kayıtların doğru toplanması ve birlikte değerlendirilmesi halinde birbirinden bağımsız görünen küçük olaylar anlamlı bir saldırı zincirine dönüşebilir.
Fakat önemli bir ayrım vardır: Log, gerçekleşen olayın kendisi değildir. Olay hakkında bir sistem tarafından üretilmiş kayıttır. Dolayısıyla log analizi yalnızca kayıt okumak değil, kayıtların kaynağını, zamanını, bütünlüğünü, bağlamını ve birbirleriyle ilişkisini değerlendirmektir.
1. Log nedir?
Basit ifadeyle log: Bir sistemde meydana gelen olayın kayıt altına alınmış bilgisidir.
Bu kayıt bize belirli bir zamanda belirli bir kullanıcı adına başarılı giriş gerçekleştiğini söyleyebilir. Ancak hemen: “Mehmet Yılmaz sisteme girdi.” sonucuna varamayız. Çünkü log yalnızca: “mehmet.yilmaz hesabıyla giriş yapıldı” bilgisini destekliyor olabilir.
- Parola çalınmış olabilir.
- Oturum token'ı ele geçirilmiş olabilir.
- MFA saldırısı gerçekleşmiş olabilir.
Gözlem: “mehmet.yilmaz hesabıyla 02.14'te başarılı giriş kaydı bulunmaktadır.”
Yorum: “Bu oturum yetkisiz kişi tarafından gerçekleştirilmiş olabilir.”
2. Event, log ve telemetry aynı şey midir?
Bu kavramlar günlük kullanımda birbirinin yerine kullanılabiliyor ancak aralarında yararlı bir ayrım yapılabilir.
- Logları,
- Ağ akışlarını,
- Endpoint davranışlarını,
- İşlem verilerini,
- Performans ölçümlerini,
- Güvenlik sensörü çıktısını
3. Neden merkezi loglama gerekir?
Bir olayın yalnızca tek sistem üzerindeki loglarına bakmak çoğu zaman yeterli değildir. Örneğin saldırgan:
- VPN üzerinden kuruma girmiş, ardından:
- Active Directory üzerinden kimlik doğrulamış, sonra:
- Sunucu A üzerinde oturum açmış, ardından:
- Sunucu B üzerine bağlantı kurmuş ve son olarak:
- Firewall üzerinden dışarı veri aktarmış olabilir.
Bu durumda olayın bütününü tek bir cihaz göremez. Farklı parçalar farklı sistemlerde bulunur. Bu nedenle merkezi log yönetiminin amaçlarından biri: Dağınık olayları ortak bağlam içerisinde birleştirebilmektir.
2024 yılında Avustralya Siber Güvenlik Merkezi ile CISA, NSA, FBI, NCSC ve diğer uluslararası ortakların yayımladığı ortak loglama rehberi dört temel unsuru özellikle öne çıkarmaktadır:
- Kurum tarafından onaylanmış loglama politikası,
- Merkezi log erişimi ve korelasyonu,
- Güvenli saklama ve log bütünlüğü,
- İlgili tehditlere yönelik tespit stratejisi. (cyber.gov.au)
4. SIEM nedir?
SIEM: Security Information and Event Management yani: "Güvenlik Bilgisi ve Olay Yönetimi" yaklaşımıdır. Basitleştirilmiş bir SIEM süreci şöyle düşünülebilir:
Log Kaynakları
↓
Toplama
↓
Normalizasyon
↓
Zenginleştirme
↓
Korelasyon
↓
Analiz
↓
Alarm
↓
Olay İncelemesi
- Örneğin tek başına şu olay normal olabilir: "Bir kullanıcı VPN'e başarıyla giriş yaptı."
- Başka bir olay da tek başına normal olabilir: "Aynı kullanıcı yeni sunucuya erişti."
- Üçüncü olay: "Kullanıcı hesabına ayrıcalık eklendi."
- Dördüncü olay: "Çok büyük miktarda veri dışarı gönderildi."
5. SIEM sihirli bir sistem değildir
SIEM kurulduğunda kurum otomatik olarak saldırıları tespit etmeye başlamaz. Çünkü SIEM'in görebileceği şey, kendisine gönderilen verilerdir.
- Eğer kritik sistem log üretmiyorsa: SIEM göremez.
- Log üretiyor ancak SIEM'e iletmiyorsa: SIEM göremez.
- Yanlış log seviyesi seçilmişse: SIEM gerekli ayrıntıyı göremeyebilir.
- Saatler yanlışsa: SIEM olay sırasını yanlış yorumlayabilir.
- Detection kuralı yoksa: SIEM veriyi saklar fakat alarm üretmeyebilir.
- Analist alarmı incelemiyorsa: tespit operasyonel karşılık bulmaz.
6. Hangi olayları loglamalıyız?
Her şeyi loglamak ilk bakışta en güvenli yaklaşım gibi görünebilir. Fakat gerçek hayatta bu:
- Devasa veri hacmi,
- Yüksek maliyet,
- Analiz güçlüğü,
- Fazla gürültü,
- Başarılı girişler,
- Başarısız girişler,
- MFA olayları,
- Hesap oluşturma,
- Hesap kapatma,
- Parola değişiklikleri.
- Admin yetkisi verilmesi,
- Ayrıcalıklı hesap kullanımı,
- Grup üyeliği değişiklikleri,
- Rol değişiklikleri.
- Servis oluşturulması,
- Güvenlik ayarlarının değiştirilmesi,
- Yeni yazılım kurulması,
- Kritik yapılandırma değişiklikleri.
- Bağlantılar,
- VPN erişimleri,
- Olağan dışı dış trafik,
- DNS sorguları,
- Güvenlik duvarı izin ve engelleme kayıtları.
- Oturum açma,
- Kritik işlem,
- Veri indirme,
- Veri değiştirme,
- Hata ve güvenlik istisnaları.
- Hassas dosya erişimleri,
- Toplu veri sorguları,
- Olağan dışı veri dışa aktarımları.
7. Log kalitesi miktardan daha önemlidir
Şu kayıt çok sınırlı bilgi taşır: Login failed.
İkinci kayıt olay analistine çok daha fazla bağlam sağlar. İyi bir log kaydında olay türüne göre:
- Tarih/saat,
- Kullanıcı/hesap,
- Kaynak,
- Hedef,
- Yapılan işlem,
- İşlem sonucu,
- Oturum veya korelasyon kimliği
8. Zaman neden dijital incelemenin temelidir?
Şimdi çok kritik bir noktaya geliyoruz.
- Bir sistem: 02.15 diyor.
- Diğer sistem: 02.23 diyor.
Gerçekte aynı olaydan söz ediyor olabilirler. Ama sistem saatlerinden biri sekiz dakika gerideyse olay sırasını yanlış kurabiliriz. Örneğin analiz sonucu şöyle görünebilir:
- 02.15 — Admin yetkisi verildi
- 02.18 — VPN girişi gerçekleşti
Böyle bakınca: “Yetki, kullanıcı sisteme girmeden önce verilmiş.” sonucu çıkar. Ancak bir sistemin saati on dakika ileri olabilir. Gerçek sıra:
- 02.08 — VPN girişi
- 02.15 — Admin yetkisi
olabilir. İki yorum tamamen farklıdır. Bu nedenle kurumlarda güvenilir zaman senkronizasyonu kritiktir.
Uluslararası loglama rehberi, sistemler arasında olayları doğru ilişkilendirebilmek için güvenilir ve tutarlı bir zaman kaynağı kullanılmasını; mümkün olduğunda ortak tarih-saat formatı ve yedek zaman kaynaklarının düşünülmesini tavsiye etmektedir. (cyber.gov.au)
9. Olay zaman çizelgesi nasıl oluşturulur?
| Saat | Kaynak | Olay |
|---|---|---|
| 02:13 | VPN | User A başarılı giriş |
| 02:15 | AD | User A yeni gruba eklendi |
| 02:17 | EDR | PowerShell çalıştırıldı |
| 02:19 | Windows | Sunucu B'ye uzak oturum |
| 02:22 | Firewall | Olağan dışı dış bağlantı |
| 02:31 | DLP/Proxy | Büyük veri transferi |
Şimdi olay anlam kazanmaya başlar. Tek tek kayıtlar: normal veya belirsiz görünebilir. Birlikte değerlendirildiğinde: hesap ele geçirilmesi → yetki yükseltme → yatay hareket → veri aktarımı senaryosunu düşündürebilir.
10. Korelasyon nedensellik değildir
Bu ayrım özellikle önemlidir. İki olay art arda gerçekleşti diye birinin diğerine neden olduğu otomatik olarak söylenemez. Örneğin:
- 10:01 — Kullanıcı giriş yaptı
- 10:02 — Sistem çöktü
Buradan: “Kullanıcı sisteme girdiği için sistem çöktü.” sonucu çıkarılamaz. İki olay yalnızca zaman açısından birbirine yakındır. Nedensellik için, ek bilgi gerekir:
- Kullanıcının yaptığı işlem,
- Uygulama logları,
- Sistem hataları,
- Performans verileri,
- Başka kullanıcıların davranışı,
- Ağ kayıtları.
Bir log bulunduğu için otomatik olarak doğru ve güvenilir kabul edilmemelidir. Şu sorular sorulmalıdır:
- Logu hangi sistem üretti?
- Sistem saati doğru muydu?
- Loglama aktif miydi?
- Log sonradan değiştirilebilir miydi?
- Saldırganın log silme yetkisi var mıydı?
- Kayıt merkezi sisteme aktarılmış mıydı?
- Eksik zaman aralıkları var mı?
- Log kaynağının bütünlüğü korunuyor muydu?
Örneğin saldırgan Domain Administrator yetkisine sahipse: yerel Windows loglarını silebilir. Ancak loglar olaydan önce merkezi ve farklı güven alanındaki sisteme aktarılmışsa saldırganın izleri tamamen yok etmesi daha zor olabilir.
12. Log bütünlüğü neden önemlidir?
Bir kayıt teknik incelemede kullanılacaksa şu soru kaçınılmazdır: “Bu kayıt olaydan sonra değiştirilmiş olabilir mi?” Bu nedenle kurumlar logları:
- Erişim kontrolü,
- Merkezi saklama,
- Değiştirmeye karşı koruma,
- Uygun yetkilendirme,
- Bütünlük doğrulaması
gibi mekanizmalarla korumalıdır. Bazı senaryolarda hash veya dijital imza gibi kriptografik mekanizmalar da bütünlük doğrulamasında kullanılabilir.
13. Log silme de bir olaydır
Saldırganların olay kayıtlarını silmeye çalışması şaşırtıcı değildir. Çünkü loglar saldırganın hareketlerini ortaya çıkarabilir. Bu nedenle: Logların silinmesi veya loglama sisteminin kapatılması da, loglanması gereken bir güvenlik olayıdır. Örneğin:
- Windows Event Log temizlendi,
- EDR servisi durduruldu,
- Audit policy değiştirildi,
- Log forwarder kapatıldı
14. Log saklama süresi ne kadar olmalıdır?
Bu sorunun tek bir evrensel cevabı yoktur. Saklama süresi:
- Hukuki yükümlülükler,
- Sektörel düzenlemeler,
- Kurum politikası,
- Tehdit modeli,
- Depolama kapasitesi,
- Olay araştırma ihtiyacı
dikkate alınarak belirlenmelidir. Çok kısa süre saklanan loglar büyük problem yaratabilir.
Örneğin saldırgan üç ay boyunca sistemde fark edilmeden kalmış olsun. Kurum yalnızca son 30 günlük logu saklıyorsa, ilk erişimi analiz etmek mümkün olmayabilir. Buna karşılık bütün logların süresiz saklanması da:
- Maliyet,
- Mahremiyet,
- Veri yönetimi
15. Her şeyi SIEM'e göndermek doğru mudur?
Analistin önünde günde yüz bin alarm varsa kritik alarm gözden kaçabilir. Bu nedenle iyi log yönetiminin amaçlarından biri: yüksek kaliteli güvenlik sinyali üretmektir.
2024 tarihli ortak rehber de loglamanın ağ savunucularının olayları doğru tanımlayabilmesini sağlayacak yüksek kaliteli güvenlik olaylarına odaklanmasını tavsiye etmektedir. (cyber.gov.au)
16. Detection Rule nedir?
SIEM'in değerli hale geldiği noktalardan biri: Detection Rules - Tespit Kuralları dır.
- Bir kullanıcı hesabında 10 dakika içinde 20 başarısız giriş ve ardından başarılı giriş varsa alarm üret.
- Başka bir örnek: Normal kullanıcı hesabı Domain Admin grubuna eklenirse kritik alarm üret.
- Veya: Sunucuda PowerShell üzerinden, şüpheli encoded command çalıştırılırsa alarm üret.
- False Positive Alarm saldırı değildir. Normal işlem yanlışlıkla şüpheli olarak işaretlenmiştir.
- False Negative Gerçek saldırı gerçekleşmiş ancak kural bunu tespit edememiştir.
17. SIEM ile SOC aynı şey değildir
Bu ayrım da önemlidir. SIEM bir teknoloji/platform sınıfıdır. SOC ise, insan + süreç + teknoloji yapısıdır.
SOC içerisinde:
- SIEM,
- EDR,
- SOAR,
- Tehdit istihbaratı,
- Olay yönetimi araçları
kullanılabilir. Ama bunları kullanan:
- Analistler,
- Olay müdahale ekipleri,
- Detection mühendisleri
18. Log, dijital delil midir?
Bu soruya verilecek en doğru cevap: Log, bir incelemede dijital kanıt niteliği taşıyabilecek veri kaynaklarından biridir; ancak tek başına her iddiayı kesin olarak kanıtlamaz.
NIST SP 800-86; dosyalar, işletim sistemleri, ağ trafiği ve uygulamalar dahil farklı veri kaynaklarının adli inceleme ve olay müdahalesinde kullanılabileceğini belirtmektedir. Rehber dört temel aşama tarif eder:
Collection
↓
Examination
↓
Analysis
↓
Reporting (nist.gov)
19. Chain of Custody neden önemlidir?
- Veriyi kim aldı?
- Ne zaman aldı?
- Nereden aldı?
- Hangi yöntemle aldı?
- Nerede saklandı?
- Kim erişti?
- Herhangi bir değişiklik yapıldı mı?
Özellikle bilirkişilik açısından: “Bu dosyayı bana verdiler.” tek başına güçlü yöntem değildir. Dosyanın:
- kaynağı,
- edinme yöntemi,
- bütünlük kontrolü,
- saklama süreci
20. Tek bir log kaynağına güvenmek neden tehlikelidir?
VPN
↓
Active Directory
↓
Endpoint
↓
Firewall
↓
Uygulama
↓
Bulut
Aynı olay, farklı kaynaklarda benzer iz bırakıyorsa analiz güçlenir.
Örneğin:
- VPN: userA login
- AD: userA authentication
- EDR: aynı cihazda userA session
- Firewall: aynı IP'den trafik
21. Örnek olay: Loglardan saldırı zinciri çıkarma
Hayali Kurum X üzerinde bir olay düşünelim.
- 01:42 — VPN
- userA - Successful Login
- Source: Foreign IP
- 01:44 — Active Directory
- userA authentication successful
- 01:49 — EDR
- powershell.exe executed
- encoded command detected
- 01:53 — Windows
- Remote service created on SERVER02
- 01:57 — Active Directory
- userA added to privileged group
- 02:05 — Database
- Large query executed
- 4.2 million records accessed
- 02:11 — Firewall
- SERVER02 → External IP
- 8.4 GB outbound traffic
Bu kayıtlar ilk bakışta bize şu hipotezi düşündürebilir:
Hesap ele geçirilmesi
↓
İlk erişim
↓
Komut çalıştırma
↓
Lateral movement
↓
Yetki yükseltme
↓
Toplu veri erişimi
↓
Muhtemel veri aktarımı
Ancak profesyonel raporda: “8,4 GB veri kesin olarak çalınmıştır.” demek için yalnızca Outbound trafik kaydı yeterli olmayabilir. Çünkü:
- Verinin içeriğini,
- Şifreli olup olmadığını,
- Hangi uygulamanın gönderdiğini,
- Gerçekten veri tabanı çıktısı olup olmadığını
doğrulamamız gerekebilir. Daha dikkatli ifade: “SERVER02 sisteminden olayla ilişkili zaman aralığında dış IP adresine, 8,4 GB veri aktarımı kaydedilmiştir. Veri tabanında kısa süre önce gerçekleşen, yüksek hacimli sorgu ile zaman ilişkisi bulunmakla birlikte, aktarılan içeriğin söz konusu veri tabanı kayıtları olduğunun ayrıca doğrulanması gerekmektedir.”
22. Analistin kullanması gereken üç seviye
Bir siber olay raporunda bilgileri şu şekilde ayırmak oldukça yararlıdır:
23. Log Yönetim ve Dijital İnceleme Zinciri
Bu çalışmanın temel modelini şöyle oluşturabiliriz:
Hangi güvenlik olaylarını görmemiz gerekiyor?
↓
2 — Üret
Sistemler yeterli kalitede log üretiyor mu?
↓
3 — Zamanı eşitle
Farklı sistemlerin saatleri güvenilir mi?
↓
4 — Topla
Loglar merkezi şekilde alınabiliyor mu?
↓
5 — Koru
Kayıtlar değişiklik ve silmeye karşı korunuyor mu?
↓
6 — Normalleştir
Farklı kaynaklar birlikte analiz edilebilir mi?
↓
7 — Korele et
Birbiriyle ilişkili olaylar birleştiriliyor mu?
↓
8 — Tespit et
Şüpheli davranış için alarm üretiliyor mu?
↓
9 — Doğrula
Alarm diğer veri kaynaklarıyla destekleniyor mu?
↓
10 — Zaman çizelgesi oluştur
Olayın sırası belirlenebiliyor mu?
↓
11 — Analiz et
Ne olmuş olabilir?
↓
12 — Sınırları belirt
Neyi bilmiyoruz?
↓
13 — Raporla
Gözlem, analiz ve kanaat birbirinden ayrılıyor mu?
24. Sık yapılan loglama ve SIEM hataları
Sonuç: Log toplamak değil, güvenilir hikâye oluşturmak
Bir siber olay sonrasında cevaplamamız gereken temel sorular vardır:
- Ne oldu?
- Ne zaman başladı?
- Hangi hesap kullanıldı?
- Hangi sistemler etkilendi?
- Saldırgan nereden nereye geçti?
- Hangi veri erişildi?
- Veri dışarı çıktı mı?
- Saldırgan hâlâ sistemde mi?
- Ne kadar güvenilir kanıtımız var?
Bu soruların cevapları çoğu zaman tek bir log dosyasında bulunmaz. Farklı kaynaklardan gelen küçük parçalar: zaman + kimlik + sistem + ağ + uygulama + davranış bağlamında bir araya getirilir.
SIEM'in gerçek değeri de burada ortaya çıkar. SIEM yalnızca log deposu değildir. Doğru tasarlandığında: Dağınık güvenlik telemetrisini anlamlı olaylara dönüştüren karar destek mekanizmasıdır.
Ancak bundan da önemli bir ilke vardır: Log ne söylüyorsa onu söylemek; logun söylemediğini ona söyletmemek. Bir log:
- Bir hesabın kullanıldığını gösterebilir.
- Ama hesabı kimin kullandığını tek başına kanıtlamayabilir.
- Bir dış trafik kaydı veri aktarımını gösterebilir.
- Ama aktarılan verinin ne olduğunu tek başına kanıtlamayabilir.
- İki olay art arda gerçekleşebilir.
- Ama biri diğerine neden olmuş olmayabilir.
Bu nedenle güçlü siber olay analizi: çok log okumak değil, kanıtın sınırını bilerek farklı kaynaklardan güvenilir bir olay hikâyesi oluşturabilmektir.
Bu beceri:
- SOC analistliği,
- olay müdahalesi,
- tehdit avcılığı,
- dijital adli inceleme
- ve ileride bilirkişilik