Merhaba

Seri: SOC Analistleri İçin Log İzleme Rehberi (Ödeme Kuruluşları)

1. Log İzleme Temelleri (Bu Yazı)
2. Mevzuat, Retention ve Silme Yasağı
3. Windows/AD ve Linux Hardening
4. Uygulama ve Veritabanı Katmanı
5. Ağ Katmanı (Firewall/IDS-IPS/WAF/DDoS)
6. Container ve Kubernetes
7. Bulut (AWS/Azure/GCP)
8. XDR/EDR ve Bütünsel Korelasyon

Ön Not – Kapsam ve Amaç

Bu seri, kritik logları izlemeyi ve anlamayı öğretmek amacıyla yazılmıştır. Odak noktası tek tek ürünler değil, sürecin kendisidir: hangi olayın neden önemli olduğu, nasıl toplandığı, korele edildiği ve korunduğu.

Metindeki donanım, yazılım ve uygulama örnekleri (ürün adları, Event ID’ler, konfigürasyon parametreleri, komutlar) versiyona, sürüme ve yıllara göre değişiklik gösterebilir. Bir ayarın adı değişebilir, bir ürün yaşam döngüsünü tamamlayabilir, yeni bir alternatif ortaya çıkabilir. Bu nedenle örnekleri birebir kopyalanacak reçeteler olarak değil, mantığı kavramak için birer illüstrasyon olarak okuyun; kendi ortamınıza uygularken ilgili üreticinin güncel dokümantasyonunu esas alın.

Aynı şekilde, “Ödeme Kuruluşları İçin PCI DSS, HIPAA ve Türkiye Mevzuatı Bağlamında” hazırlanan bölümler de yürürlükteki düzenlemelere dayanır ve mevzuat değiştikçe güncellenmesi gerekir. PCI DSS sürümleri, TCMB tebliğleri, KVKK/MASAK düzenlemeleri ve retention süreleri zaman içinde değişebilir. Bu rehber hukuki veya denetim danışmanlığı yerine geçmez; nihai uygulama için kurumunuzun uyumluluk ekibine, QSA’sına ve güncel resmi mevzuata başvurun.

Kısacası: amaç, süreci ve mantığı anlamaktır. Örnekler bugünün fotoğrafıdır; ilke ise kalıcıdır.

Loglar, her dijital aktivitenin bıraktığı ayak izleridir. Sistemler, ağlar ve uygulamalar içindeki olayların kronolojik kaydını tutarlar. Modern bir Security Operations Center (SOC) ortamında analistler; tehditleri tespit etmek, güvenlik olaylarını incelemek ve kurumun genel güvenlik duruşunu (security posture) korumak için bu loglara dayanır.

Yapılandırılmamış ve düzgün izlenmeyen loglar söz konusu olduğunda, en gelişmiş güvenlik çözümleri bile kritik Indicator of Compromise (IoC) verilerini kaçırabilir ya da farklı sistemler arasındaki şüpheli davranışları birbiriyle ilişkilendiremez (correlate edemez).

Bu yazıda hangi logların gerçekten önemli olduğunu, neden kritik olduklarını ve bunları nasıl izlemek gerektiğini junior ve mid-level SOC analistlerinin işine yarayacak bir derinlikte ele alıyorum.

Yazının son bölümünü ise Türkiye’de faaliyet gösteren ödeme kuruluşlarına ayırdım: 6493, TCMB Bilgi Sistemleri Tebliği, 5651, MASAK ve KVKK’nın log yönetimi üzerindeki birleşik etkisi, tiered retention mimarisi, Windows/AD, Linux, uygulama, veritabanı, ağ (firewall/IDS-IPS/WAF/DDoS), konteyner/Kubernetes, bulut (AWS/Azure/GCP) ve XDR/EDR katmanlarında somut hardening ve korelasyon konfigürasyonları (auditd, journald sealing, pgaudit, SQL Server Audit/Ledger, RKE2 audit + Kyverno, FortiGate/Suricata/ModSecurity, CloudTrail/Activity Log immutable arşiv, MITRE ATT&CK eşlemeli XDR kuralları), PCI DSS maskeleme kuralları ve denetimde en sık karşılaşılan bulgular. Bu kısım, regüle bir fintech ortamında yıllarca sistem ve ağ yönetimi yapmış biri olarak sahadan öğrendiklerimin bir özeti.

1. SOC’ta Log İzlemenin Önemi

Orta ve büyük ölçekli her IT altyapısında ham veri hacmi devasadır. Tek başına bir firewall saniyede binlerce log kaydı üretebilir. Bu satırlar ilk bakışta sıradan metinler gibi görünse de, güvenlik tehditlerini tespit etmek ve engellemek için son derece değerli içgörüler barındırır.

Log İzlemenin Kritik Olmasının Başlıca Nedenleri:

Görünürlük ve Bağlam (Visibility & Context)
Loglar; ne oldu, ne zaman oldu ve nasıl gerçekleşti sorularının yanıtını vererek bağlam sağlar. Bu görünürlük, normal davranışları anomalilerden ayırmanın temelidir.
Örneğin Windows sistem loglarında beklenmedik bir privilege escalation kaydı, saldırganın lateral movement yaptığına işaret edebilir. Aynı şekilde Linux ortamında tekrarlayan authentication failure kayıtları bir brute-force girişiminin habercisi olabilir.

Olay Tespiti ve Müdahale (Incident Detection & Response)
SIEM (Security Information and Event Management) platformlarından gelen otomatik uyarılar, çoğunlukla loglardaki şüpheli desenlerden doğar. Bu alert’ler SOC analistlerinin potansiyel olayları hızla tespit edip müdahale etmesini sağlar.
Tipik bir örnek: correlation rule’ların, aynı kullanıcının kısa bir zaman aralığında coğrafi olarak çok uzak iki noktadan login olduğunu yakalaması klasik bir impossible travel senaryosu, yani çalınmış kimlik bilgisi şüphesi.

Denetim ve Uyumluluk (Audit & Compliance)
PCI DSS, HIPAA, ISO 27001 gibi pek çok düzenleyici çerçeve, log retention ve düzenli log incelemesini zorunlu kılar. Log izleyen kurumlar hem uyumluluk gerekliliklerini karşılar hem de denetim ya da inceleme sürecinde net bir audit trail sunabilir.<

Denetçilerin güvenlik kontrollerinin gerçekten çalıştığını doğrulamak için baktığı ilk yer genellikle loglardır.

Threat Hunting
Loglar yalnızca tespit için değil, proaktif threat hunting için de temel oluşturur. Analistler alışılmadık desenleri arar. Örneğin PowerShell kullanımının nadir olduğu bir ortamda çalıştırılan bir PowerShell script’i.

Logları zaman içinde analiz eden threat hunter’lar, otomatik sistemlerin gözünden kaçabilecek trendleri ve adversary tactic’lerini ortaya çıkarabilir.

Adli İnceleme (Forensic Investigations)
Bir olay gerçekleştiğinde, iyi yapılandırılmış loglar adli incelemenin anahtarıdır. Saldırının zaman çizelgesini yeniden kurmayı, hangi sistemlere erişildiğini görmeyi ve hangi verilerin dışarı sızdırıldığını (exfiltration) belirlemeyi sağlarlar.

Kullanıcı aksiyonları, ağ bağlantıları ve system call’lara ait detaylı loglar; olayı doğru şekilde attribute etmekle saldırganların tespit edilmeden kalması arasındaki farkı yaratır.

Gerçek Hayattan Bir Senaryo
Bir SOC analisti, kritik bir sunucudan olağandışı outbound trafik fark eder. Firewall loglarını Windows Event Log kayıtlarıyla korele ettiğinde, harici bir IP adresiyle haberleşen zararlı bir process ortaya çıkar. Hızlı analiz, bu haberleşmenin şüpheli bir privilege escalation olayının hemen ardından başladığını gösterir.

Bu korelasyon, incident response ekibini sunucuyu izole etmeye, tehdidi kontrol altına almaya (containment) ve veri sızmadan önce zafiyeti kapatmaya yönlendirir.

Pratik İpucu
Linux tarafında yüksek öncelikli olayları ters kronolojik sırayla hızlıca bulmak için:

journalctl -p warning -r

Windows tarafında logon’la ilgili belirli Event ID’leri Security log içinde filtrelemek için:

wevtutil qe Security /rd:true /f:text /q:"*" | findstr /i "4624 4625 4634 4672"

2. Kritik Log Tipleri

2.1. Sistem Logları (Windows, Linux, macOS)

Sistem logları, incident detection ve response çalışmalarının omurgasını oluşturur. Analistlere anormal olayları incelemek, kullanıcı aktivitelerini takip etmek ve güvenlik tehditlerini teşhis etmek için gereken temel baseline veriyi sağlar.
Windows, Linux ve macOS’ta bu loglar ortak bir amaca hizmet eder. Kritik OS olaylarını kaydetmek ancak her platform logları kendi yöntemiyle organize eder.

Windows Logları
Temel Log Kaynakları

İzlenmesi Gereken Kritik Event ID’ler
Aşağıdaki tablolar, bir SOC’un Windows/Active Directory tarafında izlemesi gereken Event ID’leri kategorilere ayırıyor. Bu, orijinal rehberdeki listeden çok daha kapsamlı çünkü pratikte saldırının izi logon olaylarında değil, hesap ve grup yönetimi olaylarında görünür.
Logon ve Process

Kullanıcı Hesabı Yönetimi (User Account Management)

Global Grup Yönetimi (Security-Enabled Global Group) – Domain Admins burada

4728, “birini Domain Admin yapma” olayının ana Event ID’sidir. SIEM’inizdeki en yüksek öncelikli kural bu olmalıdır.

Local (Domain Local) Grup Yönetimi

Universal Grup Yönetimi

Distribution Group (Güvenlik Dışı – Düşük Öncelik)

Computer Account Yönetimi

Yetki ve Politika Değişiklikleri

Kerberos ve Kimlik Doğrulama

Gerekli Advanced Audit Policy Ayarları
Yukarıdaki Event ID’lerin üretilebilmesi için Domain Controller’larda GPO üzerinden (Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration) şu alt kategoriler açılmalıdır:

Ek Olarak:

• Include command line in process creation events → Enabled. Bu ayar olmadan Event ID 4688 yalnızca process adını verir; komut satırı argümanlarını göremezsiniz. Living-off-the-land tespitinde en değerli tek ayardır.
• Security log boyutu: minimum 1 GB, “Overwrite events as needed” ancak forwarding (WEF veya agent → SIEM) mutlaka aktif olmalı.
• SYSVOL/GPO klasörlerine SACL ekleyin (5145/4663 olayları için).

PowerShell Logging
Module Logging ve Script Block Logging özelliklerini etkinleştirerek şüpheli veya obfuscate edilmiş komutları takip edebilirsiniz. Bu, fileless attack ve living-off-the-land tekniklerine karşı en etkili görünürlük katmanlarından biridir.

Örnek: PowerShell ile Security Event Filtreleme:

