Tehdit Modelleme (Threat Modeling)

1. Giriş

Uygulama güvenliğinin en pahalı hatası, güvenliği bir test aşaması sanmaktır. Kod yazılır, biter, sonra "güvenlik ekibi baksın" denir. Oysa bir açığın maliyeti, yaşam döngüsünde ne kadar geç bulunursa o kadar katlanarak artar: tasarımda yakalanan bir kusur bir toplantıda çözülürken, üretimde patlayan aynı kusur bir veri ihlali, yasal süreç ve itibar kaybına dönüşür.

Tehdit modelleme, bu maliyeti öne çekmenin disiplinidir. Kod yazılmadan, hatta bazen tek satır atılmadan önce, sistemin tasarımına bakıp "bir saldırgan burada ne yapardı?" sorusunu yapısal olarak sorar. Askeri ve mühendislik kökenli bu yaklaşım, 1990'ların sonunda Microsoft'un güvenlik krizleriyle boğuştuğu dönemde yazılım dünyasına sistematik biçimde girdi ve bugün Secure SDLC'nin (Bölüm 3) kalbinde yer alır.

Tehdit modelleme bir araç değil, bir düşünme alışkanlığıdır. Amaç, her senaryoyu öngörmek değil — bu imkânsızdır — sistemli bir mercek altında körlük noktalarını azaltmaktır.

2. Dört Temel Soru

