Logging & Monitoring (Loglama ve İzleme)

1. Giriş

Şimdiye kadarki her bölüm bir tespit (Detection) alt bölümü içerdi — çünkü hiçbir savunma kusursuz değildir ve bir saldırı gerçekleştiğinde onu görebilmek hayati önemdedir. Loglama ve izleme, bu görme yeteneğidir: sistemde ne olduğunu kaydeder, anomalileri tespit eder ve zamanında uyarır. OWASP bunu 2021'de ilk 10 riske ekledi (A09: Security Logging and Monitoring Failures), çünkü ihlallerin çoğu önlenmedikleri için değil, fark edilmedikleri için felakete dönüşür.

Merkezî ilke basittir: göremediğinizi savunamazsınız. Bir saldırgan sisteminize girdiğinde, onu ne kadar erken tespit ederseniz hasar o kadar küçük olur. Loglama olmadan, bir ihlal aylarca sürebilir; yeterli loglamayla, dakikalar içinde yakalanabilir.

Bu ilkenin en çarpıcı kanıtı Equifax 2017 ihlalidir (Bölüm 11): Equifax'ın ağ trafiğini izleyen cihazındaki bir SSL sertifikası süresi dolmuştu; bu, şifreli trafiğin hiç incelenmediği anlamına geliyordu — izleme fiilen kapalıydı. Saldırganlar 76 gün boyunca veri sızdırdı ve kimse fark etmedi. Sertifika yenilenip trafik incelemesi geri geldiği anda ihlal tespit edildi. Bu, izlemenin gücünün ve yokluğunun bedelinin ders kitabı örneğidir.

Bu bölüm, güvenlik loglaması ve izlemesini ele alır ve Kısım VII'yi açar: buradan olay müdahalesine (Bölüm 32) ve web shell tespitine (Bölüm 34) uzanacağız.

---

2. Temel Teori

Neden loglama/izleme? İki amaç: (1) Tespit — bir saldırının gerçekleştiğini/gerçekleşmekte olduğunu görmek; (2) Yanıt ve adli analiz — ne olduğunu anlamak, kapsamı belirlemek, müdahale etmek (Bölüm 32). Loglama olmadan ikisi de imkânsızdır.

Ne loglanmalı — güvenlik açısından ilgili olaylar:

Kategori	Örnek
Kimlik doğrulama	Başarılı/başarısız girişler, parola değişimi, MFA (Bölüm 12)
Yetkilendirme	Yetki reddi, ayrıcalıklı erişim denemeleri (Bölüm 14)
Girdi doğrulama	Reddedilen/anormal girdiler, enjeksiyon kalıpları (Bölüm 4, 6)
Yüksek-değerli işlemler	Ödeme, veri dışa aktarma, hesap değişikliği
Yönetici eylemleri	Config değişimi, kullanıcı/rol değişimi
Anomali	Sıralı ID erişimi (Bölüm 15/22), metadata istekleri (Bölüm 21)

Ne loglanMAmalı (kritik!): Sırlar, parolalar, token'lar, tam PII, oturum kimlikleri, kart numaraları loglanmaz (Bölüm 25). Loglar merkezî sistemlere akar ve geniş erişimlidir; hassas veriyi loglamak, onu ifşa etmektir. Hassas alanları maskeleyin/hariç tutun.

Log bütünlüğü. Saldırganlar izlerini gizlemek için logları temizler/değiştirir (Bölüm 28, 34). Bu yüzden loglar: (1) merkezileştirilmeli (host dışı, ayrı bir sistemde) — saldırgan host'u ele geçirse bile logları silememeli; (2) değiştirilemez/append-only olmalı; (3) zaman senkron (NTP) olmalı ki olaylar korelasyona uygun olsun.

Merkezileştirme ve SIEM. Loglar tek tek sunucularda işe yaramaz; merkezî bir sisteme (SIEM — Security Information and Event Management) toplanır, korele edilir (farklı kaynaklardan olayları birleştirme) ve uyarı üretilir. Yapılandırılmış loglama (JSON) ve korelasyon kimlikleri (request ID) bunu kolaylaştırır.

