Siber Güvenlikte Risk Modeli: Önce Neyi Korumalı?#

İyi güvenlik çalışması en pahalı aracı seçmekle değil, neyin gerçekten kritik olduğunu anlamakla başlar. Bir sistemin saldırı yüzeyini ölçmeden yapılan her kontrol listesi eksik kalır; çünkü aynı zafiyet iki farklı kurumda bambaşka riskler doğurabilir.

Bu rehber; threat model, trust boundary, asset inventory, risk register ve mitigation workflow gibi kavramları tek bir çalışma akışında buluşturur. Hedef, bir "alıntı defteri" değil, haftalık otomasyona bağlanabilir bir sistem.

Risk Modeli Neden Gerekli?#

Risk modeli, teknik bulguları iş etkisiyle birleştirir. Bir testte çıkan bulgu sadece "kritik" etiketiyle kalmamalı; hangi varlığı etkilediği, hangi veriye erişim sağladığı, istismar için hangi ön koşulları istediği ve saldırganın bundan ne kazanacağı netleşmelidir.

Bu yüzden başlangıç soruları basittir:

1. Hangi varlıklar dış dünyaya açık?
2. Hangi sistemler kimlik, ödeme, müşteri verisi veya üretim erişimi taşıyor?
3. Hangi ekip hangi servisin sahibi?
4. Bir servis devre dışı kalırsa iş etkisi ne olur?
5. Log, alarm ve müdahale süreci gerçekten çalışıyor mu?

Bu sorulara verilen yanıtlar, güvenlik bütçesini ve test zamanını doğru yere taşır. Cevapları yazılı tutmak, üç ay sonra gelen yeni bir bulgunun aynı tabloda nereye oturduğunu görmek içindir.

Threat Model: Dört Adımlı Yaklaşım#

Basit ama yeterli bir threat model şöyle kurulur:

Copy code
+----------------+     +----------------+     +----------------+
| 1. Varlıklar   | --> | 2. Akışlar     | --> | 3. Güven sınırları |
+----------------+     +----------------+     +----------------+
                                                  |
                                                  v
                                     +-------------------------+
                                     | 4. Tehditler (STRIDE)   |
                                     +-------------------------+

STRIDE kategorileri:

Her servis için bu altı sorudan en az bir cevap üret; cevap "hayır, çünkü..." olmalı.

Trust Boundaries: Sınır Çizmeden Model Olmaz#

Tipik bir web servisi için sınırlar:

Copy code
[public internet]
      |  boundary A: kimlik doğrulama ve rate limit
      v
[edge / WAF]
      |  boundary B: iç ağ
      v
[app server] -- boundary C --> [DB / secret store]
      |
      |  boundary D: üçüncü taraf API
      v
[payment / SMTP / analytics]

Her sınırın önünde bir kontrol, arkasında bir kayıt olmalı:

• Boundary A: WAF kuralı, mTLS veya rate limit.
• Boundary B: network segmentation, güvenlik grubu.
• Boundary C: en az yetkiyle DB kullanıcısı, audit log.
• Boundary D: API anahtarı rotation, imzalı webhook doğrulaması.

Sınır sayısı arttıkça model karmaşıklaşır; her yeni sınır, yeni bir "burada kim ne yapabilir" sorusu getirir.

Varlık Envanteri: Güvenlik İşinin Haritası#

Varlık envanteri güncel değilse güvenlik ekibi karanlıkta çalışır. Alan adları, alt alan adları, bulut hesapları, API uçları, üçüncü taraf entegrasyonları ve geliştirme ortamları aynı tabloda izlenmelidir.

Küçük bir ekip için bile şu alanlar yeterli bir başlangıç sağlar:

Envanteri statik bir belge olarak değil, CI/CD çıktısı olarak tut. Yeni bir servis ayağa kalktığında satır otomatik eklensin; silinen servis satırı kapatılır.

Örnek bir envanter satırı:

Copy code
service: billing-api
env: prod
data: cardholder_tokens
owner: payments
criticality: high
last_reviewed: 2026-09-30
internet_exposed: true

Risk Register: Bulgu Değil, Bağlam#

Her risk register satırı şu alanları taşısın:

