1. GİRİŞ

Threat modeling, yazılım ve sistem tasarım sürecinde ortaya çıkabilecek güvenlik açıklarını sistematik şekilde keşfetme, önceliklendirme ve azaltma pratiğidir. Günümüzde bulut‑native mimariler, mikroservisler, üçüncü‑taraf entegrasyonları ve hızlı CI/CD döngüleri sistemleri karmaşıklaştırdı; bu karmaşıklık saldırı yüzeyini büyüttü. Threat modeling, güvenliği reaktif bir kırmızı ekip çalışmasından çıkarıp, tasarım aşamasına taşıyarak maliyetleri düşürür, hataların üretime yansımasını engeller ve uyumluluk gereksinimlerini karşılamayı kolaylaştırır.

Bu neden bugün önemli?

• Önceden tahmin edilemeyen zayıflıklar, tedarik zinciri saldırıları ve konfigürasyon hataları nedeniyle büyük veri sızıntıları yaşanıyor.
• Regülasyonlar ve denetimler (GDPR, PCI‑DSS, SOC2 vb.) tehdit modelleme ve risk değerlendirmesini giderek daha fazla bekliyor.
• Agile/DevOps kültüründe güvenliği üretime geçmeden önce entegre etmek, operasyonel maliyetleri ve MTTR'ı azaltır.

Kimler için önemli?

• Güvenlik mimarları ve uygulama mimarları
• Geliştiriciler, DevOps ve SRE ekipleri
• CISO, risk ve uyumluluk ekipleri

Hangi problemleri çözüyor?

• Design‑time güvenlik açıklarının erken tespiti
• Risk odaklı güvenlik yatırımlarının doğru hedeflenmesi
• Uygulama ve altyapı bileşenleri arasındaki etkileşimlerden kaynaklanan attack vector'ların ortaya çıkarılması

2. KAVRAMSAL TEMELLER

2.1 Threat modeling nedir — net tanım

Threat modeling, bir sistemin varlıklarını (assets), saldırı yüzeyini, potansiyel saldırgan profillerini (threat actors), zafiyetleri ve bunların gerçekleşme olasılıklarını metodolojik olarak belirleme sürecidir. Amaç; güvenlik kontrollerini tasarım aşamasında şekillendirip, konfigürasyon ve uygulama hatalarını azaltmaktır.

2.2 Temel kavramlar ve terminoloji

• Asset (Varlık): Korunması gereken veri veya hizmet (örn. kullanıcı verisi, ödeme işlemleri, admin paneli).
• Attack surface: Saldırılabilecek tüm yüzeyler—API endpoint'leri, ports, third‑party integrations, CI secrets.
• Threat actor: Saldırgan türü—script kiddie, organized crime, insider, nation state.
• Threat vector: Saldırının izlediği yol—phishing, SQL injection, supply chain compromise.
• Risk: Olayın olasılığı × etkisi (likelihood × impact).
• Mitigation / Control: Riski azaltmaya yönelik teknik veya süreçsel önlem.

2.3 Yaygın modeller ve metodolojiler

• STRIDE: Microsoft tarafından geliştirilen model; Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege kategorileriyle tehditleri sınıflandırır.
• PASTA: Process for Attack Simulation and Threat Analysis; risk odaklı, adım adım attack simulation yaklaşımı.
• ATT&CK: MITRE ATT&CK framework; saldırgan tekniklerini ve taktiklerini sınıflandırır, adversary‑centric yaklaşım sunar.
• VAST: Scalable Threat Modeling—organizasyonun farklı seviyelerinde (app, infra) ölçeklenebilir bir model sunar.

3. NASIL ÇALIŞIR? — TEKNİK ADIMLAR VE AKIŞ

3.1 Hazırlık: scope ve hedef belirleme

Başarılı bir threat modeling süreci öncelikle scope'un net tanımlanması ile başlar. Hangi sistemler, hangi servisler, hangi data sınıfları değerlendirilecek? Hedefler iş ve uyumluluk gereksinimleri ile hizalanmalı (örn. PCI dahilindeki payment flow'ları önceliklendir).

3.2 Inventory: varlık ve bağımlılık envanteri

Tüm varlıkların listelenmesi kritik adımdır: veri sınıfları, API endpoint'leri, kimlik sağlayıcılar, 3rd‑party SDK'lar, CI/CD secrets ve altyapı bileşenleri. Otomatik keşif (SBOM, dependency scanning, cloud asset inventory) ile manual envanter desteklenmelidir.

3.3 Modelleme: data flow ve trust boundaries

Data Flow Diagrams (DFD) kullanarak veri akışını, trust boundary'leri ve dış entegrasyonları gösterin. Hangi noktada veriye kim erişiyor, hangi bileşenler dış dünyaya açık, hangi network zone'ları var—bunlar attack surface analizinin temel girdileridir.