Uyarı — asıl amaç. Log toplamak yeterli değildir; kimse milyonlarca satırı elle okumaz. Değer, zamanında uyarıdadır: eşik-tabanlı (ör. 100 başarısız giriş/dk) ve anomali-tabanlı (ML/temel-çizgi sapması) uyarılar, bir saldırıyı insan müdahalesi gerektirecek kadar erken işaretler. Equifax'ın hatası, verinin toplanmaması değil, izleme cihazının kapalı olmasıydı.

İzlemeyi izleme. Equifax dersi: izleme altyapısının kendisi de izlenmelidir. Süresi dolmuş bir sertifika (Bölüm 27), izleme cihazını aylarca kör etti ve kimse bunu fark etmedi. Sertifika yaşam döngüsü, izleme sağlığı ve "log akıyor mu" kontrolleri gereklidir.

Metrikler. MTTD (ortalama tespit süresi) ve MTTR (ortalama müdahale süresi), güvenlik izlemenin olgunluğunu ölçer. Equifax'ın MTTD'si 76 gündü; hedef dakikalar/saatlerdir.

---

3. Mimarisel Bakış

 GÜVENSİZ (Equifax kalıbı — kör izleme):
   Saldırgan → RCE (Bölüm 8) → yanal hareket → veri sızdırma (şifreli)
        ↓  izleme cihazı KAPALI (süresi dolmuş sertifika)
   → 76 GÜN tespit edilmez → 147M kayıt
        ↑ sertifika yenilenince → ANINDA tespit

 GÜVENLİ:
   Olaylar → yapılandırılmış log (sır YOK — Bölüm 25)
        ↓  merkezî, değiştirilemez, zaman-senkron (host dışı)
   SIEM → korelasyon → UYARI (eşik + anomali)
        ↓  zamanında insan müdahalesi (Bölüm 32)
   + izlemeyi izle (sertifika/sağlık) → kör nokta yok

 NE LOGLANIR: authN/authZ/girdi/yüksek-değer/yönetici/anomali
 NE LOGLANMAZ: parola, token, sır, tam PII, oturum kimliği (Bölüm 25)

Kritik gözlem: değer, log toplamada değil, zamanında tespit ve uyarıdadır; ve izleme altyapısının kendisi de izlenmelidir.

---

4. Güvensiz Kod

Gerçekçi (güvensiz) loglama:

<?php
// ⚠️ GÜVENSİZ loglama
declare(strict_types=1);

// 1) Sır/PII loglama (Bölüm 25)
error_log("Giriş: $email / parola: $password");     // parola loglandı!
error_log("Token: $jwtToken");                       // token loglandı!
error_log("Kart: $creditCard");                      // PII loglandı!

// 2) Güvenlik olayları HİÇ loglanmıyor
if (!login($email, $password)) {
    return 'Hatalı';                                 // başarısız giriş loglanmadı
}

// 3) Yalnızca yerel dosya (merkezî değil, değiştirilebilir)
file_put_contents('/var/www/app/app.log', $msg, FILE_APPEND);
// saldırgan (web shell) bu logu siler (Bölüm 28, 34)

// 4) İzleme/uyarı yok; kimse logları okumuyor

---

5. Açığın Analizi

Sır/PII loglama — Bölüm 25 ihlali. Parola, token, kart numarası loglanınca, loglara erişen herkes (geniş erişimli merkezî sistemler, log yönetimi ekibi, bir log sızıntısı) bu sırlara ulaşır. Loglar hassas veri deposu olmamalı; bu alanlar maskelenmeli/hariç tutulmalı.

Güvenlik olayları loglanmıyor — Başarısız girişler, yetki redleri, anormal girdiler loglanmıyor. Bir kaba kuvvet saldırısı (Bölüm 12), enumeration (Bölüm 15/22) veya enjeksiyon denemesi (Bölüm 6) iz bırakmadan geçer; tespit imkânsızdır.

Yalnızca yerel dosya — Log yalnızca ele geçirilen host'ta duruyor. Bir saldırgan (web shell, Bölüm 34) app.log'u silip/değiştirip izlerini yok eder (Bölüm 28). Loglar host dışı, merkezî ve değiştirilemez olmalı.

İzleme/uyarı yok — Loglar toplansa bile kimse okumuyor, uyarı yok. Equifax gibi, veri "toplanıyor" ama işlenmiyor olabilir. Tespit, zamanında uyarı gerektirir.

