Incident Response & Disclosure (Olay Müdahalesi ve Açıklama)

1. Giriş

Bu kitap boyunca açıkları önlemeye ve tespit etmeye odaklandık. Ama hiçbir savunma kusursuz değildir; er ya da geç bir olay (incident) yaşanır. O anda ne yaptığınız — ve ne yapmadığınız — çoğu zaman ihlalin kendisinden daha belirleyicidir. Olay müdahalesi (Incident Response, IR), bir güvenlik olayını tespit etme, kontrol altına alma, kök nedenini bulma, kurtarma ve ondan ders çıkarma sürecidir. Açıklama (disclosure) ise, etkilenenlere, düzenleyicilere ve gerektiğinde kamuya doğru ve zamanında bilgi verme yükümlülüğüdür.

Bu bölümün merkezî mesajı sert bir gerçektir: bir ihlali gizlemek, ihlalin kendisinden daha kötüdür — hukuki, etik ve itibar açısından. Bunun en net kanıtı Uber vakasıdır (Bölüm 11, 25): 2016'daki 57 milyon kayıtlık ihlalin ardından Uber'in güvenlik sorumlusu (CSO) Joe Sullivan, olayı FTC'den gizledi ve saldırganlara ödenen "sus payını" (hush money) bir bug bounty ödemesi gibi gösterdi. 2022'de bir jüri Sullivan'ı ihlal yüzünden değil, gizleme yüzünden mahkûm etti. Gartner analistinin dediği gibi: "Sullivan'ı mahkûm ettiren şey ihlal değil, o ihlalin örtbas edilmesiydi."

Bu bölüm, olaya nasıl müdahale edileceğini ve nasıl (ve neden) doğru açıklanacağını ele alır. Loglama (Bölüm 31) burada temeldir: müdahale ve adli analiz, ancak yeterli logunuz varsa mümkündür.

---

2. Temel Teori

Olay müdahalesi yaşam döngüsü (NIST SP 800-61). Dört ana aşama:

Aşama	İçerik
1. Hazırlık (Preparation)	IR planı, roller, iletişim planı, yedekler, tatbikatlar, loglama (Bölüm 31)
2. Tespit & Analiz	Olayı fark et (loglama/izleme), kapsamı ve etkiyi belirle
3. Kontrol, Temizleme & Kurtarma	İzole et, kanıt koru, kök nedeni gider, sistemleri güvenle geri getir
4. Olay Sonrası (Lessons Learned)	Kök neden analizi, iyileştirme, süreç güncelleme

