Olay Müdahalesinde İlk 15 Dakika: Karar Ağacı ve İletişim Disiplini

Selam,

Olay müdahalesinde ilk 15 dakika çoğu zaman sonraki 15 saati belirler. Bu yazıda panik yerine karar ağacı kullanan bir L1/L2 disiplini anlatıyorum. Kurum playbook'unuz varsa o üstündür; bu metin boşluğu doldurmak içindir.

Dakika 0-2: ne olduğunu tek cümlede yaz
"Ne gördük, nerede, ne zaman, kim bildirdi?" Ticket'a düz metin. Spekülasyon yok. Örnek: "Satış ekibinden 3 kullanıcı aynı anda sahte Microsoft girişi bildiriyor; 14:02 TRT."

Dakika 2-5: güvenlik hijyeni ve kanıt

• Etkilenen hesabı/cihazı izole etmeden önce politika: izolasyon mu, yoksa izleme mi?
  
• Ekran görüntüsü + ham log zaman damgası
  
• Saat dilimi notu (Europe/Istanbul); SIEM UTC ise dönüşümü yaz
  

Karar ağacı (özet)


Dakika 5-10: iletişim
Tek kanal seçin (IR chat / telefon köprüsü). Herkese ayrı ayrı yazmak kaosu büyütür. Roller:

• Olay komutanı (karar)
  
• Teknik analist
  
• İletişim (iş birimleri)
  
• Varsa hukuk / KVKK noktası
  

"Her şeyi herkese mail atma" kuralı: durum özeti 5-10 dakikada bir, net madde işaretleriyle.

Dakika 10-15: kısa çevreleme

• Etkilenen hesaplarda aktif oturum listesi
  
• Firewall / proxy'de bilinen kötü IOC blok (geçici)
  
• Yedekleme işlerinin çalıştığını doğrula (silme/encryption senaryosu)
  
• Dışa açık yönetim panellerinde anomali
  

Windows'ta oturum düşürme örneği (lab/politika dahilinde):
Entra ID / bulut için Unified Audit Log ve "Revoke sessions" prosedürünüzü hazır tutun.

Yapmayın

• Kanıt almadan disk silmek / yeniden kurmak
  
• Saldırganla "pazarlık" maili
  
• Herkese açık Slack'te IOC paylaşmak (sızıntı riski)
  
• Saat senkronu bozuk sunucuda zaman çizelgesi kurmak
  

15. dakikada elde olması gerekenler

1. Tek cümlelik durum
   
2. Etki tahmini (düşük/orta/yüksek) — gerekçeli
   
3. Uygulanan çevreleme adımları
   
4. Sonraki checkpoint zamanı
   
5. Escalate edildi mi?
   

Kaynaklar

• NIST SP 800-61 (Computer Security Incident Handling Guide)
  
• SANS PICERL modeli
  
• Kurumunuzun IR runbook'u
  

Sizin ilk 15 dakikada en çok atlanan adım hangisi oldu? Bizde uzun süre "tek cümlelik durum" eksikti.

Severity'yi erken sabitlemeyin
İlk 15 dakikada "critical" ilan etmek panik yaratır; "bilinmiyor, çevreleme uygulandı" daha dürüsttür. Severity'yi checkpoint'te güncelleyin. Yönetime giden mesajda teknik jargon yerine iş etkisi: "fatura sistemi yazılamıyor", "e-posta gecikiyor".

Müşteri / regülasyon hattı
Kişisel veri sızıntısı şüphesinde KVKK bildirim süreleri devreye girebilir. IR ekibi hukuk ile erken konuşsun; teknik ekip tek başına "bildirmeyelim" kararını vermesin. İlk 15 dakikanın işi hukuku bilgilendirmek olabilir, resmi bildirimi tamamlamak değil.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.