Bir yazılım geliştirme ekibi, dört soruyu sırasıyla yanıtlar ve oturumdan bir doküman yerine iş kalemleriyle çıkarsa, bir özelliğin tehdit modelini bir saatte çıkarabilir. Sorular Threat Modeling Manifesto belgesinden gelir: Üzerinde ne çalışıyoruz, neler ters gidebilir, bu konuda ne yapacağız ve işi yeterince iyi yaptık mı? Güvenlik mimarına ihtiyaç yoktur, çünkü bu çalışma tek bir kişinin doğuştan gelen yeteneğine bağlı değildir.
Bir saate genel bakış
| Dakika | Soru | Çıktı |
|---|---|---|
| Öncesi | - | Bir kişi veri akış diyagramının taslağını hazırlar |
| 0-10 | Üzerinde ne çalışıyoruz | Düzeltilmiş diyagram, numaralandırılmış giriş noktaları |
| 10-30 | Neler ters gidebilir | STRIDE kategorilerine göre gruplanmış tehdit listesi |
| 30-45 | Bu konuda ne yapacağız | Her tehdit için bir yanıt |
| 45-55 | İş kalemleri ve testler | Her önlem için bir iş kalemi ve bir test |
| 55-60 | İşi yeterince iyi yaptık mı | Tamlık kontrolü |
Oturumdan önce
Tüm bir ürünü değil, tek bir özelliği seçin. Tasarım aşamasında sorun bulmak, canlı ortamdaki kusurları gidermekten çok daha verimlidir; bu nedenle oturumu geliştirme başlamadan önce yapın.
Bir geliştiriciyi, gereksinim sahibini ve altyapı söz konusuysa operasyon ekibinden birini davet edin. Katılımcılardan biri, dosyalarını ekibin sonradan düzenleyebileceği bir araçta hazırlanmış taslak bir veri akış diyagramı getirsin.
0-10. dakika: üzerinde ne çalışıyoruz
Grup taslağı düzeltir. OWASP Threat Modeling Cheat Sheet, olası saldırı noktalarını çoğu zaman temsil eden güven sınırlarının, veri akışlarının, veri depolarının, süreçlerin ve dış varlıkların net biçimde görülmesini ister. Her birinin sayfada yer aldığını kontrol edin.
Katılımcıların bir kısmı teknik değilse, DFD gösteriminde ısrar etmek yerine akışları beyaz tahtada beyin fırtınasıyla çıkarın.
İlerledikçe giriş noktalarını numaralandırın; katmanlı olanlar için OWASP topluluk süreç sayfasında olduğu gibi ana.alt numara düzenini kullanın (1, 1.2, 1.2.1) ve çıkış noktalarını da işaretleyin. Bir giriş sayfasındaki hata mesajı, ilgili giriş noktası üzerinden saldırılara olanak tanıyabilir; örneğin hesap toplama ("kullanıcı adı bulunamadı") ya da SQL injection (SQL istisna hataları aracılığıyla).
10-30. dakika: neler ters gidebilir
Teknik bir tasarım için STRIDE ile başlayın. Her bileşeni, veri akışını ve güven sınırını altı kategoriden geçirin ve her tehdidin hangi giriş noktası kimliğine temas ettiğini kaydedin.
| Kategori | İhlal ettiği özellik | Örnek |
|---|---|---|
| Spoofing (kimlik sahteciliği) | Kimlik doğrulama | Çalınan kimlik doğrulama token'ının bir kullanıcıyı taklit etmek için kullanılması |
| Tampering (veri değiştirme) | Bütünlük | Uygulama üzerinden veritabanında istenmeyen güncellemeler yapılması |
| Repudiation (inkâr) | Hesap verebilirlik | Eylemleri gizlemek için logların manipüle edilmesi |
| Information Disclosure (bilgi ifşası) | Gizlilik | Kullanıcı hesaplarının bulunduğu veritabanından veri çekilmesi |
| Denial of Service (hizmet reddi) | Erişilebilirlik | Çok sayıda başarısız kimlik doğrulama denemesiyle kullanıcının hesabından kilitlenmesi |
| Elevation of Privileges (yetki yükseltme) | Yetkilendirme | Rolü değiştirmek için bir JWT üzerinde oynama yapılması |
Bir iş kuralı için kötüye kullanım senaryoları (misuse case) ekleyin: sırasız, tekrarlı, eşzamanlı ya da amaçlanmayan bir sonuç için yapılan eylemler. Birden çok adımlı tek bir saldırgan hedefi için saldırı ağacı (attack tree) kullanın. Kapsamlı görünmek için teknik eklemeyin; her tekniğin neden uygun olduğunu ve neyi kapsam dışı bıraktığını belirtin.
Olasılık çarpı etki düzenli görünür, ancak ikisini de tahmin etmek zordur ve çarpım düzeltmenin maliyetini yok sayar. Bir saatlik oturumda her tehdit için kabaca yüksek, orta ya da düşük demek yeterlidir.
Uygulamalı örnek: parola sıfırlama
Bir parola sıfırlama akışını ele alalım. Diyagramda tarayıcı, web uygulaması, kullanıcı veritabanı ve bir e-posta servisi yer alır; internet ile uygulama arasında bir güven sınırı bulunur. Sıfırlama isteği 3 numaralı giriş noktasıdır, e-postayla gönderilen bağlantı ise 3.1'dir (örnek kimlikler).
Grup dört tehdit bulur. Bir sıfırlama bağlantısı hesap sahibi dışındaki biri için de çalışır (spoofing). "Bu adrese ait hesap yok" mesajı kimlerin kayıtlı olduğunu ele verir (information disclosure). Sıfırlama olayları loglanmaz (repudiation). Biri bir kurbana karşı art arda sıfırlama tetikler (denial of service).
30-45. dakika: bu konuda ne yapacağız
Her tehdide dört yanıttan biri verilir:
- Azaltma (mitigate): Tehdidin gerçekleşme olasılığını düşürün.
- Ortadan kaldırma (eliminate): Soruna yol açan özelliği ya da bileşeni kaldırın.
- Devretme (transfer): Sözleşmesel ya da mali sorumluluğu başka bir tarafa aktarın.
- Kabul etme (accept): Diğer seçenekler iş kısıtlarına uymadığı için hiçbir şey yapmayın.
Devretme tek başına olasılığı ya da zararı azaltmaz; bu yüzden kalan kontrollerin ve artık riskin sahibini yazın. Kabul edilen tehditler için riski kimin kabul ettiğini ve nedenini kaydedin.
45-55. dakika: iş kalemleri ve testler
Kararlaştırılan her önlemi, bir geliştiricinin alıp çalışabileceği bir gereksinime dönüştürün. Tehdit başına bir satır yeterlidir:
| Tehdit ID | STRIDE | İş kalemi | Test |
|---|---|---|---|
| 3.1-S | Spoofing | Sıfırlama bağlantılarını tek kullanımlık ve kısa ömürlü yapın | Kullanılmış ya da süresi dolmuş bağlantı reddedilir |
| 3-I | Information Disclosure | Her adres için tek bir genel yanıt döndürün | Bilinen ve bilinmeyen adresler aynı yanıtı verir |
| 3-R | Repudiation | Her sıfırlama isteğini loglayın | Bir sıfırlama denemesi logda görünür |
Test sütunu, modeli bir diyagramdan fazlası yapan şeydir. Her önlemin, kontrol eksik olduğunda başarısız olan bir testi olmalıdır. Kötüye kullanım senaryoları doğrudan teste dönüşür: isteği yeniden oynatın, adımları sırasız gönderin, aynı anda iki istek yollayın. İş kalemlerini özelliğin kendi backlog'una, başlıkta tehdit ID'siyle birlikte ekleyin.
55-60. dakika: işi yeterince iyi yaptık mı
Basit bir kontrolle başlayın: diyagramı, tehdit listesini ve kontrol listesini gösteren kayıtlar var mı? Biri eksikse oturum bitmemiştir. Her tehdidin bir yanıtı olduğunu, her önlemin ekibin onu nasıl uygulayacağını belirttiğini ve kabul edilen risklerin nedenini içerdiğini doğrulayın.
Ardından modeli canlı tutun. Sistemle birlikte güncelleyin; tasarım değiştiğinde yalnızca etkilenen bölümleri yeniden çalıştırın.
Nereden başlamalı
- Yaklaşan bir özellik seçin ve bir geliştirici, gereksinim sahibi ve operasyondan biriyle bir saatlik oturum planlayın.
- Bir kişiye, güven sınırları işaretlenmiş bir veri akış diyagramı taslağı hazırlatın. Grup ilk on dakikada taslağı düzeltir ve giriş noktalarını numaralandırır.
- 20 dakika boyunca her bileşen ve akış üzerinde STRIDE'ı çalıştırın; her tehdit için etkilenen giriş noktası kimliğini kaydedin.
- Her tehdide bir yanıt atayın, kabul edilen ya da devredilen risklerin sahibini not edin, ardından her önlem için bir iş kalemi ve bir test oluşturun.
- Diyagramı, tehdit listesini ve kontrol listesini özelliğin dokümantasyonuyla birlikte saklayın. İlk model için dışarıdan bir bakış isterseniz danışmanlık hizmetimiz modeli inceleyebilir; kaydedilen tehditler, daha sonraki bir sızma testi için de iyi bir kapsam oluşturur.
