Merhaba

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

1. Log İzleme Temelleri
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 (Bu Yazı)

Ö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.

Serinin son bölümü. Önceki yedi yazıda log kaynaklarını tek tek ele aldık. Burada hepsini birleştiriyoruz: XDR (Extended Detection and Response). MITRE ATT&CK eşlemeli korelasyon kuralları, XDR→SIEM mimarisi, threat intelligence, SOAR otomatik yanıt kısıtları ve çok aşamalı saldırı zincirinin tek bir storyline olarak yakalanması.

4.69. XDR / EDR – Katmanlar ve Regülatif Karşılık

Buraya kadar log kaynaklarını tek tek ele aldık: Windows, Linux, uygulama, veritabanı. XDR (Extended Detection and Response), bunların hepsini tek bir korelasyon katmanında birleştiren üst yapıdır. Değeri de tam olarak buradadır tek başına bir AV alert’i bağlamsızdır; XDR, farklı kaynaklardaki olayları tek bir saldırı zinciri olarak görür.

🔴 Kritik ayrım: XDR’ın ham telemetrisi (her process, her DNS) 90 gün – 1 yıl tutulur hacim çok yüksektir. Ama detection/response olayları ve audit kayıtları 10 yıl saklanmalıdır (6493). İkisini karıştırmayın; maliyet ve uyum dengesi tam burada kurulur.

4.70. Referans Ürünler – Ödeme Kuruluşu Uyumluluk Notu

Veri Lokasyonu – Kritik Karar

🔴 TCMB Bilgi Sistemleri Tebliği gereği ödeme kuruluşunun birincil ve ikincil sistemleri Türkiye’de olmalıdır. Bulut-native XDR (CrowdStrike, MS Defender) telemetriyi yurt dışında işleyebilir.

Değerlendirme Yaklaşımı:

• On-prem/hybrid mümkün olanlar (Trend Micro, Cortex on-prem, FortiEDR) → veri lokasyonu açısından daha güvenli
• Bulut zorunlu olanlar → TCMB’den görüş / region seçimi (TR yoksa AB) + hukuki değerlendirme + risk kabul dokümanı
• Detection telemetrisi bulutta işlense bile, ham log + audit kaydı yurt içi SIEM’de (QRadar/ELK) merkezileştirilmeli

4.71. MITRE ATT&CK Eşlemeli XDR Tespit Kuralları

XDR’ın değeri korelasyondur. Aşağıdaki kurallar çok kaynağı birleştirir.

🔴 P1 – Otomatik Response Tetikler

Kural X1 – Ele Geçirilmiş Kimlik: Impossible Travel + Ayrıcalık

  [Identity] Entra/AD login SUCCESS from country_A
  FOLLOWED BY login SUCCESS from country_B
  WITHIN < (mesafe / 900 km/h) saat
  AND followed by ROLE_GRANTED veya MFA_disabled
  → RESPONSE: Hesabı devre dışı bırak (revoke session) + SOC
  → MITRE: T1078 (Valid Accounts) + T1098

Kural X2 – Ransomware Davranışı

  [Endpoint] process spawns >50 file_write in <60sn
  AND file_extension_change (.encrypted/.locked)
  AND (vssadmin delete shadows OR wbadmin delete OR bcdedit)
  → RESPONSE: Host izole et + snapshot al + SOC
  → MITRE: T1486 (Data Encrypted for Impact) + T1490
  → 🔴 Ödeme kuruluşu: iş sürekliliği planı tetiklenir

Kural X3 – Living-off-the-Land (LOLBin) Zinciri

  [Endpoint] parent = (winword.exe|excel.exe|outlook.exe|mshta.exe)
  AND child = (powershell.exe|cmd.exe|wscript.exe|rundll32.exe|regsvr32.exe)
  AND child_cmdline MATCHES ("-enc"|"-w hidden"|"DownloadString"|"IEX"|
                             "FromBase64"|"bypass"|"http")
  → RESPONSE: Process sonlandır + host izole + parent dosyayı karantina
  → MITRE: T1059.001 (PowerShell) + T1566 (Phishing)

