Bir uygulamanın tehdit modeli

Açılış

Selin'in eski bir okul arkadaşı olan diş hekimi Aylin Hanım, Kadıköy'deki kliniği için küçük bir yazılım ajansına randevu uygulaması yaptırıyordu. Hastalar internetten randevu alacak, bir gün önce kısa mesajla hatırlatma gelecek, klinik sekreteri randevuları bir yönetim panelinden düzenleyecek, hekimler de her randevunun altına kısa bir tedavi notu yazabilecekti. Ajans ekranları göstermiş, iki ay içinde teslim sözü vermişti.

Aylin Hanım bir akşam Selin'i aradı. "Ajans güvenlik konusunda 'her şey şifreli, merak etme' diyor," dedi. "Ben ne soracağımı bilmiyorum."

Selin bir cumartesi sabahı kliniğe gitmeyi önerdi. Masaya Aylin Hanım, sekreter Nurcan Hanım, ajanstan bir geliştirici ve Selin oturdu. Selin bir tahta kalemi aldı ve modülün bütün adımlarını tek bir sabaha sığdırmaya hazırlandı: önce sistemi çizecek, sonra sınırları işaretleyecek, sonra tehditleri arayacak, sıralayacak, her birine bir cevap yazacak ve en sonda kendi işlerini denetleyeceklerdi.

"Bir sabah yeter mi?" diye sordu Aylin Hanım.

"İlk sürüm için yeter," dedi Selin. "Sonra her değişiklikte bir saat daha."

Tek fikir

Bir uygulamanın tehdit modeli, modülün bütün araçlarını tek bir çalışmada birleştirir: diyagram, güven sınırları, STRIDE, saldırı ağacı, önceliklendirme, her tehdide bir yanıt ve sonunda bir gözden geçirme. Çıktısı bir rapor değil, uygulanabilir ve test edilebilir güvenlik gereksinimlerinin listesidir.

Nasıl çalışır

Bu atölyenin iskeleti, modül boyunca kullandığımız uygulama güvenliği rehberinin son iki adımından gelir: tehditlere yanıt vermek ve işi denetlemek.

Modelin çıktısı bir kavramla adlandırılır.

Bir gereksinimin iyi yazılıp yazılmadığını anlamanın yolu, onu test edecek kişiye vermektir. "Uygulama güvenli olmalı" bir gereksinim değildir; "hatırlatma mesajı tedavi türünü içermez" bir gereksinimdir, çünkü bir mesaja bakarak doğru ya da yanlış olduğu söylenebilir.

Bu kararların bir yerde tutulması da başlı başına bir uygulamadır.

Bir sağlık uygulamasında bir boyut daha vardır: verinin kendisinin yasal niteliği.

Sahada

Savunma

Bir uygulamanın tehdit modeli, savunmayı soyut bir istek olmaktan çıkarıp bir iş listesine dönüştürür. Aylin Hanım'ın ajansa "her şey güvenli mi?" yerine on dört test edilebilir gereksinimle gitmesi bu dönüşümdür.

Önce sistemi işi yapanlarla çiz. Paylaşılan sekreter hesabını ne Aylin Hanım ne de ajans biliyordu; Nurcan Hanım biliyordu. Diyagramın doğruluğu, masadaki kişilerin çeşitliliğine bağlıdır.

Sonra güven sınırlarında yoğunlaş. Randevu uygulamasında dört sınır vardı: internet ile uygulama, personel ile panel, uygulama ile kısa mesaj sağlayıcısı, uygulama ile barındırma hizmeti. En hassas veri olan tedavi notlarının hangi sınırları geçtiği, önlemlerin yerini gösterdi.

Sonra en ucuz dalı kapat. Hatırlatma mesajındaki tedavi türü, bir tasarım kusuruydu ve tek cümleyle düzeltildi. Bir önceki dersin kuralı burada da geçerliydi: ağır ve ucuz bir düzeltme listenin en başına çıktı.

Sonra her tehdide bir yanıt yaz. Kısa mesaj sağlayıcısıyla yapılan sözleşmeye mesajların ne kadar süre saklanacağı maddesi eklendi; bu bir aktarma değil, bir azaltmaydı, çünkü sorumluluğu değil veriyi küçültüyordu. Hekim notlarının bir mobil uygulamadan da yazılabilmesi özelliği ilk sürümden çıkarıldı; bu bir ortadan kaldırmaydı. Panelin klinik dışından erişilebilmesi ise ikinci doğrulama adımıyla birlikte kabul edildi ve gerekçesi yazıldı.

Tespit tarafında modelden iki gereksinim çıktı: panele her girişin ve her tedavi notu görüntülemesinin kaydedilmesi, ve Aylin Hanım'ın ayda bir bu kayıtların özetine bakması.

Son olarak modeli sakla ve güncelle. NIST'in çerçevesinin istediği gibi, kararlar ve gerekçeleri uygulamanın ömrü boyunca tutulur; her yeni özellik, modele eklenen küçük bir sayfa olur.

