Tehdit modelleme nedir?

Açılış

Selin'in ekibine pazartesi sabahı yeni bir özellik geldi: hediye listesi. Bir müşteri sitede beğendiği ürünlerden bir liste yapacak, listenin bağlantısını arkadaşlarıyla paylaşacak; arkadaşları listeden bir ürün seçip ödemesini yapacak ve ürün doğrudan liste sahibinin adresine gidecekti. Pazarlama ekibi özelliği yılbaşından önce istiyordu. Tasarım hazırdı, ekranlar çizilmişti.

Geliştiriciler işi bölüştürmeye başlamışken Selin bir şey sordu: "Arkadaş hediyeyi alırken teslimat adresini görecek mi?"

Masada kısa bir sessizlik oldu. Tasarımda adres, ödeme sayfasında "teslimat bilgisi" başlığı altında açıkça yazıyordu. Bağlantıyı alan herkes, yani bağlantı bir sosyal medya paylaşımına düşerse tanımadığı herkes, liste sahibinin ev adresini görecekti. Kimse bunu kötü niyetle tasarlamamıştı. Sadece kimse sormamıştı.

Selin, kod yazılmadan önce yarım saat istedi. "Dört soru soracağız," dedi. "Cevapları bir sayfaya yazacağız. Sonra işe başlarız."

Tek fikir

Tehdit modelleme, bir sistemi daha kurulmadan ya da değişmeden önce masaya yatırıp dört soru sormaktır: ne üzerinde çalışıyoruz, ne ters gidebilir, bu konuda ne yapacağız ve yeterince iyi iş çıkardık mı. Amaç bir rapor değil, tasarımın erken ve ucuz düzeltilmesidir.

Nasıl çalışır

Önceki modül riski bir kurumun bütününe yukarıdan bakarak tarttı. Bu modül tek bir sisteme, içinden bakıyor.

Bu tanımın ve dört sorunun en çok başvurulan özeti, alandaki uygulayıcıların birlikte yazdığı kısa bir metindir.

Dört soruyu Selin'in hediye listesi üzerinden açalım.

Birinci soru, ne üzerinde çalışıyoruz? Cevap, sistemin basit bir çizimidir: müşteri listeyi oluşturur, liste bir bağlantıyla paylaşılır, arkadaş bağlantıyı açar, ürünü seçer, öder; sipariş sistemi ürünü liste sahibinin adresine gönderir. Çizimde kimin neyi gördüğü, verinin nereden nereye aktığı görünür olmalıdır. Bir sonraki ders bu çizimin nasıl yapılacağını anlatıyor.

İkinci soru, ne ters gidebilir? Burada amaç saldırı tarifi yazmak değil, kaygıları adlandırmaktır. Selin'in ekibi üç kaygı yazdı: bağlantıyı alan herkes liste sahibinin adresini görebilir; bağlantının tahmin edilebilir olması, listelerin başkaları tarafından bulunmasına yol açabilir; liste sahibinin hesabı ele geçirilirse teslimat adresi değiştirilip hediyeler başka bir yere yönlendirilebilir.

Üçüncü soru, buna karşı ne yapacağız? Her kaygı için bir karar yazılır. Adres arkadaşa hiç gösterilmeyecek; ödeme sayfasında yalnız "liste sahibinin kayıtlı adresine gönderilecek" yazacak. Bağlantılar uzun ve tahmin edilemez olacak, sahibi bağlantıyı istediği an iptal edebilecek. Teslimat adresi değiştiğinde liste sahibine e-posta ile bildirim gidecek.

Dördüncü soru, yeterince iyi iş çıkardık mı? Bu, hem modelin kendisine hem de uygulamaya yöneltilen sorudur. Kaygıların her biri bir karara bağlandı mı? Kararlar gerçekten koda girdi mi? Test aşamasında, adresin ödeme sayfasında görünmediği kontrol edildi mi?

Dört sorunun gücü, her birinin bir sonrakine girdi vermesidir. Çizim olmadan neyin ters gidebileceği tahmine kalır; kaygı listesi olmadan kararlar rastgele olur; kararlar yazılmadan neyin doğrulanacağı belli olmaz.

Selin'in yakaladığı şeyin bir adı var.

Hediye listesinde adresin görünmesi bir tasarım kusuruydu: kod doğru yazılsa da adres görünecekti. Bu tür kusurlar ancak tasarım masadayken ucuza düzeltilir. Tehdit modellemenin yazılım geliştirme süreçlerinde ayrı bir uygulama olarak yer almasının nedeni budur.

Sahada

Savunma

Tehdit modelleme bir savunma aracıdır, çünkü savunmayı saldırıdan önceye taşır. Bir tasarım kusuru yayından sonra bulunursa, düzeltmesi hem pahalıdır hem de o arada kullanıcılar zarar görmüş olabilir; tasarım masasında bulunursa düzeltmesi bir cümledir.

İlk kazanım, varsayımların görünür olmasıdır. Hediye listesi tasarımında kimse adresin görünmesine karar vermemişti; sadece kimse sormamıştı. Dört soru, sorulmamış soruları sormanın bir düzenidir.