Kanıt koruma ve adli analiz. Bir olayda ilk içgüdü "temizlemek" olabilir — ama önce kanıt korunmalıdır. Logları (Bölüm 31), bellek görüntülerini, disk imajlarını ve göstergeleri (IOC) toplamadan sistemleri silmek/yeniden kurmak, ne olduğunu ve nasıl olduğunu anlamayı imkânsız kılar. Kök neden bilinmezse, saldırgan aynı yoldan geri döner. (Bölüm 34: web shell'i sadece silmek yetmez; nasıl geldiğini ve başka arka kapı olup olmadığını bul.)

Kontrol altına alma (containment). Yayılmayı durdur: etkilenen sistemleri izole et, ele geçirilmiş kimlikleri iptal et/döndür (Bölüm 25), saldırganın erişimini kes. Bunu yaparken kanıtı koru.

Açıklama — yasal ve etik yükümlülük. Bir veri ihlali gerçekleştiğinde, çoğu yargı bölgesi zorunlu bildirim gerektirir: GDPR (72 saat içinde düzenleyiciye), çeşitli ulusal/eyalet ihlal bildirim yasaları, sektörel düzenlemeler. Etik olarak da, etkilenen kişilerin — verileri risk altında olanların — bunu bilme hakkı vardır (kendilerini koruyabilmeleri için). Açıklama bir "opsiyon" değil, bir yükümlülüktür.

Sorumlu açıklama (CVD) vs sus payı — kritik ayrım. Sorumlu/koordineli zafiyet açıklaması (Coordinated Vulnerability Disclosure) ve bug bounty programları meşrudur: bir araştırmacı bir açığı gizlice bildirir, satıcı düzeltir, sonra kamuya açıklanır; araştırmacı ödüllendirilebilir. Ama bu, bir ihlali gizlemek için kullanılamaz. Uber vakasının kırmızı çizgisi tam buradadır: Sullivan, gerçekleşmiş bir ihlalin saldırganlarına ödenen parayı bir "bug bounty ödülü" gibi gösterip NDA imzalatarak olayı gizledi. Mahkeme bunu net ifade etti: "Yasa dışı erişim, bir NDA ile aklanamaz." Bir bug bounty, keşfedilen bir açığı ödüllendirir; bir ihlalin verisini çalmış saldırganlara susmaları için ödenen para ise sus payıdır ve suçtur.

Gizleme her şeyi kötüleştirir. Uber vakası, güvenlik yöneticilerinin kişisel cezai sorumluluğu için emsal oldu. Ders açıktır: bir olay yaşandığında, doğru yanıt onu yönetmek ve açıklamaktır — gizlemek değil.

---

3. Mimarisel Bakış

 OLAY MÜDAHALESİ YAŞAM DÖNGÜSÜ (NIST):
   [1 Hazırlık] → plan, roller, yedek, loglama (Bölüm 31), tatbikat
        ↓
   [2 Tespit & Analiz] → izleme/log → olay fark edilir → kapsam belirlenir
        ↓
   [3 Kontrol/Temizleme/Kurtarma]
        → izole et  → KANIT KORU  → kök nedeni gider → güvenle geri getir
        ↓
   [4 Ders Çıkar] → kök neden analizi → iyileştir → süreç güncelle
        ↺ (hazırlığa geri besle)

 AÇIKLAMA:
   İhlal → yasal bildirim (GDPR 72s, ulusal yasalar) + etkilenenlere + gerekirse kamu
        ✓ DOĞRU: zamanında, şeffaf açıklama
        ✗ YANLIŞ: gizleme / sus payı (Uber → CSO mahkûmiyeti)

 SORUMLU AÇIKLAMA (meşru)  ≠  SUS PAYI (suç)
   açığı bildir → düzelt → ödüllendir       ihlali gizle → sustur → örtbas

Kritik gözlem: müdahale kanıtı korur ve kök nedeni bulur; açıklama şeffaf ve zamanındadır. Gizleme, hukuki ve etik olarak felakettir.

---

4. Güvensiz Kod

Bu bölüm kod-merkezli değil süreç-merkezlidir; "güvensiz kod" yerine güvensiz müdahale ve açıklama kalıpları:

# ⚠️ GÜVENSİZ olay müdahalesi ve açıklama

1) PANİKLE SİL: Web shell bulundu → hemen sil, sunucuyu yeniden başlat
   → kanıt yok, kök neden bilinmiyor, başka arka kapılar kaçtı (Bölüm 34)

2) LOG YOK / YETERSİZ: Ne olduğu, nasıl olduğu, kapsamı belirlenemiyor (Bölüm 31)

3) KÖK NEDENİ ARAMA: Web shell silindi ama nasıl geldiği (upload açığı?)
   düzeltilmedi → saldırgan aynı yoldan geri döner

4) GİZLE: İhlali FTC'ye/düzenleyiciye/kullanıcılara bildirme
   → sus payını "bug bounty" gibi göster + NDA (Uber/Sullivan kalıbı)
   → hukuki suç (obstruction + misprision), kişisel cezai sorumluluk

5) GECİKTİR: Açıklamayı haftalarca ertele (Equifax: 6 hafta, bu sırada
   yöneticiler hisse sattı) → güven ve itibar kaybı derinleşir

---

5. Açığın Analizi

Panikle silme — Bir web shell'i (Bölüm 34) veya kötü kodu hemen silmek, kanıtı yok eder. Saldırganın nasıl girdiği, ne yaptığı, hangi verilere eriştiği ve başka hangi arka kapıları bıraktığı belirlenemez. Önce kanıt korunmalı (loglar, disk/bellek imajı, IOC), sonra temizlenmelidir.

Yetersiz log — Bölüm 31'in doğrudan sonucu. Log yoksa, olayın kapsamı (hangi veriler, ne zaman, ne kadar) belirlenemez; ne müdahale ne açıklama doğru yapılabilir. Loglama, IR'nin ön koşuludur.

Kök nedeni aramama — Web shell silinir ama onu bırakan açık (dosya yükleme, LFI, RCE) düzeltilmezse, saldırgan aynı yoldan geri döner. Müdahale, belirtiyi değil kök nedeni gidermelidir.

