- Fakat gerçekten öyle midir?
- Zafiyet hangi sistemdedir?
- Sistem internete açık mıdır?
- Gerçek bir saldırgan tarafından kullanılabilir mi?
- Aktif olarak istismar edildiğine ilişkin bilgi var mıdır?
- Sistemin desteklediği hizmet ne kadar kritiktir?
- Başarılı bir saldırının kuruma etkisi ne olacaktır?
- Zafiyetin istismar edilmesini zorlaştıran başka kontroller mevcut mudur?
İşte siber güvenlikte zafiyet ile risk arasındaki fark burada başlar.
Bir zafiyet teknik olarak çok ciddi olabilir ancak bulunduğu ortam nedeniyle kurumsal riski daha düşük olabilir. Buna karşılık teknik puanı daha düşük olan başka bir zafiyet, kurumun kritik hizmetinin merkezinde bulunması nedeniyle çok daha yüksek risk oluşturabilir.
Bu nedenle profesyonel siber risk yönetiminde temel soru: “Zafiyetin puanı kaç?” değil, “Bu zafiyet hangi tehdit tarafından, hangi koşullarda kullanılırsa kurumun hangi görevini ne ölçüde etkileyebilir?” olmalıdır.
1. Risk nedir?
Siber güvenlikte risk kelimesi oldukça sık kullanılmasına rağmen bazen; tehdit, zafiyet ve risk birbirinin yerine kullanılmaktadır. Bunları ayırmak gerekir.
- Bir saldırgan: tehdit kaynağıdır.
- Sistemde güncellenmemiş ve istismar edilebilir bir açık: zafiyettir.
- Saldırganın bu zafiyeti kullanarak kritik hizmete zarar vermesi ihtimali ve bunun doğuracağı sonuç ise: risktir.
Bu nedenle risk tek başına bir teknik açık değildir. Daha doğru düşünce şöyle kurulabilir: Tehdit + Zafiyet + Maruziyet + Olasılık + Etki + Mevcut Kontroller = Riskin değerlendirilmesini sağlayan bağlam
Bu ifade matematiksel bir standart formül değildir. Risk modelleri nitel, yarı nicel veya nicel yöntemler kullanabilir. Buradaki amaç riskin yalnızca “açık bulundu” şeklinde değerlendirilemeyeceğini göstermektir.
2. Risk bir senaryodur
Siber riskleri yalnızca: “Ransomware riski” veya “Yetkisiz erişim riski” şeklinde yazmak çoğu zaman fazla genel kalır. Bunun yerine, risk mümkün olduğunca bir olay zinciri halinde ifade edilmelidir.
Örneğin: “İnternete açık vatandaş portalındaki istismar edilebilir zafiyetin bir tehdit aktörü tarafından kullanılması sonucunda, uygulama sunucusuna yetkisiz erişim sağlanması, vatandaş verilerinin sızdırılması ve çevrimiçi başvuru hizmetinin kesintiye uğraması riski.”
Bu cümlede artık: tehdit, zafiyet, sistem, olay ve etki bir arada görülebilir. Bu yöntem yönetici açısından da çok değerlidir. “CVE-XXXX kritik seviyede” ifadesi teknik ekip açısından anlamlı olabilir. Ancak üst yönetici için daha anlamlı ifade: “Bu zafiyet kullanılırsa vatandaş verilerinin açığa çıkması ve başvuru hizmetinin durması mümkündür.” olacaktır.
3. Risk değerlendirmesinde ilk soru: Ne korunuyor?
Önceki çalışmamızda siber güvenliğin merkezine sistemi değil kritik görevi koymuştuk. Risk değerlendirmesinde de aynı düşünce devam eder. Bir zafiyetin anlamını belirlemek için öncelikle zafiyetin bulunduğu sistemin: hangi hizmeti desteklediği ve hizmetin: hangi kurumsal görevi gerçekleştirdiği bilinmelidir.
- Birinci sunucu yalnızca kurum içindeki test uygulamasını çalıştırıyor olabilir.
- İkinci sunucu ise vatandaşlara sunulan ve günde yüz bin işlem gerçekleştiren kritik uygulamanın parçası olabilir. Teknik zafiyet aynıdır. Fakat iş etkisi aynı değildir.
4. Tehdit nedir?
Bir zafiyetin bulunması tek başına saldırının gerçekleşeceği anlamına gelmez. Zafiyeti kullanabilecek bir tehdit kaynağı ve tehdit olayı da bulunmalıdır.
Tehdit kaynakları örneğin: Siber suç grupları, devlet destekli aktörler, içeriden kötü niyetli kullanıcılar, dikkatsiz personel veya otomatik saldırı araçları olabilir. Ancak risk değerlendirmesinde yalnızca: “Hacker saldırabilir.” demek yeterli değildir. Şunlar düşünülmelidir:
- Saldırganın motivasyonu var mı?
- Teknik kapasitesi var mı?
- İlgili zafiyet gerçekten kullanılabilir mi?
- Sisteme erişebilmesi mümkün mü?
- Benzer saldırılar görülüyor mu?
- Aktif istismar bilgisi var mı?
5. Olasılık nasıl değerlendirilir?
Basit risk analizlerinde olasılık genellikle: Düşük – Orta – Yüksek şeklinde sınıflandırılır.
Daha gelişmiş modellerde ise; geçmiş olay sayısı, tehdit istihbaratı, saldırı yüzeyi, exploit kullanılabilirliği ve kontrol etkinliği gibi verilerden yararlanılabilir. Ancak burada önemli bir hata yapılmamalıdır. Olasılık tahmini kesin gelecek tahmini değildir. “Yüksek olasılık”: “Bu saldırı kesin olacaktır.” anlamına gelmez.
Mevcut bilgiler ışığında diğer senaryolara kıyasla daha fazla gerçekleşme ihtimali bulunduğunu ifade eder.
6. Etki nasıl değerlendirilir?
Risk değerlendirmesinin en önemli fakat bazen en zayıf yapılan bölümü etkidir. Çoğu değerlendirme yalnızca: Gizlilik – Bütünlük – Erişilebilirlik üzerinden yapılır. Bunlar gereklidir fakat yönetici seviyesinde daha geniş düşünmek gerekir. Bir siber olay şu sonuçları doğurabilir:
- Operasyonel etki: Hizmet durabilir.
- Finansal etki: Gelir kaybı veya ek maliyet oluşabilir.
- Hukuki/düzenleyici etki: Bildirim veya sorumluluklar ortaya çıkabilir.
- İtibar etkisi: Kuruma duyulan güven zarar görebilir.
- Stratejik etki: Kurumun hedeflerini gerçekleştirmesi gecikebilir.
- Toplumsal etki: Kritik kamu hizmetleri etkilenebilir.
- Güvenlik etkisi: Kritik altyapı veya insanların güvenliği etkilenebilir.
Bu nedenle “veri tabanı zarar görebilir” ifadesi yönetici için yeterli değildir. Daha anlamlı ifade: “Veri tabanının bütünlüğünün kaybedilmesi halinde başvuru bilgilerinin doğruluğuna güvenilemeyecek ve kurumun başvuruları hukuken ve operasyonel olarak sağlıklı biçimde sonuçlandırması mümkün olmayabilecektir.”
7. Risk = Olasılık × Etki midir?
Çok kullanılan basit model: Risk = Olasılık × Etki şeklindedir. Bu yöntem özellikle başlangıç seviyesindeki kurumsal risk matrislerinde yararlı olabilir.
| Olasılık | Etki | Risk |
|---|---|---|
| Düşük | Düşük | Düşük |
| Orta | Yüksek | Yüksek |
| Yüksek | Kritik | Kritik |
Ancak bu matematiksel ifade evrensel risk formülü değildir. Risk analizinde kullanılan yöntem kurumun ihtiyacına göre; nitel, yarı nicel veya nicel olabilir. Önemli olan 5×5 matris kullanmak değil; değerlendirmelerin: tutarlı, açıklanabilir ve tekrar edilebilir olmasıdır.
NIST SP 800-30, risk değerlendirmelerinin hazırlanması, gerçekleştirilmesi ve sürdürülmesine yönelik bir süreç sunarken, değerlendirme sonuçlarının karar süreçlerini desteklemesini temel amaçlardan biri olarak ele alır.
8. CVSS puanı neden risk değildir?
Bu ayrım siber güvenlik alanında özellikle önemlidir. CVSS — Common Vulnerability Scoring System — zafiyetlerin teknik özelliklerini ve şiddetini ifade etmek için kullanılan bir sistemdir.
Güncel CVSS 4.0 dört metrik grubu kullanır: Base, Threat, Environmental ve Supplemental.
FIRST, CVSS 4.0 kullanıcı rehberinde özellikle; CVSS Base Score'un zafiyet şiddetini ölçtüğünü, tek başına risk değerlendirmesi olarak kullanılmaması gerektiğini açıkça vurgulamaktadır. Bu ayrım çok önemlidir.
Örneğin iki sistemde aynı CVSS 9,8 zafiyeti bulunsun.
- Sistem A: İnternete açık, vatandaş verisi taşıyor, aktif olarak kullanılıyor.
- Sistem B: İnternete kapalı, izole test ağı içinde ve gerçek veri taşımıyor.
CVSS Base skoru aynı olabilir. Ancak kurum açısından riskleri aynı olmayabilir.
9. Mevcut kontroller risk değerlendirmesini değiştirir
Bir risk senaryosu belirlendiğinde mevcut güvenlik kontrolleri incelenmelidir.
Örneğin internete açık bir uygulamada zafiyet var. Fakat kurum: WAF, ağ segmentasyonu, MFA, EDR, sıkı yetkilendirme, olay izleme ve güçlü loglama kullanıyor olabilir. Bu kontroller zafiyeti ortadan kaldırmayabilir. Ancak saldırının gerçekleşme ihtimalini veya doğuracağı etkiyi azaltabilir.
Burada iki önemli kavram ortaya çıkar.
- Doğal / inherent risk Kontroller dikkate alınmadan düşünülen risk seviyesi.
- Artık / residual risk Kontroller uygulandıktan sonra geriye kalan risk.
10. Risk iştahı nedir?
Her riski tamamen ortadan kaldırmak mümkün değildir. Hatta bazen teknik olarak mümkün olsa bile maliyet açısından mantıklı olmayabilir. Örneğin; değeri 100 bin TL olan bir risk için 20 milyon TL maliyetli bir kontrol kurulması her durumda rasyonel olmayabilir.
Dolayısıyla kurumun hangi tür ve miktardaki riski hedeflerini gerçekleştirirken kabul etmeye hazır olduğunu belirlemesi gerekir.
NIST bunu risk appetite — risk iştahı olarak tanımlar. NIST'in güncel sözlüğünde risk iştahı, kurumun değer üretme arayışında geniş seviyede kabul etmeye istekli olduğu risk türü ve miktarı olarak açıklanmaktadır.
Buna yakın ancak daha operasyonel kavram: risk tolerance — risk toleransı dır.
NIST kaynaklarında risk toleransı, kurumun veya paydaşın hedeflerine ulaşmak amacıyla belirli seviyedeki risk veya kalan riski taşıma konusundaki kabul edilebilirlik düzeyiyle ilişkilendirilir.
11. Risk kabulü “hiçbir şey yapmamak” değildir
Bir kurum bazı riskleri kabul edebilir. Ancak: “Şimdilik böyle kalsın.” risk kabulü değildir.
Profesyonel risk kabulünde en azından:
- Riskin ne olduğu,
- Etkisinin ne olabileceği,
- Hangi kontrollerin bulunduğu,
- Neden ek önlem alınmadığı,
- Kimin kabul ettiği,
- Ne zamana kadar geçerli olduğu
belirlenmelidir. Çünkü risk kabulü aslında bir yönetim kararıdır.
12. Siber risk kayıt defteri neden önemlidir?
Riskler insanların hafızasında veya e-posta zincirlerinde tutulmamalıdır. Kurumsal bir Siber Risk Kayıt Defteri — Cybersecurity Risk Register oluşturulmalıdır.
NIST IR 8286 Rev.1, siber risk bilgilerinin risk kayıtları üzerinden kurumsal risk yönetimine aktarılmasını özellikle ele almaktadır. Amaç yalnızca teknik riskleri listelemek değil, bu riskleri kurumun daha geniş misyon ve iş hedefleriyle ilişkilendirmektir. Örnek bir kayıt şöyle olabilir:
| Alan | Örnek |
|---|---|
| Risk ID | SR-2026-001 |
| Kritik hizmet | Vatandaş başvuru hizmeti |
| Risk senaryosu | Portal zafiyetinin istismar edilmesi sonucu yetkisiz erişim |
| Tehdit | Dış tehdit aktörü |
| Zafiyet | İnternete açık kritik uygulama açığı |
| Olasılık | Yüksek |
| Etki | Kritik |
| Doğal risk | Kritik |
| Mevcut kontroller | WAF, EDR, MFA, SIEM |
| Artık risk | Yüksek |
| Risk sahibi | Hizmetten sorumlu yönetici |
| Risk cevabı | Azaltma |
| Planlanan işlem | Güncelleme + geçici telafi edici kontrol |
| Hedef tarih | 15.10.2026 |
| İzleme göstergesi | Exploit faaliyeti / saldırı girişimleri |
13. Risklere nasıl cevap verilir?
Risk belirlendikten sonra yönetimin bir karar vermesi gerekir.
Genel olarak risk: azaltılabilir, kaçınılabilir, paylaşılabilir/transfer edilebilir veya kabul edilebilir. Örneğin kritik zafiyet için:
- Azaltma: Güncelleme uygulanır veya telafi edici kontroller kurulur.
- Kaçınma: Riskli hizmet tamamen kaldırılır.
- Paylaşma/transfer: Belirli finansal sonuçlar sigorta veya sözleşme ile başka tarafa aktarılabilir; ancak sorumluluğun tamamı ortadan kalkmayabilir.
- Kabul: Kalan risk yetkili makam tarafından bilinçli şekilde kabul edilir.
NIST IR 8286B, siber risklerin kurumun hedefleri üzerindeki etkilerine göre önceliklendirilmesini ve uygun risk cevaplarının değerlendirilmesini kurumsal risk yönetimiyle ilişkilendirir.
14. Teknik bulgu yönetici diline nasıl çevrilir?
Örnek teknik bulgu: “Internet-facing Apache sunucusunda CVSS 9.8 RCE açığı tespit edildi.” Teknik ekip açısından yeterince açık olabilir. Fakat yönetim açısından şu bilgi eksiktir: Bunun bize etkisi nedir?
Daha güçlü ifade şöyle olabilir:
- Vatandaş başvuru portalında uzaktan kod çalıştırmaya imkân verebilecek kritik bir zafiyet bulunmaktadır.
- Başarılı istismar halinde saldırgan uygulama sunucusuna yetkisiz erişim sağlayabilir;
- vatandaş verilerinin gizliliği ve bütünlüğü zarar görebilir ve başvuru hizmeti kesintiye uğrayabilir.
- Sistem internete açık olduğu için maruziyet yüksektir.
- Mevcut kontroller riski kısmen azaltmakla birlikte artık risk kurumun belirlenen tolerans seviyesinin üzerindedir.
- Güncellemenin öncelikli olarak uygulanması önerilmektedir.”
Artık yönetici şunları anlayabilir:
- Ne oldu?
- Neyi etkiliyor?
- Ne kadar ciddi?
- Neden ciddi?
- Ne yapmalıyız?
15. Risk puanı tek başına yeterli değildir
İki riskin puanı aynı olabilir. Örneğin:
Risk A: Olasılık 5 × Etki 4 = 20
Risk B: Olasılık 4 × Etki 5 = 20
Her ikisi de 20 puandır. Ama aynı risk değildir.
- Birincisi sık meydana gelebilecek ancak; nispeten daha sınırlı etkili bir olay olabilir.
- İkincisi daha az olası ancak; gerçekleştiğinde kurumun görevini tamamen durdurabilecek bir olay olabilir.
Bu nedenle yalnızca toplam puan değil: riskin karakteri de incelenmelidir.
16. Siber risk ile kurumsal risk birbirinden ayrı tutulmamalıdır
Bir ransomware saldırısının teknik sonucu: sunucuların şifrelenmesi olabilir. Kurumsal sonuç ise:
- Üretimin durması,
- Vatandaşa hizmet verilememesi,
- Finansal kayıp,
- İtibar zararı
- Yasal sorumluluk
NIST IR 8286 Rev.1, siber güvenlik risklerinin daha geniş Enterprise Risk Management — Kurumsal Risk Yönetimi süreçleriyle bütünleştirilmesini ve üst yöneticilerin kurumun siber risk duruşunu anlayabilmesini özellikle vurgulamaktadır.
Siber Riskten Yönetici Kararına Modeli
Bu çalışmada kullanılabilecek basit bir karar zinciri şöyle ifade edilebilir:
1. Kritik görevi belirle
Ne korunuyor?
↓
2. Kritik hizmeti belirle
Görevi hangi hizmet gerçekleştiriyor?
↓
3. Risk senaryosunu yaz
Ne yanlış gidebilir?
↓
4. Tehdit ve zafiyeti belirle
Kim, hangi zayıflığı kullanabilir?
↓
5. Maruziyeti değerlendir
Saldırganın bu sisteme ulaşması ne kadar mümkün?
↓
6. Olasılığı değerlendir
Senaryonun gerçekleşmesi ne kadar makul?
↓
7. Etkiyi değerlendir
Gerçekleşirse kuruma ne olur?
↓
8. Mevcut kontrolleri değerlendir
Riski bugün neler azaltıyor?
↓
9. Artık riski belirle
Kontroller sonrasında ne kadar risk kaldı?
↓
10. Risk iştahı ve toleransıyla karşılaştır
Kalan risk kabul sınırımızın içinde mi?
↓
11. Risk cevabını seç
Azalt, kaçın, paylaş veya yetkili makamla kabul et.
↓
12. Risk sahibini ve tarihi belirle
Kararın sahibi kim ve ne zaman yeniden değerlendirilecek?
↓
13. İzle ve kanıtla
Risk gerçekten azaldı mı?
Sık yapılan siber risk hataları
- İlk hata, zafiyeti doğrudan risk olarak kabul etmektir. Bir CVE'nin bulunması önemlidir ancak kurumsal risk için bağlam gerekir.
- İkinci hata, CVSS puanını risk puanı olarak kullanmaktır. FIRST açık biçimde CVSS Base Score'un şiddet ölçtüğünü ve tek başına risk değerlendirmesi olarak kullanılmaması gerektiğini belirtmektedir.
- Üçüncü hata, yalnızca olasılık × etki tablosu oluşturup süreci bitirmektir. Risk matrisi karar aracıdır; kararın kendisi değildir.
- Dördüncü hata, risk sahibini belirlememektir. Sahibi olmayan risk çoğu zaman yönetilmeyen risktir.
- Beşinci hata, kontrolün varlığını kontrolün etkinliğiyle karıştırmaktır. Bir EDR kurulmuş olması, bütün kritik sistemlerde doğru biçimde çalıştığını kanıtlamaz.
- Altıncı hata, risk kabulünü süresiz bırakmaktır. Risk koşulları değişebilir; yeni exploit yayımlanabilir veya kritik hizmetin önemi artabilir.
- Yedinci hata ise teknik bulguları üst yönetime teknik dilde taşımaktır. Yönetici CVE numarasından çok görev, hizmet, etki ve karar ihtiyacını bilmelidir.
Sonuç: Risk puan değil, karar bilgisidir
Siber güvenlikte risk yönetiminin amacı en uzun zafiyet listesini hazırlamak değildir. En fazla kırmızı hücreyi gösteren risk matrisi de değildir.
Asıl amaç: Kurumun sınırlı kaynaklarını gerçekten önemli risklere yönlendirebilmesi için doğru karar bilgisini üretmektir.
Bunun için teknik uzman;
- Zafiyeti bilmeli,
- Tehdidi anlamalı,
- Sistemin nasıl çalıştığını bilmeli,
- Kritik hizmeti tanımalı,
- İş etkisini değerlendirmeli,
- Kontrolleri sorgulamalı
- Ve sonunda bütün bunları, yönetimin anlayabileceği bir dile çevirebilmelidir.
Dolayısıyla siber risk zinciri: Zafiyet → Tehdit → Olasılık → Etki → Kontrol → Artık Risk → Karar şeklinde ilerler.
Ancak bunun üzerinde daha önemli bir soru vardır: “Bu risk kurumun hangi kritik görevini etkiliyor?” Bu soru sorulduğunda teknik siber güvenlik ile kurumsal yönetim birbirine bağlanmaya başlar.
Bir güvenlik uzmanının değerini yalnızca kaç zafiyet bulduğu değil, hangi zafiyetin gerçekten önemli olduğunu açıklayabilmesi ve yöneticinin doğru kararı verebilmesi için gerekli bilgiyi üretebilmesi de belirler.