Tehdit modelleme, bir sistemin nasıl saldırıya uğrayabileceğini tasarım aşamasında sistematik olarak düşünme yöntemidir. Amaç, kod yazılmadan ya da sistem kurulmadan önce hangi senaryoların mümkün olduğunu görmek ve tasarımı buna göre düzeltmektir.

Çalışma, bir güvenlik testinin yerini almaz. Test var olan bir sistemde gerçek zafiyet arar; modelleme ise henüz var olmayan bir sistemde tasarım varsayımlarını sorgular. İkisi farklı zamanlarda ve farklı sorulara yanıt verir.

Tehdit Modelleme Nedir?

Tehdit modelleme, bir sistemin bileşenleri, veri akışları ve güven sınırları üzerinden olası tehdit senaryolarının yapılandırılmış biçimde çıkarılması ve önceliklendirilmesidir.

Yöntem, dört temel soruya yanıt aramak olarak özetlenir: ne inşa ediyoruz, ne ters gidebilir, bununla ilgili ne yapacağız ve yaptığımız iş yeterli mi? Bu dört soru, hangi çerçeve kullanılırsa kullanılsın çalışmanın omurgasını oluşturur.

Adımları Nelerdir?

İlk adım sistemin çizilmesidir. Bileşenler, veri depoları, dış varlıklar ve aralarındaki akışlar bir diyagrama dökülür; ardından güven sınırları işaretlenir. Bu diyagram olmadan sonraki adımlar dayanaksız kalır.

İkinci adım tehditlerin çıkarılmasıdır. Her sınır ve akış için kategorilere göre soru sorulur; bu aşamada eleme yapılmaz, akla gelen her senaryo listeye alınır. Eleme ve önceliklendirme sonraki adımın işidir.

• Sistemi çiz: bileşenler, akışlar, veri depoları, dış varlıklar
• Güven sınırlarını işaretle
• Her sınır için tehdit kategorilerini uygula
• Senaryoları etki ve olabilirliğe göre önceliklendir
• Her öncelikli senaryo için karşı önlem belirle
• Kararları ve kalan riskleri yaz, sürüm takibine bağla

Hangi Yöntemler Kullanılır?

En yaygın çerçeve STRIDE‘dır; tehditleri altı kategoriye ayırarak sistematik tarama sağlar. Saldırgan bakışını öne çıkaran saldırı ağaçları, varlık merkezli yaklaşımlar ve risk odaklı yöntemler de kullanılır.

Yöntem seçimi ekibin deneyimine göre yapılır. Deneyimsiz ekiplerde kategorili çerçeveler daha iyi sonuç verir çünkü akla gelmeyeni hatırlatır; deneyimli ekiplerde ise senaryo temelli serbest çalışma daha derin bulgular üretebilir.

Ne Zaman ve Ne Sıklıkla Yapılır?

İlk modelleme, mimari kararlar alınırken yapılır. Bu aşamada çıkan bulgular doğrudan tasarım değişikliğine dönüşebildiği için en yüksek getiriyi sağlar. Geç yapılan modelleme, çoğunlukla ertelenen bir iyileştirme listesi üretir.

Sonrasında model, sistemin önemli değişikliklerinde güncellenir: yeni bir entegrasyon eklendiğinde, veri akışı değiştiğinde ya da güven sınırları kaydığında. Değişmeyen bir sistemde her sürümde yeniden modelleme yapmak gereksizdir.

Çıktısı Ne Olmalı?

Çalışmanın çıktısı bir rapor değil, izlenebilir işler olmalıdır. Her öncelikli senaryo için ya bir tasarım değişikliği, ya bir güvenlik gereksinimi, ya bir test senaryosu ya da bilinçli bir risk kabulü yazılır.

Bu çıktılar ekibin kendi iş takip aracına girer. Ayrı bir belgede kalan bulgular, geliştirme akışının dışında kaldıkları için büyük olasılıkla uygulanmaz.

Sık Yapılan Hatalar

En yaygın hata, çalışmayı yalnızca güvenlik ekibinin yapmasıdır. Sistemi en iyi tasarlayan ekip bilir; onlar olmadan yapılan modelleme yanlış varsayımlar üzerine kurulur ve önerileri uygulanabilir olmaz.