Gizleme — Uber/Sullivan kalıbı. İhlali düzenleyiciden/kullanıcılardan gizlemek ve sus payını meşru bir ödeme gibi göstermek, hukuki bir suçtur (obstruction of justice + misprision of felony) ve kişisel cezai sorumluluk doğurur. Etkilenen kişilerin bilme hakkı ihlal edilir.

Geciktirme — Equifax kalıbı: açıklamayı haftalarca ertelemek (bu sırada yöneticilerin hisse satması), güven kaybını derinleştirir ve etkilenenlerin kendilerini korumasını geciktirir. Bildirim zamanında olmalıdır (GDPR: 72 saat).

Kök sorun: müdahale kanıtı yok ediyor, kök nedeni bulmuyor; açıklama gizleniyor/geciktiriliyor. Çözüm: yapısal IR (kanıt koru, kök neden, kurtarma) + zamanında, şeffaf açıklama.

---

6. Hacker Bakış Açısı

Saldırgan, kurbanın müdahale ve açıklama zayıflıklarını nasıl istismar eder?

Tespit gecikmesini kullanır. Kurbanın izleme/müdahale yeteneği zayıfsa (Bölüm 31), saldırgan uzun süre (Equifax: 76 gün) fark edilmeden kalır ve daha çok veri toplar.

Kalıcılık için çoklu arka kapı bırakır. Tek bir web shell bulunup silinse bile, saldırgan başka gizli arka kapılar (Bölüm 30 magic-string backdoor, gizli cron/servis) bırakır. Kurban kök nedeni ve tüm kalıcılığı bulmazsa, saldırgan geri döner. Bu yüzden "sadece sil" yetmez.

Kanıt yok etmeyi umar. Kurbanın panikle silmesi/yeniden kurması, saldırganın izlerini de yok eder — adli analizi engeller, saldırganın kimliğini/yöntemini gizler.

Baskı ve şantaj uygular. Modern saldırılarda (ransomware, veri şantajı), saldırgan "ödeme yaparsan açıklamayız" der — kurbanı gizlemeye teşvik eder. Uber vakası tam bu tuzağın (sus payı = suç) örneğidir.

Savunmacı dersi: Saldırgan, zayıf müdahaleden (geç tespit, kanıt yok etme, eksik kök neden) ve gizleme baskısından beslenir. Güçlü IR (kanıt koru, kök neden, tüm kalıcılığı bul) ve ilkeli açıklama (gizleme yok), saldırganın bu avantajlarını ortadan kaldırır.

---

7. Exploit Mantığı

Bu bölüm saldırı tekniği içermez. Müdahale ve açıklamanın neden belirleyici olduğu kavramsaldır:

• Müdahale kalitesi = hasar. Erken tespit + doğru kontrol altına alma, hasarı sınırlar; geç/yanlış müdahale onu büyütür. Kanıt korunmazsa kök neden bilinmez ve saldırgan geri döner.
• Kök neden ≠ belirti. Web shell'i silmek belirtiyi giderir; onu bırakan açığı düzeltmek kök nedeni giderir. Kök neden giderilmezse müdahale başarısızdır (Bölüm 34).
• Gizleme, riski çarpar. Bir ihlal kötüdür; ama gizlenmiş bir ihlal — hukuki suç, kişisel cezai sorumluluk, katlanan itibar kaybı, etkilenenlerin korunamaması — çok daha kötüdür. Uber, bunun emsal vakasıdır.
• Şeffaflık, güveni korur. Zamanında, dürüst açıklama; etkilenenlerin kendilerini korumasını sağlar ve kurumun güvenilirliğini korur. Gizleme/geciktirme (Equifax) tersini yapar.

Savunmacının çerçevesi: (a) yeterli log/hazırlık var mı, (b) kanıt korunuyor mu, (c) kök neden bulunuyor mu, (d) tüm kalıcılık temizleniyor mi, (e) açıklama zamanında ve şeffaf mı. Doğru IR beşini de sağlar.

---

8. Güvenli Kod

Bu bölümde "güvenli kod" yerine güvenli müdahale ve açıklama süreci verilir:

# ✅ GÜVENLİ olay müdahalesi (NIST yaşam döngüsü)