Kural X4 – Credential Dumping (LSASS)

  [Endpoint] target_process = lsass.exe
  AND access_mask IN (0x1010, 0x1410, 0x143a)   # PROCESS_VM_READ
  AND source_process NOT IN (allowlist: MsMpEng, wininit, csrss)
  OR cmdline MATCHES ("sekurlsa"|"comsvcs.*MiniDump"|"procdump.*lsass")
  → RESPONSE: Host izole + etkilenen hesapların parolasını sıfırla
  → MITRE: T1003.001 (LSASS Memory)

Kural X5 – Phishing → Endpoint → Identity Zinciri (Multi-stage)

  [Email] Defender O365: malicious attachment delivered to user_X
  FOLLOWED BY [Endpoint] user_X host: suspicious process execution
  FOLLOWED BY [Identity] user_X: anomalous login OR OAuth consent grant
  WITHIN 2 saat
  → RESPONSE: Kullanıcı oturumlarını iptal + host izole + e-posta geri çek (ZAP)
  → MITRE: T1566 → T1204 → T1078
  → 🔴 Bu XDR'ın ANA DEĞER ÖNERMESİDİR - üç ayrı sistem tek olayda birleşir

Kural X6 – Kart Verisi Ortamına (CDE) Lateral Movement

  [Network/Endpoint] source NOT IN (CDE_authorized_hosts)
  AND destination IN (CDE_segment: payment-db, payment-app)
  AND (SMB/RDP/WMI/PSExec/WinRM)
  → RESPONSE: Bağlantıyı FortiGate'te blokla + host izole
  → MITRE: T1021 (Remote Services) + T1210
  → 🔴 PCI DSS 1.3 segmentasyon ihlali - CDE'ye yetkisiz erişim

Kural X7 – EDR / Güvenlik Aracı Devre Dışı Bırakma

  [Endpoint] service_stop OR driver_unload (Defender/CrowdStrike/Cortex/FortiEDR)
  OR "Set-MpPreference -DisableRealtimeMonitoring $true"
  OR registry: DisableAntiSpyware = 1
  OR "fltmc unload" (EDR minifilter)
  → RESPONSE: Host izole + P1 (PCI DSS 10.7 - kritik kontrol arızası)
  → MITRE: T1562.001 (Impair Defenses)

🟠 P2 – Alert + İnceleme

Kural X8 – Threat Intel Eşleşmesi

  [Any] file_hash IN (VirusTotal_malicious, OTX_indicator)
  OR domain IN (threat_feed) OR dst_ip IN (C2_list)
  → Enrichment: VT skoru, OTX pulse, ilk görülme tarihi
  → Otomatik: bilinen kötü → P1'e yükselt

Kural X9 – Beaconing (C2 Communication)

  [Network] periyodik outbound bağlantı (düşük jitter)
  AND aynı dst_ip/domain'e düzenli aralık (örn. her 60±5sn)
  AND user-agent anormal OR domain DGA-benzeri (entropi yüksek)
  → MITRE: T1071 + T1568.002 (DGA)

Kural X11 – Veri Sızıntısı (DLP + EDR korelasyon)

  [Endpoint] büyük dosya kopyalama → USB / cloud upload
  AND [DLP] hassas veri sınıflandırması (CHD/PII)
  AND [Network] anormal outbound hacim
  → MITRE: T1567 + T1052 (USB)
  → 🔴 KVKK ihlal bildirimi (72 saat) değerlendir

🟡 P3 – Threat Hunting / Baseline

• Nadir process (ortamda ilk kez görülen exe) → prevalence < %1
• Anormal parent-child ilişkileri (baseline dışı)
• Beklenmeyen coğrafyadan yönetici erişimi
• Signed-but-suspicious (geçerli imza ama kötü davranış)