Kök sorun: yanlış şeyler (sırlar) loglanıyor, doğru şeyler (güvenlik olayları) loglanmıyor, loglar korunmuyor (yerel/değiştirilebilir) ve izlenmiyor (uyarı yok). Çözüm: doğru olayları, sırsız, merkezî/değiştirilemez logla ve zamanında uyar.

---

6. Hacker Bakış Açısı

Saldırgan loglama/izleme karşısında ne yapar?

Kör noktaları arar. İzlemenin olmadığı yerleri hedefler: loglanmayan uç noktalar, izlenmeyen iç ağ, şifreli trafik (Equifax — incelenmeyen), unutulmuş sistemler. İzleme ne kadar zayıfsa, o kadar rahat çalışır.

Yavaş ve sinsi (low and slow) hareket eder. Eşik-tabanlı uyarıları tetiklememek için yavaş çalışır (yavaş enumeration, dağıtık kaynaklar). Bu yüzden anomali-tabanlı tespit (temel-çizgi sapması) gerekir.

İzleri temizler. Erişim kazanınca logları siler/değiştirir (Bölüm 28, 34) — özellikle yerel logları. Merkezî, host-dışı, değiştirilemez loglar bunu engeller; saldırgan merkezî sistemi ele geçiremezse izler kalır.

Şifreli kanalları kullanır. Equifax'ta olduğu gibi, veri sızdırmayı şifreli bağlantılarla yapar; trafik incelemesi (TLS inspection) yoksa veya kapalıysa (süresi dolmuş sertifika) görünmez kalır.

Loglardaki sırları toplar. Loglar sır/token/PII içeriyorsa (yaygın hata), saldırgan bunları toplar — loglama, bir sızıntı kanalına dönüşür.

Savunmacı dersi: Saldırgan görünmezlik ister; loglama/izleme onu görünür kılar. Kapsamlı loglama (kör nokta yok), anomali tespiti (low-and-slow'a karşı), merkezî/değiştirilemez loglar (temizlemeye karşı) ve izlenen trafik (Equifax'a karşı), saldırganın gizlenmesini engeller.

---

7. Exploit Mantığı

Bu bölüm saldırı tekniği içermez. Loglama/izlemenin neden belirleyici olduğu kavramsaldır:

• Tespit süresi = hasar. Bir ihlalin etkisi, ne kadar sürdüğüyle orantılıdır. Equifax'ta izleme kör olduğu için 76 gün ve 147M kayıt; izleme çalışsaydı çok daha az. Erken tespit, hasarı üstel olarak azaltır.
• Göremediğini savunamazsın. İzleme yoksa, en gelişmiş savunmalar bile bir ihlali fark edemez; saldırgan süresiz kalır. Tespit, savunmanın son ve vazgeçilmez katmanıdır (Bölüm 1).
• İzlemenin kendisi kritik altyapıdır. Equifax dersi: izleme cihazı kapalıysa (süresi dolmuş sertifika), tüm loglama teorik kalır. İzleme sağlığı izlenmelidir.
• Loglar iki ucu keskin. Doğru yapılırsa tespit sağlar; yanlış yapılırsa (sır loglama) sızıntı kanalı olur. Ne loglandığı, en az loglama kadar önemlidir.

Araştırmacının/savunmacının çerçevesi: (a) güvenlik olayları loglanıyor mu, (b) loglar sırsız mı, (c) merkezî/değiştirilemez mi, (d) zamanında uyarı var mı, (e) izlemenin kendisi izleniyor mu. Etkili savunma beşini de sağlar.

---

8. Güvenli Kod

Güvenli, yapılandırılmış loglama (Monolog örneği):

<?php
// ✅ GÜVENLİ loglama (Monolog)
declare(strict_types=1);

use Monolog\Logger;
use Monolog\Handler\StreamHandler;
use Monolog\Handler\SyslogHandler;

$log = new Logger('security');
// Merkezî bir toplayıcıya (syslog → SIEM), host-dışı gönder
$log->pushHandler(new SyslogHandler('app-security'));