[1] HAZIRLIK (olay ÖNCESİ)
    - IR planı + roller (kim neyi yapar) + iletişim planı (yasal/PR/yönetim)
    - Yeterli, merkezî, değiştirilemez loglama (Bölüm 31)
    - Yedekler (test edilmiş, izole) + kurtarma prosedürleri
    - Tatbikatlar (tabletop) — plan gerçek olayda çalışsın

[2] TESPİT & ANALİZ
    - İzleme/log ile olayı fark et (Bölüm 31)
    - Kapsamı belirle: hangi sistemler, veriler, ne zaman, nasıl
    - Önem/etki sınıflandır → uygun ekibi/planı tetikle

[3] KONTROL / TEMİZLEME / KURTARMA
    - Kontrol: etkilenen sistemleri izole et; yayılmayı durdur
    - KANIT KORU: log/disk/bellek imajı, IOC topla (adli analiz — Bölüm 34)
    - Kimlik/sır rotasyonu (Bölüm 25): ele geçirilmiş tüm kimlikleri döndür
    - Kök nedeni gider: açığı (upload/LFI/RCE) düzelt — belirtiyi değil
    - TÜM kalıcılığı bul: web shell + gizli arka kapılar (Bölüm 30, 34)
    - Güvenle geri getir: temiz/yeniden inşa; izlemeyle doğrula

[4] DERS ÇIKAR (olay SONRASI)
    - Kök neden analizi (blameless post-mortem)
    - Süreç/kod/izleme iyileştirmeleri → hazırlığa geri besle

# AÇIKLAMA
    - Yasal bildirim: düzenleyici (GDPR 72s), etkilenen kişiler, gerekirse kamu
    - Zamanında + şeffaf + doğru (gecikme/gizleme YOK)
    - Etkilenenlere korunma rehberi (kredi dondurma, parola değişimi vb.)
    - ASLA: sus payını "bug bounty" gibi gösterme / NDA ile susturma (suç)

Öne çıkan modern pratikler: - Önceden hazırlan: IR planı, roller, iletişim, yedek, tatbikat — olay anında doğaçlama yapılmaz. - Yeterli loglama (Bölüm 31): Müdahale ve adli analizin ön koşulu. - Kanıt koru: Temizlemeden önce log/imaj/IOC topla; kök neden ve kapsam için gerekli. - Kök nedeni gider: Belirtiyi (web shell) değil, açığı (upload/LFI/RCE) düzelt; tüm kalıcılığı bul (Bölüm 34). - Kimlik/sır rotasyonu (Bölüm 25): Ele geçirilmiş her kimliği döndür. - Zamanında, şeffaf açıklama: Yasal bildirim (GDPR 72s) + etkilenenler + korunma rehberi. - Gizleme/sus payı ASLA: Uber dersi — hukuki suç, kişisel sorumluluk. Sorumlu açıklama (CVD/bug bounty) ≠ ihlali gizleme. - Ders çıkar (blameless post-mortem): Kök nedeni hazırlığa geri besle.

---

9. Patch Analizi

Neden işe yarar? Hazırlık, olay anında doğaçlamayı önler. Yeterli loglama (Bölüm 31), tespiti ve adli analizi mümkün kılar. Kanıt koruma, kök neden ve kapsam belirlemeyi sağlar; kök nedeni gidermek (belirtiyi değil), saldırganın geri dönmesini önler. Kimlik rotasyonu (Bölüm 25) ele geçirilmiş erişimi keser. Zamanında/şeffaf açıklama, hem yasal yükümlülüğü karşılar hem etkilenenleri korur hem güveni sürdürür. Gizlemeden kaçınmak, hukuki felaketi (Uber) önler.

Müdahale karşılaştırması:

Yaklaşım	Sonuç
Panikle sil, log yok	Kök neden bilinmez, saldırgan geri döner, adli analiz imkânsız
Kök neden + kanıt + rotasyon	Saldırgan kesilir, tekrar önlenir
Gizle / sus payı (Uber)	Hukuki suç, kişisel cezai sorumluluk, katlanan itibar kaybı
Zamanında şeffaf açıklama	Yasal uyum, etkilenenler korunur, güven sürer