Bu tablo, "önemli ama sahipsiz" riskleri görünür kılar. Sahipsiz satır, gelecek olayın adıdır.

Önceliklendirme#

Tüm açıkları aynı hızda kapatmak mümkün değildir. Bu yüzden bulguları üç eksende değerlendirmek daha sağlıklıdır:

1. Etki: Başarılı istismar hangi veriyi veya yetkiyi etkiliyor?
2. Olasılık: Saldırganın ön koşulları ne kadar zor?
3. Tespit edilebilirlik: Mevcut log ve alarm yapısı bunu yakalayabiliyor mu?

Örneğin yalnızca iç ağdan erişilebilen düşük etkili bir ayar hatası ile internete açık kimlik doğrulama bypass riski aynı takvime konulmamalıdır. İyi program, en yüksek iş etkisini taşıyan yolu önce kapatır.

Basit bir öncelik matrisi:

Copy code
 Etki
  ^
  |  [icraata al]      [öncelik 1]
  |  [izle_kayıt]     [öncelik 2]
  +-------------------> Olasılık

Tespit edilebilirlik düşükse, öncelik düşük bile olsa log eklemek ucuz bir kazançtır.

Ölçülebilir Çıktı Üretin#

Güvenlik raporu sadece bulgu listesi olmamalıdır. Yönetilebilir bir güvenlik programı şu çıktıları üretir:

• Kritik varlıkların listesi
• İnternete açık servislerin kapsamı
• Tekrarlanabilir test planı
• Her bulgu için sahip ekip ve hedef tarih
• Kapatılan risklerin kanıtı
• Tekrar eden kök nedenlerin özeti

Bu yapı, penetrasyon testi, bug bounty, kod inceleme ve bulut güvenliği çalışmalarını aynı risk dilinde buluşturur.

Detection ve Mitigation Workflow#

Tipik bir bulgu kapatma akışı:

Copy code
[Bulgu] -> [Risk skorla] -> [Sahip ata] -> [Fix] -> [Re-test] -> [Kapanış]
                                          |
                                          +-- [Ara izleme: log/alarm ekle]

Alarm tarafı için pratik bir kural: her yetki verme olayını (privilege grant), her dışarıya veri akışını ve her admin paneli erişimini logla. Bu üçü, çoğu olayı erken yakalar. Alarm yorgunluğunu önlemek için her kuralın bir "haftalık örneklem" gözden geçirmesi olsun.

Log saklama politikası: hot storage 30 gün, cold storage 1 yıl. KVKK/VERBIS veya sektörel regülasyon saklama süresini zorunlu kılıyorsa politika ona göre yazılır; aksi halde log'u "süresiz" tutmak, başka bir risk üretir.

Version Differences: Risk Modelleri#

• STRIDE: tehditleri kategorize etmek için; mikroservis sınırları için uygun.
• DREAD: risk skorlamak için; modern ekiplerde öznel bulunduğu için az kullanılır ama hızlı önceliklendirmede işe yarar.
• CVSS v3.1: zafiyet skoru; exploitability, scope, confidentiality/integrity/availability.
• CVSS v4.0 (2023): Threat, Vulnerability, Environmental ve Supplemental metrikleri ayrıştırıldı; A/B koşulları ve kullanıcı etkileşimi daha net.
• EPSS (Exploit Prediction Scoring System): CVSS'in yanına pratik exploit olasılığı ekler; "en kritik, en çok sömürülen" sorusuna cevap.
• CWE/CAPEC: kök neden ve saldırı paterni; raporlarda kategori için.

Bu raporlarda tek metrik seçmek yerine CVSS + EPSS + etki üçlüsünü yan yana koy; karar tek sayıya bağlanmaz.

ASCII: Varlık -> Tehdit -> Kontrol Eşlemesi#

Copy code
asset: billing-api (prod, public)
threat: payment webhook sahte POST
control: webhook imza doğrulaması (HMAC-SHA256)
control: webhook IP allowlist
control: replay koruması (nonce + timestamp)
detection: signature mismatch -> log + alert
test: her release öncesi sahte imza testi

Her varlık için benzer bir blok yaz; bloklar bir araya geldiğinde ürünün risk haritasını çıkarırsın. Blokları Bölüm 6'daki risk register tablosuna bağla.

