- Ancak elektrik kesildiğinde telekom baz istasyonları yedek güç kaynaklarına geçer.
- Yedek güç belirli süre sonra tükenebilir.
- Telekom hizmeti bozulduğunda internet ve veri iletişimi etkilenir.
- İletişim kesildiğinde ödeme sistemleri çalışmakta zorlanabilir.
- Hastanelerin bazı dijital hizmetleri etkilenebilir.
- Ulaşım ve lojistik sistemlerinin haberleşmesi aksayabilir.
- Kamu kurumlarının çevrimiçi hizmetleri yavaşlayabilir veya durabilir.
Bir süre sonra artık: “Elektrik sistemi çalışmıyor.” probleminden söz etmeyiz.
Karşımızda: Bir altyapıdaki kesintinin başka hizmetlere yayıldığı sistemik bir problem vardır. Modern toplumları oluşturan altyapılar birbirlerinden bağımsız sistemler değildir.
- Enerji telekomünikasyona,
- Telekom enerjiye,
- Finans iletişim altyapısına,
- Ulaşım enerji ve haberleşmeye,
- Kamu hizmetleri veri merkezlerine,
- Veri merkezleri enerji ve telekom altyapısına,
- Kurumlar ise bulut, yazılım ve dış hizmet sağlayıcılara, bağımlıdır.
CISA'nın altyapı bağımlılıkları yaklaşımı da kritik altyapı sistemlerinin yüksek derecede birbirine bağlı olduğunu ve bir sistemdeki kesintinin başka kritik sistemlere yayılan cascading — zincirleme etkiler oluşturabileceğini özellikle vurgulamaktadır.
1. Kritik altyapı nedir?
Türkiye'de 7545 sayılı Siber Güvenlik Kanunu kritik altyapıyı, işlediği bilgi veya verinin gizlilik, bütünlük ya da erişilebilirliğinin bozulmasının can kaybı, büyük ölçekli ekonomik zarar, güvenlik açıkları veya kamu düzeninin bozulması gibi ciddi sonuçlara yol açabileceği bilişim sistemlerini barındıran altyapılar üzerinden tanımlamaktadır.
Aynı Kanun kritik kamu hizmeti kavramını da tanımlar. Burada vurgu yalnızca kullanılan teknolojiye değil, hizmetin kesintiye uğramasının:
- Ulusal güvenlik,
- Toplumsal veya ekonomik refah,
- Kamu düzeni,
- Kamu sağlığı
- Veya başka hizmetlerin sunumu
- Çok pahalı olduğu için,
- Çok büyük olduğu için
- Veya ileri teknoloji kullandığı için, kritik değildir.
2. Kritikliği cihaz üzerinden değil fonksiyon üzerinden düşünmek
Kritik altyapı analizinde sık yapılan hata: “Hangi sunucular kritik?” sorusuyla başlamaktır. Oysa daha doğru başlangıç: “Hangi fonksiyonların devam etmesi gerekiyor?” sorusudur.
Örneğin: “Elektrik üretim santrali” bir varlık olabilir. Ancak korunmak istenen daha üst fonksiyon: Elektrik enerjisinin güvenilir biçimde sağlanmasıdır.
Benzer şekilde: “banka veri merkezi” bir altyapıdır. Asıl kritik fonksiyon ise: Ödeme ve finansal işlemlerin güvenilir şekilde sürdürülebilmesidir.
CISA'nın National Critical Functions yaklaşımı da kritik altyapı riskine yalnızca sektör veya varlık merkezli değil, işlev ve hizmet merkezli bakılmasının önemini vurgular. Bu yaklaşım, bir kritik fonksiyonun birden fazla sektör, sistem ve varlık tarafından birlikte üretilebileceğini kabul eder.
3. Dependency — Bağımlılık nedir?
Bir sistemin çalışabilmek için başka bir sisteme ihtiyaç duymasına: Dependency — Bağımlılık diyebiliriz. Örneğin:
- Bir veri merkezi, elektriğe bağımlıdır.
- Bir vatandaş portalı, DNS'e bağımlıdır.
- Bir ödeme sistemi, telekom altyapısına bağımlıdır.
- Bir kurum, kimlik doğrulama hizmetine bağımlıdır.
- Bir uygulama, dış API'ye bağımlıdır.
4. Interdependency — Karşılıklı bağımlılık
Bir sistem A, sistem B'ye; sistem B de sistem A'ya bağımlıysa: Interdependency — Karşılıklı Bağımlılık oluşur.
En güçlü örneklerden biri: Enerji ↔ Telekomünikasyon ilişkisidir. Telekom altyapısının çalışması için elektrik gerekir. Ancak modern enerji sistemlerinin izlenmesi, kontrol edilmesi ve yönetilmesinde telekomünikasyon altyapısı da kritik öneme sahiptir.
Dolayısıyla: Enerji → Telekom ve aynı zamanda: Telekom → Enerji bağımlılığı bulunabilir.
CISA'nın altyapı bağımlılık rehberi enerji ve iletişim sistemlerinin sıkça karşılıklı bağımlı olduğunu; enerji altyapısının diğer kritik sistemlere güç sağlarken iletişim altyapısının da modern altyapıların kontrol ve yönetiminde temel rol oynadığını belirtmektedir.
ENISA da ICS/SCADA sistemlerinin üçüncü taraf iletişim altyapılarına bağımlılığını ve kritik altyapılar arasındaki bağımlılıkların çoğu zaman çift yönlü olabileceğini vurgulamaktadır.
5. Dört farklı bağımlılık türü
Kritik altyapı bağımlılıkları yalnızca teknik bağlantılardan oluşmaz. CISA ve ENISA çalışmalarında kullanılan sınıflandırmalardan yararlanarak dört temel kategori düşünülebilir.
Bu tablo kritik bir şeyi gösterir: Bütün bağımlılıklar ağ diyagramında görünmez.
Örneğin iki sistem arasında teknik bağlantı olmayabilir. Ama ikisi de aynı binada bulunuyorsa: ortak fiziksel riskleri vardır.
İki şirketin sistemleri ayrı olabilir. Ama ikisi de aynı bulut sağlayıcısına bağımlıysa: ortak hizmet bağımlılığı vardır.
6. Cascading Failure — Zincirleme çöküş nasıl oluşur?
Basit bir örnek düşünelim.
Elektrik
↓
Telekom
↓
İnternet
↓
Bulut hizmeti
↓
Kamu uygulaması
↓
Vatandaş hizmeti
- Telekom altyapısında oluşur.
- Telekom altyapısının bazı bileşenleri yedek güçle çalışmaya devam eder.
- Bir süre sonra yedek kapasite azalır.
- İnternet bağlantıları bozulur.
- Kurumun bulut hizmetine erişimi kaybolur.
- Uygulama teknik olarak bulutta çalışıyor olabilir.
- Ancak kurum veya kullanıcılar ona ulaşamaz.
Sonuç: vatandaş hizmeti kesilir.
İlginç nokta şudur: Vatandaş uygulaması saldırıya uğramamıştır. Bulut sağlayıcı saldırıya uğramamıştır. Kurumun sunucuları saldırıya uğramamıştır. Ama hizmet yine kaybedilmiştir.
Çünkü: Kritik hizmet kendi güvenliğinden daha geniş bir bağımlılık zincirinin sonucudur.
7. Birinci, ikinci ve üçüncü derece etkiler
Kritik altyapı risk analizinde yalnızca ilk etkiye bakmak yetersizdir. Örneğin telekom kesintisi yaşandı.
8. Sistemik siber risk nedir?
Sistemik siber risk için bütün kurumlar ve standartlar tarafından kullanılan tek bir evrensel tanım bulunmayabilir.
Bu çalışma kapsamında kavramı şöyle kullanabiliriz: Bir siber olayın, ortak bağımlılıklar veya karşılıklı bağlantılar nedeniyle ilk etkilenen sistemin sınırlarını aşarak çok sayıda kurum, hizmet veya sektörde eşzamanlı ya da zincirleme bozulma oluşturabilme riski.
Normal kurumsal risk: Kurum A'nın sisteminin kaybedilmesi olabilir.
Sistemik risk ise: Kurum A'nın kaybının B, C, D ve E kurumlarının hizmetlerini de etkilemesi ile ilgilidir.
Dolayısıyla sistemik riskte: etki alanı büyür, bağımlılıklar çoğalır, tek kurumun kontrol kapasitesi azalır.
9. Single Point of Failure — Tek hata noktası
Bir sistemin çalışması tamamen tek bir bileşene bağlıysa: Single Point of Failure - SPOF ortaya çıkabilir.
Örneğin bir kurumun: iki veri merkezi, yüz sunucusu, çok sayıda güvenlik ürünü bulunabilir. Ancak iki veri merkezinin de internete çıkışı aynı tek telekom hattına bağlıysa: telekom bağlantısı SPOF olabilir.
Benzer şekilde: bütün sistemler tek bir DNS hizmetine, tek bir Active Directory yapısına, tek bir sanallaştırma yönetim platformuna, tek bir depolama sistemine bağlı olabilir.
Bu durumda görünüşte çok sayıda sistem vardır. Ama gerçek dayanıklılık tek bir bileşene bağlıdır. Bu nedenle mimari analizde şu soru sorulmalıdır: “Bu bileşeni tamamen kaybedersek başka hiçbir şey yapmadan hizmetimiz devam edebilir mi?”
10. Redundancy her zaman gerçek yedeklilik değildir
- İki internet bağlantımız var.
- İki veri merkezimiz var.
- İki bulut bölgemiz var.
- İki DNS sunucumuz var.
Bu iyi görünebilir. Fakat iki bağlantı da aynı operatörün aynı fiziksel güzergâhından geçiyorsa ne olur?
- İki veri merkezi de aynı elektrik trafo merkezine bağımlıysa?
- İki bulut ortamı da aynı merkezi kimlik sağlayıcısına bağlıysa?
- İki DNS sunucusu aynı yönetim hesabıyla kontrol ediliyorsa?
Bu durumda: iki adet bileşen vardır. Ama: iki bağımsız dayanıklılık kapasitesi olmayabilir. Bu nedenle gerçek yedeklilik için: Failure independence — hata bağımsızlığı düşünülmelidir.
11. Common Cause Failure — Ortak nedenli çöküş
- Ancak ikisi de aynı yazılım kütüphanesini kullanıyor.
- Kütüphanede kritik zafiyet ortaya çıktı.
- Tek saldırı yöntemi iki sistemi de etkileyebilir.
Başka örnek: iki telekom operatörü kullanılıyor. Ama ikisi de belirli bölgede aynı fiziksel fiber güzergâhından geçiyor. Bir fiziksel kesinti: iki operatörü aynı anda etkileyebilir.
12. Concentration Risk — Yoğunlaşma riski
Modern dijital ekosistemde başka bir problem daha büyümektedir: Concentration Risk — Yoğunlaşma Riski Çok sayıda kurum aynı:
- Bulut sağlayıcısına,
- Yazılım üreticisine,
- Kimlik sağlayıcısına,
- DNS hizmetine,
- Yönetilen hizmet sağlayıcısına
bağımlı olabilir. Bu sağlayıcının çok güçlü güvenliğe sahip olması mümkündür. Hatta bireysel kurumların kurabileceğinden daha gelişmiş kapasiteye sahip olabilir.
Ancak büyük avantaj başka bir problem oluşturur: Tek bir hizmetteki büyük sorun aynı anda çok sayıda kurumu etkileyebilir.
NIST'in bulut sistemlerine ilişkin sistemik risk çalışmaları da kaynakların yoğunlaşmasının ekonomik ve operasyonel faydalarının yanında geniş etkili sistemik riskler oluşturabileceğine dikkat çekmektedir.
ENISA da bulut altyapılarındaki kullanıcı ve veri yoğunlaşmasının bir kesinti veya güvenlik ihlalinin çok sayıda kurum ve kullanıcıyı aynı anda etkileyebilmesi nedeniyle çift yönlü bir yapı oluşturduğunu uzun süredir vurgulamaktadır.
13. Bulut kullanmak dayanıklılık mıdır?
Bulut hizmetleri:
- Coğrafi yedeklilik,
- Otomatik ölçekleme,
- Gelişmiş güvenlik hizmetleri,
- Yüksek erişilebilirlik
- Bulut sağlayıcı tamamen kullanılamazsa ne olur?
- Kimlik sağlayıcımız ayrı mı?
- Verimizi başka ortama taşıyabilir miyiz?
- Yedekler aynı sağlayıcıda mı?
- DNS aynı ekosisteme mi bağlı?
- Kurtarma prosedürümüz gerçekten test edildi mi?
- Kritik uygulamamız belirli bir sağlayıcıya özgü servislerden dolayı taşınamaz hale geldi mi?
14. Tedarik zinciri siber riski neden sistemik olabilir?
Bir kurum yalnızca kendi geliştirdiği sistemleri kullanmaz. İçerisinde:
- İşletim sistemi,
- Açık kaynak kütüphaneler,
- Ticari yazılımlar,
- Donanım,
- Bulut hizmetleri,
- Yönetilen güvenlik hizmetleri,
- Uzaktan yönetim yazılımları
bulunabilir. Dolayısıyla saldırganın her kuruma tek tek saldırması gerekmeyebilir. Ortak kullanılan bir tedarikçi veya teknolojinin kompromize olması çok sayıda müşteriye aynı anda erişim sağlayabilir.
NIST SP 800-161 Rev.1 Update 1, kurumların satın aldıkları ürün ve hizmetlerin nasıl geliştirildiği, entegre edildiği ve işletildiği konusunda tam görünürlüğe sahip olmayabileceklerini; bu nedenle siber güvenlik tedarik zinciri risklerinin kurumun genel risk yönetimi içerisinde ele alınması gerektiğini belirtmektedir.
NIST ayrıca günümüzün bağlantılı dünyasında bütün kurumların kritik ürün ve hizmetler için başka kuruluşlara bağımlı olduğunu ve kurumların kendi tedarik ekosistemlerini bütünüyle kontrol edemediğini vurgulamaktadır.
15. MSP ve merkezi yönetim araçları neden özel risk taşır?
Managed Service Provider — MSP veya uzaktan yönetim platformları çok sayıda sistemi merkezi olarak yönetebilir. Bu büyük verimlilik sağlar. Ancak aynı özellik saldırgan açısından da değerlidir.
Bir saldırgan: 1.000 müşteriye ayrı ayrı saldırmak yerine, 1.000 müşteriyi yöneten tek platformu hedefleyebilir.
CISA, Remote Monitoring and Management platformlarının kötüye kullanılmasının yönetilen hizmet sağlayıcısı üzerinden çok sayıda müşteri ağına erişim sağlayabilmesi nedeniyle önemli ekosistem riski oluşturduğunu belirtmektedir.
16. Kritik bağımlılıkların bazıları görünmezdir
Bir kurum: “Dış bağımlılıklarımızı biliyoruz.” diyebilir. Listede:
- Elektrik sağlayıcısı
- Telekom operatörü
- Bulut sağlayıcı
bulunabilir. Ancak bulut sağlayıcının kendisi:
- Başka DNS sağlayıcısına,
- Başka sertifika otoritesine,
- Farklı yazılım tedarikçilerine,
- Başka telekom altyapılarına
bağımlı olabilir. Bu durumda: bizim tedarikçimizin tedarikçisi de bizim riskimizin parçasıdır. Bu nedenle bağımlılık haritası: birinci seviye tedarikçide bitmemelidir.
17. Kritik Bağımlılık Haritası nasıl oluşturulur?
Hayali bir vatandaş hizmetini ele alalım.
Vatandaş Başvuru Hizmeti↓Web uygulaması↓Veri tabanı↓Kimlik sistemi↓DNS↓Ağ / İnternet↓Telekom↓Enerji
Bunların yanında:
- Web uygulaması → Bulut sağlayıcı
- Kimlik sistemi → MFA sağlayıcı
- Uygulama → Başka kamu kurumunun API'si
- Operasyon → Yazılım tedarikçisi
- Kurtarma → Yedekleme sağlayıcısı
gibi başka dallar olabilir. Şimdi soruyu değiştirelim: Hangi bileşen en çok sayıda kritik fonksiyonun ortak bağımlılığıdır?
18. Dependency Graph — Bağımlılık grafiği
Bağımlılık haritasını daha ileri taşımanın yollarından biri: Dependency Graph oluşturmaktır. Grafikte:
Node — düğüm bir sistem veya hizmeti;
Edge — bağlantı bağımlılık ilişkisini temsil eder.
Örneğin:
Enerji → Veri Merkezi
Telekom → Veri Merkezi
Veri Merkezi → Kimlik Hizmeti
Kimlik Hizmeti → 25 Uygulama
19. Kritiklik merkeziyetle de ilişkilidir
Bazı bileşenler kendileri çok görünür değildir. Ancak çok sayıda hizmet onların üzerinden geçer. Örneğin:
- DNS,
- NTP,
- Active Directory,
- API Gateway,
- Ana ağ omurgası
gibi servisler kullanıcıya doğrudan hizmet vermeyebilir. Ama bunların biri çöktüğünde birçok uygulama aynı anda çalışmayı bırakabilir.
20. Zincirleme risk senaryosu
Hayali bir örnek oluşturalım. Kurum X'in kimlik sağlayıcısı kompromize oldu. Bu kimlik sistemi: 25 uygulama, VPN, bulut yönetim konsolu, yedekleme sistemi tarafından kullanılıyor. Saldırgan ayrıcalıklı hesap elde etti.
İlk etki: Kimlik sistemi Sonra:
Kimlik
↓
Bulut yönetimi
↓
Sunucular
↓
Veri tabanı
↓
Vatandaş portalı
Aynı zamanda:
Kimlik
↓
Yedekleme sistemi
↓
Kurtarma kapasitesi
etkileniyor.
21. Bir saldırının sistemik hale gelmesi için yayılması şart değildir
Bu önemli bir ayrımdır. Saldırganın onlarca kuruma doğrudan geçmesi gerekmeyebilir.
- Bir bulut sağlayıcı kullanılamaz hale gelirse: binlerce müşteri aynı anda etkilenebilir.
- Bir ortak DNS hizmeti bozulursa: çok sayıda kurumun hizmeti erişilemez hale gelebilir.
- Bir merkezi yazılım güncelleme mekanizması kompromize olursa: çok sayıda müşteri etkilenebilir.
22. Kritik altyapı risk analizinde neden “worst case” tek başına yeterli değildir?
Her şeyin aynı anda çöktüğü senaryo yazmak kolaydır. Ancak yönetime gerçek değer sağlayabilmek için: Plausible Severe Scenario - Makul Ağır Senaryo oluşturmak daha yararlıdır.
Örneğin: Telekom operatörünün bölgesel hizmeti 12 saat kullanılamaz hale gelirse hangi kritik hizmetlerimiz etkilenir?
Veya: Merkezi kimlik sağlayıcısı kompromize olur ve 24 saat güvenilir kullanılamazsa kurum hangi görevleri sürdürebilir?
23. Sistemik riski azaltmak için ne yapılabilir?
Sistemik risk tamamen ortadan kaldırılamaz. Ancak etkisi azaltılabilir.
Örneğin:
- Bağımlılık haritalama Kritik hizmetlerin neye bağımlı olduğu bilinmelidir.
- Gerçek bağımsız yedeklilik Yedek sistem aynı hata nedenine bağımlı olmamalıdır.
- Çeşitlilik Uygun durumlarda tek teknoloji veya tek sağlayıcı bağımlılığı azaltılabilir.
- Segmentasyon Bir sistemin kompromize olması diğerlerine otomatik geçiş sağlamamalıdır.
- Minimum hizmet modu Dış bağımlılık kaybedildiğinde sınırlı hizmet devam edebilmelidir.
- Veri taşınabilirliği Kritik veri gerektiğinde alternatif ortama geçirilebilmelidir.
- Tedarik zinciri risk yönetimi Kritik tedarikçiler yalnızca fiyat ve performans açısından değerlendirilmemelidir.
- Kurtarma ve çıkış planı Tedarikçi tamamen kaybedildiğinde ne yapılacağı önceden belirlenmelidir.
- Ortak tatbikatlar Birbirine bağımlı kurumlar yalnızca kendi içlerinde değil birlikte test yapmalıdır.
24. Tedarikçiye “SLA var” demek yeterli değildir
Bir hizmet sağlayıcıyla: %99,99 erişilebilirlik SLA'sı imzalanmış olabilir. Bu operasyonel açıdan değerlidir. Ama sağlayıcının gerçekten büyük siber olay yaşaması halinde: SLA hizmeti geri getirmez. Ödenen ceza kritik hizmeti sürdürmez.
Dolayısıyla sözleşmede yalnızca: uptime değil,
- Olay bildirimi,
- Kurtarma kapasitesi,
- Veri taşınabilirliği,
- Yedekleme,
- Güvenlik gereksinimleri,
- Denetim hakkı,
- Alt yükleniciler,
- Exit plan
25. Cross-Sector Exercise — Sektörler arası tatbikat
Kurumlar çoğu zaman kendi felaket senaryolarını test eder.
- Enerji kurumu enerji senaryosu.
- Telekom kurumu telekom senaryosu.
- Banka finans senaryosu.
Ancak sistemik risk: kurum sınırlarını sevmez. Bu nedenle kritik senaryolarda sektörler arası bağımlılıkların birlikte test edilmesi gerekir.
ENISA'nın 2025 tarihli siber stres testi rehberi, zincirleme arızaların azaltılabilmesi için sektörler arası ve sınır ötesi bağımlılıkların daha iyi analiz edilmesi gerektiğini özellikle vurgulamaktadır.
Örneğin tatbikat senaryosu şöyle olabilir: Büyük telekom kesintisi + siber olay + enerji yedek kapasitesi problemi. Test edilmesi gereken yalnızca teknik sistemler değildir. Aynı zamanda:
- Bilgi paylaşımı,
- Koordinasyon,
- Alternatif hizmet,
- Karar yetkileri,
- Kaynak paylaşımı, test edilmelidir.
26. Türkiye açısından kritik altyapı yaklaşımı
7545 sayılı Siber Güvenlik Kanunu, kritik altyapı ve bilişim sistemlerinin korunmasını temel hedeflerden biri olarak belirlemektedir. Kanun ayrıca Siber Güvenlik Başkanlığına kritik altyapıları ve ilgili kurumları belirleme; kamu kurumları ile kritik altyapıların varlık envanterinin tutulmasını ve kritiklik temelinde risk analizlerinin gerçekleştirilmesini sağlama görevleri vermektedir.
Siber Güvenlik Başkanlığının resmi açıklamasında da Kanunun:
- Kritik altyapıların korunması,
- Risk analizleri,
- Zafiyet testleri,
- Tehdit istihbaratı,
- Denetim ve standardizasyon, mekanizmalarını kurumsal zemine taşıdığı belirtilmektedir.
Türkiye'nin Ulusal Siber Güvenlik Stratejisi ve Eylem Planı 2024–2028'de ise Siber Dayanıklılık başlığı altında kamu kurumları ve kritik altyapılarda düzenleme ve denetim yaklaşımının geliştirilmesi ile kurumsal, sektörel ve ulusal düzeyde risk temelli analiz ve acil durum planlamasının geliştirilmesi hedeflenmektedir.
Buradaki önemli üç seviye şudur:
Kurumsal risk
↓
Sektörel risk
↓
Ulusal risk
Bir kurum kendi riskini kabul edilebilir görebilir.
27. Sistemik risk neden tek kurum tarafından yönetilemez?
Bir kurum: kendi firewall'ını, sunucusunu, kimlik sistemini yönetebilir. Ama:
- Elektrik şebekesini,
- Telekom operatörünü,
- Ulusal internet altyapısını,
- Kritik dış API'yi,
- Küresel bulut sağlayıcısını
tek başına yönetemez. Dolayısıyla sistemik risk: Koordinasyon problemi de oluşturur. Kurumların:
- Ortak risk dili,
- Bilgi paylaşımı,
- Olay koordinasyonu,
- Karşılıklı bağımlılık analizi,
- Ortak tatbikatlar, geliştirmesi gerekir.
CISA'nın kritik fonksiyon yaklaşımında da sektör bazlı silo anlayışının günümüzün çapraz sektör altyapı risklerini yönetmek için yeterli olmadığı belirtilmektedir.
28. Kritik Bağımlılık ve Zincirleme Etki Modeli
Bir kritik hizmet analizinde şu yöntemi kullanabiliriz.
1 — Kritik görevi belirle
Kaybedilmemesi gereken görev nedir?
↓
2 — Kritik hizmetleri belirle
Görevi hangi hizmetler destekliyor?
↓
3 — Doğrudan bağımlılıkları belirle
Enerji, telekom, kimlik, veri, uygulama, tedarikçi.
↓
4 — İkinci seviye bağımlılıkları belirle
Tedarikçilerimiz neye bağımlı?
↓
5 — Karşılıklı bağımlılıkları belirle
A ↔ B ilişkileri nerede?
↓
6 — Ortak bağımlılıkları bul
Çok sayıda hizmet hangi ortak bileşeni kullanıyor?
↓
7 — SPOF'ları belirle
Tek bir bileşenin kaybı hizmeti tamamen durduruyor mu?
↓
8 — Yoğunlaşma riskini değerlendir
Aynı tedarikçi veya teknoloji ne kadar yaygın?
↓
9 — Zincirleme senaryo üret
Bir düğüm kaybolursa ikinci ve üçüncü derece etkiler ne?
↓
10 — Minimum hizmet kapasitesini belirle
Bağımlılık kaybolduğunda hangi hizmet devam edebilir?
↓
11 — Bağımsız alternatif tasarla
Aynı olay alternatif sistemi de devre dışı bırakabilir mi?
↓
12 — Sektörler arası koordinasyonu test et
Bağımlı kurumlarla ortak hareket edebiliyor muyuz?
Bu modele: Kritik Bağımlılık ve Zincirleme Etki Modeli adı verilebilir.
29. Yönetim seviyesinde sorulması gereken sorular
Bir yöneticiye yüzlerce sistem bağlantısını göstermek yerine şu sorular daha değerlidir:
- Kritik görevlerimizin en önemli dış bağımlılıkları nelerdir?
- Tek bir sağlayıcının kaybı kaç kritik hizmetimizi etkiler?
- Alternatiflerimiz gerçekten bağımsız mı?
- Hangi altyapıya bağımlılığımızın ikamesi yok?
- Tedarikçimiz kaybolursa ne kadar süre çalışabiliriz?
- Başka hangi kurumlar bizim hizmetimize bağımlı?
- Biz çökersek kim çöker?
- Onlar çökerse biz ne kadar süre dayanabiliriz?
- En büyük zincirleme etki senaryomuz nedir?
- Bu senaryoyu hiç tatbik ettik mi?
30. Sık yapılan kritik altyapı risk hataları
Sadece kendi sistemine bakmak
Kritik hizmet dış bağımlılıklar nedeniyle kaybedilebilir.
Sadece birinci derece etkiyi değerlendirmek
Asıl büyük zarar ikinci ve üçüncü derece etkilerde ortaya çıkabilir.
İki sistemi otomatik olarak yedekli kabul etmek
Aynı hata nedenine bağlı iki sistem gerçek redundancy sağlamayabilir.
Tedarikçinin tedarikçisini görmemek
Dolaylı bağımlılıklar görünmeyen risk oluşturabilir.
Bulutu sınırsız dayanıklılık olarak görmek
Bulut güçlü dayanıklılık sağlayabilir; aynı zamanda yoğunlaşma ve bağımlılık yaratabilir.
SPOF'u yalnızca donanım sanmak
Kimlik sağlayıcısı, DNS, yönetici hesabı veya yazılım tedarikçisi de tek hata noktası olabilir.
Her sektörü ayrı değerlendirmek
Enerji, telekom, finans ve dijital hizmetler birbirlerinden bağımsız değildir.
Tatbikatı yalnızca kurum içinde yapmak
Sistemik risk kurum sınırlarını geçtiği için ortak bağımlılıklar da sınanmalıdır.
Sonuç: En tehlikeli sistem, sadece kendisi çöken sistem değildir
Kritik altyapı güvenliğinde başlangıç sorusu: “Hangi sistemimiz kritik?” olabilir.
Ancak daha olgun soru: “Bu sistem çökerse başka kimler çöker?” olmalıdır.
Ve bunun ardından: “Başka bir sistem çökerse biz ne kadar süre ayakta kalabiliriz?” sorusu gelir.
Modern dijital toplumda sistemler:
- Birbirlerine,
- Ortak tedarikçilere,
- Bulut hizmetlerine,
- Enerjiye,
- Telekomünikasyona,
- Kimlik sistemlerine
- Yazılım ekosistemlerine
giderek daha fazla bağımlıdır. Bu bağımlılıkların büyük bölümü verimlilik sağlar. Sorun bağımlılığın kendisi değildir. Asıl problem: Bağımlılığı bilmeden ona güvenmektir.
Bu nedenle kritik altyapı güvenliği: yalnızca daha güçlü firewall, daha fazla SOC analisti veya daha gelişmiş EDR meselesi değildir. Aynı zamanda: sistemlerin birbirleriyle nasıl yaşadığını anlamaktır.
Gerçek siber dayanıklılık için üç şeyi bilmek gerekir:
- Neye bağımlıyız?
- Kim bize bağımlı?
- Bu bağımlılık kırıldığında zincirin geri kalanına ne olur?
Bir kurumun siber risk yönetimi kendi ağ sınırında bitiyorsa: kurumsal güvenliği yönetiyor olabilir. Fakat: enerji, telekom, bulut, tedarikçi, kritik hizmet ve diğer kurumlarla olan karşılıklı bağımlılıklarını anlamaya başladığında: sistemik siber risk yönetimine geçmeye başlar.