Karmaşık çerçevelerden önce, tehdit modellemenin özü dört sorudur (Adam Shostack'in formülasyonu):

1. Ne inşa ediyoruz? — Sistemi anlamadan tehdit edilemez. Veri akışları, bileşenler, güven sınırları.
2. Ne ters gidebilir? — Tehditlerin sistematik listelenmesi (STRIDE burada devreye girer).
3. Bu konuda ne yapacağız? — Her tehdit için karar: azalt, aktar, kabul et veya ortadan kaldır.
4. İşimizi iyi yaptık mı? — Doğrulama; modelin gerçekle örtüşüp örtüşmediği.

Bu dört soru, ölçekten bağımsız çalışır: bir mikroservise de, tek bir yeni forma da uygulanabilir.

3. Sistemi Modelleme: Veri Akış Diyagramı (DFD)

"Ne inşa ediyoruz?" sorusunun yanıtı bir Veri Akış Diyagramıdır (Data Flow Diagram). DFD dört öğe kullanır: dış varlıklar (kullanıcı, 3. parti API), süreçler (PHP uygulaması), veri depoları (veritabanı, dosya sistemi) ve veri akışları (oklar). En kritik öğe ise güven sınırlarıdır — verinin güvenilirlik seviyesinin değiştiği çizgiler.

Tipik bir PHP e-ticaret uygulamasının basitleştirilmiş DFD'si:

   [Kullanıcı]                    [Ödeme Sağlayıcı (3. parti)]
       │                                    ▲
       │ HTTP                               │ HTTPS
       ▼                                    │
  ╳═══════════ GÜVEN SINIRI 1 (İnternet) ═══════════════╳
       │                                    │
   ( Nginx )──▶( PHP-FPM: Uygulama )────────┘
                     │        │
       ╳═══ SINIR 2 ═╳        ╳═══ SINIR 3 ═══╳
                     ▼                        ▼
              [ MySQL ]                [ Redis: Session ]
                     ▲
       ╳═══ SINIR 4 (Admin ağı) ═══╳
                     │
              ( Admin Paneli )

Her güven sınırı, tehdit modellemenin odak noktasıdır. Veri bir sınırı her geçtiğinde şu sorulur: Bu veri artık güvenilir mi? Doğrulanıyor mu? Kim erişebiliyor? Sınır 4 (admin ağı) örneğinde, admin panelinin internete açık olup olmadığı tek başına bir tehdit kararıdır.

4. STRIDE ile Tehdit Bulma

STRIDE, "ne ters gidebilir?" sorusunu altı tehdit kategorisine böler. Her kategori, ihlal edilen bir güvenlik özelliğinin karşıtıdır:

Uygulama yöntemi: DFD'deki her öğeye ve her akışa STRIDE merceğini tutun. Örneğin "Kullanıcı → Uygulama" akışında: - Spoofing: Kullanıcı başkası gibi mi davranabilir? (oturum çalma) - Tampering: Gönderilen veri kurcalanabilir mi? (fiyat alanını değiştirmek) - Information Disclosure: Yanıt fazla mı bilgi sızdırıyor? (hata detayı) - DoS: Bu uç nokta bir istekle aşırı kaynak tüketebilir mi?

Basitleştirilmiş bir kural: süreçler altı tehdidin tümüne, veri akışları tampering/disclosure/DoS'a, veri depoları tampering/disclosure/repudiation'a açıktır. Bu eşleme, hangi öğeye hangi soruları soracağınızı hızlandırır.

5. Riski Önceliklendirme

Bulunan her tehdit eşit değildir. Sınırlı kaynağı doğru yere harcamak için önceliklendirme gerekir. İki yaygın yaklaşım:

Basit matris (çoğu ekip için yeterli): Her tehdide etki (düşük/orta/yüksek) ve olasılık (düşük/orta/yüksek) atayın. Yüksek-yüksek olanlar önce ele alınır.

             Etki →
          Düşük  Orta  Yüksek
Olasılık ┌──────┬──────┬──────┐
 Yüksek  │  Orta│ Yüksek│ KRİTİK│
  Orta   │ Düşük│  Orta │ Yüksek│
 Düşük   │ Düşük│ Düşük │  Orta │
         └──────┴──────┴──────┘

CVSS (Common Vulnerability Scoring System): Somut bir açığı standart bir sayısal skorla (0–10) derecelendirir; saldırı vektörü, karmaşıklık, gerekli yetki, gizlilik/bütünlük/erişilebilirlik etkisi gibi metrikleri birleştirir. CVE kayıtlarında gördüğünüz skorlar budur. Tasarım aşamasındaki soyut tehditler için basit matris, kayıtlı açıklar için CVSS daha uygundur.

6. Tehdide Yanıt: Dört Strateji

Her önceliklendirilmiş tehdit için dört karardan biri verilir:

• Azalt (Mitigate): Bir kontrol ekleyerek riski düşür. En yaygın yanıt. (Örn: CSRF token, parametreli sorgu.)
• Ortadan kaldır (Eliminate): Tehdide yol açan özelliği/kabiliyeti tamamen kaldır. (Örn: kullanılmayan bir dosya yükleme alanını silmek.) En güçlü ama her zaman mümkün olmayan yanıt.
• Aktar (Transfer): Riski başka bir tarafa devret. (Örn: ödeme verisini hiç tutmayıp bir PCI-DSS uyumlu sağlayıcıya yönlendirmek; sigorta.)
• Kabul et (Accept): Riskin düşük ve maliyetin yüksek olduğu durumda, bilinçli ve belgelenmiş biçimde kabul et. Kabul, "görmezden gelmek" değildir; bir karardır ve kayda geçer.

7. Pratik: Bir Uç Noktayı Modellemek

Somut bir örnek — "profil fotoğrafı yükleme" özelliği. Kısa bir tehdit modeli:

Akış: Kullanıcı → [POST /profile/avatar] → Uygulama → Dosya sistemi + DB

STRIDE analizi:
  Tampering (T): Dosya adı/uzantı kurcalanıp .php yüklenebilir mi?
     → Kontrol: içerik-tipi doğrulama + rastgele ad + web-dışı dizin (Bölüm 19)
  Info Disclosure (I): Başka kullanıcının avatar yoluna erişilebilir mi (IDOR)?
     → Kontrol: dosya sahipliği kontrolü (Bölüm 15)
  DoS (D): Dev dosya / zip bomb ile disk/CPU tüketilebilir mi?
     → Kontrol: boyut limiti, işleme timeout'u
  Elevation (E): Yüklenen dosya çalıştırılabilir hâle gelir mi (web shell)?
     → Kontrol: yürütmeyi engelleyen dizin yapılandırması (Bölüm 27, 34)

Bu tablo, dosya yükleme kodunu yazmadan önce dört ayrı kontrolün gerekli olduğunu ortaya koyar. Kodu yazıp sonra test etmek, bu dördünden birini kaçırmayı neredeyse garanti eder.

8. Ne Zaman ve Kim Modellemeli

Tehdit modelleme ayrı bir "güvenlik ekibi ritüeli" olmamalıdır. En etkili olduğu an, yeni bir özellik veya mimari değişiklik tasarlanırkendir. Küçük değişiklikler için 15 dakikalık bir beyaz tahta oturumu yeterlidir; büyük mimari kararlar için daha yapılandırılmış bir seans gerekir.

Katılımcılar yalnızca güvenlik uzmanları değil, özelliği yazan geliştiriciler olmalıdır — çünkü sistemi en iyi onlar bilir ve modeli onlar uygulayacaktır. Güvenlik uzmanı, mercek ve deneyim getirir; geliştirici, bağlam getirir.

9. Checklist

• [ ] Yeni özellik için bir DFD (basit de olsa) çizildi mi?
• [ ] Tüm güven sınırları işaretlendi mi?
• [ ] Her sınırı geçen akışa STRIDE mercekleri tutuldu mu?
• [ ] Bulunan tehditler etki/olasılık ile önceliklendirildi mi?
• [ ] Her tehdit için bir strateji (azalt/kaldır/aktar/kabul) belgelendi mi?
• [ ] Kabul edilen riskler yazılı ve onaylı mı?
• [ ] Model, kod tamamlandıktan sonra gerçekle karşılaştırıldı mı (Soru 4)?

10. Laboratuvar

Lab 2.1 — DFD çizimi. Kendi projenizden bir uç nokta seçin. Dış varlıkları, süreçleri, veri depolarını ve güven sınırlarını içeren bir DFD çizin. En az iki güven sınırı belirleyin.

Lab 2.2 — STRIDE taraması. Lab 2.1'deki DFD'nin en kritik akışına altı STRIDE kategorisini tek tek uygulayın. Her kategori için ya bir tehdit ya da "uygulanamaz — çünkü…" yazın.

Lab 2.3 — Önceliklendirme. Bulduğunuz tehditleri etki/olasılık matrisine yerleştirin ve en kritik üçü için bir yanıt stratejisi belirleyin.

11. Quiz

1. Bir açığı tasarımda yakalamak, üretimde yakalamaktan neden çok daha ucuzdur?
2. Tehdit modellemenin dört temel sorusu nedir?
3. Veri Akış Diyagramında güven sınırı neden en kritik öğedir?
4. STRIDE'ın altı kategorisini, ihlal ettikleri güvenlik özellikleriyle eşleştirin.
5. "Repudiation" tehdidi PHP bağlamında nasıl görünür ve hangi kontrolle azaltılır?
6. Basit risk matrisi ile CVSS ne zaman kullanılır? Farkları nedir?
7. Dört tehdit yanıt stratejisini sayın. "Kabul et" ile "görmezden gel" arasındaki fark nedir?
8. Bir dosya yükleme özelliğine STRIDE uygularken hangi iki kategori en kritiktir ve neden?
9. Tehdit modelleme neden yalnızca güvenlik ekibinin işi olmamalıdır?
10. Bir güven sınırını geçen veri için sorulması gereken üç soru nedir?

12. Kaynakça

• Adam Shostack, Threat Modeling: Designing for Security (Wiley).
• Microsoft, The STRIDE Threat Model ve Threat Modeling Tool dokümantasyonu.
• OWASP, Threat Modeling Cheat Sheet ve Threat Modeling Process.
• FIRST, Common Vulnerability Scoring System (CVSS) v3.1 Specification.
• NIST SP 800-154, Guide to Data-Centric System Threat Modeling.