// 1) Güvenlik olaylarını logla — sır/PII OLMADAN (Bölüm 25)
function logAuthFailure(Logger $log, string $email, string $ip): void {
    $log->warning('auth.failure', [
        'email_hash' => hash('sha256', $email),   // e-posta maskelendi
        'ip'         => $ip,
        'ts'         => time(),
        // parola/token ASLA loglanmaz
    ]);
}

$log->info('auth.success',  ['user_id' => $userId, 'ip' => $ip]);
$log->warning('authz.denied', ['user_id' => $userId, 'resource' => $res]);  // Böl.14
$log->warning('input.rejected', ['rule' => 'sql_pattern', 'ip' => $ip]);    // Böl.6
$log->notice('admin.action', ['actor' => $userId, 'change' => 'role_update']);

// 2) Yüksek-değerli işlem + korelasyon kimliği
$log->info('payment.processed', [
    'user_id'        => $userId,
    'amount'         => $amount,
    'correlation_id' => $requestId,      // olayları ilişkilendir
    // kart numarası: yalnızca son 4 hane
    'card_last4'     => substr($card, -4),
]);

İzleme/uyarı ve altyapı (kod dışı ama kritik):

- Merkezî SIEM: tüm loglar host-dışı, değiştirilemez, zaman-senkron (NTP)
- Korelasyon + uyarı:
    * eşik: >N başarısız giriş/dk (kaba kuvvet — Bölüm 12)
    * anomali: sıralı ID erişimi (BOLA — Bölüm 15/22), metadata istekleri (SSRF — Bölüm 21)
    * web shell: upload dizininde yeni .php, web sürecinden alt süreç (Bölüm 19/34)
    * yetki yükseltme: www-data'dan root'a geçiş (Bölüm 28)
- İZLEMEYİ İZLE (Equifax dersi): sertifika yaşam döngüsü, "log akıyor mu", cihaz sağlığı
- Metrik: MTTD/MTTR ölç ve iyileştir

Öne çıkan modern pratikler: - Güvenlik olaylarını logla: authN/authZ/girdi/yüksek-değer/yönetici/anomali (önceki bölümlerin tespit sinyalleri). - Sır/PII loglama (Bölüm 25): Parola/token/kart/oturum kimliği asla; hassas alanları maskele/hariç tut. - Merkezî, değiştirilemez, zaman-senkron: Host-dışı SIEM; saldırgan logları silemesin (Bölüm 28, 34); NTP ile korelasyon. - Yapılandırılmış log + korelasyon kimliği: JSON + request ID; korelasyon ve uyarı kolaylaşır. - Zamanında uyarı (asıl amaç): Eşik + anomali; log toplamak değil, tespit etmek. - İzlemeyi izle (Equifax dersi): Sertifika/cihaz sağlığı, log akış kontrolü — kör nokta olmasın. - MTTD/MTTR ölç: Tespit ve müdahale hızını iyileştir. - Olay müdahalesine besle (Bölüm 32): Loglar, IR ve adli analizin temelidir.

---

9. Patch Analizi

Neden işe yarar? Güvenlik olaylarını loglamak, saldırıyı görünür kılar. Sır/PII'yi hariç tutmak, logların sızıntı kanalına dönüşmesini engeller (Bölüm 25). Merkezî/değiştirilemez loglar, saldırganın izlerini temizlemesini önler (Bölüm 28). Zamanında uyarı, tespiti insan müdahalesi gerektirecek kadar erken yapar. İzlemeyi izlemek, Equifax türü kör noktaları kapatır. Bunlar birlikte, "göremediğinizi savunamazsınız" gerçeğini tersine çevirir: saldırgan görünür olur ve erken durdurulur.

Equifax karşılaştırması:

Durum	Sonuç
İzleme kapalı (süresi dolmuş sertifika)	76 gün tespit edilmez, 147M kayıt
İzleme geri geldiğinde	Anında tespit

Bu tek karşılaştırma, çalışan izlemenin değerini kanıtlar: aynı saldırı, izleme açıkken saniyeler içinde, kapalıyken 76 gün görünmez kaldı.

Loglama dengeleri: Aşırı loglama gürültü ve maliyet yaratır; az loglama kör nokta. Denge, güvenlik açısından ilgili olaylara odaklanmak ve anomali-tabanlı uyarıyla sinyali gürültüden ayırmaktır. Sır loglamak asla kabul edilebilir bir denge değildir.

