Çoğu tehdit modeli, kimsenin iki kez açmadığı bir Confluence sayfasında ölür. Bir ekip üç saatliğine bir oda ayırtır, güzel bir veri akış diyagramı çizer, ulus-devlet saldırganları hakkında tartışır ve süt gibi çabuk bozulan bir PDF üretir. İki sprint sonra mimari değişmiştir, diyagram yanlıştır ve "eylem maddeleri" hiçbir zaman kayda dönüşmemiştir.
Sorun tehdit modellemesi değildir. Sorun, çoğu ekibin onu bir alışkanlık yerine bir etkinlik olarak ele alması - ve beyaz tahtayı, mühendislik işinin gerçekten yaşadığı tek yere, yani iş listesine hiçbir zaman bağlamamasıdır.
Tehdit modellemesi bir çerçeve değil, dört sorudur
Kısaltmaları ayıklayın; tüm pratik, Adam Shostack'ın ünlü hale getirdiği dört soruya indirgenir ve bunları karmaşıklaştırmak için hiçbir zaman bir neden bulamadım:
- Ne inşa ediyoruz? Ezberden çizilebilecek kadar basit bir diyagram. Kutular, oklar ve güven sınırları - verinin, denetlediğiniz bir şeyden denetlemediğiniz bir şeye geçtiği yer.
- Ne ters gidebilir? Her sınırı ve her veri akışını adım adım gözden geçirin. STRIDE burada iyi bir yönlendirici olsa da, sade bir "bunu nasıl kötüye kullanırdım?" sorusu sizi yolun %80'ine götürür.
- Bu konuda ne yapacağız? Bu, herkesin atladığı adımdır. Her gerçek tehdit bir karara dönüşür: azalt, kabul et ya da devret.
- İyi bir iş çıkardık mı? Bir takvime göre değil, tasarım değiştiğinde yeniden gözden geçirin.
Bir araca ihtiyacınız yok. Verdiğim danışmanlıklarda en yüksek sinyalli oturumlar bir beyaz tahta, onun bir fotoğrafı ve "bu aslında istismar edilebilir değil, sonraki" demeye istekli bir kişi kullandı.
Kapsamını bir özellikle sınırlayın, süresini bir saatle kutulayın
"Tüm platformu" modellemek, işe yaramaz PDF'yi elde etme biçiminizdir. Bu çeyrekte gerçekten hayata geçirdiğiniz şeyi modelleyin: yeni dosya yükleme akışı, iş ortağı API'si, parola sıfırlama yolu. Dar bir kapsam, diyagramın tek bir tahtaya sığması ve ekibin bütünü zihninde tutabilmesi demektir.
Bunu erken yapın - tasarım sırasında, kod yazılmadan önce, bir güven sınırını değiştirmenin bir yeniden düzenleme (refactor) yerine bir sohbete mal olduğu zaman. İşin gizli tehlikelerinin nerede olduğunu bilen kişileri davet edin: bir arka uç mühendisi, bir ön uç mühendisi, altyapının sahibi kim ise ve ideal olarak bir bekçi değil, kolaylaştırıcı olarak davranan güvenlikten biri.
Koruduğu özellikten daha uzun sürede üretilen bir tehdit modeli tekrarlanmaz. Kapsayıcı için değil, tekrarlanabilir için optimize edin.
Altmış ila doksan dakika, bir özellik, üç ya da dört güven sınırı. Bir düzineden fazla inandırıcı tehdit bulursanız, bu tasarımın fazla karmaşık olduğuna dair bir sinyaldir - ki bu, üzerine harekete geçmeye değer başlı başına bir bulgudur.
Önemli olan adım: beyaz tahtadan iş listesine
İyi niyetlerin öldüğü yer işte burasıdır. Odadan on beş "endişe" ile ve hiçbir sahip olmadan çıkarsınız. Çözüm mekaniktir: azaltmaya karar verdiğiniz her tehdit, kimse odadan ayrılmadan önce bir iş listesi maddesine dönüşür.
Onları denetim bulguları gibi değil, gerçek iş gibi yazın. Kötü: "SQL enjeksiyonu riski." İyi: "Rapor arama sorgusunu parametreleştir ve ham dize birleştirmede başarısız olan bir test ekle." Bir geliştiricinin bir çeviri katmanı olmadan üstlenebileceği bir kayıt.
İş listesine gerçekte ne girer
- Azaltıcı önlemler - aç kalan ayrı bir "güvenlik iş listesinde" değil, özellik çalışmasının yanında boyutlandırılıp önceliklendirilen somut mühendislik görevleri.
- Kabul edilen riskler - bir isim ve bir tarihle yazıya dökülür. "Herkese açık listelemelere kimlik doğrulaması olmadan okuma erişimini kabul ediyoruz - M.A., 2026-07." Sessiz kabul, bir ihlali bir düzenleyiciye açıklamakla sonuçlandığınız yerdir.
- Doğrulanacak varsayımlar - "ağ geçidinin bu başlığı ayıkladığını varsayıyoruz." Bunların yarısı yanlış çıkar. Onları da kayda dönüştürün.
Daha sonra bulabilmeniz için onları etiketleyin. Kaydı, diyagram fotoğrafına geri bağlayın. Planlamada bir azaltıcı önlem bir özellikle rekabet ettiğinde, en azından ödünleşim görünmez değil, görünür olur.
Bunu kahramanca bir etkinlik değil, bir alışkanlık yapın
Bundan değer elde eden ekipler yıllık bir güvenlik kampı düzenlemez. Kimlik doğrulama, para, PII veya yeni bir dış entegrasyona dokunan herhangi bir şeyin tasarım incelemesinde tehditlere yirmi dakika ayırırlar. Bu, test yazmak kadar sıradan hale gelir.
Onu canlı tutan birkaç şey:
- Bunu içeren bir "tamamlandı" tanımı. Belirli bir risk katmanının üzerindeki özelliklerde bir onay kutusu olarak "Tasarım güvenlik tehditleri açısından incelendi."
- Donmuş değil, yaşayan bir diyagram. Onu kodun yanında depoda (repo) tutun. Güncel olan kaba bir diyagram, bir yıl bayatlamış muhteşem bir diyagramdan iyidir.
- Denetlemek yerine kolaylaştırmak. Güvenlik kişisinin işi keskin sorular sormaktır, bir hüküm vermek değil. Model ekibindir.
Pazartesi nereden başlamalı
Şu anda tasarım aşamasında olan bir özellik seçin. Altmış dakika ayırtın. Kutuları ve güven sınırlarını çizin, her birini "bunu nasıl kötüye kullanırdım" diye sorarak adım adım gözden geçirin ve kimse ayağa kalkmadan önce, üzerinde anlaşılan her azaltıcı önlemi bir sahibi olan bir kayda dönüştürün. Kusursuz diyagramı geçin. Kapsayıcı saldırgan taksonomisini geçin.
Amaç asla güzel bir belge olmadı. Amaç, bu sprintte bir sonraki ihlali başkasının hikâyesi yapan bir avuç kayıttı. Tehdit modellemeniz iş listesini değiştirmiyorsa, hiç gerçekleşmemiştir.