Uygulama

Bu atölyede bir uygulamanın tehdit modelini baştan sona kuracaksın. Modülün her dersinde bir parçasını denedin; şimdi hepsi tek bir çalışmada birleşiyor.

Modelin özet tablosu şu sütunları taşıyabilir:

Çalışmanın sonunda elinde bir diyagram, bir kaygı tablosu, bir ağaç, bir öncelik sırası ve bir gereksinim listesi olacak. Bu beşi birlikte, o uygulamanın ilk tehdit modelidir.

Defter: Uygulamanın adı ve kapsamı, katılan kişiler, diyagram, özel nitelikli verilerin işaretlendiği veri listesi, güven sınırları, STRIDE tablosu, saldırı ağacı ve en ucuz dal, öncelik sırası, her kaygının yanıtı, test edilebilir güvenlik gereksinimleri, altı gözden geçirme sorusunun cevapları ve bir sonraki güncelleme tarihi.

Hata köşesi

Etik ve sınırlar

Bir uygulamanın tehdit modelini kurmak, o uygulamanın sahibinin daveti ve yetkisiyle yapılan bir iştir; Selin kliniğin modeline Aylin Hanım'ın isteğiyle katıldı ve ajansın sistemlerine hiçbir şekilde dokunmadı, yalnız tasarımı ve belgeleri konuştu. Model, bir sağlık uygulamasında hasta verisinin nereden geçtiğini ve nerede zayıf olduğunu gösterir; bu yüzden yalnız bu işte görevli olanların erişebileceği bir yerde saklanır, kliniğin ortak klasörüne ya da bir mesajlaşma grubuna konmaz. Sağlık verisi özel nitelikli olduğu için, tasarım kararlarında hastanın beklentisi de hesaba katılır: bir hasta, randevusunun hangi tedavi için olduğunun ailesinin göreceği bir ekranda yazmasını beklemez. Modelde bulunan bir eksiklik, ajansı suçlamak için değil, uygulamayı düzeltmek için kullanılır; Aylin Hanım'ın teslim toplantısına götürdüğü liste bir şikâyet değil, bir iş tanımıydı.

Kapanış

1. Bir uygulamanın tehdit modeli modülün bütün araçlarını sırayla birleştirir: diyagram, veri ve sınırlar, STRIDE, saldırı ağacı, önceliklendirme, yanıtlar ve gözden geçirme.
2. Her tehdit için azaltma, ortadan kaldırma, aktarma ya da kabul seçilir; azaltma kararları test edilebilir güvenlik gereksinimlerine, kabuller yazılı gerekçelere dönüşür.
3. Model bütün paydaşlarca gözden geçirilir, yalnız bilmesi gerekenlerin erişebileceği biçimde saklanır ve her değişiklikte güncellenir; özel nitelikli veri taşıyan uygulamalarda tasarım kararları bu verinin yasal niteliğini de hesaba katar.

Üç soru

1. Kliniğin saldırı ağacında en ucuz dal neydi ve neden hiçbir saldırı gerektirmiyordu?
2. "Veriler şifreli tutulur" maddesi neden bir güvenlik gereksinimi sayılmadı ve nasıl düzeltildi?
3. Paylaşılan sekreter hesabını kim fark etti ve bu, modeli kimlerin incelemesi gerektiği hakkında ne söyler?

Yanıtlar

1. Hatırlatma mesajı taslağı tedavi türünü içeriyordu. Bu metin kısa mesaj sağlayıcısına gidiyor ve hastanın kilitli telefon ekranında, aile üyelerinin görebileceği bir yerde beliriyordu. Tasarımın kendisi sağlık verisini açığa çıkarıyordu; bu yüzden hiçbir saldırı gerekmedi ve mesaj tedavi türü olmadan yeniden yazıldı.
2. Madde hangi verinin, nerede ve hangi anahtarla şifrelendiğini söylemiyordu; bu yüzden test edilemezdi. Üç gereksinime bölündü: tedavi notları veritabanında şifreli saklanır, yedekler şifreli alınır, şifreleme anahtarı barındırma hizmetinin anahtar yönetiminde tutulur ve uygulama sunucusunun dosyalarında bulunmaz.
3. Diyagram çizilirken sekreter Nurcan Hanım, öğle aralarında hekimin asistanının panele onun hesabıyla baktığını söyledi; ajans bunu bilmiyordu. Bu, OWASP'ın modelin yalnız teknik ekiplerce değil bütün paydaşlarca incelenmesi önerisinin nedenini gösterir: sistemin gerçekte nasıl kullanıldığını işi yapanlar bilir.

Sonraki derse köprü

Bu modelde birçok önlem tek bir ilkeye dayanıyordu: tek bir önlem çökse bile ardında bir başkasının durması. Derinlemesine savunma dersi, güvenlik mimarisi ilkelerinin ilkini bu düşünceyle açıyor: katmanların neden üst üste konduğunu ve bir katmanın ne zaman yalnız bir yanılsama olduğunu.