4.72. XDR → SIEM Merkezileştirme Mimarisi

XDR kendi konsolunda güçlüdür, ancak regülatif retention ve çapraz kaynak korelasyonu için SIEM’e (QRadar/ELK) akmalıdır.

┌─── XDR/EDR Katmanları ──────────────────────────────────────┐
│  Endpoint (FortiEDR/Trend/Cortex/Defender)                  │
│  Identity (Entra ID / AD / CyberArk)                        │
│  Email (Defender O365 / Trend / FortiMail)                  │
│  Network (FortiGate / NDR sensör)                           │
│  Cloud/Container (RKE2 audit / Defender for Cloud)          │
└──────────────┬──────────────────────────────────────────────┘
               │ ① XDR native korelasyon (real-time response)
               │    → otomatik playbook (izole/disable/blok)
               ▼
┌─── XDR Konsol (real-time detection & response) ─────────────┐
│  ML analytics · storyline · attack graph                    │
│  Otomatik response: contain, revoke, block                  │
└──────────────┬──────────────────────────────────────────────┘
               │ ② JSON/CEF/Syslog · API pull veya push (TLS)
               ▼
┌─── SIEM: QRadar / ELK / Splunk ─────────────────────────────┐
│  ③ ÇAPRAZ KAYNAK KORELASYON                                 │
│     XDR + FortiGate + AD + PostgreSQL + Exchange + App      │
│  ④ Threat Intel enrichment (VT / OTX / MISP / USOM)        │
│  ⑤ SOC tek görünüm (single pane of glass)                  │
│  ⑥ Uzun vadeli retention (regülatif)                       │
└──────────────┬──────────────────────────────────────────────┘
        ┌──────┴──────┐
        ▼             ▼
   ┌─────────┐   ┌──────────────────┐
   │ HOT     │   │ SOAR Playbook    │
   │ 0-12 ay │   │ (yanıt orkestr.) │
   └────┬────┘   └──────────────────┘
        │ hash-chain + NEZD
        ▼
   ┌─────────────────────────────────┐
   │ 🔒 WORM Arşiv (yurt içi, 10 yıl)│
   │ Detection/audit olayları        │
   └─────────────────────────────────┘

Neden XDR’a Rağmen SIEM?

Sonuç: XDR ve SIEM rakip değil, tamamlayıcıdır. XDR = derin endpoint görünürlüğü + hızlı response. SIEM = geniş korelasyon + regülatif retention. Ödeme kuruluşunda ikisi de gerekir.

4.73. Log Formatı Standardizasyonu (ECS)

Farklı XDR/EDR ürünleri farklı format üretir; SIEM’de korelasyon için normalize edilmelidir.

Hedef Şema – ECS (Elastic Common Schema):

{
  "@timestamp": "2026-07-13T09:14:22.847+03:00",
  "event": {
    "kind": "alert",
    "category": ["intrusion_detection", "process"],
    "action": "credential_dumping_detected",
    "severity": 90,
    "provider": "FortiEDR"
  },
  "host": { "name": "pay-app-01", "ip": "10.20.10.15", "os": {"type":"linux"} },
  "user": { "name": "app_user", "id": "u-10042", "domain": "corp" },
  "process": {
    "name": "suspicious.exe",
    "hash": { "sha256": "9c81..." },
    "parent": { "name": "winword.exe" }
  },
  "destination": { "ip": "203.0.113.77", "domain": "evil[.]com" },
  "threat": {
    "framework": "MITRE ATT&CK",
    "technique": { "id": "T1003.001", "name": "LSASS Memory" },
    "tactic": { "id": "TA0006", "name": "Credential Access" }
  },
  "enrichment": {
    "virustotal": { "malicious": 47, "total": 72 },
    "otx": { "pulse_count": 12 }
  },
  "response": {
    "action_taken": "host_isolated",
    "playbook_id": "PB-CONTAIN-001",
    "correlation_id": "corr-7f3a91e2"
  },
  "integrity": { "prev_hash": "a3f2...", "hash": "9c81..." }
}