Performans: Yapılandırılmış loglama ve async/merkezî gönderim, uygulama gecikmesini minimalde tutar. SIEM ayrı altyapıda çalışır. Güvenlik kazancı (erken tespit) maliyeti kat kat aşar.

---

10. Gerçek Hayat Senaryosu

Kurgu — bir fintech. Uygulama iyi savunulmuş ama loglama zayıf: başarısız girişler ve yetki redleri loglanmıyor, loglar yalnızca yerel dosyada ve hiçbir uyarı yok. Bir saldırgan, çalınan bir kimlikle (Bölüm 25) yavaşça (low and slow) hesap kimliklerini enumerate ediyor (BOLA, Bölüm 22) ve aylarca veri topluyor. Loglama olmadığından hiç fark edilmiyor; olay ancak veriler forumda satışa çıkınca öğreniliyor — Equifax gibi. Doğru loglama/izlemeyle: authN/authZ olayları + BOLA anomali uyarısı (tek kaynaktan sıralı ID erişimi) + merkezî loglar → saldırı erken tespit edilir. Dersler: (1) güvenlik olayları loglanmalı; (2) anomali uyarısı low-and-slow'u yakalar; (3) merkezî/değiştirilemez loglar adli analizi (Bölüm 32) mümkün kılar.

---

11. Gerçek Vaka Analizi — Equifax İhlali (2017, 147 milyon kayıt)

ABD GAO raporu, Equifax açıklamaları ve The Register/Security.org ile doğrulanmıştır. İzleme başarısızlığının ders kitabı vakasıdır.

Özet. 2017'de Equifax (ABD'nin üç büyük kredi bürosundan biri), yamalanmamış bir Apache Struts açığı (CVE-2017-5638) üzerinden ele geçirildi; saldırganlar ~147 milyon Amerikalının hassas verisini (ad, SSN, doğum tarihi, adres, kısmi ehliyet) 76 gün boyunca sızdırdı. İhlal Mayıs 2017'de başladı, 29 Temmuz 2017'ye kadar tespit edilmedi ve 7 Eylül 2017'ye kadar kamuya açıklanmadı. CEO, CIO ve CSO görevden ayrıldı; ihlal, güvenlik başarısızlığının ders kitabı vakası oldu.

Teknik neden — yama başarısızlığı + kör izleme. Zincir iki ana başarısızlıktan oluşuyordu: 1. Yamalanmamış açık. Apache 7 Mart 2017'de CVE-2017-5638'i (Struts RCE) açıkladı; yama 10 Mart'ta çıktı. Equifax'ın iç direktifi 48 saat içinde yamayı zorunlu kılıyordu, ama yama tüketici anlaşmazlık portalına (ACIS) hiç uygulanmadı — otomatik tarama, yanlış yapılandırma ve güncel olmayan bildirim listesi yüzünden savunmasız alt dizini atladı. Saldırganlar 13 Mayıs'ta girdi. 2. Kör izleme (bu bölümün asıl dersi). Equifax, ağ trafiğini kötü amaçlı etkinlik için inceleyen bir cihaz kurmuştu — ama bu cihazın SSL sertifikasının süresi dolmuştu (bazı raporlara göre 10 aydan uzun süredir). Sertifika geçersiz olduğundan, cihaz şifreli trafiği inceleyemiyordu; fiilen kapalıydı. Saldırganlar veritabanlarını sorgulayıp veriyi şifreli bağlantılar üzerinden sızdırdı ve 76 gün boyunca kimse fark etmedi.

Kritik an — GAO raporunun vurguladığı ders şudur: 29 Temmuz'da bir güvenlik ekibi üyesi süresi dolmuş sertifikayı yeniledi; trafik incelemesi geri gelir gelmez cihaz anında şüpheli etkinliği (normal operasyonun parçası olmayan sistem komutları) işaretledi. Yani izleme çalışsaydı, ihlal ilk günlerde yakalanabilir ve çok daha az veri sızardı. Bu, "göremediğinizi savunamazsınız" ilkesinin en net kanıtıdır: aynı saldırı, izleme kapalıyken 76 gün, açıkken saniyeler içinde görünür oldu.