Get-WinEvent -LogName Security | Where-Object { $_.Id -in 4624, 4625 }

Bu komut, Security Log içindeki başarılı ve başarısız login olaylarını çeker; anormal aktivitenin hızlı tespitini sağlar.

Linux Logları

Syslog ve Journald
Çoğu Linux dağıtımı log mesajlarını toplamak ve yönetmek için syslog veya systemd-journald kullanır:

İzlenmesi Gereken Alanlar

1. Authentication: Tekrarlayan başarısız login denemeleri, /etc/passwd içinde yeni kullanıcı eklenmesi veya sudo kullanımındaki ani değişimler.
2. Cron Job’lar: /var/log/cron içinde yetkisiz scheduled task’lar. Cron, saldırganların persistence için sıkça kullandığı bir mekanizmadır.
3. Kernel Mesajları: Tekrarlayan kernel warning/error kayıtları donanım sorununa ya da potansiyel rootkit aktivitesine işaret edebilir.
4. Servis Logları: Apache, Nginx, SSH gibi servislerin kendi logları (/var/log/apache2/access.log, /var/log/nginx/access.log, /var/log/secure) beklenmedik trafik ya da tekrarlayan authentication failure için.

Örnek: journalctl Kullanımı

# SSH ile ilgili tüm logları görüntüle
journalctl -u sshd

# Belirli bir zaman aralığını filtrele
journalctl --since "2025-01-01" --until "2025-01-31"

Dağıtıma Göre Log Kaynakları
Dosya konumları RHEL ailesi (RHEL/CentOS/Rocky) ile Debian ailesi (Debian/Ubuntu) arasında farklılık gösterir. Regüle bir ortamda tüm sunucu filosu için bu ayrımı bilmek şarttır:

Binary log dosyaları (wtmp , btmp , utmp , lastlog) doğrudan cat ile okunamaz sırasıyla last , lastb , who , lastlog komutları kullanılır.

Windows Event ID ↔ Linux Karşılığı
Bir SOC analisti çoğunlukla Windows Event ID’leri üzerinden düşünür. Aynı güvenlik olaylarının Linux’taki karşılığını bilmek, heterojen ortamlarda tutarlı korelasyon kurmayı sağlar:

Linux’ta ayrıcalıklı gruplar (Windows’taki Domain Admins/Enterprise Admins muadili): root , wheel (RHEL), sudo (Debian) , adm , shadow , disk ve konteyner ortamlarında docker , lxd . docker grubuna üyelik pratikte root yetkisine eşdeğerdir. Bu yüzden bir kullanıcının docker grubuna eklenmesi, wheel grubuna eklenmesi kadar kritiktir.

Önemli uyarı: Linux varsayılan kurulumda bu olayların çoğunu kernel seviyesinde yakalamaz. auth.log / secure Yalnızca PAM/SSH katmanını görür; process çalıştırma, syscall, dosya erişimi gibi olaylar için auditd‘nin doğru kural setiyle yapılandırılması gerekir. Ödeme kuruluşu bağlamındaki auditd konfigürasyonunu Bölüm 4.13‘te ele alıyorum.

macOS Logları
Unified Logging System
macOS Sierra (10.12) ile birlikte Apple, log mesajlarını yapılandırılmış formatta saklayan bir unified logging system getirdi.

# Canlı log akışını izle (sistem geneli)
log stream --level=info

# Belirli process veya hataları ara
log show --predicate 'process == "sshd" AND eventMessage CONTAINS "Failed password"'

Güvenlik Odaklı Loglar

• /var/log/system.log – Temel sistem mesajlarının çoğunu tutar, troubleshooting için ilk durak.
• Apple System Log (ASL) – Unified logging ile birlikte var olmaya devam eden legacy logging katmanı.
• Authentication Logs – SSH veya lokal hesap login denemeleri /var/log/asl/ altında ya da unified logging arayüzünde görünür.

Dikkat Edilmesi Gerekenler

• Tekrarlayan başarısızlıklar: Linux’ta olduğu gibi, tekrarlayan SSH denemeleri veya beklenmedik process başlatmaları.
• Crash raporları: Saldırganlar bazen güvenlik araçlarını crash ettirmeye çalışır. macOS crash logları, tampering’in erken göstergesi olabilir.
• Console App: Logları Process veya Message Type’a göre filtrelemek için built-in aracı kullanın.

Platformlar Arası Karşılaştırma

Logging Agent’lar ve Merkezileştirme

• Windows: Windows Event Forwarding (WEF), detaylı process seviyesi logging için Sysmon, veya NXLog / Splunk Universal Forwarder gibi üçüncü parti agent’lar.
• Linux: Rsyslog, Syslog-ng veya systemd-journald ile remote forwarding. Elastic’in Beats ailesi (Filebeat, Metricbeat) de log toplama ve gönderme için kullanılabilir.
• macOS: Osquery (query tabanlı logging), Splunk veya Datadog agent’ları.

2.2. Ağ Logları (Firewall, Router, IDS/IPS)

Ağ cihazlarından ve güvenlik sistemlerinden gelen loglar, bir SOC’un en kritik veri kaynakları arasındadır. Firewall, router ve IDS/IPS loglarını analiz eden analistler; trafik desenleri, güvenlik olayları ve potansiyel anomaliler konusunda görünürlük kazanır.

Firewall Logları
Firewall’lar çoğunlukla ilk savunma hattıdır ve trafiği önceden tanımlanmış kurallara göre filtreler. Firewall loglarını izlemek, hem izin verilen hem de reddedilen bağlantılar hakkında içgörü sağlar.

Tipik Firewall Log Alanları

Modern firewall’lar özellikle Next-Generation Firewall (NGFW) çözümleri kimlik yönetimi sistemleriyle entegre çalıştığında application-level veri ve kullanıcı bilgisi de loglayabilir.

Pratik Kullanım Senaryoları

• Bloklanan bağlantı denemeleri: Hassas portlara (22/SSH, 3389/RDP) yönelik tekrarlayan bağlantı denemeleri brute-force veya port scan’e işaret eder.
• Olağandışı trafik hacmi: Tek bir IP veya subnet’ten gelen ani trafik artışı DoS/DDoS girişimi olabilir.
• Inbound vs. Outbound izleme: Kurumun iş yapmadığı ülkelere veya şüpheli IP’lere giden outbound bağlantılar, ele geçirilmiş host’ların erken göstergesidir. (malware’in “calling home” davranışı)

SIEM’de Firewall Log Analizi – Splunk Örneği

RDP (3389) portuna yönelik reddedilen bağlantıları filtreleyen sorgu:

index=firewall_logs action=DENY dest_port=3389
| stats count by src_ip, dest_ip, action, rule_name

Bu sorgu, RDP servislerine tekrar tekrar ulaşmaya çalışan ancak reddedilen source IP’leri öne çıkarır muhtemel bir intrusion girişiminin işareti.

Router Logları
Router’lar temelde paketleri ağlar arasında yönlendirir ve routing table’ları yönetir. Ürettikleri loglar, uygulama verisinden çok sistem mesajlarına, routing güncellemelerine ve interface hatalarına odaklanır. Yine de genel görünürlük için özellikle dağıtık mimarilerde kritiktir.

Router Log Tipleri

• System / Event Logs: Cihaz reboot, yazılım crash, konfigürasyon değişikliği mesajları
• Routing Protocol Logs: BGP, OSPF, EIGRP ve diğer routing protokollerine ait bilgiler
• Interface Logs: Interface durum değişiklikleri (up/down), paket hataları (CRC error, collision), bant genişliği kullanımı
• Authentication Logs: SSH, Telnet veya console üzerinden başarılı/başarısız router login’leri

Örnek: Cisco Router Syslog Mesajı

<189>Jan 25 10:25:10 MY-ROUTER: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up

• 189 – Syslog priority değeri
• %LINK-3-UPDOWN – Severity level 3 (Error) ile link durum değişikliği
• Mesaj, hangi interface’in durum değiştirdiğini belirtir

SIEM’de %LINK-3-UPDOWN olaylarını filtreleyerek beklenmedik interface durum değişikliklerini takip edebilirsiniz. Bir interface aniden down olduysa; fiziksel bir sorun, hatalı konfigürasyon ya da ağ segmentlerini kesintiye uğratmayı amaçlayan kötü niyetli bir aktivite söz konusu olabilir.

IDS/IPS Logları
Intrusion Detection System (IDS) ve Intrusion Prevention System (IPS) çözümleri; ağ trafiğini zararlı davranış, policy ihlali veya bilinen saldırı imzaları açısından izler. Firewall’lar genellikle transport/network katmanında çalışırken, IDS/IPS paketleri daha derinlemesine (Layer 7) inceleyerek application-level tehditler hakkında çok daha zengin bağlam sunar.
IDS vs. IPS

• IDS: Potansiyel tehditleri tespit eder ve alert üretir. Trafiği otomatik olarak bloklamaz.
• IPS: Tehditleri tespit eder ve önleyici aksiyon alabilir. Zararlı paketleri drop etmek, IP adreslerini gerçek zamanlı bloklamak gibi.

IDS/IPS Loglarında Tipik Alanlar

• Signature ID: Tetiklenen kural/imzanın benzersiz kimliği (örneğin Snort’ta SID değerleri)
• Event / Alert Message: Şüpheli aktivitenin adı veya açıklaması (örn. “ET TROJAN Zeus Tracker”)
• Severity / Priority: Alert’in kritiklik seviyesi
• Source IP / Destination IP / Ports: Trafik akışına dair bilgiler
• Action: Trafiğin detect mi, drop mu, allow mu edildiği

Pratik Örnek: Suricata
Suricata, yaygın kullanılan açık kaynak bir IDS/IPS engine’idir. JSON formatında log üretir ve Elasticsearch ya da Splunk gibi SIEM araçları tarafından kolayca ingest edilebilir:

{
  "timestamp": "2025-01-25T10:30:45.123456+0000",
  "flow_id": 1234567890,
  "event_type": "alert",
  "src_ip": "192.168.1.100",
  "src_port": 53452,
  "dest_ip": "10.0.5.20",
  "dest_port": 80,
  "proto": "TCP",
  "alert": {
    "action": "blocked",
    "gid": 1,
    "signature_id": 2010935,
    "rev": 3,
    "signature": "ET TROJAN Known Malicious Domain",
    "category": "Trojan Activity",
    "severity": 2
  }
}

Yukarıdaki Örnekte:

• signature_id: 2010935 – Belirli bir Trojan imzasına karşılık gelen Suricata kural ID’si
• action: "blocked" – Trafik Suricata tarafından bloklanmış (IPS modu)
• category: "Trojan Activity" – Tehdidin tipi

Gerçek Hayattan Saldırı Senaryoları

• SQL Injection denemeleri: IDS/IPS, HTTP request’lerinde bilinen SQL injection tekniklerine uyan desenleri arar.
• Exploit kit’ler: Bir host, exploit kit domain’ine bağlanmaya veya ondan indirme yapmaya çalışırsa, IDS/IPS logları şüpheli domain adını ve imza eşleşmesini ortaya koyar.
• Lateral movement: Saldırganlar ağ içinde yatay hareket etmeye çalışabilir. IDS/IPS, olağandışı SMB veya RDP trafik desenlerini yakalayabilir.

