Tehdit modelleme nasıl yapılır: veri akışından önlemlere STRIDE yöntemi

Tehdit modelleme nedir, neden tasarım aşamasında yapılır?

Tehdit modelleme, bir yazılımın ya da sistemin saldırıya nasıl uğrayabileceğini tasarım aşamasında sistematik olarak düşünme çalışmasıdır. Amaç, hata ortaya çıktıktan sonra yama yapmak yerine, açığı henüz çizim tahtasındayken görmektir. Microsoft, tehdit modelleme aracını Güvenlik Geliştirme Yaşam Döngüsü'nün (SDL) çekirdek unsurlarından biri olarak tanımlar; amaç, mimarların güvenlik sorunlarını henüz kolay ve düşük maliyetle çözülebildikleri erken aşamada bulmasıdır.

Süreç; neyi koruduğunuzu (varlık), bunun nasıl çalıştığını (mimari), neyin ters gidebileceğini (tehdit) ve buna karşı ne yapacağınızı (önlem) sorarak ilerler. Bu bakış, kod taramasından ya da sızma testinden farklıdır: tarama mevcut kodu denetler, sızma testi çalışan sistemi dener, tehdit modelleme ise henüz yazılmamış ya da değiştirilecek tasarımı sorgular.

İyi tehdit modeli ağır bir belge değildir. Küçük bir ekip, bir tahta ve veri akış çizimi ile başlayabilir. Önemli olan model çıktısının geliştirme işine, yani gereksinimlere, test senaryolarına ve kod incelemesine dönüşmesidir.

STRIDE ile tehditleri kategorilere ayırmak

STRIDE, tehditleri altı kategoride sınıflandıran ve güvenlik konuşmasını basitleştiren bir modeldir. Microsoft Learn'deki tanıma göre kategoriler şunlardır: kimlik sahteciliği (Spoofing), veri üzerinde kötü niyetli değişiklik yapma (Tampering), eylemi inkâr etme (Repudiation), bilginin yetkisiz kişilere ifşası (Information Disclosure), hizmeti geçerli kullanıcılara engelleme (Denial of Service) ve yetkisiz kullanıcının yetki yükseltmesi (Elevation of Privilege).

Her kategori, bir güvenlik özelliğinin ihlaline karşılık gelir ve tipik önlem ailesini çağrıştırır. Sahtecilik için güçlü kimlik doğrulama, değişiklik için bütünlük kontrolü ve imza, inkâr için denetim kayıtları, ifşa için şifreleme ve erişim kontrolü, hizmet engelleme için kapasite ve hız sınırlama, yetki yükseltme için en az yetki ve yetki ayrımı akla gelir.

STRIDE'ı kontrol listesi gibi kullanmayın; soru üreten bir mercek olarak kullanın. Her veri akışında ve her bileşende altı kategoriyi sırayla sormak, akla gelmeyen senaryoları yüzeye çıkarır. Kategoriye uymayan tehdit varsa not alınır; yöntem sizi sınırlamamalıdır.

Adım adım: veri akış diyagramından önleme

Çalışma, sistemin veri akış diyagramını çizmekle başlar. Diyagramda dış varlıklar (kullanıcı, harici servis), süreçler (uygulama bileşenleri), veri depoları ve aralarındaki akışlar yer alır. Güven sınırları, yani farklı yetki ve güven düzeylerini ayıran çizgiler, işaretlenir: internet ile uygulama, uygulama ile veritabanı, kullanıcı ile yönetici. Tehditler genellikle bu sınırları geçen akışlarda yoğunlaşır.

İkinci adımda diyagramdaki her öğe ve akış için STRIDE soruları sorulur. Örneğin kullanıcı ile web uygulaması arasındaki akışta: biri kullanıcı gibi davranabilir mi, istek değiştirilebilir mi, işlem sonradan inkâr edilebilir mi? Üçüncü adımda bulunan tehditler kaydedilir ve değerlendirilir. Dördüncü adımda her tehdit için önlem belirlenir: gider, azalt, kabul et ya da başkasına devret. Son olarak model doğrulanır ve önlemler iş listesine aktarılır.