Ek bir ders (Bölüm 27, 32): süresi dolmuş bir sertifika gibi temel bir operasyonel hata (sertifika yaşam döngüsü yönetimi), 147 milyon kaydın sızmasına doğrudan katkıda bulundu; ve açıklamanın 6 hafta geciktirilmesi (bu sırada yöneticilerin hisse satması) itibar ve güven kaybını derinleştirdi (Bölüm 32).

Etki. 147 milyon kayıt; üst yönetimin istifası; düzenleyici reformlar (ücretsiz kredi dondurma); "her başarısızlık standart uygulamalarla önlenebilirdi" — sofistike bir saldırı değil, temel başarısızlıklar zinciriydi.

Çıkarılacak dersler: 1. Göremediğinizi savunamazsınız. Kör izleme (süresi dolmuş sertifika) 76 gün maliyet; çalışan izleme anında tespit. 2. İzlemeyi izleyin. İzleme altyapısının sağlığı (sertifika yaşam döngüsü, cihaz durumu, log akışı) sürekli kontrol edilmeli — kör nokta olmasın. 3. Yama + izleme birlikte (Bölüm 30). Yama başarısızlığı girişi açtı; izleme başarısızlığı sızıntıyı gizledi. İkisi de gerekliydi. 4. Erken tespit hasarı azaltır. MTTD kritiktir; 76 gün yerine dakikalar hedeflenmelidir.

---

12. Detection

Loglama yapılandırması incelemede:

grep -rnE 'error_log|Logger|log->' src/ | grep -iE 'password|token|secret|card'  # sır loglama!
grep -rn 'file_put_contents.*log' src/    # yalnızca yerel log mu?
# Merkezî loglama, uyarı ve izleme-sağlığı yapılandırmasını kontrol et

Kontroller: Güvenlik olayları loglanıyor mu? Sır/PII hariç mi? Loglar merkezî/değiştirilemez mi? Uyarı var mı? İzlemenin kendisi izleniyor mu (sertifika/sağlık)?

Öz-değerlendirme (bu kitabın tespit sinyalleri): Önceki bölümlerin tespit alt bölümlerindeki sinyallerin gerçekten loglanıp uyarıya bağlandığını doğrulayın: SQLi kalıpları (Bölüm 6), enumeration/BOLA (Bölüm 15/22), SSRF metadata (Bölüm 21), web shell (Bölüm 19/34), yetki yükseltme (Bölüm 28), kimlik kötüye kullanımı (Bölüm 25).

SIEM/izleme: Log toplama kapsamı (kör nokta var mı?), korelasyon kuralları, uyarı eşikleri/anomali modelleri, ve izleme sağlığı (Equifax dersi — sertifika/cihaz/log akışı). "Log gelmiyor" da bir alarmdır.

Metrikler: MTTD/MTTR ölç; tespit tatbikatları (purple team) ile uyarıların gerçekten çalıştığını doğrula.

---

13. Prevention

• Güvenlik olaylarını logla: authN/authZ/girdi/yüksek-değer/yönetici/anomali.
• Sır/PII loglama (Bölüm 25): Parola/token/kart/oturum kimliği asla; maskele.
• Merkezî, değiştirilemez, zaman-senkron: Host-dışı SIEM; NTP; saldırgan silemesin (Bölüm 28).
• Yapılandırılmış log + korelasyon kimliği.
• Zamanında uyarı (eşik + anomali): Toplamak değil, tespit etmek.
• İzlemeyi izle (Equifax dersi): Sertifika/cihaz/log-akışı sağlığı.
• MTTD/MTTR ölç ve iyileştir; tespit tatbikatları.
• Olay müdahalesine besle (Bölüm 32).

---

14. Mitigation

• Acil: Sır loglamasını durdur/maskele; kritik güvenlik olaylarını loglamaya başla; merkezî toplama ve temel uyarıları (kaba kuvvet, BOLA anomali) kur; izleme sağlığını (sertifika) doğrula.
• Geçici: Mevcut loglardan geçmiş ihlal izlerini ara (adli analiz, Bölüm 32); kör noktaları belirle ve kapat; sızmış olabilecek sırları döndür (Bölüm 25).
• Kalıcı: Kapsamlı güvenlik loglaması + merkezî değiştirilemez SIEM + anomali uyarısı standardını kur; izleme sağlığı kontrolünü otomatikleştir; MTTD/MTTR izle; tespit tatbikatlarını düzenli yap.

