Siber olay müdahale planı nasıl hazırlanır?

Planın amacı bütün olayları önceden tahmin etmek değil, karar belirsizliğini azaltmaktır

Bir olay sırasında zaman kaybının önemli bölümü teknik teşhisten değil; kimin karar vereceği, hangi sistemin kapatılabileceği, müşteriye ne söyleneceği, hangi verinin korunacağı ve hizmetin ne zaman geri açılacağı konularındaki belirsizlikten doğar. Plan, bu kararları olay türü ve etki seviyesine göre önceden çerçeveler.

Hazırlık; envanter, temas, log ve alternatif çalışma yoluyla başlar

• Kritik hizmetler, veri kümeleri, bağımlılıklar ve iş sahipleri.
• İç ve dış olay temas listesi; yedek kişiler ve 7/24 ulaşım yöntemi.
• Bulut, SaaS, barındırma, güvenlik ve iletişim tedarikçilerinin olay kanalları.
• Merkezî zaman senkronizasyonu, log saklama ve erişim yetkileri.
• Temiz cihaz, güvenli iletişim kanalı ve kriz çalışma alanı.
• Yedek, geri dönüş, geçici manuel süreç ve asgari hizmet planı.
• Hukuk, veri koruma, sigorta ve düzenleyici temaslarının güncelliği.

NIST SP 800-61 Rev. 3, olay müdahaleyi ayrı bir teknik faaliyet olarak değil, CSF 2.0 içindeki Govern, Identify, Protect, Detect, Respond ve Recover işlevleriyle bütünleşik risk yönetimi olarak ele alır.

Olay ekibi teknik kişilerden daha geniş olmalıdır

Her olay için bir Incident Commander belirlenmeli; teknik müdahaleyi yapan kişiyle kurumsal karar sahibinin aynı kişi olması zorunlu değildir. Kritik kararlar için vekâlet ve ulaşılamama senaryosu da yazılmalıdır.

Olay sınıflandırması yalnız teknik şiddete göre yapılmamalıdır

İlk saat için kısa ve uygulanabilir kontrol kartı gerekir

1. Olay kaydı: İlk sinyal, saat, kaynak ve gözlenen davranışı kaydedin.
2. Komuta: Incident Commander ve teknik lideri atayın.
3. Etki: Kritik hizmet, veri, kullanıcı ve tedarikçileri belirleyin.
4. Kanıt: Log ve görüntüleri koruyun; gereksiz yeniden başlatmadan kaçının.
5. Sınırlama: Hesap, anahtar, ağ, tenant veya özelliği kontrollü sınırlandırın.
6. İletişim: Güvenli kanal kurun ve tek zaman çizelgesi tutun.
7. Karar kapısı: Hizmet, müşteri ve bildirim kararlarını yetkili kişilere taşıyın.

Sınırlama, temizleme ve kurtarma ayrı karar kapılarıdır

Kısa vadeli sınırlama zararı azaltır; uzun vadeli sınırlama güvenli çalışma düzenini kurar. Temizleme kök nedeni ve kalıcılık mekanizmasını kaldırır. Kurtarma ise sistemin güvenilir biçimde yeniden hizmete alınmasıdır.

• Etkilenen hesap, token, sertifika ve anahtarların döndürülmesi.
• Zararlı kalıcılık, yanlış yapılandırma ve açık bağımlılığın giderilmesi.
• Temiz kaynaktan geri yükleme ve bütünlük doğrulaması.
• Yüksek riskli işlemlerde çift kontrol ve geçici limit.
• Artırılmış izleme ve yeniden bulaşma göstergeleri.
• İş sahibinin işlevsel kabulü ve güvenlik sahibinin teknik kabulü.

Kanıt zinciri ve ortak zaman çizelgesi korunmalıdır

Kim, ne zaman, hangi sistemi gördü; hangi komut çalıştırıldı; hangi karar kimin onayıyla verildi; hangi veri dışa aktarıldı? Bu bilgiler olay sonrası analiz, sigorta, sözleşme, düzenleyici ve adli süreç için önemlidir.

• Kaynağın kimliği, zaman damgası, hash ve kopyalama yöntemi.
• Logların saat dilimi ve zaman senkronizasyonu.
• Kanıta erişen kişiler ve değişiklik kaydı.
• Ham kanıt ile çalışma kopyasının ayrılması.
• Mesaj, toplantı ve kararların tek zaman çizelgesinde birleştirilmesi.

İletişim doğru, tutarlı ve kanıt sınırları içinde olmalıdır

İlk mesajın her ayrıntıyı açıklaması gerekmez; fakat bilinmeyeni kesin bilgi gibi sunmamalıdır. Etkilenen hizmet, mevcut önlem, kullanıcıdan beklenen işlem ve bir sonraki güncelleme zamanı açık olmalıdır.

Plan, tatbikat ve ölçüm olmadan güncel kabul edilemez

• Üç ayda bir temas ve araç kontrolü.
• En az yılda bir masa başı tatbikat.
• Kritik sistemler için teknik kurtarma testi.
• Tedarikçi katılımlı olay senaryosu.
• Tespit, komuta, sınırlama ve kurtarma sürelerinin ölçümü.
• Her olay ve tatbikat sonrası sahipli aksiyon listesi.

Başarı yalnız olayın kapanması değildir. Tekrarlayan kök neden, uygulanmayan aksiyon, eksik log ve geciken kararlar ayrıca ölçülmelidir.

İlk 24 saat için yönetim karar dosyası hazırlanmalıdır

Teknik zaman çizelgesine ek olarak yönetim için kısa bir karar dosyası tutulmalıdır. Dosyada doğrulanmış etki, henüz bilinmeyenler, alınan sınırlama önlemleri, hizmet ve müşteri etkisi, mevzuat ve sözleşme değerlendirmesi, beklenen sonraki karar ve bir sonraki güncelleme saati bulunmalıdır. Böylece yönetim aynı soruları farklı ekiplerden tekrar istemek yerine tek kanıt seti üzerinden karar verir.

Karar dosyası olay kapandıktan sonra da korunmalıdır. Olayın maliyeti, kesinti süresi, etkilenen kayıt sayısı, müşteri temasları, tedarikçi performansı, manuel işlem yükü ve düzeltici faaliyetler bu kayıt üzerinden izlenebilir. Olay raporunun amacı suçlu aramak değil; hangi kontrolün eksik, hangi varsayımın yanlış ve hangi kararın gecikmiş olduğunu görünür kılmaktır.