4.74. Threat Intelligence Entegrasyonu

Detection olaylarını feed’lerle zenginleştirmek doğrulamayı hızlandırır, false positive’i azaltır.

🔴 Kritik uyarı: VirusTotal public API’ye dosya yüklemek, hassas/CHD içeren dosyayı üçüncü tarafa sızdırabilir. Ödeme kuruluşunda sadece hash sorgusu yapılmalı; dosya analizi gerekiyorsa VT Enterprise (private) veya on-prem sandbox (Cuckoo/CAPE) kullanılmalı.

Enrichment Örneği – Sadece Hash Sorgusu (Dosya Yükleme Yok):

# QRadar/ELK enrichment - sadece HASH sorgusu (dosya YÜKLEMESİ YOK)
def enrich_detection(event):
    ioc = event.get("process.hash.sha256")
    if ioc:
        vt = vt_hash_lookup(ioc)          # GET /api/v3/files/{hash} - upload YOK
        if vt and vt["malicious"] > 40:
            event["severity"] = 90
            event["auto_response"] = "isolate_host"
            trigger_soar_playbook("PB-CONTAIN-001", event["host.name"])
    domain = event.get("destination.domain")
    if domain:
        event["otx"]  = otx_indicator(domain)
        event["usom"] = usom_blocklist_check(domain)   # ulusal liste
    return event

4.75. Adaptive Response (SOAR) – Ödeme Kuruluşu Kısıtları

XDR otomatik response güçlüdür, ama ödeme kuruluşunda her aksiyon loglanmalı ve bazıları onaya bağlı olmalıdır.

Her Otomatik Aksiyon AUDIT Loglanmalı (10 Yıl):

{
  "timestamp": "2026-07-13T09:15:00.112+03:00",
  "log_type": "AUDIT",
  "event_action": "AUTO_RESPONSE_HOST_ISOLATED",
  "outcome": "SUCCESS",
  "actor": { "user_id": "SYSTEM_SOAR", "playbook_id": "PB-CONTAIN-001",
             "is_automated": true, "triggered_by_rule": "X4_LSASS_Dump" },
  "target": { "resource_type": "HOST", "resource_id": "pay-app-01",
              "isolation_method": "network_contain" },
  "context": { "correlation_id": "corr-7f3a91e2", "incident_id": "INC-2026-0891",
               "reversible": true, "human_reviewed": false },
  "integrity": { "hash": "9c81..." }
}

🔴 is_automated: true + human_reviewed alanları kritiktir. Denetçi “Otomatik bir sistem üretim ödeme sunucusunu izole etti kim gözden geçirdi?” diye sorar. İzlenebilirlik zinciri kopmamalıdır.

4.76. XDR ile Bütünsel Görünüm, Kanıt Listesi ve Sık Bulgular

Tüm Log Kaynakları XDR/SIEM Altında Birleşir:

XDR’ın vaadi tam da budur: Bir saldırgan phishing e-postasıyla girer (Email), endpoint’te LSASS dump yapar (Endpoint), çalınan kimlikle Domain Admin olur (Identity/Windows 4728), CDE’ye lateral hareket eder (Network), PostgreSQL’den toplu kart verisi çeker (Database), sonra izlerini siler (1102/auditd). Tek tek her olay düşük öncelikli görünebilir; XDR bunları tek bir saldırı zinciri (storyline) olarak birleştirir ve otomatik yanıt verir.

Tüm Katmanların Bir Arada Olduğu Somut Saldırı Zinciri:

1. [WAF]        SQL Injection denemesi bloklandı        → sid 942100
2. [WAF]        30 dk sonra farklı payload GEÇTİ        → bypass!
3. [IPS]        Web sunucudan anormal outbound          → T1190
4. [EDR]        web-01'de reverse shell process         → T1059
5. [auditd]     web-01'de useradd + wheel grubuna ekle  → T1136
6. [FortiGate]  web-01 → CDE segmentine SMB (445)       → T1021 (LATERAL!)
7. [Windows]    4728 - Domain Admins'e üye eklendi      → T1098
8. [pgaudit]    payment.cardholder_data toplu SELECT    → T1213
9. [FortiGate]  CDE → internete DNS tunneling           → T1071.004
10.[auditd]     /var/log/audit/audit.log silme girişimi → T1070 🔴

Her adım tek başına “orta” öncelikli görünür. XDR/SIEM bunları tek bir saldırı zinciri olarak birleştirir. 6. adımda (CDE’ye lateral) otomatik response tetiklenmeliydi; 10. adımda silme yasağı (chattr +a , auditd -e 2) girişimi zaten engellemiş olmalı. Ağ katmanının bu zincirdeki rolü kritiktir: giriş noktası tespiti (WAF/IPS), lateral movement görünürlüğü (doğu-batı trafik en kritik), exfiltration tespiti (kuzey-güney çıkış) ve otomatik response noktası (FortiGate API → IP/domain blok).

Denetim Kanıt Listesi – XDR/EDR

• Kapsam: Tüm CDE endpoint’leri (sunucu + iş istasyonu) EDR ajanı ile korumalı – PCI DSS 5.2
• EDR ajan sağlık raporu: kaç host’ta ajan var / olması gereken (gap analizi)
• EDR devre dışı bırakma koruması: tamper protection aktif kanıtı
• XDR → SIEM akışı: uçtan uca test (endpoint olayı SIEM’de görünüyor)
• Veri lokasyonu: XDR telemetri işleme lokasyonu + TCMB uyum değerlendirmesi
• Retention: detection/audit 10 yıl, ham telemetri ≥90 gün kanıtı
• MITRE ATT&CK kapsama haritası (coverage matrix)
• Threat intel entegrasyonu: VT/OTX/USOM feed aktif + enrichment örneği
• VT dosya upload yasağı: sadece hash sorgusu yapıldığı kanıtı
• Otomatik response audit: her playbook aksiyonu loglanıyor (örnek kayıt)
• SOC inceleme kaydı: günlük alert review (kim, ne zaman, ne aksiyon)
• Kritik kontrol arızası (PCI 10.7): EDR durursa tespit mekanizması

En Sık Denetim Bulguları – XDR/EDR

XDR – Altı Maddelik Ana ilke:

1. XDR, SIEM’in yerini almaz besler. Derin endpoint response + geniş korelasyon = ikisi birlikte.
2. Ham telemetri (90 gün) ile audit kaydı (10 yıl) ayrı retention maliyet/uyum dengesi.
3. Veri lokasyonu bulut-native XDR’da TCMB değerlendirmesi zorunlu; mümkünse on-prem/hybrid.
4. Her otomatik response loglanır is_automated + izlenebilirlik; silme asla otomatik değil.
5. Threat intel ile zenginleştir ama VT’ye dosya yükleme (sadece hash) CHD sızıntısını önle.
6. Korelasyon değeri çok kaynaktan gelir tek AV alert’i değil, phishing→endpoint→identity→network→DB zinciri.

Sonuç

Log izleme, SOC operasyonlarının sıkıcı ama vazgeçilmez temelidir. En pahalı EDR’ı, en gelişmiş NGFW’ı ya da en yetenekli XDR’ı satın alabilirsiniz ancak logları doğru toplayıp normalize etmiyor, anlamlı correlation rule’lar kurgulamıyor ve alert threshold’larını düzenli tune etmiyorsanız, elinizde yalnızca pahalı bir gürültü üreteci olur.
Bu yazıda ele aldığımız çerçeveyi bir kez daha özetleyelim:

1. Kritik log kaynaklarını belirleyin – Windows Event ID’lerinden Kubernetes audit loglarına, Modbus trafiğinden veritabanı slow query’lerine kadar.
2. Doğru Event ID’leri toplayın – 4624/4625 logon olayları hikâyenin sadece başlangıcıdır. Saldırının asıl izi 4728 (Domain Admin’e ekleme), 4720 (hesap oluşturma), 1102 (log temizleme) ve 4719 (audit policy değişimi) gibi hesap/grup/politika olaylarındadır. Bunların üretilebilmesi için Advanced Audit Policy’yi doğru yapılandırmayı unutmayın.
3. Merkezileştirin ve normalize edin – Korelasyon ancak tutarlı alan isimleri ve senkronize timestamp’lerle mümkündür.
4. Korelasyon kurgulayın – Tek bir log kaynağı nadiren yeterlidir; asıl değer kaynaklar arası ilişkidedir.
5. Bütünlüğü ve retention’ı koruyun – Hashing, WORM/immutable storage, şifreleme ve regülasyonla uyumlu saklama süreleri. Compliance Mode, Governance Mode değil.
6. Silme kurallarını netleştirin – Retention süresi içinde silmek yasak; süre dolduğunda saklamak da yasak. İkisi de denetim bulgusudur. Linux’ta bu, chattr +a + -e 2 + disk_full_action=HALT + object store Compliance Mode ile on katmanlı olarak zorlanır.
7. Platform ayrımını gözetin – Windows GPO/Advanced Audit Policy ile korunurken, Linux varsayılan kurulumda PCI DSS uyumlu değildir. auditd doğru kural setiyle yapılandırılmadan sunucu denetimden geçemez.
8. Uygulama katmanını ihmal etmeyin – Denetimde en sık kesilen nokta burasıdır. Loglanmayacak veri (CVV, PIN, parola, token) hiçbir koşulda loglanmaz; PAN maskelenir. Üç katmanlı maskeleme (uygulama → shipper → SIEM) ve production’da DEBUG yasağı, teknik olarak zorlanmalıdır
9. Transaction log’u audit log sanmayın – Recovery ve denetim ayrı şeylerdir. CHD’ye yapılan her SELECT‘i yalnızca native audit (pgaudit / SQL Server Audit / MySQL Audit) yakalar. Log yazılamıyorsa veritabanı durmalıdır
10. Perimetrede IDS/IPS ve WAF zorunludur – PCI DSS 11.5.1 ve 6.4.2 bunları mecbur kılar; detect-only değil, blocking modda. Firewall’da bir kuralın deny→accept’e dönmesi (Windows 4719 muadili) P1 alarmdır. Deny trafiği ve implicit-deny mutlaka loglanır; syslog TCP+TLS ile taşınır
11. Konteyner ortamında pod stdout’u audit sanmayın – Kubernetes API audit log, “kim cluster’da ne yaptı” sorusunun cevabıdır (Windows Security Event Log muadili) ve zorunludur. secrets audit seviyesi Metadata olmalı, admission controller Enforce modda riskli işlemleri engellemeli, CDE için ayrı cluster tercih edilmelidir
12. Bulutta veri lokasyonu önce gelir – TCMB tebliği CDE’yi Türkiye’de zorunlu kılar. CloudTrail/Activity Log/Cloud Audit bulutun Security Event Log’udur (CloudWatch/Monitor uygulama logudur); CHD storage’a erişim için data event’ler zorunludur; audit log’lar immutable Compliance/locked modda tutulur ve yurt içi SIEM’de merkezileştirilir
13. XDR ile katmanları birleştirin – XDR, SIEM’in yerini almaz; onu besler. Phishing → endpoint → identity → ağ → konteyner → bulut → veritabanı zincirini community_id üzerinden tek bir storyline olarak görmek, tek tek alert’lerin kaçırdığı çok aşamalı saldırıyı yakalar
14. Otomatikleştirin – PCI DSS 10.4.1.1 sonrası SIEM opsiyonel değil, zorunlu. SIEM + SOAR entegrasyonuyla MTTD ve MTTR’ı düşürün. Ancak her otomatik response loglanmalı; silme asla otomatik olmamalıdır