Önceliklendirme: her tehdit aynı ağırlıkta değildir

Bir modelleme çalışması çok sayıda tehdit çıkarabilir; hepsini kapatmak mümkün ya da gerekli değildir. Her tehdit iki eksende değerlendirilir: gerçekleşme olasılığı ve gerçekleşirse etkisi. Olasılığı yüksek ve etkisi yüksek tehditler ilk sırada ele alınır ve tasarım değişikliği gerektirir. Etkisi yüksek ama olasılığı düşük tehditler için izleme ve olay planı ile hazırlık yapılır.

Olasılığı yüksek ama etkisi düşük tehditler genellikle ucuz önlemlerle kapatılır; örneğin giriş doğrulama ya da hız sınırlama gibi standart kontroller. Hem olasılığı hem etkisi düşük tehditler kayda alınır, kabul edilir ve gözden geçirme takvimine konur.

Kabul kararı bilinçli ve belgeli olmalıdır. Kimin, hangi gerekçeyle, hangi tarihe kadar riski kabul ettiği yazılmazsa, bir sonraki sürümde aynı tehdit yeniden keşfedilir.

Küçük bir örnek: kullanıcı profili güncelleme

Kurgusal bir web uygulamasında kullanıcı, profil bilgilerini güncelleyen bir istek gönderiyor. Veri akışı kullanıcıdan uygulamaya, uygulamadan veritabanına gidiyor. İnternet ile uygulama arasında bir güven sınırı var. STRIDE soruları sorulduğunda şunlar ortaya çıkabilir: başkasının oturum bilgisiyle istek gönderilebilir (sahtecilik), istek gövdesindeki kullanıcı kimliği değiştirilerek başka profil güncellenebilir (değişiklik, yetki), güncelleme kaydı tutulmadığı için kimin değiştirdiği bilinemez (inkâr), hata mesajı veritabanı ayrıntısı sızdırır (ifşa), yoğun istekle servis yavaşlatılabilir (hizmet engelleme) ve sıradan kullanıcı yönetici alanını çağırabilir (yetki yükseltme).

Önlemler bu tehditlerle eşleşir: güçlü oturum doğrulaması, kimliğin oturumdan alınıp istekten alınmaması, değişiklik kaydı, genel hata mesajı, hız sınırlaması ve rol kontrolü. Bu önlemler kodlanmadan önce gereksinime yazıldığında, güvenlik sonradan eklenen bir iş değil tasarımın parçası olur.

Sık yapılan hatalar

İlk hata, tehdit modellemeyi tek seferlik bir belge sanmaktır. Mimari değiştikçe model eskir; büyük özellikler ve mimari değişikliklerde güncellenmelidir.

İkinci hata, yalnızca güvenlik ekibinin yapmasıdır. Sistemi en iyi bilen geliştiriciler ve mimarlar masada olmalı, güvenlik uzmanı soruları zenginleştirmelidir.

Üçüncü hata, tehdit listesi çıkarıp önlemlere bağlamamaktır. Sonuç iş listesine, teste ve kod incelemesine ulaşmıyorsa çalışma faydasız kalır.

Son hata, aracı yöntem sanmaktır. Çizim yazılımı ya da özel araç yardımcı olabilir ama kritik olan sorulan sorulardır; kâğıt üzerinde yapılan sade bir çalışma da değer üretir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Siber Güvenlik Bootcamp Programı'nın Yazılım Geliştirme Güvenliği ile Güvenlik Mimarisi ve Mühendislik bölümleri, güvenli tasarım ilkelerini ve mimari kararların güvenlik etkisini ele alır. Geliştirici, mimar ve güvenlik mühendisleri için tehdit modellemeyi tasarım sürecine yerleştirmek açısından zemin sunar.