Ağ Loglarını Pratikte Parse Etmek ve Analiz Etmek

SIEM Entegrasyonu
SOC analistleri firewall, router ve IDS/IPS loglarını korelasyon ve analiz için tipik olarak bir SIEM’de merkezileştirir. Bu, farklı kaynaklardan gelen olayların çapraz referanslanmasını sağlar.
Örneğin: Bir IDS alert’i Trojan imzası bildiriyor ve aynı anda firewall logları şüpheli bir IP’ye giden outbound trafik gösteriyorsa, SIEM daha yüksek öncelikli bir alert üretebilir.

Örnek: Suricata JSON Loglarını Parse Eden Logstash Konfigürasyonu:

input {
  file {
    path => "/var/log/suricata/eve.json"
    type => "suricata"
    codec => "json"
  }
}

filter {
  if [event_type] == "alert" {
    mutate {
      add_tag => ["suricata_alert"]
    }
  }
}

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "suricata-alerts-%{+YYYY.MM.dd}"
  }
}

Bu konfigürasyon Suricata’nın eve.json dosyasını okur, alert tipindeki olayları filtreler, suricata_alert tag’i ile etiketler ve Elasticsearch’e gönderir.

Correlation Rule Örnekleri:

Bir SIEM’de kurgulanabilecek korelasyon kuralları:

1. Yüksek hacimli deny: Aynı source IP’den 5 dakika içinde 100’den fazla firewall deny olursa alert üret.
2. Aynı host için çoklu IDS alert: Bir host kısa süre içinde 3’ten fazla farklı IDS imzası tetiklerse olayın önceliğini yükselt.
3. Router interface down + IDS alert: Kritik bir interface down olur ve komşu ağ segmentlerinde çoklu IDS alert görülürse; sabotaj ya da yaygın compromise olasılığını araştır.

Farklı log tiplerini birleştiren correlation rule’lar, koordineli saldırıları tespit etmenin yanı sıra false positive hacmini de düşürür.
Zorluklar ve Best Practice’ler

• Log hacmi: Ağ cihazları devasa veri üretir. Filtreleme veya sampling gerekebilir. Ancak önemli bilgiyi atmamaya dikkat edin.
• Normalization: Cisco, Palo Alto, Fortinet gibi farklı üreticiler farklı log formatları kullanır. Alanların normalize edilmesi (src_ip , dest_ip gibi tutarlı isimlendirme) etkili korelasyonun ön koşuludur.
• Şifreli ve güvenli taşıma: Log verisini güvenli şekilde iletin. Örneğin Syslog over TLS. Şifrelenmemiş loglar saldırganlar tarafından dinlenebilir ve manipüle edilebilir.
• Düzenli tuning: IDS/IPS ruleset’leri yeni tehditleri yansıtacak şekilde güncellenmelidir. Firewall policy’leri de değişen ağ ortamına göre gözden geçirilmelidir.
• Zaman senkronizasyonu: Tüm cihazlarda NTP etkin ve doğru yapılandırılmış olmalıdır. Doğru timestamp, event correlation’ın olmazsa olmazıdır.

2.3. Uygulama ve Veritabanı Logları

Uygulama logları, bir uygulamanın işlevselliğine doğrudan bağlı olay ve davranışları yakalar: kullanıcı etkileşimleri, sistem operasyonları, exception’lar, debug detayları ve geliştiricilerin tanımladığı özel olaylar.

Veritabanı logları ise veri transaction’ları, schema değişiklikleri, authentication ve performans darboğazlarıyla ilgili tüm aksiyonları kaydeder.

Bu ikisi birlikte, yazılımın nasıl çalıştığına ve veriye nasıl erişildiğine dair bütünsel bir görünüm sunar. Yetkisiz aktiviteleri, performans sorunlarını ve anomalileri tespit etmenin temeli.

Uygulama Logları

Yaygın Uygulama Log Tipleri

1. Error ve Exception Logları: Beklenmeyen davranışları ve stack trace’leri yakalar. Java’da Log4j/Logback, Python’da logging , .NET’te built-in logging özellikleri tarafından üretilir.
2. Debug ve Diagnostic Logları: İç operasyonların detayını verir. Çok verbose olabilir; genelde sadece test/development ortamlarında ya da production’da derin bir sorun analizinde açılır.
3. Transaction / Event Logları: E-ticaret checkout gibi kullanıcı transaction’larını işleyen uygulamalar; sepete ekleme, ödeme işleme gibi her adımı loglar.
4. Audit Logları: Uyumluluk veya güvenlik amacıyla üretilir. Kullanıcı erişimini, rol değişikliklerini ve kritik konfigürasyon güncellemelerini takip eder. Kim, ne zaman, ne yaptı sorusunun cevabı.

Logging Framework’leri

Bu framework’ler log level’larını yapılandırmayı, log mesajlarını (örneğin JSON olarak) structure etmeyi ve console/dosya/harici aggregation servisleri gibi output target’ları belirlemeyi sağlar. Format tutarlılığı, SIEM içinde parsing ve correlation için kritiktir.

Örnek Konfigürasyon (Java – Log4j2):

<Configuration status="warn">
  <Appenders>
    <File name="FileLogger" fileName="logs/application.log">
      <PatternLayout pattern="%d{ISO8601} [%t] %-5level %logger{36} - %msg%n" />
    </File>
  </Appenders>
  <Loggers>
    <Logger name="com.example.app" level="info" additivity="false">
      <AppenderRef ref="FileLogger"/>
    </Logger>
    <Root level="error">
      <AppenderRef ref="FileLogger"/>
    </Root>
  </Loggers>
</Configuration>

Bu snippet; timestamp, thread adı, log level ve mesajı içeren bir pattern ile application.log dosyasını tanımlar. Root level’ı error , uygulama logger’ını info yaparak gereksiz gürültüden kaçınılır.

Uygulama Loglarını İzlerken

• Baseline davranışı belirleyin: Normal uygulama davranışını (ortalama response time, tipik error oranı) bilmek, belirli exception’lardaki ani artış gibi anomalileri tespit etmeyi sağlar.
• Yaygın saldırı desenlerini arayın: Yetkisiz erişim denemeleri genelde tekrarlayan login failure, URL’lerde şüpheli parametreler (SQL injection probe’ları) veya session management’ta anormallikler olarak görünür. Saldırı altındaki web uygulamaları yüksek frekansta 404 hatası veya olağandışı HTTP method’ları loglayabilir.
• SIEM entegrasyonu: Uygulama loglarını sistem/ağ olaylarıyla korele etmek için Splunk, IBM QRadar veya Elastic Security kullanın. Örneğin uygulamanın “çoklu başarısız login” olayını, firewall’da görünen şüpheli IP taramasıyla korele ederek bir intrusion girişimini hızla doğrulayabilir veya eleyebilirsiniz.
• Alert ve threshold’lar: Error oranı, transaction hacmindeki düşüş veya exception spike’ları üzerine threshold tabanlı alert’ler olayları erken yakalar.
• Retention policy: Uygulama logları hızla büyür. Güvenlik ihtiyaçları ile depolama maliyetini dengeleyen retention policy’ler tanımlamak gerekir. PCI DSS, HIPAA gibi çerçeveler belirli log tipleri için minimum saklama süreleri dayatabilir.

Veritabanı Logları

Temel Veritabanı Log Tipleri

• Transaction Logs: Veritabanındaki her değişikliği yakalar. Recovery ve forensic analiz için kritiktir. Örneğin Microsoft SQL Server’da transaction log, her modifikasyonu gerçekleşme sırasıyla takip eder ve point-in-time recovery’yi mümkün kılar.
• Error Logs: Sunucu başlatma sorunları veya veritabanı erişilebilirliğini etkileyen ciddi hatalar gibi kritik olayları öne çıkarır. MySQL’in error.log dosyası veya Oracle’ın alert log’ları buna örnektir.
• General Query Logs (MySQL) / Audit Logs: Sunucuya gelen tüm sorguları kaydeder veya hesap aktivitesini izler. SQL injection saldırılarını, şüpheli veri çekmelerini ve privilege escalation girişimlerini tespit etmede paha biçilmezdir.
• Slow Query Logs: MySQL ve PostgreSQL’de bulunur; belirli bir çalışma süresi eşiğini aşan sorguları yakalar. Yavaş sorgular performans sorununa işaret edebileceği gibi, saldırgan tarafından manipüle ediliyorsa potansiyel bir DoS girişimi de olabilir.

Pratik İzleme Stratejileri

1. Şüpheli sorguları düzenli inceleyin: Beklenen change-control ticket’ı olmadan kritik tabloları DROP veya ALTER eden sorguları izleyin. Ayrıca olağandışı saatlerde yapılan wildcard aramaları ve büyük veri çekimlerine dikkat edin
2. Privilege abuse tespiti: Minimal yetkiye sahip bir kullanıcı, administrator’a özgü sorgular çalıştırmaya başlarsa; bu, ele geçirilmiş credential veya privilege escalation’ın güçlü bir göstergesidir. Least privilege prensibini uygulayıp logları anomali açısından incelemek etkili bir stratejidir
3. Error pattern analizi: “invalid column name” veya “syntax error” gibi tekrarlayan veritabanı hata mesajları, SQL injection girişimlerine işaret edebilir. Tek bir source IP’den gelen tekrarlayan hataları flag’leyen SIEM correlation rule’ları kurgulayın
4. Performans verisi: Yüksek kaynak kullanımı veya timeout’a işaret eden loglar, veritabanı katmanında brute-force veya DoS saldırısının erken uyarısı olabilir

Örnek Konfigürasyonlar

MySQL – General Query Log:

SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/var/log/mysql/general.log';

MySQL – Slow Query Log:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;  -- 2 saniyeden uzun süren sorgular loglanır

Not: Tüm sorguları loglamak performansı ciddi şekilde etkileyebilir. Bunu yalnızca geçici diagnostic amaçla açın ya da logları merkezi bir sisteme yönlendirip orada verimli şekilde parse edip analiz edin.

PostgreSQL (postgresql.conf üzerinden):

logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%a.log'
log_statement = 'all'
log_min_duration_statement = 2000

log_statement = 'all' ayarı her statement’ı görmenizi sağlar, ancak production için genellikle fazla verbose’tur.

Gerçek Hayattan Senaryolar

Veri Sızıntısı (Data Exfiltration) Tespiti
SOC analisti, bir REST API çağrısında olağandışı parametre değerleri gösteren bir uygulama log kaydı fark eder. Veritabanı loglarıyla çapraz kontrol yaptığında, hassas müşteri verisini çeken çok sayıda büyük SELECT statement’ı olduğunu doğrular. Ağ loglarıyla ek korelasyon, harici bir IP’ye büyük veri transferi yapıldığını gösterir. Loglar bir araya geldiğinde, devam eden bir data exfiltration girişimine işaret eder.