3.4 Tehditlerin tanımlanması ve sınıflandırılması

STRIDE veya ATT&CK gibi taksonomilerle tehditleri kategoriye ayırın. Örneğin bir DFD üzerindeki "user input → order API" akışı için STRIDE uygulayarak spoofing (sahte kimlik), tampering (veri değişimi), SQL injection gibi riskleri belirleyin.

3.5 Threat feasibility ve risk değerlendirmesi

Her tehdit için likelihood (olasılık) ve impact (etki) değerlendirmesi yapın. Olasılık analizinde attacker capability, exploit complexity ve mevcut kontroller göz önünde bulundurulur. Impact değerlendirmesinde veri hassasiyeti, işsel etki ve uyumluluk sonuçları hesaplanır. Risk puanlaması bu iki metriğin kombinasyonu ile yapılır.

3.6 Mitigation: kontroller ve tasarım değişiklikleri

Öncelikli riskler için teknik ve süreçsel kontroller önerin: input validation, least privilege, rate limiting, WAF, encryption, secrets rotation, secure default config. Kontrollerin maliyet‑fayda analizi yapılmalı; kritik riskler hızlıca ele alınmalıdır.

3.7 Validation: test ve attack simulation

Threat modeling çıktıları penetration test, red team veya attack simulation ile doğrulanmalıdır. PASTA gibi metodolojiler attack simulation'ı süreç içine alır; bulgular modelde düzeltmeler yapılmasını tetikler.

3.8 Documentation, follow‑up ve continuous process

Modelleme sonucu politikalar, kararlar, adopted mitigations ve owner'lar açıkça dökümante edilmeli; izleme ve takip listesi oluşturulmalıdır. Threat modeling tek seferlik bir aktivite değil, sistem değiştikçe tekrarlanması gereken continuous bir süreçtir—CI/CD pipeline'ına entegrasyon önerilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Örnek: E‑ticaret ödeme akışı

Bir e‑ticaret platformunda ödeme akışı özellikle kritik bir bileşendir. Threat modeling sürecinde DFD üzerinde ödeme formu, ödeme gateway'i, tokenization servisleri ve PCI‑scope veri tanımlanır. STRIDE kullanılarak card data leakage, tampering (ödeme tutarı değiştirme), replay attacks ve man‑in‑the‑middle riskleri belirlenir. Mitigasyon olarak TLS, tokenization, HSM tabanlı key management ve idempotency/nonce mekanizmaları önerilir.

4.2 Örnek: Microservice mimarisi

Mikroservislerde servis‑to‑servis authentication, authorization ve network zoning önemlidir. Threat modeling aşamasında service mesh, mTLS, sidecar proxy'ler ve pod security politikaları değerlendirilir. ATT&CK teknikleri ile lateral movement ve credential harvesting riskleri analiz edilir; mitigasyon için short‑lived tokens, workload identity ve network policies önerilir.

4.3 Örnek: CI/CD pipeline ve tedarik zinciri

CI/CD pipeline'lar git repo, build server, artifact registry ve deploy target'ları kapsar. Threat modeling tedarik zinciri saldırılarına odaklanır: compromised dependency, leaked pipeline secrets veya malicious build step. Mitigasyon olarak signed artifacts, SBOM, least privilege runner permissions ve pipeline as code review süreçleri uygulanır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Erken tespit ile güvenlik maliyetlerini düşürür; bug fixing üretimde olmaktan daha ucuzdur.
• Risk odaklı yaklaşım önceliklendirme sağlar; limited resources ile en yüksek etki azaltılabilir.
• Uyumluluk ve audit süreçleri için güçlü delil sağlar; denetimler sırasında süreç gösterilebilir.

Sınırlamalar

• Modelleme kalitesi takımın deneyimine bağlıdır—yanlış varsayımlar eksik veya yanlış mitigasyonlara yol açar.
• Large‑scale sistemlerde modelleme zaman alıcı olabilir; ölçeklenebilir metode ihtiyaç vardır.
• False positive/negative riski—her tespit edilebilir tehdit gerçek risk oluşturmayabilir ya da bazı riskler atlanabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Threat modeling'i SDLC'ye entegre edin—design review ve pull request süreçlerine ekleyin.
• DFD ve attack surface envanterini otomatikleştirin; asset inventory sürekli güncel olsun.
• Risk scoring ve SLA bazlı remediation hedefleri belirleyin—kritik bulgular için 24–72 saat arası bir SLA olabilir.

Performans ve operasyon

• Otomatik tarama ve CI pipeline entegrasyonu ile modelleme çıktılarının test edilmesini sağlayın (static analysis, dependency checks).
• Threat intelligence ve telemetry ile modeling sonuçlarını validate edin—olay verileri ile feedback loop kurun.

Güvenlik