Mitigation Örnekleri#

Her mitigation için Detection sütununu doldurmadan satırı kapatma. Mitigation olmadan detection, gürültü; detection olmadan mitigation, kör y noktadır.

Kısa Sonuç#

Siber güvenlikte olgunluk, daha çok araç çalıştırmakla değil, doğru soruları düzenli sormakla artar. Önce varlıkları görünür yapın, sonra riskleri iş etkisine göre sıralayın, ardından düzeltme sürecini sahiplik ve kanıt üzerinden yönetin. Risk modeli tek seferlik değil, her release öncesi güncellenen canlı bir belgedir.

Örnek: Bir Özellik İçin Mini Threat Model#

Diyelim ki yeni bir "şifre sıfırlama" akışı ekledin. Varlıklar: kullanıcı tablosu, mail servisi, rate limit sayacı. Akışlar: kullanıcı -> endpoint -> mail. Tehditler:

Bu tablo, risk register satırına dönüşür; sahibi ve hedefi yazılır. Tek sayfalık threat model, sayfa sayfa dokümandan daha sık kullanılır.

Risk Skorlama: CVSS + EPSS + Etki#

Karar verirken üç sayı birlikte okunur:

• CVSS: zafiyetin teknik ağırlığı.
• EPSS: sömürülme olasılığı.
• İş etkisi: bu sistemde ne kaybedilir (veri, gelir, itibar).

Üçünü tek tabloya indirgeyip renk grafiği çizme; renk yorumu özneldir. Bunun yerine üç ayrı sütun ve her satır için tek karar cümlesi yaz. "Bu bulgu, ilgili sistemde X veriye erişim sağladığı için 7 gün içinde kapatılır."

Detection Inequalities#

Bir servisi izlerken üç metrik birlikte durur: QPS, hata oranı, p95 latency. Normal davranış tanımı, bu üç sütunun taban çizgisidir. İstisna: saldırı, üçünün de eşikleri aştığı tek nokta değildir. Bazen tek başına hata oranı artar (rate limit tetiklenmiş olabilir), bazen tek başına latency (kaynak tükendi). Alarmı tek metrik yerine kombinasyona bağla:

Copy code
if error_rate > 5% and qps > baseline * 3: page
if latency_p95 > 3x baseline and cpu > 85%: investigate
if error_rate > 20% regardless: page

Alert yorgunluğunu ölçmek için her kuralın haftalık "tetikleme sayısı / doğruluk" çiftini çıkar.

Mitigation Patterns: Hızlı Referans#

Trust Boundary Üzerine Derinlemesine#

Her sınırın önünde iki soru:

1. Bu sınırı geçen trafik, hangi kimliği taşıyor?
2. Bu trafik için hangi rate limit, hangi timeout, hangi retry politikası geçerli?

Kimlik yoksa, "rate limit" kimlik başına yapılamaz; IP bazına düşer. IP bazlı limit NAT arkası kullanıcıları tek torbaya koyar. Çözüm: token'i ilk istekte al, sonra token başına limit. Bu basit değişiklik, 401/429 oranını genelde belirgin şekilde düzeltir.

Güvenlik Borcu: Görünür Tutma#

Teknik borç gibi güvenlik borcu da birikir: legacy endpoint, geçici policy, unutulmuş env değişkeni. Bunu yönetmek için:

• Her borcun bir sahibi ve bir termination tarihi olsun.
• Borcu ekleyen PR'da // SECURITY-DEBT yorum satırı bulunsun.
• Her çeyrekte borç listesi gözden geçirilsin; kapatılanlar kutlansın, açık kalanlar yeniden önceliklendirilsin.

Borç, görünür olduğunda ertelemez; görünmez olduğunda bekler ve büyür.

Mitigation Verifier#

Her mitigation'ın yanına doğrulama adımı koy:

Copy code
mitigation: SQL injection fix (parameterized queries)
verify: sqlmap --batch --level=3 --risk=2 -u <url>
verify: hand-crafted payload: ' OR 1=1 --
success: 500 -> 400, no error message leak
next_review: next release

Doğrulanmayan mitigation, teoride güvenli pratikte yanlış yapılandırılmıştır. Doğrulama adımı olmadan satırı kapatma.