Uyumluluk Denetimi
Bir finansal servis uygulamasında, uyumluluk gereklilikleri her transaction’ın audit edilmesini zorunlu kılar. Uygulama logları (mantık katmanını yakalar) ve veritabanı transaction logları (nihai kayıt değişikliklerini yakalar) birlikte incelendiğinde; her para yatırma ve çekme işleminin yetkili ve doğru şekilde yürütüldüğü doğrulanabilir.

Performans Saldırısının Teşhisi
Bir dizi yavaş sorgu ilk bakışta performans darboğazı gibi görünür. Ancak daha derin inceleme, saldırganların uygulamanın yanıt verebilirliğini düşürmek için kasten kaynak yoğun sorgular ürettiğini ortaya çıkarır. SIEM’de bu yavaş sorguların web sunucusundaki tekrarlayan 503 hatalarıyla korele edilmesi, bir DoS girişimini doğrular.

Karşılaştırmalı Özet

Bu logları toplarken ve analiz ederken; timestamp, user ID ve hostname gibi alanların normalize edilmesi, farklı log kaynaklarının etkili şekilde korele edilebilmesi için şarttır. ELK Stack gibi bazı platformlar, ortak field mapping’leri ve uygulama–veritabanı içgörülerini birleştiren dashboard’lar tanımlamanıza olanak tanır.

2.4. Güvenlik Logları (AV, EDR, XDR)

–Antivirus (AV), Endpoint Detection and Response (EDR) ve Extended Detection and Response (XDR) çözümlerinin ürettiği güvenlik logları, modern SOC operasyonlarının merkezindedir. Endpoint’leri ve daha geniş ortamı etkileyen tehditler konusunda granüler görünürlük sunarlar.

Antivirus (AV) Logları
AV çözümleri temelde bilinen malware imzalarını tespit etmeye ve şüpheli dosyaları bloklamaya odaklanır. Logları genellikle şunları içerir:

• Malware Detections: Bir dosya bilinen bir imzayla eşleştiğinde veya zararlı davranış sergilediğinde tetiklenen alert’ler.
• Quarantine ve Remediation Actions: Hangi dosyaların karantinaya alındığı, silindiği veya etkisiz hale getirildiği.
• Update ve Scan Events: İmza güncellemeleri, zamanlanmış tarama ve on-demand scan sonuçları.

Gerçek Hayattan Örnek
Microsoft Defender Antivirus (Windows Security’nin parçası), loglarını Windows Event Log altında üretir:

• Event ID 1116 – Malware tespiti
• Event ID 5001 – Tarama motorunun başlatılması

Bu Event ID’leri bir SIEM’de toplayan analistler, enfeksiyon girişimi desenlerini hızla görebilir ve güncellemelerin uygulandığını doğrulayabilir.

Endpoint Detection and Response (EDR) Logları
EDR çözümleri, temel antivirüs yeteneklerinin ötesine geçerek derinlemesine endpoint telemetrisi, gerçek zamanlı tehdit tespiti ve response kabiliyeti sunar.

Tipik Log Verisi:

• Process Creation ve Termination: Command-line parametreleri, kullanıcı bağlamı ve dosya yollarının detaylı takibi.
• Behavioral Indicators: Code injection, privilege escalation veya olağandışı registry modifikasyonları gibi şüpheli aktiviteler.
• Isolation ve Response Actions: Bir endpoint’in ne zaman ve neden izole edildiği, ağ bağlantılarının bloklandığı veya containment için otomatik script çalıştırıldığı.

EDR logları çoğunlukla korele edilmiş olay dizileri sunar; bu da SOC analistlerinin saldırının zaman çizelgesini yeniden kurmasını kolaylaştırır. CrowdStrike Falcon, SentinelOne veya Carbon Black gibi araçlar; tetiklenen detection rule’ları (örneğin MITRE ATT&CK teknikleriyle eşleştirilmiş) otomatik remediation aksiyonlarıyla birlikte dashboard’larda gösterir.

Örnek EDR Log Analizi (Splunk)

PowerShell’in şüpheli child process’lerini tespit etmeye yönelik sorgu:

index=edr_logs parent_process=PowerShell.exe
| stats count by child_process, user, host
| where count > 3

Bu sorgu, PowerShell tarafından spawn edilen child process’leri arar ve tekrarlayan oluşumları flag’ler zararlı script’lere veya living-off-the-land tekniklerine işaret edebilir.

Extended Detection and Response (XDR) Logları

XDR, EDR’nin endpoint merkezli yaklaşımını genişleterek ağ cihazları, cloud workload’ları ve uygulamalardan gelen verileri de kapsar. Amaç; detection, investigation ve response süreçlerini IT ortamının tüm katmanlarında birleştirmektir.

• Cross-Source Correlation: Endpoint’ler, e-posta gateway’leri, identity provider’lar ve daha fazlasından gelen logları toplayarak gizli tehditleri ortaya çıkaran analitikler uygular.
• Cloud ve Hybrid Entegrasyonlar: Cloud platformları ve container’laşmış workload’lardan gelen telemetri, endpoint verisiyle birleşerek karmaşık saldırıların bütünsel görünümünü sunar.
• Adaptive Response: Machine learning ve correlation rule’lara dayanarak, tehditlere gerçek zamanlı yanıt veren otomatik playbook’ları tetikleyebilir (ele geçirilmiş kullanıcı hesabını devre dışı bırakmak, enfekte host’u izole etmek, şüpheli domain’i firewall’da bloklamak gibi)

Referans Mimariler

• Microsoft 365 Defender: Endpoint (Defender for Endpoint), e-posta (Defender for Office 365), kimlik (Entra ID / Azure AD) ve cloud app (Defender for Cloud Apps) verilerini entegre eder.
• Palo Alto Cortex XDR: Endpoint verilerini işler; ağ sensörleri veya firewall’larla entegre olarak gelişmiş korelasyon sağlar.

Log Toplama Best Practice’leri

1. Logları SIEM’de merkezileştirin: Tüm AV, EDR ve XDR loglarını Splunk, Elastic Stack veya IBM QRadar gibi bir platformda birleştirin. Bu, threat hunting ve alert triage için tek bir görünüm sağlar.
2. Tutarlı log formatı kullanın: Mümkün olduğunda formatı standartlaştırın (JSON, Syslog) parsing, correlation ve uzun vadeli saklamayı kolaylaştırır.
3. Yeterli geçmişi saklayın: Regülasyon gereklilikleri ve threat modeling’e bağlı olarak, yavaş ilerleyen saldırıları veya APT (Advanced Persistent Threat) faaliyetlerini inceleyebilecek kadar uzun süre log saklayın.
4. Birden fazla kaynağı korele edin: AV alert’leri tek başına minimal bağlam sunar. Endpoint telemetrisi ve kullanıcı login desenleriyle çapraz referanslandığında büyük resim ortaya çıkar. Özellikle çok aşamalı saldırılarda.
5. Otomatik detection rule’lar kurgulayın: EDR/XDR çözümünüzün built-in tespit yeteneklerini kullanın ve ortamınıza özel kurallarla destekleyin. Örneğin bilinen güvenli bir process’in olağandışı bir child process spawn etmesi (outlook.exe → cmd.exe) durumunda alert üretin.
6. Threat intelligence’tan yararlanın: Detection olaylarını threat intelligence feed’leriyle (VirusTotal, AlienVault OTX) zenginleştirin. Bir alert bilinen zararlı bir domain veya file hash’e referans veriyorsa, bu doğrulama süreci hızlandırır.

İzlenmesi Gereken Yaygın Güvenlik Olayları

Pratik İzleme İpuçları

• Başarılı ve başarısız remediation denemelerini takip edin: AV bir dosyayı defalarca karantinaya almaya çalışıp başarısız oluyorsa, bu gelişmiş malware’e ya da kullanıcı tampering’ine işaret edebilir.
• EDR agent sağlığını izleyin: EDR agent’larının tüm endpoint’lerde çalıştığından düzenli olarak emin olun. Beklenmedik agent downtime, saldırganın güvenlik kontrollerini devre dışı bırakma girişiminin erken göstergesi olabilir.
• Otomatik playbook sonuçlarını gözden geçirin: XDR platformları sıklıkla otomatik yanıtlar çalıştırır. Bu yanıtların hem etkili olduğundan hem de kurumunuzun incident response prosedürleriyle uyumlu olduğundan emin olun.
• Üretici dokümantasyonunu takip edin: Her AV, EDR veya XDR üreticisinin log toplama ve yorumlama konusunda kendi best practice’leri vardır.

Örnek Olay Akışı: AV + EDR + XDR

1. AV Alert: Bilinen zararlı hash’e sahip şüpheli bir executable üzerinde tetiklenir.
2. EDR Korelasyonu: Şüpheli executable’ı bir process tree’ye bağlar; olağandışı bir script tarafından başlatıldığını gösterir.
3. XDR Görünürlüğü: Script’in tanınmayan bir domain’den indirildiğini doğrular ve threat intelligence feed’leri üzerinden bu domain’i bilinen bir threat actor ile ilişkilendirir.
4. Otomatik Yanıt: XDR veya SOAR platformu endpoint’i karantinaya alır, domain’i firewall’da bloklar ve incident management sisteminde bir ticket açar.
5. SOC Analisti Aksiyonu: Olay zincirinin tamamını inceler, tehdidin kaldırıldığını doğrular ve benzer saldırıları önlemek için detection rule’ları günceller.

2.5. Cloud Logları (AWS, Azure, GCP) ve Container Logları (Docker, Kubernetes)

Cloud platformları ve container orkestrasyon sistemleri artık pek çok kurumun vazgeçilmez bir parçası. SOC ortamında bu platformlardan gelen logları izlemek; tehdit tespiti, uyumluluk ve troubleshooting için kritik.

AWS Logları

1. CloudTrail Logs

• Amaç: AWS servisleri genelinde API çağrılarını ve hesap aktivitesini takip etmek.
• Anahtar Alanlar: eventName , eventSource , awsRegion , sourceIPAddress , userAgent , requestParameters , responseElements
• Güvenlikte Kullanımı: IAM policy’lerinde beklenmedik değişiklikler, kritik kaynakların oluşturulması/silinmesi veya olağandışı console login’leri gibi şüpheli ya da yetkisiz aksiyonları tespit eder.

2. CloudWatch Logs

• Amaç: AWS servisleri için merkezi logging (EC2 sistem logları, Lambda function logları vb.)
• Anahtar Alanlar: Servise göre değişir; tipik olarak timestamp, log level (ERROR, WARNING, INFO) ve özel uygulama mesajları.
• Güvenlikte Kullanımı: Sistem seviyesi olayları daha üst seviye aktivitelerle korele etmeye yardımcı olur. Örnek: Bir EC2 instance’ının sistem error loglarını, CloudTrail’de görünen yetkisiz erişim girişimiyle ilişkilendirmek.

3. VPC Flow Logs