Türkiye’de regüle bir kurumda çalışıyorsanız, uluslararası çerçeveler yalnızca zeminin bir kısmıdır. 6493, TCMB Bilgi Sistemleri Tebliği, 5651, MASAK ve KVKK birlikte değerlendirildiğinde tasarım hedefiniz 10 yıl retention, yurt içi veri lokasyonu ve NEZD zaman damgası olmak zorundadır. Bunları sonradan eklemek, baştan kurgulamaktan çok daha pahalıdır bunu deneyimle söylüyorum.

Siber tehditler hızla evriliyor; logging ve monitoring best practice’leri de öyle. NIST SP 800-92 (Guide to Computer Security Log Management), MITRE ATT&CK ve üretici dokümantasyonları, sürekli öğrenme için güvenilir başlangıç noktalarıdır.

Kaynakça

• NIST SP 800-92 – Guide to Computer Security Log Management: https://csrc.nist.gov/publications/detail/sp/800-92/final
• NIST SP 800-61r2 – Computer Security Incident Handling Guide: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
• NIST SP 800-137 – Information Security Continuous Monitoring (ISCM): https://csrc.nist.gov/publications/detail/sp/800-137/final
• MITRE ATT&CK Framework: https://attack.mitre.org/
• AWS CloudTrail Documentation: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-userguide.html
• Azure Monitor Documentation: https://learn.microsoft.com/en-us/azure/azure-monitor/
• Google Cloud Logging: https://cloud.google.com/logging/docs
• Kubernetes Auditing Documentation: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
• Docker Logging Documentation: https://docs.docker.com/config/containers/logging/
• Microsoft Sentinel Documentation: https://learn.microsoft.com/en-us/azure/sentinel/
• Microsoft Defender Documentation: https://learn.microsoft.com/en-us/microsoft-365/security/defender/
• IBM QRadar Documentation: https://www.ibm.com/docs/en/qradar
• Splunk Documentation: https://docs.splunk.com/
• Elastic Documentation: https://www.elastic.co/guide/index.html
• Suricata Documentation: https://suricata-ids.org/docs/
• Snort (IDS/IPS) Documentation: https://www.snort.org/
• Wazuh Documentation: https://documentation.wazuh.com/
• OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/
• PCI DSS: https://www.pcisecuritystandards.org/
• ISO/IEC 27001: https://www.iso.org/isoiec-27001-information-security.html
• Sysinternals Documentation: https://learn.microsoft.com/en-us/sysinternals/
• VirusTotal: https://www.virustotal.com/
• AlienVault OTX: https://otx.alienvault.com/

Türkiye Mevzuatı

• 6493 sayılı Ödeme ve Menkul Kıymet Mutabakat Sistemleri, Ödeme Hizmetleri ve Elektronik Para Kuruluşları Hakkında Kanun
• TCMB – Ödeme Hizmetleri ve Elektronik Para İhracı Yönetmeliği
• TCMB – Bilgi Sistemleri ve Bilgi Sistemleri Denetimi Hakkında Tebliğ
• 5651 sayılı İnternet Ortamında Yapılan Yayınların Düzenlenmesi Hakkında Kanun
• 5549 sayılı Suç Gelirlerinin Aklanmasının Önlenmesi Hakkında Kanun (MASAK)
• 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) – https://www.kvkk.gov.tr/
• BDDK – Bilgi Sistemleri ve İş Süreçleri Denetimi Yönetmeliği

Windows / Active Directory Güvenliği