İkinci hata, mükemmel diyagram peşinde koşmaktır. Çizim aracının detayına harcanan zaman, tehdit çıkarmaya ayrılan zamandan çalar; beyaz tahtada çizilmiş kaba bir diyagram çoğu çalışma için yeterlidir.

Oturum Nasıl Yürütülür?

Verimli bir tehdit modelleme oturumu genellikle iki saati aşmaz ve az sayıda kişiyle yapılır. Odada sistemi tasarlayan mühendis, ürün sahibi ve güvenlik tarafından bir kişi bulunması çoğu durumda yeterlidir. Kalabalık toplantılar tartışmayı dağıtır ve karar üretmeyi zorlaştırır. Oturumun sonunda her katılımcının üzerinde anlaştığı somut bir iş listesi çıkmalıdır.

Oturum, sistemin katılımcılar tarafından birlikte çizilmesiyle başlar. Çizim sırasında ortaya çıkan anlaşmazlıklar çoğu zaman bulguların kendisi kadar değerlidir; ekibin sistemi farklı anladığı bu aşamada görülür. Diyagram üzerinde uzlaşıldıktan sonra kategorilere geçilir. Bu sıralamanın bozulması, oturumun teknik bir tartışmaya dönüşmesine yol açar.

Kayıt tutma işi önceden bir kişiye verilir. Konuşulan senaryoların anında yazılması, oturum sonrası hatırlama çabasını ortadan kaldırır. Kayıtlar ham hâliyle bile değerlidir; sonradan düzenlenip önceliklendirilebilir. Yazılmayan senaryolar ise oturum biter bitmez kaybolur.

Her Projede Nasıl Ölçeklendirilir?

Her değişiklik için tam kapsamlı bir oturum düzenlemek mümkün değildir. Bu nedenle olgun kurumlar kademeli bir yaklaşım kullanır: küçük değişiklikler için kısa bir kontrol listesi, orta ölçekli değişiklikler için yarım saatlik bir gözden geçirme, yeni sistemler için tam oturum. Hangi değişikliğin hangi kategoriye gireceği önceden yazılır. Böylece süreç öngörülebilir hâle gelir ve ekipler tarafından benimsenir.

Kontrol listeleri, tam oturumun yerini tutmasa da yaygın hataları yakalar. Kimlik doğrulama nerede yapılıyor, yeni bir dış bağımlılık eklendi mi, hassas veri yeni bir yere yazılıyor mu gibi sorular kısa sürede yanıtlanabilir. Listenin kısa tutulması kullanılma olasılığını artırır. Uzun listeler doldurulur ama okunmaz.

Ölçeklendirmenin diğer yolu, ekiplere kendi modellemelerini yapabilecek yetkinliği kazandırmaktır. Güvenlik ekibinin her oturumda bulunması gerekmez; yöntem öğretildiğinde ekipler kendi çalışmalarını yürütür ve yalnızca karmaşık senaryolarda destek ister. Bu model, güvenlik ekibinin darboğaz olmasını engeller.

Çıktıların Testle Bağlanması

Modelleme sırasında çıkan her senaryo, mümkün olduğunda bir test senaryosuna dönüştürülür. Böylece tasarım aşamasındaki varsayım, sonraki her sürümde otomatik olarak sınanır. Bu bağlantı kurulmadığında bugün kapatılan bir açık, gelecekteki bir değişiklikle yeniden açılabilir. Güvenli geliştirme yaşam döngüsü bu bağı süreç olarak kurar.

Testlerin tamamı otomatikleştirilemez. Yetkilendirme ve iş mantığı senaryolarının bir kısmı elle yürütülen gözden geçirmelerle doğrulanır. Bu durumda senaryolar bir kontrol listesine yazılır ve sürüm öncesi kontrolde kullanılır. Önemli olan, hiçbir senaryonun yalnızca toplantı notunda kalmamasıdır.

Privia Security olarak yeni sistem tasarımlarında tehdit modelleme oturumlarını ekiplerle birlikte yürütüyor,çıktıları altyapı ve mimari gözden geçirme raporuyla uygulanabilir maddelere dönüştürüyoruz.