• Amaç: Ağ akış bilgisini yakalamak (kaynak/hedef IP, port, trafiğin kabul/red durumu).
• Anahtar Alanlar: version , account-id , interface-id , srcaddr , dstaddr , srcport , dstport , protocol , action , log-status
• Güvenlikte Kullanımı: Olağandışı trafik desenlerini veya data exfiltration girişimlerini tespit eder. Büyük outbound veri transferleri, bilinmeyen IP aralıklarından gelen trafik gibi.

Pratik Örnek
Tipik bir ingestion akışı: CloudTrail ve VPC Flow Log’ları bir S3 bucket’a yönlendirmek, ardından Amazon Kinesis veya üçüncü parti bir araç (örneğin Logstash) ile parse edip SIEM’e göndermek.

AWS CLI ile CloudTrail Logging’i Etkinleştirme:

aws cloudtrail create-trail \
  --name MySecurityTrail \
  --s3-bucket-name my-security-logs \
  --include-global-service-events

Azure Logları

1. Azure Activity Logs

• Amaç: Yönetim operasyonlarına dair içgörü sağlamak (kaynak oluşturma, değiştirme, silme)
• Anahtar Alanlar: authorization , caller , category , operationName , resourceId , status
• Güvenlikte Kullanımı: Yetkisiz kaynak oluşturma, security group değişiklikleri veya privilege escalation girişimlerini tespit eder

2. Azure Monitor Logs (Log Analytics)

• Amaç: Azure kaynakları, container’lar, VM’ler ve uygulamalardan log toplamak
• Anahtar Alanlar: Kaynak tipine göre değişir; genellikle timestamp, operation ID, kullanıcı bilgileri ve bağlamsal veriler
• Güvenlikte Kullanımı: Kapsamlı sorgulama ve korelasyon yetenekleri sunar. SOC ekipleri birden fazla kaynaktan gelen sinyalleri birleştirerek anomali tespit edebilir

3. Diagnostics Logs

• Amaç: Belirli Azure servislerinden detaylı içgörü Key Vault erişim logları, Azure App Service logları, Azure Storage logları
• Anahtar Alanlar: Servise bağlı; genellikle request endpoint’leri, authentication detayları ve sonuç kodları
• Güvenlikte Kullanımı: Olası credential kötüye kullanımını, veri depolamada şüpheli aktiviteyi veya olağandışı uygulama davranışını tespit eder

Pratik Örnek
Azure Monitor’a log göndermek için her kaynak üzerinde bir Diagnostic Setting yapılandırılır:

Set-AzDiagnosticSetting -ResourceId `
  /subscriptions//resourceGroups//providers/Microsoft.Web/sites/ `
  -WorkspaceId  `
  -StorageAccountId `
  /subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/ `
  -Enabled $true

GCP Logları

1. Cloud Audit Logs

• Amaç: GCP servisleri için admin ve data access olaylarını kaydetmek (AWS CloudTrail’in muadili)
• Anahtar Alanlar: protoPayload.serviceName , protoPayload.methodName , resourceName , authenticationInfo , requestMetadata
• Güvenlikte Kullanımı: Privilege escalation girişimlerini veya GCP kaynaklarında şüpheli değişiklikleri (kritik servislerin etkinleştirilmesi/devre dışı bırakılması gibi) yüzeye çıkarır.

2. VPC Flow Logs

• Amaç: Google Cloud VPC’leri için ağ akış bilgisi toplamak.
• Anahtar Alanlar: srcIP , destIP , srcPort , destPort , protocol , connectionEstablished , bytesSent , bytesReceived
• Güvenlikte Kullanımı: Inbound ve outbound trafik desenlerini analiz ederek reconnaissance veya exfiltration aktivitesini yakalar.

3. Cloud Logging

• Amaç: GCP servisleri, container’lar ve özel uygulamalardan gelen olaylar için merkezi logging servisi.
• Anahtar Alanlar: Servise özel veri, timestamp’ler, severity level’ları, resource label’ları (k8s_container , gce_instance vb.)
• Güvenlikte Kullanımı: Uygulama seviyesi logların altyapı seviyesi olaylarla korele edilmesini sağlar.

Pratik Örnek
GCP loglarını bir SIEM’e export etmek için, logları bir Pub/Sub topic’e yönlendiren bir sink oluşturabilirsiniz:

gcloud logging sinks create my-security-sink \
  storage.googleapis.com/ \
  --log-filter="resource.type=gce_instance AND severity>=WARNING"

Container Logları
Container’lar uygulamaları ve bağımlılıklarını tek bir hafif birim halinde paketler. Sıklıkla ephemeral (kısa ömürlü) workload çalıştırdıkları için, sürekli ve standartlaştırılmış logging güvenlik izlemesinin anahtarıdır.

Docker Logları

1. Docker Engine Logs

• Konum: Linux host’larda tipik olarak /var/log/docker.log
• Anahtar Alanlar: Daemon seviyesi olaylar container start/stop, image pull, container runtime hataları.
• Güvenlikte Kullanımı: Yetkisiz container oluşturmayı veya güvenilmeyen registry’lerden zararlı image çekilmesini tespit eder.

2. Container STDOUT/STDERR Logs

• Konum: Varsayılan olarak /var/lib/docker/containers//-json.log
• Güvenlikte Kullanımı: Çalışan uygulamalar içindeki anomalileri yakalar brute-force girişimine veya uygulama kötüye kullanımına işaret eden tekrarlayan hata mesajları gibi.

3. Docker Logging Drivers

• Tipler: json-file , syslog , fluentd , gelf , awslogs ve diğerleri
• Güvenlikte Kullanımı: Merkezi logging çözümleriyle entegre olabilir; container ele geçirilse bile log tampering riskini azaltır.

Docker Örneği – Container loglarını uzak bir syslog sunucusuna yönlendirmek:

docker run --log-driver=syslog \
  --log-opt syslog-address=tcp://192.168.1.10:514 \
  --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}" \
  my_secure_image

Kubernetes Logları

1. Container Logs

• Toplama: Tipik olarak kubectl logs ile ya da bir logging agent (Fluentd, Logstash veya sidecar pattern) aracılığıyla.
• Güvenlikte Kullanımı: Şüpheli uygulama hatalarını veya authentication brute-force girişimine işaret eden tekrarlayan 401/403 yanıtları gibi tetikleyicileri tespit eder.

2. Kubelet Logs

• Konum: OS dağıtımına göre değişir; /var/log/kubelet.log olabilir
• Güvenlikte Kullanımı: Container scheduling sorunlarını, privileged pod planlamaya yönelik yetkisiz girişimleri veya ele geçirilmiş bir node’a işaret edebilecek etkileşimleri takip eder

3. Control Plane Logs (API Server, Scheduler, Controller Manager)

• Konum: Genellikle control plane node üzerinde /var/log/ altında ya da merkezi bir logging çözümünde toplanır.
• Güvenlikte Kullanımı: Yetkisiz API çağrılarını, şüpheli pod oluşturmaları veya Kubernetes role binding‘leri üzerinden privilege escalation girişimlerini tespit eder.

4. Audit Logs

• Amaç: Kubernetes API server’a gelen her request’i kaydetmek.
• Konfigürasyon: API Server üzerinde --audit-log-path ve --audit-policy-file flag’lerini ayarlayarak auditing’i etkinleştirin.
• Güvenlikte Kullanımı: Olay incelemesi için temeldir. RBAC değişikliklerinden privileged container spawn’larına kadar her şeyi takip edebilirsiniz.

Kubernetes Örneği – Basit bir audit policy (audit-policy.yaml):

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec"]

Pratik Değerlendirmeler

• Merkezileştirme: AWS CloudWatch, Azure Monitor, Google Cloud Logging veya self-hosted ELK stack hangisi olursa olsun, birden fazla cloud provider ve container platformundan gelen logları merkezileştirmek korelasyon için şarttır.
• Access Control: Özellikle hassas bilgi (credential, kişisel veri) içeren logların kısıtlı alanlarda saklandığından emin olun. Logları kimin okuyabileceğini veya export edebileceğini kontrol etmek için IAM rollerini yapılandırın.
• Alert ve Dashboard’lar: Hedefli alert’ler kurgulayın. Örneğin: cluster admin yetkisi veren yeni bir Kubernetes ClusterRoleBinding oluşturulduğunda alert üretin.
• Retention Policy: Regülasyon gereklilikleriyle uyumlu olun. Bazı sektörler uzun süreli log saklamayı zorunlu kılarken, bazıları maliyet optimizasyonunu önceliklendirebilir.
• Log Hacmi vs. Alaka Düzeyi: Aşırı “gürültüyü” filtrelemek veri yükünü azaltır. Yalnızca gerekli yerlerde granüler logging kurgulayın ya da container debug logları gibi yüksek hacimli olaylarda log sampling uygulayın.
• Cross-Platform Korelasyon: Bir olayı incelerken container loglarını altyapı loglarıyla çapraz referanslayın. Örneğin zararlı bir container tespit edildiğinde, AWS CloudTrail veya GCP Cloud Audit logları onu kimin ve nereden deploy ettiğini gösterebilir.

2.6. IoT / SCADA / OT Logları

IoT (Internet of Things), SCADA (Supervisory Control and Data Acquisition) ve OT (Operational Technology) cihazları; üretim tesislerinden enerji şebekelerine kadar modern endüstrilerde kritik rol oynar. Bu sistemlerin ürettiği loglar operasyonel durum, performans metrikleri ve potansiyel güvenlik tehditleri hakkında değerli içgörüler sunar.

Ancak bu logları etkili şekilde izlemek zordur: protokol çeşitliliği, farklı işletim sistemleri ve firmware’ler, bir de endüstriyel ortamları karakterize eden yüksek erişilebilirlik (high availability) gereksinimleri…

IoT, SCADA ve OT Ortamlarını Anlamak

IoT’ye Genel Bakış
IoT cihazları tipik olarak akıllı ev sistemleri, endüstriyel sensörler, sağlık cihazları gibi bağlamlarda kullanılan gömülü sistemlerdir.

Genellikle:

• Sınırlı kaynaklara (CPU, memory) sahiptirler logların lokal saklanmasını zorlaştırır.
• Özel firmware kullanırlar standartlaştırılmış log üretebilir ya da üretmeyebilirler.
• Ağ kısıtları yaşarlar düşük bant genişliği veya kesintili bağlantı.

SCADA ve OT Sistemleri
SCADA ve diğer OT sistemleri; enerji, üretim, ulaşım ve kritik altyapıda endüstriyel süreçleri kontrol eder ve izler.

Temel Farkları:

• Gerçek zamanlı veya gerçek zamana yakın işleme katı performans ve erişilebilirlik gereksinimleri.
• Özel protokoller (Modbus, DNP3, OPC-UA) logging yetenekleri IT ortamlarından ciddi şekilde farklıdır.
• Legacy bileşenler güncel siber güvenlik standartlarını veya modern logging framework’lerini desteklemeyebilir.

İzlenmesi Gereken Log Tipleri

1. System Logs: Endüstriyel kontrolörlerin (PLC, RTU, HMI) kullandığı gömülü işletim sistemleri, mümkün olduğunda kernel mesajları veya standart syslog kayıtları üretebilir.
2. Network Traffic Logs: Pek çok endüstriyel protokol ağ sensörleri veya özel gateway’ler tarafından yakalanabilir. Trafikteki anomaliler örneğin beklenmedik Modbus function code‘ları zararlı aktiviteye veya hatalı konfigürasyona işaret edebilir.
3. Application Logs: SCADA yazılımı; operatör aksiyonlarını, process eşiklerini, alarm durumlarını ve cihaz bağlantı sorunlarını loglar. Bu loglar kritik setpoint‘lerde yapılan yetkisiz değişiklikleri ortaya çıkarabilir.
4. Firmware / Device Logs: IoT ve OT cihazları sıklıkla firmware bütünlük kontrolleri veya patch güncellemeleriyle ilgili mesajlar üretir. Bunları izlemek, yetkisiz firmware yükleme girişimlerini tespit etmeye yardımcı olur.
5. Security Appliance Logs: Endüstriyel ağlarda perimeter güvenliği mevcutsa; firewall’lar, IDS/IPS ve OT’ye özel güvenlik cihazları intrusion girişimleri, bloklanan trafik ve tespit edilen tehditlerle ilgili log üretir.

Log Toplamada Pratik Zorluklar

1. Protokol Karmaşıklığı Pek çok IoT ve endüstriyel protokol tescilli (proprietary) ya da yalnızca kısmen dokümante edilmiştir. Logları yorumlamak, ilgili protokol versiyonunu ve üretici implementasyonunu bilmeyi gerektirir.
2. Sınırlı Depolama ve İşlem Gücü Bazı cihazlar sınırlı disk alanı nedeniyle logları hızla rotate eder. Veri kaybını önlemek için SOC analistlerinin bu logları gerçek zamanlı olarak merkezi bir sunucuya forward etmesi gerekebilir.
3. Yüksek Erişilebilirlik Gereksinimi Belirli logları etkinleştirmek için bir production sistemini durdurmak veya yeniden yapılandırmak, kritik operasyonları kesintiye uğratacaksa mümkün olmayabilir. Logging konfigürasyonları dikkatle çoğunlukla planlı bakım pencerelerinde uygulanmalıdır.
4. Segmentasyon ve Air Gap Endüstriyel ağlar bazen kurumsal ağlardan izoledir (air-gapped). Yeni zafiyetler yaratmadan log aktarımı için güvenli mekanizmalar (data diode, jump host) gerekir.

İzleme İçin Best Practice’ler

1. Logları Standartlaştırın ve Normalize Edin
Mümkün olduğunda cihazları syslog veya JSON gibi standart bir formatta log üretecek şekilde yapılandırın. Bu adım, SIEM’e ingestion’ı ciddi şekilde basitleştirir.

Örnek: Linux tabanlı bir endüstriyel kontrolörde syslog yapılandırması

sudo apt-get install rsyslog
sudo systemctl enable rsyslog

# /etc/rsyslog.conf içinde log forwarding
*.* @192.168.100.10:514

Bir OT ortamında syslog forwarding’i etkinleştirmek için üreticiye özel dokümantasyona ihtiyaç duyabilirsiniz. Syslog bir seçenek değilse; native logları parse edip ortak bir formatta gönderebilen bir endüstriyel gateway veya protocol converter kullanın.

2. Fiziksel Süreç Verisiyle Korele Edin
SCADA sistemleri process değişkenlerini (sıcaklık, basınç, akış) takip eder. Bu metrikleri login denemeleri veya konfigürasyon değişiklikleriyle çapraz referanslamak, kötü niyetli ya da hatalı aksiyonları ortaya çıkarabilir.

SIEM’inizdeki Correlation Rule’lar Şunları Arayabilir:

• Ani setpoint değişikliği ve hemen ardından gelen alarm acknowledgment.
• Kritik ekipman devre dışı bırakılmadan hemen önce oluşturulmuş yetkisiz kullanıcı hesapları.
• IoT sensörlerinde yükselen sıcaklık okumalarıyla eş zamanlı tekrarlayan ağ taramaları.

3. Least Privilege ve Erişim Kontrolü Uygulayın
Modern endüstriyel çözümler genellikle role-based access control (RBAC) içerir. Identity and access management araçlarından gelen loglar, sisteme kimin eriştiğini ve hangi değişiklikleri yaptığını gösterir:

• Tüm login’lerin ve rol yükseltmelerinin kaydedildiğinden emin olun.
• SCADA ve OT konsollarına uzaktan bağlantılar için MFA (multi-factor authentication) etkinleştirin.

4. Firmware Güncellemelerini ve Bütünlüğü İzleyin
Planlanmamış veya yetkisiz firmware güncellemeleri, compromise’ın erken işareti olabilir. Şu logları izleyin:

• Firmware versiyon uyumsuzluğu veya beklenmedik reboot’lar
• Normal bakım penceresi dışında gerçekleşen cihaz reimaging olayları

Pek çok endüstriyel cihaz üreticisi bütünlük kontrolü özellikleri sunar. Bunlardan yararlanın ve ilgili olayları SOC’a forward edin.

5. Özelleşmiş Threat Intelligence Kullanın
ICS/SCADA zafiyetlerine odaklanan threat intelligence feed’leri log analizinizi zenginleştirebilir. Örneğin MITRE ATT&CK for ICS, operasyonel teknolojiyi hedefleyen düşmanların kullandığı teknik ve taktikleri listeler. Bu göstergeleri izleme kurallarınıza dahil etmek tespit kabiliyetinizi artırır.

Gerçek Hayattan Senaryolar

Senaryo 1: Elektrik Şebekesi Manipülasyon Girişimi
Bir saldırgan, bölgesel bir elektrik şebekesini yöneten SCADA workstation’ına erişim sağlar. Log incelemesi şunları gösterir:

1. Harici bir IP’den çok sayıda başarısız RDP login denemesi.
2. Bir admin hesabıyla başarılı login (muhtemelen çalınmış credential ile)
3. Olağandışı saatlerde verilen ani devre kesici (circuit breaker) aç/kapa komutları.

SCADA yazılımı loglarının firewall loglarıyla çapraz kontrolü, inbound bağlantıların normal VPN kanallarını bypass ettiğini ortaya koyar perimeter’da bir compromise olduğunu gösterir. Logların zamanında korele edilmesi, büyük ölçekli bir elektrik kesintisini önler.

Senaryo 2: Ele Geçirilmiş IoT Sensör Ağı
Bir üretim tesisi, bir grup IoT sensöründen düzensiz sıcaklık okumaları alır. Cihaz yönetim platformundan toplanan loglar şunları gösterir:

1. Sensörlere yönelik olağandışı ağ trafiği artışı
2. Cihazın built-in bütünlük kontrolleri tarafından loglanan firmware tampering girişimleri
3. Sensörlerden yetkisiz IP adreslerine giden outbound bağlantılar

İnceleme, sensörlerin bilinen bir zafiyeti barındıran eski firmware sürümüyle çalıştığını ortaya çıkarır. Hızlıca patch uygulanması ve zararlı IP adreslerinin firewall’da bloklanması; daha fazla veri sızıntısını ve potansiyel sistem hasarını engeller.

IoT vs. SCADA/OT – Karşılaştırma

SOC Analistleri İçin Aksiyon Adımları

1. Kritik log kaynaklarını belirleyin: Kritik kontrolörlere (PLC, RTU) ve yüksek etkili IoT cihazlarına öncelik verin.
2. Güvenli log forwarding kurun: Logları ağ sınırları arasında gönderirken şifreli kanallar (TLS, SSH tunnel) kullanın.
3. Baseline profilleri oluşturun: Cihazların normal çalışmasını anlayın ve sapmaları tespit edin. Örneğin bir PLC normalde yalnızca mesai saatlerinde komut alıyorsa, mesai dışı değişikliklerde alert tetikleyin.
4. Ağ ve host tabanlı izlemeyi birleştirin: OT sistemlerine yönelik saldırıların çoğu, IT tarafından lateral movement veya pivot içerir. Analizinize NetFlow, firewall ve endpoint loglarını dahil edin.
5. Üretici rehberliğini takip edin: Siemens, Rockwell Automation, Schneider Electric gibi büyük endüstriyel üreticiler logging ve güvenlik best practice’lerine dair dokümantasyon yayınlar. Patch’leri ve advisory’leri takip edin.

3. Temel İzleme Pratikleri

Etkili log izleme; sağlam süreçlere, doğru yapılandırılmış araçlara ve net hedeflere dayanır. SOC analistleri normal ile şüpheli davranışı ayırmaya, ilgili veriyi korumaya ve mümkün olduğunda otomasyondan yararlanmaya odaklanmalıdır.

3.1. Anomali ve Olay Tespiti (Alert, Correlation)

Anomaly Detection vs. Signature-Based Detection
Anomaly detection, normal operasyonların bir baseline’ını oluşturmayı ve sapmaları flag’lemeyi içerir. Zero-day tehditleri veya olağandışı kullanıcı davranışını tespit etmek için faydalıdır.

Buna karşılık signature-based detection, bilinen IoC’lere dayanır belirli IP adresleri, hash değerleri veya saldırı desenleri.

Modern SOC’ların çoğu hibrit yaklaşım kullanır: hem bilinmeyen tehditleri (anomali) hem de bilinen zararlı aktiviteyi (imza) yakalamak için.

Logların Bağlamsal Analizi
Olayları incelerken tek bir log kaynağına bakmak nadiren yeterlidir. Birden fazla kaynaktan (firewall, EDR, Active Directory) gelen veriyi korele etmek, sofistike saldırıları ortaya çıkarabilir.

Örneğin: Active Directory logunda tekrarlayan authentication failure kayıtları ve eş zamanlı olarak firewall logunda olağandışı outbound bağlantılar görmek brute-force girişiminin ardından gelen data exfiltration’a işaret edebilir.

Alert Threshold’ları ve Fine-Tuning
SOC ekipleri şüpheli aktiviteler için SIEM veya IDS/IPS üzerinde alert kuralları devreye alır. Bu eşikleri dengelemek kritiktir:

• Çok sıkı: SOC’u false positive’lerle boğar, alert fatigue yaratır ve gerçek tehditlerin kaçırılmasına yol açar
• Çok gevşek: Ciddi güvenlik olaylarının fark edilmeden geçmesine, müdahale ve remediation’ın gecikmesine neden olur

Doğru dengeyi bulmak; geçmiş veriye, ortama özgü koşullara ve bilinen iş süreçlerine dayanan iteratif bir tuning gerektirir.

Gerçek Hayattan Örnek
Bir kullanıcı hesabının olağandışı saatlerde bir dosya sunucusundaki yüzlerce dosyaya erişmeye başladığını düşünün. Anomaly detection kuralları, bu davranış kullanıcının normal kullanım deseninden saptığı için flag’leyebilir. Aynı anda signature-based bir kural, bu dosyalardan bazılarının bilinen zararlı toolkit’lerle (örneğin Mimikatz) eşleştiğini tespit edebilir.

İki alert’in korele edilmesi, SOC analistlerinin potansiyel bir hesap ele geçirilmesi ve veri hırsızlığı olayını çok daha hızlı tanımlamasını sağlar.

Örnek SIEM Sorgusu (Splunk):

index=windows_logs sourcetype=WinEventLog:Security
EventCode=4625 OR EventCode=4624
| stats count by Account_Name, EventCode
| where count > 20

Bu sorgu başarılı (4624) veya başarısız (4625) logon’ları kontrol eder ve belirli bir eşiğin üzerinde tekrar eden hesapları arar brute-force veya lateral movement girişimine işaret edebilir.

Ödeme Kuruluşu Bağlamı – İki Farklı Tespit Katmanı
Ödeme kuruluşunda anomali tespiti, birbirinden ayrı iki katmanda işler ve ikisi de zorunludur:

• Güvenlik tespiti (SOC / SIEM): Bu yazının ana konusu yetkisiz erişim, privilege escalation, lateral movement, log tampering. Kaynak: sistem/ağ/uygulama logları.
• Fraud/dolandırıcılık tespiti (anti-fraud / MASAK): İşlem katmanında çalışır anormal tutar, yeni alıcıya yüksek transfer, mesai dışı işlem deseni, hız (velocity) kuralları, cihaz parmak izi. Kaynak: transaction logları. Şüpheli İşlem Bildirimi (ŞİB) üretimi buraya bağlıdır.

Bu ikisi ayrı sistemlerdir ama korelasyonları en değerli sinyali üretir. Örneğin: bir kullanıcının hesabında SIEM tarafında impossible travel tespit edilir (güvenlik katmanı) ve eş zamanlı olarak anti-fraud aynı hesaptan olağandışı bir para transferi görür (fraud katmanı) → yüksek olasılıkla hesap ele geçirilmiş (Account Takeover). Tek başına her ikisi “orta” öncelikliyken, korelasyon P1’dir.

Günlük İnceleme Zorunluluğu (PCI DSS 10.4.1)
Ödeme kuruluşunda alert threshold’larını dengelemek yalnızca bir verimlilik meselesi değildir. PCI DSS 10.4.1 kart verisi ortamındaki (CDE) kritik sistemlerin, güvenlik olaylarının ve güvenlik fonksiyonu sunucularının (FW, IDS/IPS, WAF, AAA) günlük incelenmesini zorunlu kılar. Üstelik 10.4.1.1 (31 Mart 2025’ten itibaren mandatory) bu incelemenin otomatik bir mekanizma ile yapılmasını şart koşar yani SIEM fiilen zorunludur. Manuel “her sabah loglara bakıyoruz” yaklaşımı denetimde doğrudan başarısızlıktır.

Alert Önceliklendirme – Ödeme Kuruluşu

Bu yazının teknik bölümlerinde (Bölüm 4) her katman için P1/P2/P3 önceliklendirmeli somut SIEM korelasyon kuralları yer alıyor.

3.2. Log Retention ve Log Güvenliği

Retention konusu, rehberlerde genellikle “regülasyonlara uygun süre saklayın” gibi bir cümleyle geçiştirilir. Oysa pratikte denetimde en çok bulgu çıkan alan tam olarak burasıdır. Bu yüzden bu bölümü, uyumluluk çerçevelerinin gerçekte ne dediğini göstererek ele alalım.

PCI DSS v4.0.1 – Requirement 10

Retention (10.5.1)

Ne Loglanacak (10.2.1.x)

Her Kayıtta Olması Gerekenler (10.2.2)
Kullanıcı kimliği · Olay tipi · Tarih-saat · Başarı/başarısızlık · Olayın kaynağı · Etkilenen kaynak/nesne kimliği

Log Güvenliği (10.3)

İnceleme (10.4)

• 10.4.1 – Şunlar günlük incelenecek: güvenlik olayları, CHD/SAD işleyen sistemlerin logları, kritik sistemler, güvenlik fonksiyonu sunucuları (FW, IDS/IPS, AAA, WAF)
• 10.4.1.1 – Otomatik mekanizma zorunlu. (v4.0 ile gelen yeni madde; 31 Mart 2025’ten itibaren mandatory.) Bu, SIEM’i fiilen zorunlu kılar.
• 10.4.2 – Diğer tüm sistem bileşenleri risk analizine göre periyodik incelenecek.
• 10.4.3 – Tespit edilen anomaliler yanıtlanacak.

Diğer Kritik Maddeler

• 10.6 – Zaman senkronizasyonu (NTP); kritik sistemlerde tutarlı ve korunmuş zaman kaynağı.
• 10.7 – Kritik güvenlik kontrol arızası tespiti. Log/SIEM/FIM/AV/segmentasyon kontrolleri devre dışı kalırsa derhal tespit edilip müdahale edilecek (v4.0’da tüm kuruluşlar için genişletildi)

HIPAA (Security Rule)

Not: HIPAA, audit log’lar için açık bir süre belirtmez. 6 yıllık dokümantasyon kuralı, sektör yorumu ve OCR beklentisi doğrultusunda pratikte audit log’lara da uygulanır. İnceleme sıklığı da “regularly” der kurumun risk analizine bırakılmıştır.

ISO/IEC 27001:2022 (Annex A)

Retention: ISO 27001 sayı vermez. Süre; yasal/regülatif gereklilikler + risk değerlendirmesi + iş gereksinimi ile belirlenir ve kayıt saklama politikasında dokümante edilir (A.5.31, A.5.33).

Üç Çerçevenin Karşılaştırması

🔴 Türkiye’de faaliyet gösteren ödeme kuruluşları için bu tablo yalnızca zeminin bir kısmıdır. Yukarıdaki uluslararası çerçevelerin üzerine 6493 sayılı Kanun ve TCMB Bilgi Sistemleri Tebliği (10 yıl), 5651 (2 yıl + NEZD zaman damgası), MASAK/5549 (8 yıl) ve KVKK (min. 2 yıl) eklenir. Bağlayıcı süre daima en uzunudur yani ödeme kuruluşu için tasarım hedefi 10 yıldır ve veri Türkiye’de tutulmalıdır. Bu yükümlülüklerin tam matrisini, tiered retention mimarisini ve silme yasağını Bölüm 4‘te ele alıyorum.

Log Depolama ve Bütünlük

Temel Değerlendirmeler

• Merkezileştirme: Log, üretildiği kaynakta bırakılamaz. Tek bir repository (SIEM veya log management platformu) arama, korelasyon ve yedeklemeyi basitleştirir.
• Redundancy: Birden fazla depolama konumu veya clustering, donanım arızasında bile logların erişilebilir kalmasını sağlar
• Şifreleme: At-rest (AES-256, disk seviyesi) ve in-transit (TLS 1.2+, log forwarding)
• Erişim Kontrolü: RBAC; log okuyan ≠ log yöneten ≠ sistem admini (Separation of Duties)

Bütünlük (Integrity) Mekanizmaları

1. Hashing: Log dosyaları için SHA-256 hash üretmek ve bunları ayrı saklamak, yetkisiz değişiklikleri tespit etmeyi sağlar.
2. Hash-chain / Merkle tree: Her log batch’inin hash’i bir öncekine zincirlenir tamper-evident yapı.
3. WORM (Write-Once-Read-Many) Storage: Logların yazılabildiği ancak sonradan değiştirilemediği depolama.
4. Digital signature: Log paketleri kurum sertifikasıyla imzalanır.
5. FIM (File Integrity Monitoring): Tripwire, Wazuh/OSSEC, QRadar FIM  PCI DSS 10.3.4’ün doğrudan karşılığı.
6. Audit Trail: Log repository’sine kimin, ne zaman eriştiği ve hangi değişiklikleri yaptığı.

Immutable / WORM Depolama Seçenekleri

Orijinal rehberdeki S3 + KMS + IAM örneği doğru ama tek seçenek değil. Immutability + encryption + access control üçlüsünü sağlayan alternatifler aşağıda. Ancak Türkiye’de faaliyet gösteren bir ödeme kuruluşu için bu listeyi okumadan önce şunu bilmek gerekir:

🔴 ÖNEMLİ – Ödeme kuruluşları için veri lokasyonu kısıtı: TCMB Bilgi Sistemleri Tebliği gereği ödeme ve elektronik para kuruluşlarının birincil ve ikincil sistemleri Türkiye’de bulunmak zorundadır. Bu nedenle aşağıdaki yurt dışı konumlu hyperscaler / bulut object storage çözümleri (AWS S3 & Glacier, Azure Blob, Google Cloud Storage, Wasabi, Backblaze B2) teknik olarak mükemmel WORM yetenekleri sunsalar da ödeme kuruluşunun audit log arşivi, CDE verisi ve yedeklerinde kullanılamaz. Bunlar burada teknik referans olarak, kavramı (Object Lock, retention lock, Compliance Mode) anlatmak ve ödeme kuruluşu dışındaki kurumlar için yer alıyor.
Ödeme kuruluşu için geçerli seçenekler: on-premises WORM (Ceph / NetApp StorageGRID / Cloudian / SeaweedFS gibi S3-uyumlu çözümler, NetApp SnapLock, ExaGrid RTL, LTO WORM tape) veya yurt içi datacenter / bulut (Bulutistan, İş Net, İnnova, Superonline, DgpaysIT, DT İletişim gibi ödeme kuruluşlarına altyapı desteği verebilen sağlayıcılar) hepsi Türkiye sınırları içinde. S3-uyumlu on-prem alternatiflerin ayrıntılı karşılaştırması aşağıda.

Bulut – Object Storage ❌ (Yurt Dışı Bölgeler Ödeme Kuruluşunda KULLANILAMAZ; Teknik Referans)

⚠️ Kritik teknik ayrım (kavramsal olarak her yerde geçerli): Object Lock’ta Compliance Mode seçilmelidir, Governance Mode değil. Governance Mode’da s3:BypassGovernanceRetention yetkisi olan biri silebilir → denetimde bulgu. Compliance Mode’da root hesap bile silemez. Aynı ayrım MinIO Object Lock ve NetApp SnapLock için de geçerlidir (Compliance vs. Enterprise/Governance) ödeme kuruluşunda daima Compliance seçilir.

On-Premises / Hybrid ✅ (Ödeme Kuruluşu için Geçerli – Türkiye’de Konumlu)

• 🔴 S3-uyumlu on-prem object storage (WORM/Object Lock) – ELK/Splunk/QRadar arşivi doğrudan S3 API ile konuştuğu için ödeme kuruluşunda en pratik on-prem tercih; veri Türkiye’de kalır. Bu kategoride birden fazla seçenek var (aşağıda ayrı bir başlıkta karşılaştırdım) – MinIO tek seçenek değildir ve 2026 itibarıyla tek başına önerilmez (lisans/bakım durumu değişti, bkz. aşağıdaki uyarı)
• NetApp SnapLock (Compliance mode) – WORM volume, ComplianceClock ile retention; NAS üzerinde native immutability
• Dell EMC PowerProtect DD (Data Domain) Retention Lock – Compliance mode
• ExaGrid Retention Time-Lock – Non-network-facing tier; ransomware’e karşı air-gap benzeri koruma
• Veeam Hardened Repository – Linux XFS + immutability flag ( mantığı), tek seferlik yazım
• IBM Spectrum Protect + LTO WORM tape – Fiziksel WORM kartuşlar, air-gapped arşiv (10 yıllık regülatif arşiv için ideal)

Yurt İçi Bulut ✅ (TCMB Veri Lokasyonu ile Uyumlu)

• Bulutistan, İş Net, İnnova, Superonline, DgpaysIT, DT İletişim ödeme kuruluşlarına Türkiye’de konumlu datacenter / bulut / yedekleme altyapısı sağlayabilen yerli firmalar. Seçerken immutability (WORM) desteği ve PCI DSS uyum belgesi (AoC) mutlaka sorulmalıdır her yurt içi sağlayıcı Object Lock muadili sunmaz.

SIEM / Log Platform Katmanı

• IBM QRadar – Data Node + offline archive; event/flow retention bucket’ları, hash-based integrity
• Elastic (ELK) – Searchable Snapshots + Frozen Tier → on-prem S3-uyumlu object storage (Ceph/StorageGRID/SeaweedFS vb.) backend; ILM ile hot/warm/cold/frozen
• Splunk – SmartStore (S2) + Frozen bucket → on-prem S3-uyumlu object storage / NFS
• Graylog Archives → S3-uyumlu object storage / NFS

🔴 Dikkat: ELK/Splunk dokümantasyonu snapshot/arşiv hedefi olarak varsayılan biçimde AWS S3‘ü örnekler. Ödeme kuruluşunda bu hedef yurt içindeki S3-uyumlu bir object storage (Ceph, NetApp StorageGRID, SeaweedFS, ticari appliance veya yurt içi bulut) olarak yapılandırılmalıdır. S3 API uyumlu olduğu için konfigürasyon farkı yalnızca endpoint adresidir, ancak regülatif fark çok büyüktür.

Erişim Kontrolü Katmanı

• HashiCorp Vault – Transit engine ile encryption-as-a-service, dynamic secrets
• CyberArk PAM – Arşiv/backup sistemlerine privileged erişimin session recording ile kontrolü
• Organizasyon seviyesi politika – Bucket delete ve policy-change işlemlerinin merkezi olarak engellenmesi (S3-uyumlu object storage’da IAM policy; bulutta SCP/Azure Policy/Org Policy)
• MFA Delete – Versioned object silme için MFA zorunluluğu
• Separation of Duties – Log yazan hesap ≠ log silen hesap ≠ log okuyan hesap

S3-Uyumlu On-Prem WORM – MinIO Alternatifleri

Rehber boyunca S3-uyumlu on-prem WORM için sık sık MinIO örneğini verdim; çünkü S3 API uyumu sayesinde ELK/Splunk/QRadar arşiv entegrasyonu doğrudan çalışır. Ancak MinIO tek seçenek değildir ve önemli bir gelişme yaşandı:

⚠️ MinIO Community Edition durumu (2026): MinIO’nun açık kaynak (Community) sürümünün GitHub deposu Şubat 2026’da arşivlendi; artık aktif geliştirme, güvenlik yaması ve hazır binary yayınlanmıyor. Ticari AIStor ürünü devam ediyor ama ayrı lisans gerektiriyor. Ödeme kuruluşu bağlamında yamasız/bakımsız bir depolama katmanı, denetimde ciddi bir bulgu kaynağıdır (PCI DSS 6.3.3 desteklenen/güncel yazılım). Bu nedenle 2026 itibarıyla yeni kurulumlarda MinIO Community’yi tek başına önermiyorum; ya ticari destekli bir ürün ya da aktif bakımı olan bir alternatif seçilmelidir.

Ödeme kuruluşunun Türkiye’de konumlandırabileceği S3-uyumlu WORM seçenekleri (hepsi Object Lock / Compliance-benzeri immutability sunar):

Açık Kaynak / Yazılım-Tanımlı (Kendi Donanımınızda, Türkiye’de)

Ticari Appliance / Yazılım (Destekli – Kurumsal Ödeme Kuruluşu için Tercih Edilir)

Yurt İçi Datacenter / Bulut (Türkiye’de Konumlu)
Aşağıdaki firmalar ödeme kuruluşlarına Türkiye sınırları içinde datacenter, bulut ve/veya yedekleme altyapısı sağlayabilir. Bu bir sıralama ya da öneri değildir; her sağlayıcının S3 / Object Lock / immutability yeteneği projeden projeye değişir ve mutlaka teyit edilmelidir.

🔴 Yurt içi sağlayıcı seçerken kritik iki soru : (1) Object Lock / immutability Compliance modda destekleniyor mu? Her yerli sağlayıcı S3 API sunar ama hepsi WORM/Compliance modu vermez; “versioning var” ≠ “Object Lock var”. (2) PCI DSS uyum kanıtı (AoC / sorumluluk paylaşım matrisi) var mı? Ödeme kuruluşu servis sağlayıcının PCI kapsamını dokümante etmek zorundadır (PCI DSS 12.8). Bu iki madde sözleşmede açıkça yer almalıdır.

Karar Rehberi (Ödeme Kuruluşu İçin):

• Kurumsal ölçek + tam kontrol istiyorsanız: Ceph (destekli dağıtım) veya ticari appliance (NetApp StorageGRID / Cloudian / Dell ObjectScale) on-prem, Türkiye’de
• Bütçe kısıtlı + orta ölçek: SeaweedFS veya QNAP QuObjects (kendi DC’nizde)
• Kendi DC’niz yoksa: Yurt içi datacenter / bulut sağlayıcısı (Bulutistan, İş Net, İnnova, Superonline, DgpaysIT, DT İletişim) ama Object Lock + AoC teyidiyle
• MinIO’da ısrar edilecekse: yalnızca ticari AIStor (destekli) sürümü; Community değil.

3.3. Destekleyici Araçlar (SIEM, SOAR)

SIEM (Security Information and Event Management)
SIEM çözümleri; farklı kaynaklardan gelen logları toplar, parse eder ve normalize eder. Analistlerin neredeyse gerçek zamanlı olarak arama yapmasını, korelasyon kurmasını ve alert üretmesini sağlar.

Yaygın SIEM platformları: Splunk Enterprise Security, IBM QRadar, Microsoft Sentinel.

Temel Özellikler:

• Log Aggregation ve Normalization: Olayları ortak bir formata standartlaştırır.
• Correlation Rules: Birden fazla göstergenin belirli bir sırayla oluşması durumunda alert üretir.
• Dashboarding ve Reporting: Güvenlik duruşunu izlemek ve yönetime metrik sunmak için görsel arayüzler sağlar.

SOAR (Security Orchestration, Automation, and Response)
SOAR platformları, analistlerin aksi halde manuel yapacağı görevleri otomatikleştirir. Örnekler: Palo Alto Networks Cortex XSOAR (eski adıyla Demisto) ve Splunk Phantom.

Bu Araçlar Şunları Yapacak Şekilde Yapılandırılabilir:

1. Alert Enrichment: Threat intelligence kaynaklarından otomatik olarak host veya ağ bilgisi toplamak.
2. Containment: Ele geçirilmiş bir kullanıcı hesabını devre dışı bırakmak veya zararlı bir endpoint’i izole etmek.
3. Response Orchestration: Birden fazla güvenlik ve IT sistemini içeren workflow’ları tetiklemek.

Otomasyon ve Playbook’lar
SOAR’da standart yaklaşım, belirli olaylara nasıl yanıt verileceğini tanımlayan otomatik workflow’lar yani playbook‘lar geliştirmektir.

Örneğin bir alert, bir sunucuda şüpheli bir PowerShell script’inin çalıştığını gösteriyorsa; playbook şu adımları izleyebilir:

1. İlgili endpoint loglarını çek.
2. Script hash’ini bir threat intelligence veritabanıyla karşılaştır.
3. Hash zararlıysa host’u karantinaya al.
4. Incident management sisteminde bir ticket oluştur.

SIEM vs. SOAR – Karşılaştırma

Pek çok durumda SOC’lar kapsamlı bir kapsama için SIEM ve SOAR’ı birlikte entegre eder: SIEM büyük ölçekli ingestion ve korelasyonu üstlenirken, SOAR platformu inceleme ve yanıt adımlarını otomatikleştirir.

Bu entegrasyon, MTTD (Mean Time to Detect) ve MTTR (Mean Time to Respond) sürelerini düşürerek kurumun güvenlik duruşunu ciddi şekilde güçlendirir.

Ödeme Kuruluşu Bağlamı – SIEM ve SOAR Kısıtları
Ödeme kuruluşunda SIEM ve SOAR, “olsa iyi olur” araçlar değildir; regülatif zorunlulukların taşıyıcısıdır.

Ancak Birkaç Kritik Kısıt Vardır:

• Veri lokasyonu (TCMB): SIEM’in kendisi ve log arşivi Türkiye’de bulunmalıdır. Bulut SIEM (Microsoft Sentinel gibi) kullanılıyorsa workspace Türkiye/AB bölgesinde olmalı ve hukuki değerlendirme yapılmalıdır. Yaygın yurt içi tercih: on-prem IBM QRadar veya Elastic (ELK).
• 10.4.1.1 = SIEM zorunlu: Otomatik korelasyon şartı, SIEM’i pratikte mecburi kılar.
• Log bütünlüğü ve NEZD: SIEM’den arşive giden günlük log paketleri SHA-256 hash-chain ve Nitelikli Elektronik Zaman Damgası ile mühürlenmelidir (5651).
• SOAR otomatik yanıt sınırları: SOAR güçlüdür ama ödeme kuruluşunda her aksiyon eşit değildir:

Her otomatik SOAR aksiyonu audit loglanmalıdır (is_automated: true + human_reviewed alanlarıyla). Denetçi “Otomatik bir sistem üretim ödeme sunucusunu izole etti. Kim gözden geçirdi?” diye sorar; izlenebilirlik zinciri kopmamalıdır. SOAR playbook’larının ödeme kuruluşuna özel detaylı kurgusunu Bölüm 4.75‘te ele alıyorum.

Bu yazıda log izlemenin temellerini; log, anomali ve fraud tespitini, retention ve WORM depolama yaklaşımlarını ele aldık. Log İzleme Temelleri – Bölüm 1 böylece tamamlandı.

Serinin bir sonraki yazısında “Ödeme Kuruluşlarında Log Yönetimi: Mevzuat, Retention ve Silme Yasağı” konularına giriyoruz: PCI DSS, HIPAA ve Türkiye mevzuatının (6493, TCMB, 5651, MASAK, KVKK) log yönetimi üzerindeki birleşik etkisi.

Başka bir yazıda görüşmek dileğiyle…