Tehdit Modelleme için Veri Akış Diyagramları: Adım Adım STRIDE Analizi

Her tehdit modelleme yöntemi aynı soruyla başlar: Ne üzerinde çalışıyoruz? Bu sorunun olağan cevabı bir veri akış diyagramıdır. Beş tür öğeden oluşan basit bir çizimdir ve güvenlik incelemesinden önce ona ayıracağınız bir saat, harcayabileceğiniz en verimli saattir; çünkü tehditlerin çoğu, verinin bir güven düzeyinden diğerine geçtiği yerlerde ortaya çıkar.

Bu rehber, tehdit modelleme için bir veri akış diyagramının (DFD) nasıl çizileceğini, güven sınırlarının nereye yerleştirileceğini ve diyagramın üzerinden STRIDE ile nasıl geçileceğini gösteriyor. Örnek, neredeyse her üründe bulunan bir özellik: kullanıcıların profil fotoğrafı yüklemesi.

Dört soru

Pratik bir tehdit modeli, Adam Shostack ve Threat Modeling Manifesto'nun yaygınlaştırdığı dört soruyu yanıtlar:

1. Ne üzerinde çalışıyoruz?
2. Ne ters gidebilir?
3. Bu konuda ne yapacağız?
4. Yeterince iyi bir iş çıkardık mı?

Veri akış diyagramı ilk soruyu yanıtlar. STRIDE ikinci soruya yanıt bulmanıza yardım eder. Diyagrama eklediğiniz notlar ve ticket'lar üçüncüsünü, birkaç hafta sonra yapılan bir gözden geçirme de dördüncüsünü yanıtlar.

Veri akış diyagramının öğeleri

Öğe	Nedir	Olağan şekli
Dış varlık	Kontrolünüz dışındaki bir kişi ya da sistem: bir kullanıcı, bir iş ortağının API'si	Dikdörtgen
Süreç	Veriyi dönüştüren ya da taşıyan, sizin çalıştırdığınız kod	Daire ya da yuvarlatılmış şekil
Veri deposu	Verinin saklandığı yer: bir veritabanı, bir bucket, bir kuyruk, bir log	İki paralel çizgi ya da silindir
Veri akışı	İki öğe arasında hareket eden veri	Taşıdığı veriyle etiketlenmiş ok
Güven sınırı	Güven düzeyinin değiştiği yer	Kesikli çizgi ya da öğeleri çevreleyen bir bölge

İki kural, bir DFD'yi güvenlik açısından işe yarar hale getirir. Her akışı yalnızca protokolle değil, taşıdığı veriyle etiketleyin: photo + session token, bir inceleyiciye HTTPS etiketinden çok daha fazlasını anlatır. Ayrıca iki veri deposunu ya da iki dış varlığı asla doğrudan birbirine bağlamayın: veri yalnızca bir süreç üzerinden hareket eder ve onu denetleyebileceğiniz yer de orasıdır.

Örnek: profil fotoğrafı yükleme

Kullanıcılar tarayıcıdan bir profil fotoğrafı yükler. Web API oturumu doğrular ve ham dosyayı özel bir bucket'a kaydeder. Bir yükleme işleyicisi dosyayı alır, baytları üçüncü taraf bir zararlı yazılım tarama API'sine gönderir, görseli yeniden kodlar, meta verilerini siler, temiz sürümü bucket'a geri yazar ve fotoğrafın URL'sini kullanıcı veritabanına kaydeder.

Dört güven bölgesi var: internet, uygulama katmanımız, veri katmanımız ve üçüncü taraf tarama servisi. DFD olarak çizildiğinde:

Bir bölge sınırını geçen akışları sayın: tarayıcıdan API'ye, API'den bucket'a, bucket'tan işleyiciye ve geri, işleyiciden tarama servisine ve geri, işleyiciden veritabanına. Zamanınızı harcamanız gereken yerler bunlardır.

Diyagramın üzerinden STRIDE ile geçin

STRIDE altı tür tehdidi adlandırır. Microsoft'un "öğe başına STRIDE" (STRIDE per element) yaklaşımı, her öğeyi yalnızca kendi türü için geçerli olan tehditler açısından kontrol eder:

Öğe türü	S	T	R	I	D	E
Dış varlık	✓		✓
Süreç	✓	✓	✓	✓	✓	✓
Veri deposu		✓	✓ (loglar)	✓	✓
Veri akışı		✓		✓	✓

Harfler sırasıyla kimlik sahteciliği (Spoofing), kurcalama (Tampering), inkâr (Repudiation), bilgi ifşası (Information disclosure), hizmet reddi (Denial of service) ve yetki yükseltme (Elevation of privilege) anlamına gelir. Yükleme özelliğini öğe öğe gezdiğinizde şuna benzer bir liste çıkar:

• Kimlik sahteciliği (tarayıcı). Çalınmış ya da sahte bir oturum token'ıyla başka biri adına fotoğraf yüklenir. Önlem: Token'ı her istekte doğrulayın, oturumları kısa ömürlü tutun ve nesne anahtarını istekten gelen bir değere değil, her zaman kimliği doğrulanmış kullanıcının ID'sine bağlayın.
• Kurcalama (bucket'tan işleyiciye). photo.jpg adlı bir dosya aslında bambaşka bir şeydir. Önlem: Dosyanın adına ya da bildirilen türüne değil, gerçek biçimine bakın ve her görseli başka biri görmeden önce yeniden kodlayın.
• İnkâr (API). Bir kullanıcı uygunsuz bir görsel yüklediğini inkâr eder ve aksini kanıtlayan hiçbir şey yoktur. Önlem: Her yükleme için kullanıcı ID'sini, nesne anahtarını, zamanı ve istemci adresini loglayın.
• Bilgi ifşası (bucket). Bucket herkese açık listelemeye izin verir ya da fotoğraflar EXIF meta verilerinde GPS koordinatlarını korur. Önlem: kısa ömürlü imzalı URL'lerle erişilen özel bir bucket ve yeniden kodlama sırasında temizlenen meta veriler.
• Hizmet reddi (API ve işleyici). Çok büyük dosyalar ya da sıkıştırması açılınca devasa boyutlara ulaşan görseller belleği tüketir. Önlem: dosya boyutu ve piksel sayısı için sınırlar, işleyicide de zaman aşımları.
• Yetki yükseltme (işleyici). Kötü niyetle hazırlanmış bir dosya, görsel kütüphanesindeki bir hatayı istismar ederek işleyicinin yetkileriyle kod çalıştırır. Önlem: İşleyiciyi bir sandbox'ta çalıştırın; kendi bucket önekinden ve tek tablosundan başka hiçbir şeye erişimi olmasın.

Tehditleri diyagrama, etkiledikleri öğelerin yanındaki bir nota kısa ve numaralı satırlar halinde yazın ve her birini, düzeltmeyi takip eden ticket'a bağlayın. Böylece diyagram aynı zamanda incelemenin özeti olur.

Tehdit modelleme diyagramları için kurallar

• Şirketi değil, özelliği çizin. Her özellik ya da servis için bir DFD. Her şeyi kapsayan bir diyagramda önemli ayrıntılara yer kalmaz.
• Kimlik doğrulamanın nerede yapıldığını gösterin. Sınırı geçen her akışta kimliği denetleyen süreci işaretleyin.
• Kimsenin demoda göstermediği yolları da ekleyin. Yönetici araçları, destek erişimi, toplu işler ve yedekler de sınırları geçer.
• Tek bir ayrıntı düzeyinde kalın. Bağlam düzeyindeki bir DFD sistemi tek bir süreç olarak gösterir; 1. düzey bir DFD ise onu ana süreçlerine ayırır. Her diyagram için birini seçin.
• Diyagramı özelliğin yanında sürümleyin. Tasarım değiştiğinde tehditler de değişir. Diyagramı, tasarım dokümanıyla aynı pull request'te güncelleyin.

Bu işe özel araçlar mı, ortak bir tuval mi?

OWASP Threat Dragon ve Microsoft Threat Modeling Tool gibi ücretsiz araçlar tam olarak bu iş için tasarlanmıştır ve her öğe için tehdit önerebilir. Süreci bir güvenlik ekibi yürüttüğünde iyi çalışırlar.

Özelliği geliştiren kişiler diyagramı tasarım sırasında birlikte çizdiğinde ortak bir tuval daha iyi sonuç verir: DFD mimari diyagramların yanında durur, herkes onu canlı olarak düzenler ve notlar öğelere bağlı kalır. Hangisini seçerseniz seçin, asıl değerli olan diyagramın etrafında dönen konuşmadır.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Her güven bölgesi için Temel paketinden bir Çerçeve ekleyin ve ona bölgenin adını verin, örneğin Trust zone: app tier.
3. Dış varlıkları Temel paketinden Kutu düğümleri, süreçleri yine Temel paketinden Elips şekilleri olarak ekleyin; veri depolarını ise Veri paketinden alın (Nesne deposu, Postgres).
4. Port'ları bağlayın ve her kenarı taşıdığı veriyle etiketleyin.
5. Etkilenen öğelerin yanına, her tehdidi STRIDE harfi, numarası ve ticket'ıyla listeleyen bir Not ekleyin.

Örnek, 10 diyagram düğümü ve yedi tehdidi listeleyen üç not kullanıyor; Free planın sınırları içinde kalıyor. Güvenliğin ağ tarafı için sıfır güven mimarisi diyagramı şablonuna, kişisel verilerin haritasını çıkarmak için de GDPR veri haritalama kullanım alanına göz atın.

SSS

Veri akış diyagramı, mimari diyagramla aynı şey mi? Hayır. Mimari diyagram bileşenleri ve bunların nasıl bağlandığını gösterir; DFD ise verinin nasıl hareket ettiğini ve güvenin nerede değiştiğini gösterir. Çoğu zaman aynı kutuları paylaşırlar, ama DFD güvenlik sorusu için çizilir.

STRIDE mı, başka bir yöntem mi? STRIDE, yazılım özellikleri için iyi bir varsayılan seçimdir. LINDDUN gizlilik tehditlerine odaklanır; PASTA ise daha büyük programlar için risk odaklı bir süreçtir. Diyagram, hepsi için aynı başlangıç noktasıdır.

Toplantıda kimler olmalı? Özelliği geliştiren mühendisler, onu işletecek biri ve varsa bir güvenlik mühendisi. Tehditleri kodu bilenler bulur; güvenlik mühendisi ise incelemenin göstermelik kalmamasını sağlar.

Ne kadar sürmeli? Fotoğraf yükleme gibi bir özellik için bir saat tipiktir: çizmek için 15 dakika, STRIDE ile üzerinden geçmek için 30, düzeltmeler ve sorumlular üzerinde anlaşmak için 15.

Modeli ne sıklıkla güncellemeliyiz? Bir akış yeni bir sınırı geçtiğinde, yeni bir veri deposu ortaya çıktığında ya da özellik kimin neyi yapabileceğini değiştirdiğinde.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.