Vebende Akademi - stride-model
Uzmanla Konuşun
Blog
MAKALE

STRIDE Model — Tehdit Sınıflandırma ve Uygulamalı Güvenlik Rehberi

Yayınlayan: Vebende Akademi  |  Okuma süresi: ~60–140 dk

STRIDE Model — Tehdit Sınıflandırma ve Uygulamalı Güvenlik Rehberi

Yayınlayan: Vebende Akademi  |  Okuma süresi: ~60–140 dk

1. GİRİŞ

Güvenlik mühendisliği ve uygulama tasarımında ortak bir zorluk, sistemlerin maruz kaldığı farklı tehditleri tutarlı ve tekrar edilebilir bir yöntemle sınıflandırmak ve önceliklendirmektir. STRIDE modeli, Microsoft tarafından geliştirilen ve tehditleri altı kategoride (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) sınıflandıran yaygın bir yaklaşımdır. STRIDE yalnızca tehditleri tanımlamakla kalmaz; tasarım kararlarını yönlendirmek, güvenlik kontrollerini eşlemek ve ekipler arasında ortak bir dil oluşturmak için pratik bir çerçeve sunar.

Bu konu neden bugün önemli?

Bulut‑native uygulamalar, mikroservis mimarileri, API ekonomisi ve tedarik zinciri karmaşıklığı modern sistemlerin saldırı yüzeyini büyüttü. Hızlı iterasyon süreçleri (CI/CD) ve extensively third‑party usage, tasarım aşamasında güvenliği entegre etmeyi zorunlu kılıyor. STRIDE gibi sınıflandırma modelleri, tehditlerin sistematik analizini sağlayarak güvenliği reaktif olmaktan çıkarıp proaktif bir disipline dönüştürür.

Kimler için önemli?

  • Uygulama mimarları ve çözüm mimarları
  • Güvenlik mühendisleri ve DevSecOps ekipleri
  • Geliştiriciler, SRE'ler ve QA ekipleri
  • Ürün yöneticileri ve risk/uyum ekipleri

Hangi problemleri çözüyor?

  • Tehditlerin tutarlı şekilde tanımlanması ve iletişimi
  • Risk odaklı önceliklendirme ve kaynak kullanımının etkinleştirilmesi
  • Design‑time güvenlik bulgularının üretime yansımadan önce ele alınması

2. KAVRAMSAL TEMELLER

2.1 STRIDE nedir — kısa tanım

STRIDE, tehditleri sınıflandırmak için kullanılan bir akronimdir ve her harf belirli bir tehdit sınıfını temsil eder:

  • Spoofing: Kimlik taklidi; saldırganın başka bir kullanıcı veya servis gibi davranması.
  • Tampering: Verinin veya sistem bileşenlerinin yetkisiz değişimi.
  • Repudiation: İşlem reddi; kullanıcı veya sistem tarafından gerçekleştirilen işlemin reddedilebilmesi (trace eksikliği).
  • Information Disclosure: Yetkisiz bilgi sızıntısı.
  • Denial of Service: Hizmetin kullanılmaz hale getirilmesi veya performansının bozulması.
  • Elevation of Privilege: Yetki yükseltme; düşük yetkili kullanıcının yüksek yetki elde etmesi.

2.2 Temel terminoloji

  • DFD (Data Flow Diagram): Veri akışları ve trust boundary'leri görselleştirmek için kullanılan temel araç.
  • Asset: Korunması gereken varlık — veri, servis, anahtar, işlem.
  • Threat actor: Potansiyel saldırgan türü ve motivasyonu.
  • Control / Mitigation: Tehdidi azaltmaya yönelik uygulama veya süreçsel önlem.

3. NASIL ÇALIŞIR?

3.1 STRIDE uygulama akışı (DFD ile entegrasyon)

