- Firewall kurarız.
- MFA uygularız.
- EDR kullanırız.
- Zafiyetleri kapatırız.
- Ağları segmentlere ayırırız.
- Kullanıcıları eğitiriz.
Bütün bunlar gereklidir. Fakat profesyonel siber güvenlik yaklaşımı daha zor bir soruyu da sormak zorundadır: Ya bütün önlemlere rağmen saldırgan başarılı olursa?
- Bir sistem ele geçirilebilir.
- Bir bulut hizmeti kesilebilir.
- Bir tedarikçi saldırıya uğrayabilir.
- Kimlik altyapısının güvenilirliği kaybedilebilir.
- Ransomware yedekleme altyapısına ulaşabilir.
- Kritik verinin bütünlüğünden şüphe edilebilir.
Bu durumda siber güvenliğin başarısı artık yalnızca: “Saldırıyı engelleyebildik mi?” sorusuyla ölçülemez.
İkinci soru ortaya çıkar: “Saldırı gerçekleşmesine rağmen kurum kritik görevini sürdürebiliyor mu?” İşte siber dayanıklılık - cyber resilience düşüncesi burada başlar.
NIST, siber dayanıklılığı sistemlerin siber kaynakları kullanan veya bu kaynaklar üzerinden gerçekleşen olumsuz koşulları, saldırıları ve kompromize durumları öngörebilme, bunlara dayanabilme, bunlardan toparlanabilme ve değişen koşullara uyum sağlayabilme kapasitesi üzerinden tanımlamaktadır. Amaç yalnızca sistemi korumak değil; siber kaynaklara bağımlılığın doğurduğu görev, iş ve kurumsal riski azaltmaktır.
1. Siber güvenlik ile siber dayanıklılık aynı şey değildir
Siber güvenlik ve siber dayanıklılık birbirinin alternatifi değildir. Birbirini tamamlar. Siber güvenliğin önemli bir bölümü:
- Saldırıyı önlemek,
- Erişimi kontrol etmek,
- Zafiyetleri azaltmak,
- Kötü niyetli faaliyeti tespit etmek
üzerine kuruludur. Siber dayanıklılık ise buna şu soruları ekler:
- Kontrol başarısız olursa ne olacak?
- Kritik hizmet devam edebilir mi?
- Ne kadar kapasiteyle devam edebilir?
- Alternatif çalışma yöntemi var mı?
- Güvenilir biçimde ne kadar sürede toparlanabiliriz?
- Toparlandıktan sonra aynı saldırıya yeniden açık mıyız?
- Olaydan sonra sistemimizi daha dayanıklı hale getirdik mi?
Dolayısıyla: Güvenlik saldırının gerçekleşme ihtimalini azaltmaya çalışır; dayanıklılık saldırının kurumsal görevi kaybettirmesini önlemeye çalışır.
Bir kurumda binlerce sistem bulunabilir. Ancak kurumun amacı: sunucuları çalıştırmak değildir. Teknoloji, kurumsal görevin gerçekleştirilmesini sağlar.
Vatandaş başvurularının alınması ve sonuçlandırılması olabilir.
Bu nedenle dayanıklılık analizi şu sırayla başlamalıdır:
Kritik görev
↓
Kritik hizmet
↓
Kritik süreç
↓
İnsan
↓
Bilgi/veri
↓
Uygulamalar
↓
Teknik altyapı
↓
Tedarikçiler ve dış bağımlılıklar
Sadece sunucunun yedeğini almak, bu zincirin tamamının dayanıklı olduğu anlamına gelmez. Örneğin uygulama çalışıyor olabilir. Ancak kimlik doğrulama hizmeti çökmüşse kullanıcılar sisteme giremeyebilir. Veri tabanı çalışıyor olabilir. Ancak kritik üçüncü taraf API'si kapalıysa hizmet yine verilemeyebilir.
3. İş sürekliliği, felaket kurtarma ve siber dayanıklılık arasındaki fark
ISO 22301:2019, kuruluşların kesintilere hazırlanmasını, bunlara cevap vermesini ve kesinti sonrasında toparlanmasını sağlayacak bir İş Sürekliliği Yönetim Sistemi için gereksinimler tanımlar. ISO'nun güncel kayıtlarında 2019 sürümü yürürlüktedir; yeni baskının hazırlanması ise 2026 itibarıyla geliştirme aşamasındadır.
4. “Sistem ayakta mı?” sorusu yeterli değildir
- Ama saldırganın: Domain Administrator yetkisine ulaştığı doğrulanmış olsun.
- Portal: çalışıyor. Fakat kimlik altyapısına güvenemiyoruz.
- Verilerin değiştirilip değiştirilmediğini bilmiyoruz.
- Saldırganın başka sistemlerde persistence mekanizması olup olmadığını bilmiyoruz.
Bu durumda: Availability var ama trustworthiness yoktur. Yani erişilebilirlik tek başına dayanıklılık değildir.
5. Dayanıklılık yüzde yüz hizmet anlamına gelmez
- Siber kriz sırasında kurumun normal kapasitesinin tamamını koruması mümkün olmayabilir.
- Örneğin normal zamanda: 100.000 işlem/gün yapan bir sistem düşünelim.
- Ransomware saldırısı sonrasında ana altyapı kullanılamıyor.
- Ancak kurum alternatif ortam üzerinden yalnızca: 20.000 kritik işlem/gün gerçekleştirebiliyor.
- Teknik açıdan kapasitenin %80'i kaybedilmiştir. Fakat en kritik işlemler devam edebiliyorsa kurumun görevi tamamen kaybolmamıştır.
Bu nedenle dayanıklılığın önemli kavramlarından biri: Minimum kabul edilebilir hizmet seviyesi dir.
Hizmet durumunu şu şekilde düşünebiliriz:
Normal hizmet
↓
Azaltılmış hizmet
↓
Öncelikli/kritik hizmet
↓
Alternatif hizmet
↓
Manuel işlem
↓
Tam hizmet kaybı
ISO'nun geliştirilmekte olan yeni ISO 22301 taslağında da kesinti sırasında ürün ve hizmetlerin önceden tanımlanmış kabul edilebilir bir kapasitede sürdürülebilmesi iş sürekliliğinin amaçlarından biri olarak ifade edilmektedir.
6. Business Impact Analysis — İş Etki Analizi neden gereklidir?
Kriz başladığında: “Hangi sistemi önce kurtaralım?” sorusunu ilk kez sormak geç kalmaktır. Bu sorunun cevabı olaydan önce hazırlanmalıdır.
İş Etki Analizi — BIA şu tür sorulara cevap vermeye çalışır:
- Hangi hizmetler kritik?
- Ne kadar süre kesilebilir?
- Kesinti büyüdükçe etkisi nasıl artar?
- Hizmet hangi sistemlere bağımlı?
- Hangi insanlar gereklidir?
- Hangi veriler olmadan çalışamaz?
- Hangi dış tedarikçilere bağımlıyız?
- Kurtarma önceliği ne olmalıdır?
NIST SP 800-34 Rev.1, contingency planning kapsamında kurumların bilgi sistemleri ve operasyonlarını değerlendirerek kurtarma gereksinimleri ve önceliklerini belirlemesini; bunun için BIA, önleyici kontroller, kurtarma stratejileri, planlar, testler ve bakım faaliyetlerini kullanmasını önermektedir.
7. RTO nedir?
Dayanıklılık ve iş sürekliliği çalışmalarında sık kullanılan kavramlardan biri: Recovery Time Objective — RTO dur. Basit ifadeyle: Bir hizmet veya sistem ne kadar sürede geri getirilmelidir?
- Örneğin: Vatandaş başvuru hizmeti: RTO = 4 saat olarak belirlenmiş olabilir.
- Bu: “Dört saat sonra kesin çalışacaktır.” garantisi değildir.
- Kurumun tasarladığı hedef kurtarma süresidir.
- RTO belirlenirken iş etkisi dikkate alınmalıdır.
- Bir sistem için: 4 saat kabul edilebilir olabilir.
- Başka bir kritik sistem için: 15 dakika bile fazla olabilir.
- Dolayısıyla RTO teknik ekibin rastgele belirlediği süre değildir. İş ihtiyacından türemelidir.
8. RPO nedir?
- Bir diğer temel kavram: Recovery Point Objective — RPO dur. RPO: Ne kadar veri kaybını tolere edebiliriz? sorusuyla ilgilidir.
- Örneğin: RPO = 1 saat ise kurtarma sırasında son bir saate kadar olan verinin kaybedilmesi kabul edilmiş olabilir.
- Ama önemli bir ayrım vardır. RPO: “Yedeği saatte bir alıyoruz.” demek değildir.
- İş ihtiyacıdır. Yedekleme tasarımı bu ihtiyaca göre yapılmalıdır.
- Örneğin banka işlemlerinde bir saatlik veri kaybı kabul edilemezken başka bir sistemde kabul edilebilir olabilir.
9. Yedeğimiz varsa dayanıklı mıyız?
- Yedek gerçekten alınıyor mu?
- Yedek tamamlandı mı?
- Geri dönüş testi yapıldı mı?
- Yedek saldırganın erişebildiği kimlik altyapısına bağlı mı?
- Yedek şifrelenebilir mi?
- Saldırgan eski yedekleri silebilir mi?
- Yedekte zararlı persistence bulunuyor olabilir mi?
- Hangi yedeğin temiz olduğundan eminiz?
- Geri döndüğümüzde kritik hizmet çalışacak mı?
NIST SP 1800-11 özellikle ransomware ve yıkıcı olaylarda hızlı kurtarmanın yanında geri getirilen verinin doğruluğuna ve bütünlüğüne güvenilebilmesini kritik görmektedir.
10. “Temiz yedek” ne demektir?
Bir yedek teknik olarak bozulmamış olabilir. Ama saldırganın sisteme girişinden sonra alınmış olabilir. Örneğin saldırgan:
- 1 Ağustos'ta sisteme girdi.
- 20 Ağustos'ta persistence oluşturdu.
- 1 Eylül'de ransomware çalıştırdı.
- Kurum 31 Ağustos yedeğini geri yükledi.
- Sistem tekrar çalışıyor.
- Fakat saldırganın persistence mekanizması da geri geldi.
Soru: “Hangi noktadan itibaren sisteme güvenebiliyoruz?” olmalıdır.
11. İzole kurtarma ortamı neden önemlidir?
Ana altyapı ele geçirilmişse kurtarma ortamının da aynı güven alanında bulunması ciddi risk oluşturabilir.
Örneğin: Production ve Backup aynı:
- Active Directory,
- Yönetici hesabı,
- Ağ,
- Sanallaştırma yönetimi
üzerinden kontrol ediliyorsa saldırganın her ikisine de ulaşma ihtimali vardır. Daha dayanıklı mimaride kurtarma sistemi:
- Farklı erişim kontrolleri,
- Sınırlı bağlantılar,
- Farklı yönetim yetkileri,
- Değiştirilemez veya korumalı yedekler
12. Graceful Degradation — Kontrollü kapasite kaybı
Dayanıklı sistemlerde yararlı tasarım fikirlerinden biri: Graceful Degradation yaklaşımıdır.
Basit ifadeyle sistemin bir bölümü kaybedildiğinde: Tamamen çökmesi yerine sınırlı kapasiteyle çalışmaya devam etmesi hedeflenir. Örneğin bir vatandaş portalında; normal dönemde:
- Yeni başvuru,
- Belge yükleme,
- Sorgulama,
- Ödeme,
- Geçmiş kayıtlar
sunuluyor olabilir. Siber kriz sırasında yalnızca: kritik yeni başvuru + sorgulama fonksiyonları açık bırakılabilir.
Diğer özellikler geçici olarak durdurulabilir. Bu yaklaşım: “Ya hep ya hiç” tasarımını kırar.
13. Alternatif çalışma yöntemleri önceden tasarlanmalıdır
Bir sistem kullanılamadığında alternatif süreç ne olacak? Bu cevap olay sırasında üretilmemelidir. Örneğin alternatifler:
- İkincil veri merkezi
- Bulut failover
- İzole DR ortamı
- Alternatif iletişim kanalı
- Başka kurum sistemi
- Sınırlı manuel işlem olabilir.
NIST'in contingency planning yaklaşımı da kesinti sırasında alternatif ekipman, alternatif lokasyon veya gerektiğinde manuel yöntemler gibi geçici çalışma seçeneklerini iş sürekliliği ve kurtarma planlamasının parçası olarak ele almaktadır.
Ancak manuel işlem de risksiz değildir. Örneğin: Kağıt form kullanmak hizmeti sürdürebilir. Ama: Veri bütünlüğü, Kişisel veri güvenliği, sonradan sisteme aktarım gibi yeni riskler oluşturabilir.
14. İnsan dayanıklılığın parçasıdır
Siber dayanıklılık sadece teknoloji değildir. Bir kriz 48 saat devam ederse:
- SOC analistleri yorulur.
- Sistem yöneticileri hata yapmaya başlayabilir.
- Karar vericilerin dikkat seviyesi düşebilir.
- Tek kişi üzerinde bulunan kritik bilgi darboğaz oluşturabilir.
Bu nedenle:
- Vardiya planı,
- Rol yedekleme,
- Yetki delegasyonu,
- Dokümantasyon,
- İletişim prosedürleri
de dayanıklılığın parçalarıdır. Bir sistem teknik olarak Redundant olabilir. Ama onu yöneten tek uzman erişilebilir değilse, sistem yine kırılgan olabilir.
15. Tedarikçi dayanıklılığı neden kritiktir?
Kurum kendi sistemlerini çok iyi koruyabilir. Ancak kritik hizmet:
- Tek bir bulut sağlayıcısına,
- Tek telekom operatörüne,
- Tek yazılım üreticisine,
- Tek API'ye
bağımlı olabilir. Bu durumda kurumun dayanıklılığı: tedarikçinin dayanıklılığı kadar güçlü olabilir.
Soru sadece: “Tedarikçimiz güvenli mi?” değil, “Tedarikçimiz tamamen kullanılamaz hale gelirse, kritik görevimizi sürdürebilir miyiz?” olmalıdır.
16. Dayanıklılık tatbikatla ölçülmelidir
Bir kurum: “DR planımız var.” diyebilir. Ama hiç test edilmediyse ne kadar güvenebiliriz?
Aynı şekilde: “Yedeklerimiz var.” demekle: “Yedekten başarıyla dönebildik.” aynı şey değildir. Dayanıklılık tatbikatlarında şu sorular ölçülebilir:
- Kritik sistem ne kadar sürede kurtarıldı?
- RTO karşılandı mı?
- RPO karşılandı mı?
- Alternatif ortam çalıştı mı?
- Veri bütünlüğü doğrulandı mı?
- Kullanıcılar hizmete erişebildi mi?
- Kritik bağımlılıklar çalıştı mı?
- Karar mekanizması zamanında devreye girdi mi?
- Beklenmeyen hangi sorunlar çıktı?
Türkiye'nin Ulusal Siber Güvenlik Stratejisi ve Eylem Planı 2024–2028 de risk temelli analizlerin acil durum ve iş sürekliliği planlamalarıyla desteklenmesini ve ulusal/uluslararası tatbikatlarla hazırlık seviyesinin ölçülerek siber dayanıklılığın geliştirilmesini açıkça hedeflemektedir.
17. Türkiye açısından siber dayanıklılık neden stratejik bir konudur?
Ulusal Siber Güvenlik Stratejisi ve Eylem Planı 2024–2028'in temel stratejik amaçlarından biri doğrudan: Siber Dayanıklılık olarak belirlenmiştir. Strateji:
- Kamu kurumlarında ve kritik altyapılarda düzenleme ve denetime dayalı yaklaşımın geliştirilmesini,
- Kurumsal, sektörel ve ulusal düzeyde risk temelli analiz ve acil durum planlamasını,
- Güvenli veri paylaşım altyapılarını,
- Standardizasyon ve test mekanizmalarının geliştirilmesini, hedeflemektedir.
Strateji belgesinde siber dayanıklılığın, özellikle kritik altyapıların ve verilerin siber risklere karşı dayanma kapasitesinin artırılmasıyla ilişkilendirildiği; Risk analizlerini, İş sürekliliği ve Acil durum planlamalarıyla desteklenmesinin, önemli görüldüğü belirtilmektedir.
18. Dayanıklılığı yalnızca “Recover” olarak düşünmemeliyiz
Siber dayanıklılık bazen: “Saldırı oldu, geri döndük.” şeklinde algılanır. Oysa NIST yaklaşımının dört temel fiili daha geniştir: Anticipate — Öngör
Neler yanlış gidebilir?
Bağımlılıklarımız nedir?
Hangi senaryolar kritik?
↓
Withstand — Dayan
Saldırı devam ederken hizmetin ne kadarını sürdürebiliriz?
↓
Recover — Toparlan
Güvenilir operasyonu nasıl geri getiririz?
↓
Adapt — Uyum Sağla
Olaydan sonra sistemimizi nasıl değiştiririz?
NIST SP 800-160 Vol. 2 Rev.1 siber dayanıklılığı tam olarak bu öngörme, dayanma, toparlanma ve uyum sağlama kabiliyetleri üzerinden kurmaktadır.
19. Adapt — Uyum sağlama neden en çok unutulan bölümdür?
- Ransomware yaşandı.
- Sistemler kurtarıldı.
- Hizmet tekrar başladı.
- Olay kapandı.
Ama şu değişmedi:
- aynı ağ mimarisi,
- aynı yetki yapısı,
- aynı yedek altyapısı,
- aynı zafiyetli süreç.
O zaman kurum: Toparlanmıştır ama daha dayanıklı hale gelmemiştir. Adapt aşamasında şu sorular sorulmalıdır:
- Bu saldırı neden başarılı oldu?
- Hangi bağımlılık beklenenden daha kritikti?
- Hangi sistem gereksiz tek hata noktası oluşturuyordu?
- RTO gerçekçi miydi?
- Yedekten dönüş neden yavaşladı?
- Karar mekanizması neden gecikti?
- Hangi kontrol beklediğimiz gibi çalışmadı?
- Bundan sonra mimariyi nasıl değiştireceğiz?
20. Siber dayanıklılık nasıl ölçülür?
“Dayanıklıyız.” tek başına ölçülebilir bir ifade değildir. Bunun yerine göstergeler kullanılabilir. Örneğin:
Kritik hizmetlerin yüzde kaçı tanımlı?BIA güncel mi?Kurtarma planları test edildi mi?
Kritik hizmet alternatif modda sürdürülebiliyor mu?Tek hata noktaları var mı?
Olayın fark edilme süresi nedir?
Containment ne kadar sürüyor?
Gerçek kurtarma süresi nedir?RTO karşılanıyor mu?RPO karşılanıyor mu?
Geri getirilen verinin bütünlüğü doğrulanabiliyor mu?
Kritik roller için yedek personel var mı?
Kritik dış bağımlılıkların alternatifleri var mı?
Olay sonrası aksiyonların yüzde kaçı zamanında kapatılıyor?
21. Örnek: Kurum X ransomware saldırısı
Hayali Kurum X'i düşünelim. Vatandaşlara 7/24 çevrimiçi hizmet veriyor. Saat 10.00: Ransomware tespit edildi. Ana uygulama ortamının güvenilirliği kaybedildi.
10.15 — Ana sistem kapatılır.
10.30 — Yedeğin aynı kimlik altyapısına bağlı olduğu fark edilir.
12.00 — Son başarılı geri yükleme testinin 18 ay önce yapıldığı anlaşılır.
16.00 — Hangi sistemin önce kurtarılacağı tartışılır.
Daha dayanıklı kurum
10.15 — Kriz seviyesi yükseltilir.
10.20 — Önceden tanımlı kritik hizmet planı devreye alınır.
10.30 — Vatandaş hizmeti azaltılmış kapasiteye geçirilir.
10.40 — Ana ortam izole edilir.
11.00 — Bağımsız kurtarma ortamında bilinen güvenilir noktadan recovery başlatılır.
12.00 — Veri bütünlüğü doğrulanır.
13.30 — Kritik hizmet kontrollü biçimde yeni ortamdan açılır.
Olay sonrası — Mimari eksiklikler düzeltici programa dönüştürülür. İki kurum da saldırıya uğramıştır.
22. Bu yazıda önerilen Siber Dayanıklılık Değerlendirme Modeli
| Boyut | Temel soru |
|---|---|
| 1. Kritik Görev | Mutlaka sürdürülmesi gereken hizmetler belli mi? |
| 2. Bağımlılık | Hizmetin insan, veri, teknoloji ve tedarik bağımlılıkları biliniyor mu? |
| 3. Hazırlık | BIA, olay ve kurtarma planları var ve güncel mi? |
| 4. Dayanma | Ana sistem kaybedildiğinde sınırlı hizmet sürdürülebiliyor mu? |
| 5. Müdahale | Olay hızlı biçimde tespit ve sınırlandırılabiliyor mu? |
| 6. Kurtarma | RTO/RPO hedefleri içinde güvenilir ortama dönülebiliyor mu? |
| 7. Doğrulama | Geri getirilen sistem ve veriye güvenildiği kanıtlanabiliyor mu? |
| 8.Uyum ve Öğrenme | Olay ve tatbikat sonuçları kalıcı iyileştirmeye dönüşüyor mu? |
Bu model herhangi bir resmî standardın birebir kopyası değildir. Bu yazı kapsamında NIST siber dayanıklılık yaklaşımı, iş sürekliliği, olay müdahalesi ve kurtarma prensiplerinin pratik bir değerlendirme modeline dönüştürülmüş örnek sentezidir.
Her boyut örneğin:
0 — Yok
1 — Başlangıç
2 — Tanımlı
3 — Uygulanıyor
4 — Ölçülüyor
5 — Sürekli geliştiriliyor
23. Siber Dayanıklılık Zinciri
Bu çalışmanın ana modeli şöyle özetlenebilir:
1 — Görevi belirle
Neyi mutlaka sürdürmeliyiz?
↓
2 — Bağımlılıkları belirle
Bu görev neye bağlı?
↓
3 — Etkiyi analiz et
Kesinti ne zaman kabul edilemez hale gelir?
↓
4 — Minimum hizmet seviyesini belirle
Tam kapasite yoksa ne kadar hizmet yeterlidir?
↓
5 — RTO ve RPO hedeflerini oluştur
Ne kadar sürede ve ne kadar veri kaybıyla toparlanmalıyız?
↓
6 — Alternatif çalışma tasarla
Ana ortam kaybolursa ne yapacağız?
↓
7 — Kurtarma ortamını güvenli tasarla
Aynı saldırıda onu da kaybeder miyiz?
↓
8 — Olay sırasında dayan
Kritik görevi mümkün olduğunca sürdür.
↓
9 — Güvenilir biçimde toparlan
Yalnızca çalıştırma; bütünlüğü doğrula.
↓
10 — Test et
Plan gerçek hayatta çalışıyor mu?
↓
11 — Ölç
RTO, RPO ve hizmet hedefleri karşılandı mı?
↓
12 — Öğren ve uyum sağla
Bir sonraki olaya daha güçlü gir.
Buna: Siber Dayanıklılık ve Görev Sürekliliği Zinciri adı verilebilir.
Sonuç: Dayanıklılık saldırıyı engellemekten daha zor bir sorudur
Siber güvenlikte uzun süre temel başarı ölçütü: “Saldırgan içeri girebildi mi?” sorusu olmuştur. Bu soru önemlidir. Ama tek başına yeterli değildir.
Daha olgun soru: “Saldırgan içeri girdiğinde kurum görevini kaybetti mi?” olmalıdır.
Gerçek siber dayanıklılık: saldırıyı kabul etmek değildir. Saldırının kurumsal felakete dönüşmesini engelleyecek kapasiteyi önceden tasarlamaktır. Bu kapasite:
- Güvenlik mimarisini,
- İş sürekliliğini,
- Yedeklemeyi,
- Olay müdahalesini,
- Kriz kararlarını,
- Alternatif çalışma yöntemlerini,
- İnsan kaynağını,
- Tedarikçileri
- Kurumsal öğrenmeyi, birlikte gerektirir.
Dayanıklı kurum: Hiç saldırıya uğramayan kurum değildir.
Daha doğru ifade: Saldırıya uğradığında kritik görevini kaybetmeyen, güvenilir biçimde toparlanan ve olaydan sonra kendisini daha güçlü hale getiren kurumdur.
Bu nedenle siber güvenliğin nihai hedeflerinden biri yalnızca: sistemi korumak değil, görevin devamını güvence altına almaktır.