• Mitigations için defense‑in‑depth yaklaşımı uygulayın—bir kontrol başarısız olursa diğeri çözmelidir.
• Least privilege, secure defaults ve otomatik rotation (secrets/keys) politikasını zorunlu kılın.

8. SIK YAPILAN HATALAR

• Threat modeling'i bir formalite olarak görmek—bulgular uygulanmadan süreç sonlandırılır.
• Scope'u çok geniş tutup hiçbir şeyi derinlemesine inceleyememek—önceliklendirme şarttır.
• Modellemeyi tek seferlik bir etkinlik sanmak—sistem değiştikçe tekrarlanmalı.
• Operator ve dev ekipleri süreçten dışlamak—uygulama ekipleri katılımcı olmalı ki mitigations uygulanabilsin.

9. GELECEK TRENDLER

1. AI destekli threat modeling: Telemetry ve geçmiş incident verileriyle otomatik tehdit önerileri ve risk scoring yapabilen araçlar yaygınlaşacak.
2. Runtime threat modeling: Statik modellemenin ötesinde canlı sistem telemetrisine dayalı dinamik risk haritaları ortaya çıkacak.
3. DevSecOps entegrasyonu: Threat modeling Ci/CD pipeline'larına yerleşecek ve pull request seviyesinde güvenlik geri bildirimi sağlayacak.
4. Supply chain‑centric modeling: SBOM, signed artifacts ve provenance tabanlı modelleme daha fazla önem kazanacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Threat modeling ne sıklıkla yapılmalı?

   Her önemli tasarım değişikliğinde, yeni entegrasyon veya release öncesi ve düzenli periyotlarla (ör. çeyreklik) tekrar edilmelidir. Kritik sistemlerde CI/CD entegrasyonuyla sürekli değerlendirme hedeflenmelidir.

2. 2. Küçük ekipler için basit bir başlangıç nasıl olmalı?

   İlk aşamada DFD çıkarın, STRIDE uygulayın ve en yüksek riskli 3–5 tehdidi ele alın. Basit checklist ve remediation ticket'ları oluşturun; süreçleri sonra olgunlaştırın.

3. 3. Hangi araçlar yardımcı olur?

   Microsoft Threat Modeling Tool, OWASP Threat Dragon, IRIS, Miro templates, ayrıca SBOM ve dependency scanning için Snyk/Dependabot gibi araçlar faydalıdır.

4. 4. Threat modeling ekip içi hangi rolleri kapsamalı?

   Güvenlik mimarı, uygulama mimarı, geliştirici temsilcisi, SRE/DevOps ve ürün sahibi/PO süreçte yer almalı—uygulama bilgisi ve operasyonel veri kritik önemdedir.

5. 5. Modeling çıktıları nasıl önceliklendirilir?

   Likelihood × impact hesaplayarak risk puanı oluşturun ve iş etkisi, compliance gereği ve exploitability kriterlerine göre SLA'lar tanımlayın.

6. 6. Threat modeling ile penetration test arasındaki fark nedir?

   Threat modeling tasarım aşamasında riskleri belirler; penetration test ise uygulama/infra layer'ında aktif testlerle zafiyetleri doğrular. İkisi birbirini tamamlar.

7. 7. Threat modeling CI/CD'ye nasıl entegre edilir?

   DFD ve asset metadata'yı pipeline'da güncel tutun; PR hook'larında threat checklist'leri çalıştırın ve otomatik scanning sonuçlarını modeling verisiyle korele edin.

8. 8. Modellemeden çıkan bulguları kim takip etmeli?

   Bulgu sahipleri (owners) açıkça atanmalı—bu genelde uygulama sahibidir. Güvenlik takımı remediation'ı takip eder ve SLA ile kapatılmasını sağlar.

Anahtar Kavramlar

DFD

Data Flow Diagram—veri akışını ve trust boundary'leri gösteren diyagram.

STRIDE

Tehdit sınıflandırma yöntemi: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.

PASTA

Risk‑odaklı threat modeling metodolojisi, attack simulation içerir.

SBOM

Software Bill of Materials—uygulamanın bileşen envanteri; supply chain modeling için kritik.

Attack surface

Saldırılabilir tüm bileşenler ve yolların toplamı.

Öğrenme Yol Haritası

1. 0–1 ay: Temel threat modeling kavramlarını öğrenin; küçük bir sistemi DFD ile modelleyin ve STRIDE uygulayın.
2. 1–3 ay: PASTA ve ATT&CK metodolojilerini çalışın; bir uygulama için risk scoring ve mitigation planı oluşturun.
3. 3–6 ay: Tooling (Threat Dragon, Microsoft TMT), SBOM ve dependency scanning ile entegrasyonlar kurun; pipeline ile test edin.
4. 6–12 ay: Attack simulation, red team/blue team tatbikatları ve AI destekli risk scoring uygulamaları ile olgunlaştırın.