STRIDE analizi genellikle bir DFD üzerinde yürütülür. Adımlar şu şekildedir:

  1. DFD oluşturun: Sistem bileşenleri, veri depoları, veri akışları ve dış aktörleri gösterin.
  2. Her bileşen/akış için STRIDE kategorilerini uygulayın: Örneğin "API Gateway" elemanı için Spoofing (düşük‑güçlü kimlik doğrulama), Tampering (gönderilen payload'ın değiştirilmesi), Information Disclosure (ölçümsüz logging) gibi tehditleri not edin.
  3. Tehditleri risk skoruna çevirin: likelihood × impact yaklaşımıyla önceliklendirin.
  4. Mitigasyon eşlemesi: Her tehdit için uygulanabilir kontroller (authentication, encryption, signing, rate limiting, logging) belirleyin.
  5. Takip ve doğrulama: Mitigasyonlar test edilir (SAST/DAST, pentest) ve model güncellenir.

3.2 Sistem bileşenlerine göre STRIDE örnekleri

STRIDE'i çeşitli mimari katmanlarda uygulamak pratik açıdan öğretişlidir:

  • Client / UI: Spoofing (zayıf oturum yönetimi), Information Disclosure (local storage'ta hassas veri), Tampering (XYSS).
  • API Gateway / Edge: Spoofing, Tampering, DoS (rate limit eksikliği), Information Disclosure (exposed debug endpoints).
  • Service Layer: Elevation of Privilege (insufficient RBAC), Tampering (man‑in‑the‑middle between services), Repudiation (insufficient audit logs).
  • Data Store: Information Disclosure (unencrypted at rest), Tampering (injection), Repudiation (no immutable audit trail).

3.3 STRIDE'i testlere bağlamak

STRIDE çıktıları pentest ve otomatik test planlarına doğrudan çevrilebilir. Örneğin SQL injection ihtimali not edilen bir akış için DAST ve parametrized query kontrolleri pipeline'da zorunlu hale getirilebilir. Repudiation bulguları için audit log entegrasyon testleri oluşturulabilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Finansal uygulama örneği

Ödeme akışları STRIDE açısından kritik senaryolar sunar. Spoofing (sahte API token), Tampering (ödeme tutarı değiştirme), Information Disclosure (kart verisi sızıntısı), Repudiation (işlem kaydının yetersiz olması) gibi tehditler ayrıntılı şekilde modellenir. Mitigasyon olarak tokenization, HSM tabanlı key management, strong authentication ve immutable audit log kullanımı öne çıkar.

4.2 SaaS multi‑tenant platform örneği

Multi‑tenant sistemlerde tenant isolation tehdit modelinin merkezindedir. STRIDE analizinde elevation of privilege (tenant A'nın tenant B kaynaklarına erişimi), information disclosure (tenant metadata sızıntısı) ve tampering (shared config üzerinde yetkisiz değişiklik) riskleri değerlendirilir. Teknik çözümler arasında tenant‑aware RBAC, per‑tenant encryption keys ve rigorous CI checks yer alır.

4.3 CI/CD ve supply chain

Pipeline komponentleri STRIDE açısından attack surface oluşturur: leaked secrets (information disclosure), compromised runners (tampering), signed artifact eksikliği (repudiation). SBOM, signed builds, least privilege runners ve policy‑as‑code ile bu riskler azaltılabilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

  • Tutarlı sınıflandırma: Farklı ekipler arası ortak dil sağlar.
  • Hızlı uygulama: DFD ile kombine edilince hızlıca yeni tehditler tespit edilir.
  • Kontrollerle eşleme: STRIDE kategorileri doğrudan güvenlik kontrolleri ile ilişkilendirilebilir.

Sınırlamalar

  • Yüzeysel inceleme riski: STRIDE tehditleri sınıflandırır ama risk skorlaması ve attack simulation sağlamaz; bu nedenle DREAD/PASTA veya ATT&CK ile tamamlanması gerekir.
  • Öznellik: Tehdit olasılığı ve etkisi ekipten ekibe değişebilir; objektif metrikler gereklidir.
  • Ölçek problemi: Çok büyük sistemlerde elle STRIDE uygulamak zaman alıcı olabilir; otomasyon ve tooling desteği gerekir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

MetodolojiAvantajDezavantaj
STRIDEBasit, DFD ile doğrudan kullanılabilir, geniş kabul görmüşRisk skorlaması sağlamaz, attack path simülasyonu yok
DREADRisk skorlama sunarSubjektiflik problemi; tutarlı skorlaması zordur
PASTARisk‑odaklı, attack simulation içerirUygulaması karmaşık ve zaman alıcı
ATT&CKAdversary‑centric, operasyonel kullanım için güçlüÜst düzey tasarım süreçleri için doğrudan uygun olmayabilir

7. EN İYİ PRATİKLER

Production kullanımı

  • STRIDE analizlerini SDLC'nin erken aşamalarına taşıyın; tasarım review'larına zorunlu ekleyin.
  • DFD ve attack surface envanterini otomatik güncelleyen araçlar kullanın; CI pipeline'larında değişiklik algılandığında yeniden değerlendirme tetikleyin.
  • Mitigation'ları test‑edilebilir şekilde tanımlayın; otomatik testler, SAST/DAST ve pentest ile doğrulayın.

Performans ve operasyon

  • Risk‑based SLA'lar ile remediation önceliklendirmesi yapın; kritik riskler için kısa SLA belirleyin.
  • Telemetri ve güvenlik loglarını STRIDE çıktıları ile korele edin; örneğin spoofing riskleri için auth failure trendlerini izleyin.

Güvenlik

  • Least privilege ve defense‑in‑depth prensiplerini uygulayın.
  • Secrets yönetimini merkezi ve otomatik (rotation) hale getirin; HSM/KMS entegrasyonları kullanın.

8. SIK YAPILAN HATALAR

  • STRIDE'i formaliteye indirgeyip bulguları uygulanmadan bırakmak.
  • Scope'u belirsiz tutmak; tüm sistemi tek seferde analiz etmeye çalışmak yerine modüler yaklaşımla başlayın.
  • Tooling eksikliği: Elle yönetilen büyük modeller zamanla güncelliğini yitirir.
  • Repudiation (izlenebilirlik) gibi kontrolleri hafife almak; audit log'ların eksik veya yapılandırılmamış olması sık görülen açık kaynaklı hatadır.

9. GELECEK TRENDLER

AI destekli tehdit sınıflandırma

Yapay zekâ, geçmiş incident verileri, telemetri ve kod/config analizini birleştirerek STRIDE kategorileriyle eşleşen otomatik tehdit önerileri üretebilecek. Bu, özellikle büyük ölçekli sistemlerde elle yapılan modellemenin yükünü azaltacak ve canlı (runtime) risk izlemeyi kolaylaştıracaktır.

Runtime / living threat models

Threat modelleri statik belgeler olmaktan çıkıp runtime telemetri ile beslenecek living models hâline gelecek. Sisteme yapılan değişiklikler veya anomali tespitleri otomatik olarak ilgili threat model parçalarını güncelleyecek.

DevSecOps entegrasyonu

STRIDE çıktıları doğrudan PR seviyesindeki güvenlik kontrollerine, SBOM incelemelerine ve image signing politikalarına bağlanacak; böylece güvenlik kod seviyesinden üretime kadar devam edecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

  1. STRIDE ile nereden başlamalıyım?

    Basit bir DFD çıkarın ve kritik veri akışları ile edge komponentleri üzerinde STRIDE uygulayarak başlayın. İlk analizde en yüksek 5 riske odaklanın.

  2. STRIDE tek başına yeterli mi?

    STRIDE sınıflandırma için güçlüdür, ancak risk skorlaması ve attack simulation için DREAD, PASTA veya ATT&CK gibi yaklaşımlarla kombine edilmesi önerilir.

  3. Hangi araçlar STRIDE destekliyor?

    Microsoft Threat Modeling Tool, OWASP Threat Dragon ve çizim araçları (draw.io, Miro) DFD ve STRIDE sürecini destekler. Ayrıca bazı platformlar otomatik mapping ve reporting sağlar.

  4. STRIDE çıktıları nasıl raporlanmalı?

    Her tehdit için kısa açıklama, likelihood, impact, risk skor, önerilen mitigasyon ve owner bilgisi içeren bir risk register oluşturun. ADR'lerle önemli kararları saklayın.

  5. STRIDE'i CI/CD'ye nasıl bağlarım?

    DFD veya asset metadata değişiklikleri PR'larla tetiklendiğinde threat checklist'lerini çalıştırın; otomatik scanning sonuçlarını model verisiyle korele edip PR blocker veya advisory workflow kurun.

  6. STRIDE ile ATT&CK'i birlikte nasıl kullanırım?

    STRIDE yüksek seviyedeki tehdit kategorilerini bulurken, ATT&CK belirli adversary tekniklerini ve davranışlarını anlamaya yardımcı olur; pentest ve detection use case'lerini ATT&CK'e bağlayın.

  7. Threat modeling sürecini kim yönetmeli?

    Cross‑functional ekipler en iyi sonucu verir: güvenlik mühendisleri, uygulama mimarları, geliştirici temsilcileri, SRE ve ürün sahibi birlikte çalışmalıdır.

  8. Neye öncelik vermeliyim?

    High impact × high likelihood bulgulara öncelik verin; compliance‑critical varlıklar (PII, payment) her zaman yüksek önceliklidir.

Anahtar Kavramlar

  • Spoofing: Kimlik taklidi saldırıları.
  • Tampering: Veriye veya bileşene yetkisiz müdahale.
  • Repudiation: İşlem reddi ve izlenebilirlik eksikliği.
  • Information Disclosure: Veri sızıntıları.
  • Denial of Service: Hizmet sürekliliğinin kesintiye uğraması.
  • Elevation of Privilege: Yetki yükseltme saldırıları.

Öğrenme Yol Haritası

  1. 0–1 ay: DFD ve temel güvenlik kavramları (authentication, authorization, encryption, OWASP) öğrenin.
  2. 1–3 ay: STRIDE ile pratik yapın; küçük bir uygulama üzerinde DFD çıkarıp tehdit analizi yapın. Microsoft Threat Modeling Tool deneyin.
  3. 3–6 ay: PASTA, ATT&CK ve DREAD ile STRIDE'i kombine ederek risk‑odaklı modellemeler yapın; pentest ve CI/CD entegrasyonları kurun.
  4. 6–12 ay: Attack simulation, red team tatbikatları ve AI‑destekli threat önerileri ile süreçleri olgunlaştırın; tooling ve automation ekosistemi oluşturun.