Açıklama dengesi: "Ne zaman/ne kadar açıklamalı?" bir denge gibi görünse de, yasal bildirim (GDPR 72s) ve etik yükümlülük gizlemeyi asla haklı çıkarmaz. Kapsamı belirlemek için makul süre alınabilir, ama Equifax'ın 6 haftalık gecikmesi (hisse satışlarıyla birlikte) bunun kötü örneğidir. Şeffaflık varsayılan olmalıdır.

Not: IR ve açıklama, teknik olduğu kadar yönetişim meselesidir; yasal, PR, yönetim ve teknik ekiplerin koordinasyonu gerekir. Bu, bir "kod yaması" değil, kurumsal bir yetenektir.

---

10. Gerçek Hayat Senaryosu

Kurgu — bir e-ticaret şirketi. Bir sabah, izleme bir web shell alarmı veriyor (Bölüm 31, 34). İki yol var: Yanlış yol — panikle web shell'i sil, sunucuyu yeniden başlat, kimseye söyleme; birkaç hafta sonra saldırgan aynı upload açığından (Bölüm 19) geri döner ve bu kez müşteri kart verisini sızdırır; şirket olayı gizler, sonra ifşa olunca hukuki ve itibar felaketi yaşanır (Uber). Doğru yol — kanıt topla (loglar, disk imajı), kapsamı belirle, upload açığını (kök neden) düzelt, tüm kalıcılığı bul, sızmış kimlikleri döndür (Bölüm 25), yasal bildirim yap (72 saat) ve etkilenen müşterilere korunma rehberi ver; sonra blameless post-mortem ile süreci iyileştir. Dersler: (1) belirtiyi değil kök nedeni gider; (2) kanıt koru; (3) gizleme değil, zamanında şeffaf açıklama.

---

11. Gerçek Vaka Analizi — Uber Örtbası ve CSO Mahkûmiyeti (2016 ihlali, 2022 mahkûmiyet)

ABD Adalet Bakanlığı, Norton Rose Fulbright/Arnold & Porter hukuki analizleri, Cybersecurity Dive ve 9. Daire temyiz kararıyla doğrulanmıştır. Açıklama etiğinin emsal vakasıdır.

Özet. 2016'da Uber, 57 milyon kullanıcı ve 600.000 sürücünün verisinin çalındığı bir ihlal yaşadı (Bölüm 25: koda gömülü AWS kimlik bilgileri). Uber'in CSO'su Joe Sullivan, olayı — Uber zaten 2014'teki başka bir ihlal için FTC soruşturması altındayken — FTC'den ve kullanıcılardan gizledi. Saldırganlara 100.000 dolar (bitcoin) ödendi ve bu ödeme Uber'in bug bounty programı üzerinden yapılıp saldırganlara NDA imzalatıldı — gerçek adları bile bilinmeden. Olay bir yıl sonra (2017) yeni CEO tarafından açıklandı; Sullivan kovuldu. 5 Ekim 2022'de bir federal jüri Sullivan'ı obstruction of justice (FTC soruşturmasını engelleme) ve misprision of a felony (bir suçu bilerek gizleme) suçlarından mahkûm etti. Mayıs 2023'te 3 yıl denetimli serbestlik + 200 saat kamu hizmeti + 50.000 dolar para cezasına çarptırıldı; 9. Daire mahkûmiyeti 2025'te onadı.