---

15. Checklist

• [ ] Güvenlik olayları (authN/authZ/girdi/yüksek-değer/yönetici/anomali) loglanıyor mu?
• [ ] Sır/PII (parola/token/kart/oturum kimliği) loglardan hariç/maskeli mi (Bölüm 25)?
• [ ] Loglar merkezî, host-dışı, değiştirilemez ve zaman-senkron (NTP) mu (Bölüm 28)?
• [ ] Yapılandırılmış log + korelasyon kimliği kullanılıyor mu?
• [ ] Zamanında uyarı (eşik + anomali) var mı — sadece toplama değil?
• [ ] Önceki bölümlerin tespit sinyalleri uyarıya bağlı mı (SQLi/BOLA/SSRF/web shell/privesc)?
• [ ] İzlemenin kendisi izleniyor mu (sertifika/cihaz/log-akışı sağlığı — Equifax dersi)?
• [ ] MTTD/MTTR ölçülüyor ve tespit tatbikatları yapılıyor mu?
• [ ] Loglar olay müdahalesine (Bölüm 32) besleniyor mu?

---

16. Laboratuvar

Lab 31.1 — Sır loglama tespiti. İzole bir uygulamada parola/token loglayan kod yaz; loglarda sırların göründüğünü gözlemle. Maskeleme/hariç tutma ile düzelt (Bölüm 25).

Lab 31.2 — Güvenlik olayı loglama. Başarısız giriş, yetki reddi ve anormal girdi için yapılandırılmış (JSON) loglar üret; bir korelasyon kimliğiyle bir isteği baştan sona izle.

Lab 31.3 — Eşik uyarısı. Başarısız girişleri logla; "N/dk üzeri → uyarı" mantığını kur ve bir kaba kuvvet simülasyonuyla (Bölüm 12) tetikle.

Lab 31.4 — Kör nokta (Equifax). İzlemenin kapalı olduğu bir senaryoda bir saldırının fark edilmediğini, izleme açılınca anında tespit edildiğini modelle. "İzlemeyi izleme"nin önemini yaz.

---

17. Quiz

1. Loglama/izlemenin iki temel amacı nedir?
2. "Göremediğinizi savunamazsınız" ne demektir? Equifax bunu nasıl kanıtlar?
3. Hangi güvenlik olayları loglanmalıdır (en az beş kategori)?
4. Ne loglanmamalıdır ve neden (Bölüm 25)?
5. Loglar neden merkezî, değiştirilemez ve host-dışı olmalıdır (Bölüm 28)?
6. Log toplamak neden yeterli değildir? Asıl değer nerededir?
7. Eşik-tabanlı ve anomali-tabanlı uyarı arasındaki fark nedir? "Low and slow" neden anomali gerektirir?
8. "İzlemeyi izleme" ne demektir? Equifax'ta hangi kör nokta oluştu?
9. Equifax'ta süresi dolmuş sertifika izlemeyi nasıl kör etti ve tespit ne zaman gerçekleşti?
10. MTTD ve MTTR nedir? Equifax'ın MTTD'si neydi?
11. Zaman senkronu (NTP) korelasyon için neden önemlidir?
12. Loglama nasıl "iki ucu keskin" olabilir (tespit vs sızıntı)?

---

18. Kaynakça

• OWASP, Top 10:2021 A09 Security Logging and Monitoring Failures; Logging Cheat Sheet; Logging Vocabulary Cheat Sheet.
• MITRE, CWE-778 (Insufficient Logging); CWE-532 (Insertion of Sensitive Information into Log File); CWE-223 (Omission of Security-relevant Information).
• ABD Government Accountability Office (GAO), Equifax Data Breach raporu (GAO-18-559); The Register ve Security.org Equifax analizleri.
• MITRE / NVD, CVE-2017-5638 (Apache Struts); NIST SP 800-92 (Guide to Computer Security Log Management).
• Monolog dokümantasyonu; SIEM/syslog ve sertifika yaşam döngüsü yönetimi rehberleri.