İkinci kazanım, kararların yazılı olmasıdır. Selin'in ekibinin tek sayfası, her kaygının yanına bir karar koydu. Bu sayfa, kodu yazan geliştiriciye, testi yazan kişiye ve iki ay sonra yeni bir alan isteyen pazarlama ekibine aynı şeyi söyledi.

Tespit tarafında dördüncü soru devreye girer. "Yeterince iyi iş çıkardık mı?" sorusu, kararların test edilecek maddelere dönüşmesini sağlar: ödeme sayfasında adres görünmüyor mu, iptal edilen bağlantı gerçekten çalışmıyor mu, adres değiştiğinde e-posta gidiyor mu?

Ve tehdit modelleme bir kez yapılıp bırakılmaz. Manifesto tek bir teslim yerine sürekli iyileştirmeyi değerli sayar; Selin'in ekibinde yeni bir alan geldiğinde model on dakikada güncellendi. Bir kayıt defteri gibi, tehdit modeli de sistem yaşadıkça yaşar.

Uygulama

Bu derste dört soruyu kendi kullandığın küçük bir sisteme soracaksın. Amaç tekniği öğrenmek değil, soruları sormanın alışkanlığını kazanmaktır.

Dört başlık dolduğunda elinde ilk tehdit modelin olacak. Bir sonraki derste bu çizimi daha düzenli bir biçime sokacağız.

Defter: Tehdit modelleme bölümüne seçilen sistemin adı, dört başlıklı ilk model: çizim, en az beş kaygı, her kaygının kararı, kontrol yolu ve bugün yapılan ilk kontrolün sonucu. Çağrılan kişinin eklediği kaygı.

Hata köşesi

Etik ve sınırlar

Tehdit modelleme, bir sistemin zayıf noktalarını bilerek aramaktır; bu yüzden kapsamı, sana ait olan ya da üzerinde çalışma yetkin ve izni bulunan sistemlerle sınırlı tutulur. Bir başkasının uygulamasını ya da sitesini "ne ters gidebilir" sorusuyla incelemek düşünce olarak serbesttir; ama o kaygıları sistemin üzerinde denemek, sahibinin açık izni olmadan yasal ve etik sınırı aşar. Tehdit modeli belgesinin kendisi de hassastır: bir sistemin bilinen kaygılarını ve henüz uygulanmamış kararları içerir, erişimi işi gereği görmesi gerekenlerle sınırlanmalıdır. Mahremiyet kaygıları, güvenlik kaygıları kadar ciddiye alınmalıdır: Selin'in hediye listesinde kimse saldırıya uğramadan da bir adres yanlış kişilere görünebilirdi. Tehdit modelleme toplantısında dürüst konuşanı korumak, örneğin bir eksikliği söyleyen depo şefini suçlamamak, bir sonraki toplantının işe yaramasının koşuludur.

Kapanış

1. Tehdit modelleme bir sistemi kurmadan ya da değiştirmeden önce dört soru sormaktır: ne üzerinde çalışıyoruz, neler bozulabilir, hangi kararları alacağız, işimiz yeterli oldu mu.
2. En değerli bulguları tasarım kusurlarıdır: kod kusursuz yazılsa da kalan, ancak tasarım masasında ucuza düzeltilebilen sorunlar.
3. Tehdit modelleme herkesin işidir ve bir kez yapılıp bırakılmaz; sistemi tanıyanlar masaya çağrılır ve model sistem değiştikçe güncellenir.

Üç soru

1. Hediye listesinde adresin görünmesi neden bir kodlama hatası değil, bir tasarım kusuruydu?
2. Kaan'ın şirketinde açık terminal kaygısı nereden geldi ve bu, manifestonun hangi uyarısını gösterdi?
3. Selin'in ekibi yeni not alanı geldiğinde modeli neden on dakikada güncelleyebildi?

Yanıtlar

1. Adresin ödeme sayfasında görünmesi, kodun yanlış yazılmasından değil, tasarımın kendisinden geliyordu: kod tasarıma uygun yazılsa bile bağlantıyı alan herkes adresi görecekti. Bu yüzden düzeltme kodda değil, tasarım kararında yapıldı: adres arkadaşa hiç gösterilmeyecekti.
2. Kaygıyı bir güvenlik uzmanı değil, depo şefi getirdi; vardiya değişiminde terminallerin açık kaldığını yalnız o biliyordu. Bu, manifestonun "kahraman tehdit modelleyici" kalıbına karşı uyarısını ve farklı bakış açılarını masaya toplamanın değerini gösterdi.
3. Çizim ve kaygı listesi ilk çalışmadan zaten vardı. Yeni alan, var olan modelin üzerine eklenen küçük bir değişiklikti; ekip yalnız bu değişikliğin getirdiği yeni kaygıyı, notlarda kişisel bilgi paylaşılabilmesini, ele alıp kararını yazdı.

Sonraki derse köprü

Birinci soru, ne üzerinde çalıştığımız, bu derste kutular ve oklarla kaba bir çizimle cevaplandı. Veri akış diyagramı dersi bu çizime düzen veriyor: süreçler, veri depoları, dış varlıklar ve akışlar için ayrı işaretler ve çizimin ne kadar ayrıntılı olması gerektiği.