• Microsoft – Advanced Security Audit Policy Settings: https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/advanced-security-audit-policy-settings
• Microsoft – Events to Monitor (Appendix L): https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l–events-to-monitor
• MITRE ATT&CK for ICS: https://attack.mitre.org/matrices/ics/

Linux Güvenlik ve Denetim

• Linux Audit (auditd) Documentation: https://github.com/linux-audit/audit-documentation/wiki
• AIDE (Advanced Intrusion Detection Environment): https://aide.github.io/
• Wazuh Documentation: https://documentation.wazuh.com/
• RKE2 – Audit Log: https://docs.rke2.io/security/hardening_guide
• Kyverno – Policy Engine: https://kyverno.io/docs/
• OPA / Gatekeeper: https://open-policy-agent.github.io/gatekeeper/
• CIS Kubernetes Benchmark: https://www.cisecurity.org/benchmark/kubernetes
• Fluent Bit Documentation: https://docs.fluentbit.io/
• Sigstore / Cosign: https://docs.sigstore.dev/

Bulut Güvenliği ve Immutability

• S3-Uyumlu On-Prem Object Storage (WORM): Ceph RADOS Gateway (https://docs.ceph.com/en/latest/radosgw/), NetApp StorageGRID, Dell ObjectScale, Cloudian HyperStore, Scality RING/ARTESCA, SeaweedFS (https://github.com/seaweedfs/seaweedfs)
• Yurt İçi Datacenter / Bulut (ödeme kuruluşu altyapısı): Bulutistan, İş Net, İnnova, Superonline, DgpaysIT, DT İletişim – S3/Object Lock/immutability desteği ve PCI DSS AoC her sağlayıcıdan ayrıca teyit edilmelidir
• AWS S3 Object Lock: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
• AWS GuardDuty: https://docs.aws.amazon.com/guardduty/
• Azure Immutable Blob Storage: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview
• Microsoft Defender for Cloud: https://learn.microsoft.com/en-us/azure/defender-for-cloud/
• GCP Bucket Lock: https://cloud.google.com/storage/docs/bucket-lock

Veritabanı Denetim (Audit)

• PostgreSQL – pgAudit: https://www.pgaudit.org/
• SQL Server Audit: https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine
• SQL Server Ledger Tables: https://learn.microsoft.com/en-us/sql/relational-databases/security/ledger/ledger-overview
• MariaDB Audit Plugin: https://mariadb.com/kb/en/mariadb-audit-plugin/
• MySQL Enterprise Audit: https://dev.mysql.com/doc/refman/8.0/en/audit-log.html

Ağ Güvenliği ve WAF

• FortiGate – Logging & Reporting: https://docs.fortinet.com/document/fortigate/administration-guide
• Suricata Documentation: https://docs.suricata.io/
• Snort Documentation: https://www.snort.org/documents
• OWASP ModSecurity Core Rule Set (CRS): https://coreruleset.org/
• OWASP Top Ten: https://owasp.org/www-project-top-ten/

Bu yazıda XDR/EDR ile bütünsel korelasyonu; MITRE ATT&CK eşlemeli tespit kurallarını, XDR→SIEM mimarisini, threat intelligence entegrasyonunu, SOAR otomatik yanıt kısıtlarını ve phishing’den veritabanına uzanan çok aşamalı saldırı zincirinin tek bir storyline olarak yakalanmasını ele aldık. XDR/EDR ve Bütünsel Korelasyon – Bölüm 8 ile serimiz tamamlanmış oldu.

Sekiz bölüm boyunca log izlemenin temellerinden başlayıp; mevzuat, Windows/Linux, uygulama, veritabanı, ağ, container, bulut ve XDR katmanlarını bir ödeme kuruluşu bağlamında baştan sona işledik. Umarım bu seri, kendi ortamınızda görünürlüğü artırmanız ve denetimlere hazırlanmanız için sağlam bir yol haritası olmuştur.

Okuduğunuz için teşekkürler…

Başka bir seride görüşmek dileğiyle…