- İki sunucu şifrelenmeye başlamış.
- Saldırganın ayrıcalıklı bir hesaba erişmiş olabileceğine ilişkin bulgular var.
- Vatandaşlara hizmet veren ana portal ise hâlâ çalışıyor.
- Teknik ekip saldırıyı araştırıyor.
Bu aşamada yaşanan şey nedir? Bir siber olay mı? Yoksa: bir siber kriz mi? Bu ayrım önemlidir. Çünkü her siber güvenlik olayı üst yönetimin, hukuk biriminin, iletişim ekibinin veya kriz masasının devreye girmesini gerektirmez. Buna karşılık bazı olaylar teknik ekiplerin rutin müdahale kapasitesini aşarak:
- Kurumsal hizmetleri,
- Hukuki yükümlülükleri,
- İtibarı,
- Kritik kararları,
- Dış paydaşları
Ve hatta, Kurumun görevini sürdürme yeteneğini etkileyebilir. Bu noktada olay artık yalnızca: “Hangi sunucu etkilendi?” sorusundan ibaret değildir.
Asıl soru: “Kurum hangi kararı, hangi bilgiyle, hangi yetki seviyesinde ve ne kadar sürede vermelidir?” haline gelir.
ENISA'nın 2024 tarihli Best Practices for Cyber Crisis Management çalışması da büyük ölçekli bir siber olayın krize yükseltilmesinin tamamen teknik bir eşik olmadığını; kurumun veya devletin risk toleransı, olayın etkisi ve olağan araçlarla yönetilip yönetilemediği gibi faktörlerin önemli olduğunu vurgulamaktadır.
1. Incident ile Crisis arasındaki temel fark
Bir incident — olay, güvenlik açısından müdahale gerektiren teknik veya operasyonel durumdur. Örneğin:
- Bir kullanıcı hesabının ele geçirilmesi,
- Tek bir istemcide zararlı yazılım bulunması,
- Bir sunucunun istismar edilmesi
siber olay olabilir. Kurumun mevcut SOC, CSIRT veya BT süreçleri olayı:
- Tespit edebiliyor,
- Sınırlayabiliyor,
- Temizleyebiliyor
- Ve normal yetki mekanizması içinde çözebiliyorsa
ISO 22361:2022, kriz yönetimini kurumun stratejik kriz yönetimi kapasitesini planlamasına, oluşturmasına, sürdürmesine, gözden geçirmesine ve geliştirmesine yönelik bir yaklaşım olarak ele alır.
Standart özellikle kriz liderliği, kriz ekiplerinin zor koşullarda karar vermesi, kriz iletişimi, eğitim ve krizlerden öğrenme konularını öne çıkarmaktadır. Bu çerçevede kurumsal siber kriz için şu yaklaşım kullanılabilir:
2. Krizi saldırının büyüklüğü değil etkisi belirler
Teknik olarak çok gelişmiş bir saldırı her zaman kriz değildir. Buna karşılık teknik olarak basit bir olay çok büyük bir kriz oluşturabilir.
Örneğin bir saldırgan son derece gelişmiş tekniklerle önemsiz bir test sunucusuna erişmiş olabilir. Teknik açıdan ilginçtir. Ancak; kurumun görevini etkilemiyorsa kriz olmayabilir.
Başka bir olayda ise çok karmaşık olmayan bir DDoS saldırısı:
- Acil sağlık hizmetini,
- Finansal işlemleri,
- Ulaşım hizmetini
- Veya kritik kamu hizmetini
3. Bir olay hangi koşullarda krize dönüşebilir?
Tek bir evrensel kriz eşiği yoktur. Ancak; bazı göstergeler olayın artık yalnızca teknik ekip seviyesinde yönetilemeyeceğini düşündürür.
| Boyut | Kriz seviyesine yaklaşmayı gösteren durum |
|---|---|
| Hizmet etkisi | Kritik hizmetin ciddi biçimde kesilmesi |
| Yayılım | Çok sayıda sistem veya kurumun etkilenmesi |
| Yetki etkisi | Kritik kimlik/yönetim altyapısının güvenilirliğini kaybetmesi |
| Veri etkisi | Büyük ölçekli hassas veri kaybı, değişikliği veya sızıntısı |
| Süre | Olayın normal müdahale süresini aşması |
| Belirsizlik | Olayın kapsamının ve saldırganın durumunun bilinmemesi |
| Kaynak ihtiyacı | Mevcut ekip ve kaynakların yetersiz kalması |
| Hukuki etki | Bildirim, soruşturma veya önemli hukuki yükümlülük doğması |
| İtibar | Kamuoyu ve paydaş güveninin etkilenmesi |
| Dış bağımlılık | Tedarikçi, sektör veya diğer kurumlara yayılma |
| Karar ihtiyacı | Teknik ekip yetkisini aşan kararların gerekmesi |
4. Teknik olay yönetimi ile kriz yönetimi neden aynı değildir?
Teknik ekip şu kararı verebilir: “Sunucuyu ağdan izole edelim.” Ancak sistem kritik vatandaş hizmetini sağlıyorsa bu kararın sonucu: hizmet kesintisi olabilir.
Dolayısıyla soru değişir: “Saldırganın erişimini kesmek için sistemi kapatmalı mıyız, yoksa sınırlı hizmeti devam ettirmeli miyiz?” Bu artık yalnızca teknik soru değildir. Çünkü:
- Güvenlik,
- Hizmet sürekliliği,
- Hukuk,
- Kurumsal itibar,
- Paydaş etkisi
5. Krizin en zor unsuru: Eksik bilgi altında karar
- Saldırgan hâlâ içeride mi,
- Veri dışarı çıktı mı,
- Yedekler etkilenmiş mi,
- Kaç sistem ele geçirilmiş,
- Saldırı ne zamandır devam ediyor?
Yönetici: “Tüm bilgiler gelince karar verelim.” diyebilir. Ama bilgi tamamlanana kadar saldırı büyüyebilir. Bu nedenle kriz yönetiminin önemli becerilerinden biri: Eksik fakat yeterli bilgiyle zamanında karar verebilmektir.
ISO 22361'in özellikle kriz ekiplerinin karar verme sırasında karşılaştığı karmaşıklık ve zorlukları ayrı bir konu olarak ele alması bu nedenle önemlidir.
6. Kararı geciktirmenin de riski vardır
Kriz sırasında: karar vermek risklidir. Ancak: karar vermemek de karardır. Örneğin saldırganın domain administrator yetkisine sahip olduğundan şüpheleniyoruz.
Portal çalışmaya devam ediyor. Kesin doğrulama için iki saat gerektiği söyleniyor. İki saat boyunca hiçbir şey yapmamak: hizmeti sürdürür. Ama saldırganın:
- Başka sistemlere geçmesine,
- Yedekleri etkilemesine,
- Veri sızdırmasına da imkân verebilir.
7. Siber krizde üç farklı karar seviyesi
Kurumsal yapıya göre isimler değişebilir ancak siber olaylarda üç temel karar seviyesini düşünmek yararlıdır.
- Bir IP adresini engellemek,
- EDR ile sistemi izole etmek,
- Zararlı dosyayı karantinaya almak.
- Kritik uygulamayı geçici olarak kapatmak,
- EDR ortamına geçmek,
- Dış destek çağırmak,
- Büyük kapsamlı hesap sıfırlaması yapmak.
- Kritik hizmeti tamamen durdurmak,
- Olağanüstü iş sürekliliği planını devreye almak,
- Kurum dışı geniş iletişim yapmak,
- Yüksek maliyetli kurtarma kararını onaylamak,
- Kritik kaynakları başka hizmetlerden çekmek.
8. Eskalasyon nedir?
Örneğin SOC: Zararlı yazılımı izole edebilir. Ama: “Vatandaş portalını altı saat kapatalım mı?” kararını tek başına vermemelidir. Çünkü karar, artık hizmet ve kurum riskini etkiler.
9. Eskalasyon eşikleri önceden belirlenmelidir
Kriz sırasında ilk kez: “CISO'yu arayalım mı?” diye tartışmak doğru değildir. Önceden eşikler oluşturulabilir. Örnek:
10. Severity ile Crisis Level aynı şey değildir
Bu ayrım önemlidir. Bir olayın teknik severity seviyesi yüksek olabilir. Ama kurum tarafından kontrol altına alınmışsa kriz olmayabilir.
Başka bir olay teknik olarak orta seviyede olabilir fakat: ana hizmeti saatlerce durdurduğu, medyada hızla yayıldığı, önemli paydaşları etkilediği için kriz yönetimi gerektirebilir.
Dolayısıyla: Teknik kritiklik ile kurumsal kriz seviyesi birbirinden ayrı değerlendirilmelidir.
11. Kriz masasında kimler bulunmalıdır?
Her olaya bütün yöneticilerin dahil edilmesi doğru değildir. Ancak; büyük siber krizlerde kararın niteliğine göre farklı fonksiyonlara ihtiyaç olabilir. Örnek bir kriz yapısı:
| Fonksiyon | Temel katkı |
|---|---|
| Kriz Lideri / Üst Yönetim | Stratejik karar ve kaynak |
| CISO / Siber Güvenlik | Teknik risk ve saldırı durumu |
| BT / Operasyon | Sistem ve kurtarma kapasitesi |
| İş/Hizmet Sahibi | Hizmet etkisi ve öncelikler |
| İş Sürekliliği | Alternatif çalışma ve toparlanma |
| Hukuk/Uyum | Hukuki ve düzenleyici yükümlülükler |
| Kurumsal İletişim | İç ve dış iletişim |
| İnsan Kaynakları | Personel kaynaklı veya iç tehdit boyutu |
| Tedarik/Satın Alma | Kritik tedarikçi ve dış destek |
| Sekretarya/Kayıt | Kararların ve olay gelişiminin kayıt altına alınması |
12. CISO'nun görevi her kararı vermek değildir
Siber krizlerde önemli bir yanlış beklenti: “CISO siber güvenlikten sorumluysa bütün kararları o versin.” yaklaşımıdır.
CISO: teknik risk, tehdit, kontrol, olası saldırı gelişimi konusunda güçlü bilgi sağlayabilir.
Fakat: bir hastane hizmetini durdurmak, vatandaş portalını günlerce kapatmak, üretimi kesmek gibi kararların etkisi siber güvenliğin ötesindedir.
Dolayısıyla CISO'nun görevi: kurum adına bütün riski sahiplenmek değil, karar vericinin siber riski anlayabilmesini sağlayacak bilgiyi üretmek olmalıdır.
13. Kriz sırasında yönetici hangi bilgiyi görmelidir?
Yöneticiye yüzlerce log satırı veya onlarca IOC verilmemelidir. Bir siber kriz durum raporu aşağıdaki yapıya indirgenebilir:
| Alan | Yönetici sorusu |
|---|---|
| Ne oldu? | Olayın kısa özeti |
| Ne biliyoruz? | Doğrulanmış bilgiler |
| Ne bilmiyoruz? | Kritik belirsizlikler |
| Ne etkileniyor? | Sistem, hizmet, veri, insan |
| Saldırgan aktif mi? | Tehdidin devam durumu |
| Hizmet durumu ne? | Normal, azaltılmış, kesintili |
| En kötü makul senaryo ne? | Olay büyürse ne olabilir? |
| Seçeneklerimiz ne? | A, B, C karar alternatifleri |
| Her seçeneğin riski ne? | Güvenlik ve iş etkisi |
| Hangi karar gerekiyor? | Yönetimden beklenen karar |
| Bir sonraki güncelleme ne zaman? | Bilgi ritmi |
14. Ortak operasyonel resim neden önemlidir?
Kriz sırasında farklı ekiplerin farklı gerçekliklerle hareket etmesi ciddi problemdir.
SOC: “Saldırgan hâlâ aktif.” diyebilir.
BT: “Sistemler çalışıyor.” diyebilir.
İş birimi: “Vatandaş hizmet alamıyor.” diyebilir.
İletişim: “Basında veri sızıntısı haberi çıktı.” diyebilir.
Bütün bunlar aynı anda doğru olabilir. Bu nedenle kriz yönetiminin görevi yalnızca teknik olayları izlemek değildir. Farklı bilgi kaynaklarını: tek bir ortak durum görünümünde birleştirmektir.
15. Karar kaydı neden tutulmalıdır?
Kriz sırasında onlarca karar verilebilir. Örneğin:
- 10.40 — VPN erişimi kapatıldı.
- 11.05 — Vatandaş portalı azaltılmış hizmete geçirildi.
- 11.30 — Dış olay müdahale firması devreye alındı.
- 12.10 — Yedek ortamdan kurtarma kararı verildi.
Bu kararların: kim tarafından, hangi bilgiyle, hangi gerekçeyle verildiği kaydedilmelidir. Basit bir: Decision Log — Karar Kaydı şöyle olabilir:
- Birincisi olay sırasında: aynı kararın tekrar tekrar tartışılmasını azaltır.
- İkincisi olay sonrasında: “Neden böyle karar verdik?” sorusuna cevap verir.
16. Geri döndürülebilir kararlar tercih edilebilir
Tabii her olayda mümkün değildir. Ama kriz düşüncesinde yararlı soru şudur: “Bu kararı daha sonra değiştirme imkânımız var mı?”
17. Kriz sırasında iletişim teknik rapor değildir
Teknik ekip şu ifadeyi kullanabilir: “Domain admin credential compromise ve muhtemel lateral movement görüyoruz.” Bu teknik ekip için anlamlıdır.
Üst yönetim için şöyle çevrilebilir: “Merkezi kimlik altyapısına güvenimiz azalmıştır ve saldırganın diğer sistemlere erişmiş olma ihtimali bulunmaktadır.”
Kamuoyuna yapılacak açıklama ise daha farklı olabilir: “Siber güvenlik olayı nedeniyle bazı hizmetlerde geçici kısıtlamalar uygulanmaktadır. İnceleme ve güvenli hizmet geri dönüş çalışmaları devam etmektedir.”
Her seviyenin bilgi ihtiyacı farklıdır. Dolayısıyla: Teknik doğruluk korunmalı, fakat iletişim hedef kitleye göre uyarlanmalıdır.
18. Bilmediğimizi açıkça söylemek neden önemlidir?
Krizlerde en tehlikeli iletişim biçimlerinden biri: belirsiz bilgiyi kesin bilgi gibi sunmaktır. Örneğin henüz kanıt yokken: “Herhangi bir veri dışarı çıkmadı.” demek risklidir.
Daha doğru ifade: “Mevcut inceleme aşamasında veri sızıntısını doğrulayan bulgu tespit edilmemiştir; inceleme devam etmektedir.”
- İlki: kesin sonuç bildirir.
- İkincisi: mevcut kanıt durumunu bildirir.
19. Örnek kriz senaryosu
Hayali Kurum X üzerinde düşünelim.
- 09.10: EDR, iki sunucuda şifreleme davranışı tespit ediyor.
- 09.15: SOC iki sunucuyu izole ediyor.
- 09.25: Domain Administrator hesabının şüpheli kullanımına ilişkin bulgu görülüyor.
- 09.40: Vatandaş portalı hâlâ çalışıyor.
- 09.55: Yedekleme sisteminin aynı Active Directory yapısına bağlı olduğu belirleniyor.
- 10.15: Veri sızıntısı henüz doğrulanamadı.
20. Siber Kriz Karar Matrisi
Kriz kararlarını daha sistematik hale getirmek için şu model kullanılabilir:
| Seçenek | Siber risk | Hizmet etkisi | Geri dönüş kolaylığı | Belirsizlik | Karar |
|---|---|---|---|---|---|
| Açık tut | Yüksek | Düşük | Yüksek | Yüksek | ? |
| Tam kapat | Düşük/Orta | Çok yüksek | Orta | Orta | ? |
| İzole/sınırlı hizmet | Orta | Orta | Yüksek | Orta | ? |
21. Kriz liderinin görevi teknik çözüm üretmek değildir
Kriz lideri en iyi malware analisti olmak zorunda değildir. Temel görevi:
- Doğru uzmanlardan doğru bilgiyi almak,
- Belirsizlikleri anlamak,
- Çatışan öncelikleri dengelemek,
- Kararı geciktirmemek,
- Karar sahipliğini açık tutmak
- Kurumun kritik görevinin devamını sağlamaktır.
ISO 22361'in kriz liderliğini ayrı bir temel unsur olarak ele alması da kriz yönetiminin teknik uzmanlıktan farklı bir yetkinlik olduğunu göstermektedir.
22. Kriz toplantıları nasıl yönetilmelidir?
Kriz sırasında saatler süren toplantılar tehlikelidir. Çünkü saldırgan toplantı bitmesini beklemez. Daha etkili yapı: Kısa ve düzenli karar döngüleridir.
Örneğin her 30 veya 60 dakikada:
- Ne değişti?
- Yeni doğrulanan bilgi ne?
- En büyük risk ne?
- Hangi karar gerekiyor?
- Kim ne yapacak?
- Bir sonraki güncelleme ne zaman?
23. Kriz seviyesi düşürülebilir
- Saldırgan çıkarılmış,
- Kritik sistemler güvenilir duruma getirilmiş,
- Hizmet stabil hale gelmiş,
- Kalan işler normal ekiplerle yönetilebilir, duruma gelmiş olabilir.
- Personel yorgunluğu,
- Karar karmaşası,
- Gereksiz kaynak tüketimi
24. Siber kriz tatbikatı neden gereklidir?
Siber kriz yönetimini gerçek saldırıda ilk kez denemek doğru değildir. Tatbikatlarda yalnızca: SOC saldırıyı bulabildi mi? sorusuna bakmak eksiktir. Şunlar da test edilmelidir:
- Karar vericiye bilgi ne kadar hızlı ulaştı?
- Kriz seviyesi doğru zamanda yükseltildi mi?
- Doğru kişiler çağrıldı mı?
- Hizmet sahibi karara dahil edildi mi?
- Hukuk ve iletişim doğru zamanda devreye girdi mi?
- Kararlar kaydedildi mi?
- Ekipler aynı durumsal farkındalığa sahip miydi?
ENISA'nın Cyber Europe tatbikatlarının amaçları arasında da kriz prosedürlerini test etmek, yüksek baskı altında ekip performansını değerlendirmek, iş sürekliliği ve kriz yönetimi durumlarını çalışmak ve teknik, operasyonel ve stratejik seviyelerde koordinasyonu geliştirmek bulunmaktadır.
25. Türkiye açısından neden önemli?
Türkiye'nin Ulusal Siber Güvenlik Stratejisi ve Eylem Planı 2024–2028; İnsan, Savunma, Caydırıcılık ve İş Birliği temaları üzerine kurulmuş; altı stratejik amaç, 18 hedef ve 61 eylem tanımlamıştır. Planın stratejik amaçlarından biri doğrudan Siber Dayanıklılıktır.
- Teknik müdahale,
- Kurumsal koordinasyon,
- Karar yetkisi,
- İş birliği,
- Toparlanma
Siber Kriz Karar ve Eskalasyon Zinciri
Bu çalışmanın temel modelini şöyle kurabiliriz:
1 — Olayı doğrula
Gerçek bir güvenlik incident'ı var mı?
↓
2 — Etkiyi belirle
Hangi görev, hizmet, veri ve sistem etkileniyor?
↓
3 — Mevcut kapasiteyi değerlendir
Normal ekip ve süreçlerle yönetilebilir mi?
↓
4 — Eskalasyon eşiğini değerlendir
Teknik, operasyonel veya stratejik seviyeye mi taşınmalı?
↓
5 — Kriz seviyesini ilan et
Karar mekanizmasını açık hale getir.
↓
6 — Ortak durumsal farkındalık oluştur
Ne biliyoruz, ne bilmiyoruz?
↓
7 — Seçenekleri üret
A, B ve C seçenekleri neler?
↓
8 — Risk ve etkileri karşılaştır
Her seçeneğin siber ve operasyonel sonucu nedir?
↓
9 — Karar ver
Karar sahibi kim?
↓
10 — Kararı kaydet
Hangi bilgiyle neden verildi?
↓
11 — Uygula ve izle
Karar işe yaradı mı?
↓
12 — Yeniden değerlendir
Durum değişti mi?
↓
13 — De-eskale et veya artır
Normal yönetime mi dönülmeli, kriz seviyesi mi yükseltilmeli?
Bu yapıya: Siber Kriz Karar ve Eskalasyon Mimarisi adı verilebilir.
Sık yapılan siber kriz yönetimi hataları
Her kritik teknik olayı kriz ilan etmek:
Kurum gereksiz yere sürekli alarm durumunda kalabilir.
Sonuç: Siber kriz teknik problemin büyümüş hâli değildir
Bir siber kriz yalnızca: daha fazla sunucunun etkilenmesi anlamına gelmez.
Asıl fark: Olayın kurumun normal karar, kaynak ve koordinasyon kapasitesini aşmasıdır.
Bu noktada artık sadece: teknik uzmanlık yetmez. Gerekli olan:
- Durumsal farkındalık,
- Doğru eskalasyon,
- Açık karar yetkisi,
- Hizmet sürekliliği,
- Risk değerlendirmesi,
- İletişim
- Liderliktir.
Siber olay yöneticisi: “Saldırganı nasıl durduracağız?” diye sorar.
Siber kriz yöneticisi buna ek olarak: “Saldırganı durdururken, kurumun kritik görevini nasıl sürdüreceğiz ve hangi riski kabul edeceğiz?” sorusunu sormalıdır.
Bu nedenle siber krizlerde en önemli kaynak yalnızca teknoloji değildir. Karar verme kapasitesidir. En değerli güvenlik teknolojilerine sahip bir kurum:
- Karar yetkileri belirsizse,
- Bilgi üst yönetime ulaşmıyorsa,
- Kriz eşikleri tanımlı değilse,
- Ekipler farklı gerçekliklerle hareket ediyorsa