Neden mahkûm oldu — ihlal değil, gizleme. Bu vakanın en kritik dersi, uzmanların ve mahkemenin ortak vurgusudur: Sullivan ihlal yüzünden değil, ihlali örtbas etmesi yüzünden mahkûm oldu. Gartner analisti Jon Amato'nun deyimiyle: "Bir ihlalin örtbasını dışarıya yaptırmak, o örtbasa katılmaktır." Suçun unsurları: 1. Obstruction of justice. Uber FTC soruşturması altındayken yeni ihlali gizlemek, düzenleyiciyi yanıltma çabasıydı. FTC baş müfettişi, ihlali Kasım 2017'de öğrenmesini "FTC'deki en sinir bozucu deneyimim" diye niteledi. 2. Misprision of a felony. Saldırganların (Bilgisayar Sahtekârlığı ve Kötüye Kullanım Yasası'nı ihlal eden yetkisiz erişimleri bir "felony"ydi) suçunu yetkililere bildirmek yerine, para ödeyip NDA ile gizlemek bir suçtu.

Sus payı vs bug bounty — kırmızı çizgi. Mahkemenin kilit tespiti: "Yasa dışı erişim, sonradan imzalatılan bir NDA ile aklanamaz." Bir bug bounty programı, keşfedilen bir açığı iyi niyetle bildiren araştırmacıyı ödüllendirir. Uber ise, gerçekleşmiş bir ihlalin verisini çalmış saldırganlara — kimliklerini bile bilmeden — susmaları için para ödeyip bunu bir "ödül" gibi gösterdi. Bu, sorumlu açıklamanın (CVD) değil, örtbasın ta kendisiydi. Ayrıca saldırganlar (Glover, Mereacre) 2019'da suçlarını kabul etti.

Emsal niteliği. Sullivan, bir ihlalle bağlantılı olarak suçlanan tek yönetici oldu ve dava, güvenlik yöneticilerinin (CSO/CISO) kişisel cezai sorumluluğu için emsal oluşturdu. Hâkim Orrick'e, davanın sektöre "caydırıcı etkisinden" endişe eden 50'den fazla CISO'nun imzaladığı mektuplar geldi. Yine de mahkûmiyet, "şeffaflık pazarlık konusu değildir" mesajını verdi.

Çıkarılacak dersler: 1. Gizleme, ihlalden daha kötüdür. Örtbas, hukuki suç ve kişisel cezai sorumluluk doğurur; ihlalin kendisi bunu (genelde) doğurmaz. 2. Sus payı ≠ bug bounty. Meşru açıklama/ödül programları, bir ihlali gizlemek için kullanılamaz; kırmızı çizgi budur. 3. Zamanında ve dürüst açıkla. Düzenleyiciye ve etkilenenlere yükümlülük, gizlemeyle değil şeffaflıkla yerine getirilir. 4. IR bir yönetişim meselesidir. Teknik, yasal, yönetim ve PR koordinasyonu; kararlar önceden planlanmalıdır.

---

12. Detection

Bu bölüm bir açık sınıfı değil, bir süreç olduğundan, "tespit" IR yeteneğinin kendisini değerlendirmedir:

Hazırlık denetimi: IR planı var mı ve güncel mi? Roller/iletişim tanımlı mı? Tatbikat (tabletop) yapılıyor mu? Yedekler test edilmiş ve izole mi? Loglama (Bölüm 31) yeterli mi?

Olay tespiti: Loglama/izleme (Bölüm 31), olayı zamanında yakalıyor mu? Önceki bölümlerin tespit sinyalleri (SQLi, BOLA, SSRF, web shell, privesc) uyarıya bağlı mı?

Müdahale kalitesi: Kanıt koruma prosedürü var mı? Kök neden analizi yapılıyor mu? Kimlik rotasyonu (Bölüm 25) müdahalenin parçası mı? Tüm kalıcılık aranıyor mu (Bölüm 34)?

Açıklama uyumu: Yasal bildirim yükümlülükleri (GDPR 72s, ilgili yasalar) biliniyor ve uygulanıyor mu? Bildirim süreci tanımlı mı? Şeffaflık ilkesi benimsenmiş mi?

Tatbikat/metrik: Purple team / tabletop ile IR planı gerçekten çalışıyor mu? MTTD/MTTR (Bölüm 31) ölçülüyor mu?

---

13. Prevention

• Hazırlan: IR planı, roller, iletişim, yedek, tatbikat — olaydan önce.
• Yeterli loglama (Bölüm 31): Tespit ve adli analizin ön koşulu.
• Kanıt koru: Temizlemeden önce log/imaj/IOC topla.
• Kök nedeni gider: Belirtiyi (web shell) değil açığı düzelt; tüm kalıcılığı bul (Bölüm 34).
• Kimlik/sır rotasyonu (Bölüm 25): Ele geçirilmiş kimlikleri döndür.
• Zamanında, şeffaf açıklama: Yasal bildirim + etkilenenler + korunma rehberi.
• Gizleme/sus payı ASLA: Sorumlu açıklama (CVD/bug bounty) ≠ ihlali gizleme.
• Blameless post-mortem: Kök nedeni hazırlığa geri besle.

---

14. Mitigation

• Acil (olay anında): Planı tetikle; kontrol altına al (izole et) + kanıt koru; kapsamı belirle; sızmış kimlikleri döndür (Bölüm 25).
• Kısa vade: Kök nedeni gider (açığı düzelt); tüm kalıcılığı temizle (Bölüm 34); yasal bildirimleri (72s) yap; etkilenenlere şeffaf bilgi ver.
• Kalıcı: Blameless post-mortem; süreç/kod/izleme iyileştirmeleri; IR planını ve açıklama sürecini güncelle; düzenli tatbikat.

---

15. Checklist

• [ ] Güncel bir IR planı, tanımlı roller ve iletişim planı var mı?
• [ ] Yeterli, merkezî, değiştirilemez loglama var mı (Bölüm 31)?
• [ ] Yedekler test edilmiş, izole ve kurtarma prosedürleri hazır mı?
• [ ] Müdahalede kanıt (log/imaj/IOC) temizlemeden önce korunuyor mu?
• [ ] Kök neden gideriliyor (belirti değil) ve tüm kalıcılık aranıyor mu (Bölüm 34)?
• [ ] Ele geçirilmiş kimlikler/sırlar döndürülüyor mu (Bölüm 25)?
• [ ] Yasal bildirim yükümlülükleri (GDPR 72s, ilgili yasalar) biliniyor ve uygulanıyor mu?
• [ ] Açıklama zamanında ve şeffaf mı (gizleme/sus payı YOK)?
• [ ] Olay sonrası blameless post-mortem yapılıp süreç iyileştiriliyor mu?
• [ ] IR planı düzenli tatbikatlarla (tabletop) test ediliyor mu?

---

16. Laboratuvar

Lab 32.1 — Tabletop tatbikat. Bir web shell senaryosu (Bölüm 34) için masabaşı tatbikat yürüt: tespit → kontrol → kanıt koruma → kök neden → kurtarma → açıklama adımlarını rolleriyle canlandır.

Lab 32.2 — Kanıt koruma. İzole ortamda bir "olay" oluştur; temizlemeden önce logları/imajı koru. Kanıt korunmadan silmenin adli analizi nasıl imkânsız kıldığını gözlemle.

Lab 32.3 — Kök neden vs belirti. Bir web shell'i sil ama onu bırakan (simüle) upload açığını düzeltme; saldırının "geri döndüğünü" modelle. Sonra kök nedeni giderip farkı gör.

Lab 32.4 — Açıklama kararı. Bir ihlal senaryosunda yasal bildirim yükümlülüklerini (GDPR 72s vb.) haritalandır; "gizleme vs şeffaf açıklama" seçeneklerinin hukuki/etik sonuçlarını (Uber vakası) tartış.

---

17. Quiz

1. Olay müdahalesi yaşam döngüsünün (NIST) dört aşaması nedir?
2. Bir web shell bulunduğunda neden "hemen silmek" yanlıştır?
3. Kanıt koruma neden temizlemeden önce gelir?
4. "Kök neden vs belirti" ne demektir? Web shell örneğinde açıklayın.
5. Müdahalede kimlik/sır rotasyonu (Bölüm 25) neden gereklidir?
6. Veri ihlali açıklaması hangi yasal yükümlülükleri doğurur (örn. GDPR)?
7. Sorumlu açıklama (CVD/bug bounty) ile sus payı arasındaki kırmızı çizgi nedir?
8. Uber/Sullivan vakasında CSO neden mahkûm oldu (ihlal mi, gizleme mi)?
9. "Yasa dışı erişim bir NDA ile aklanamaz" ne anlama gelir?
10. Equifax'ın açıklama gecikmesi neden zararlıydı?
11. Neden IR bir "kod yaması" değil, bir yönetişim yeteneğidir?
12. Blameless post-mortem neden değerlidir?

---

18. Kaynakça

• NIST SP 800-61 (Computer Security Incident Handling Guide); SANS Incident Handler's Handbook.
• ABD Adalet Bakanlığı, United States v. Sullivan; 9. Daire temyiz kararı (2025); Norton Rose Fulbright ve Arnold & Porter hukuki analizleri; Cybersecurity Dive, Uber ex-CSO verdict.
• GDPR Madde 33-34 (ihlal bildirimi); ilgili ulusal/sektörel ihlal bildirim yasaları.
• FIRST, Coordinated Vulnerability Disclosure (CVD) rehberleri; ISO/IEC 29147 (Vulnerability disclosure) ve 30111 (Vulnerability handling).
• MITRE, CWE-778 (yetersiz loglama — IR ile ilişki); OWASP Incident Response rehberleri.