Kapsayıcı Güvenlik Tasarımı: İstismarı Ürün Canlıya Çıkmadan Görmek
Bir ürünün nasıl kötüye kullanılabileceği çoğu ekipte ilk kez destek kayıtlarında ortaya çıkar, yani iş işten geçtikten sonra. Eva PenzeyMoog'un Design for Safety kitabındaki beş adımlı süreç aynı soruyu tasarım masasına taşıyor: araştır, arketip kur, senaryoları çıkar, çözüm tasarla, iki taraftan da test et. Adımların hepsi her projede gerekmiyor, ama sıraları kendi içinde tutarlı.
Araştırma: zarar nerede olmuş?
İlk adım ürünün kötüye kullanım yollarını hayal etmek değil, benzerlerinde ne olduğuna bakmak. Akıllı ev cihazlarının, konum paylaşımının, ortak hesapların birinin diğerini izlemesi için kullanıldığı vakalar dava dosyalarında ve haber arşivlerinde fazlasıyla var. Peki uzmana da mağdura da erişimi olmayan üç kişilik bir ekip ne yapar? Kendi destek kuyruğuna bakar. "Eski eşim hesabıma giriyor" tipi talepler zaten oradadır, sadece güvenlik başlığı altında sınıflandırılmamıştır.
Mağdurlarla ya da onlarla çalışan uzmanlarla görüşülecekse iki koşul var: görüşme etik bir çerçevede yürür ve katkı ücretlendirilir. Deneyimini anlatan kişi sana araştırma malzemesi veriyor, gönüllü hikâye değil.
Arketip, persona değil
Persona gerçek kullanıcılarla yapılan görüşmelerden çıkar. İstismarcı ve mağdur arketipleri ise örüntüden çıkar: kimseyle görüşmeden, olay kayıtlarında tekrar eden davranışı tarif edersin. Bir fitness uygulamasında ayrıldığı kişinin koşu rotalarını takip eden kullanıcı tek bir kişi değil, tekrar eden bir kalıptır.
Mağdur tarafında tek arketip yetmiyor. Neyin olup bittiğini bilen ama durduramayan kullanıcıyla, durumun farkında bile olmayan kullanıcı tasarımdan bambaşka şeyler ister. Birincisi ayara giden en kısa yolu arar. İkincisinin ise ilk sinyali arayüzde görmesi gerekir, çünkü aramayı akıl edeceği bir şey yok. Aynı ekranla ikisini birden kurtaramazsın.
Uyarı kimin eline geçiyor?
Çözüm tasarlarken sorular kısa: zarar tamamen engellenebiliyor mu, engellenemiyorsa nasıl zorlaştırılır, mağdur olan biteni fark edebilir mi, fark ettiğinde durdurabilir mi?
Şüpheli aktiviteyi otomatik tespit edip kullanıcıyı uyarma fikri bu noktada kulağa hoş geliyor. Tespiti doğrudan bildirime bağlamam. Sebebi arketiplerin kendisinde duruyor: bu senaryoların çoğunda istismarcının cihaza, hesaba ya da bildirimlere erişimi zaten var. "Hesabınızda olağandışı erişim tespit edildi" satırı kilit ekranında görünüyorsa mağduru değil karşı tarafı uyarmış olursun. Kaynak metnin atladığı sınır da burası, tespitle bildirimi tek bir özellik saymak. Tespit sunucuda kalabilir; kullanıcıya ne zaman, hangi kanaldan söyleneceği ayrı bir karardır.
Yanlış pozitifin maliyeti de simetrik değil. Sıradan bir üründe hatalı uyarı can sıkar, burada bir kullanıcıyı kendi evinde tehlikeye atabilir.
İki taraftan test
Test aşaması ikiye ayrılıyor. İstismarcı testinde soru şu: arketipin hedefine ulaşmasını ürün gerçekten engelliyor mu? Konumunu gizlemek isteyen kullanıcının konumu, uygulamanın bir köşesinden, paylaşılan bir rapordan ya da bildirim önizlemesinden sızıyor mu? Bu iş kullanılabilirlik testinden çok sızma testine benziyor ve ekipte "bunu nasıl kırarım" diye düşünmekten hoşlanan birine ihtiyaç duyuyor.
Mağdur testinde akış tersten yürür: kullanıcı sorunu fark edebiliyor mu, erişimi geri alabiliyor mu, ayarı kaç adımda değiştiriyor? Bunu sakin bir odada ölçmek yanıltıcı. İnsan bu ekranları hayatının en kötü gününde açıyor, o yüzden aynı akışın baskı altında bir kez daha denenmesi gerekiyor.
Yayına çıkmış üründe de yapılır. Hatta arşivdeki eski özellikler sıranın başında olmalı, çünkü bu senaryoların çoğu o kod ilk yazılırken kimsenin aklında yoktu.
Kaynak