01Sorun ve çözüm
Tehdit modelleme, sistemin nasıl çalıştığını çizip her parçasına "burada ne yanlış gidebilir" sorusunu sistemli biçimde sorma çalışmasıdır. Mimar, geliştiriciler ve ürün sahibiyle birlikte veri akış diyagramını çıkarıyor, güven sınırlarını işaretliyor ve her bileşen için tehditleri listeliyoruz. Çıktı, önceliklendirilmiş ve iş takip aracınıza girilebilecek somut güvenlik gereksinimleridir.
Devamını okuDaha az göster
Çalışma yeni başlayan bir proje için yapılabileceği gibi, yıllardır çalışan bir sistemin büyük bir değişiklikten önce gözden geçirilmesi için de yapılabilir.
02Kimler için
Tehdit modelleme hizmeti ne zaman işe yarar
En yüksek değer, kararların hâlâ değiştirilebildiği anlarda alınır.
- Ödeme, kişisel veri ya da sağlık bilgisi işleyecek yeni bir ürünün mimarisini çizen yazılım ekipleri
- Monolitik bir uygulamayı mikro servislere ya da buluta taşımaya hazırlanan teknik yöneticiler
- Dış bir firmaya yazılım yaptıracak ve güvenlik gereksinimlerini şartnameye yazmak isteyen işletmeler
- Sızma testi bulgularının hep aynı türden çıktığını görüp kök nedeni tasarımda arayan ekipler
- Üçüncü taraf API'ler, iş ortakları ve yapay zekâ servisleriyle yeni veri akışları açan ürün sahipleri
03İhtiyaçlar
Tehdit modellemede ele alınan sorular
Her oturum birkaç temel soru etrafında döner.
- 01
Neyi koruyoruz
Kişisel veriler, ödeme bilgileri, ticari sırlar, yönetici yetkileri ve hizmetin kesintisiz çalışması gibi varlıklar ve bunların işletmeye etkisi belirlenir.
- 02
Veri nereden nereye akıyor
Kullanıcıdan, iş ortağından ya da başka bir servisten gelen her veri yolu çizilir. Verinin bir güven sınırını geçtiği her nokta, doğrulama ve yetki kontrolü gerektiren bir yerdir.
- 03
Kim, nasıl saldırabilir
Dışarıdan bir saldırgan, kötü niyetli bir kullanıcı, yetkisini aşan bir çalışan ya da ele geçirilmiş bir tedarikçi hesabı için ayrı senaryolar düşünülür.
- 04
Mevcut önlem yeterli mi
Her tehdit için var olan kontrol yazılır; kontrol yoksa ya da zayıfsa yeni bir gereksinim tanımlanır, kabul edilen risk ise gerekçesiyle kayda geçer.
04Özellikler
Çalışmanın çıktıları
Model, rafta kalan bir belge değil, ekibin işine doğrudan giren bir araç olarak tasarlanır.
- 01
Veri akış diyagramı
Bileşenler, veri depoları, dış aktörler ve güven sınırları tek bir diyagramda gösterilir; diyagram düzenlenebilir biçimde size teslim edilir.
- 02
Önceliklendirilmiş tehdit listesi
Her tehdit, etkilediği bileşen, olasılık ve etki değerlendirmesi, önerilen önlem ve sorumlu ekip bilgisiyle listelenir.
- 03
Güvenlik gereksinimleri ve kabul kriterleri
Önlemler, geliştiricinin sprint planına koyabileceği kullanıcı hikâyeleri ya da kabul kriterleri biçiminde yazılır.
- 04
Test senaryoları
Yüksek öncelikli tehditler, ileride yapılacak sızma testinin kapsamına ve otomatik testlere girecek senaryolara dönüştürülür.
05Entegrasyonlar
Tehdit modelinin geliştirme sürecindeki yeri
Modelin güncel kalması, ekibin günlük araçlarına bağlanmasına bağlıdır.
- 01
İş takip araçları
Jira, Azure Boards ya da GitHub Issues gibi araçlarda her önlem ayrı bir kayıt olarak açılır ve tehdit kimliğiyle ilişkilendirilir.
- 02
Mimari dokümantasyon
Diyagram, mevcut mimari belgelerinizin yanında tutulur; kod deposunda metin tabanlı olarak saklanması da mümkündür.
- 03
Tasarım inceleme adımı
Yeni bir dış servis, yeni bir veri türü ya da yeni bir kullanıcı rolü eklendiğinde modelin güncellenmesi, tasarım inceleme kontrol listesine eklenir.
- 04
Olay müdahale planı
Kabul edilen riskler ve yüksek etkili tehditler, olay müdahale planındaki senaryolara girdi olur; bir saldırı anında hangi bileşenin önce izole edileceği modelden okunabilir.
06Süreç
Tehdit modelleme hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Tehdit modellemede kullandığımız yöntemler
Tehditleri sınıflandırırken çoğunlukla STRIDE'dan yararlanıyoruz: kimlik sahteciliği, veriyle oynama, inkâr, bilgi ifşası, hizmet engelleme ve yetki yükseltme. Her bileşen bu altı başlıkla tek tek sorgulandığında, deneyime dayalı beyin fırtınasının atladığı noktalar ortaya çıkar. Kişisel verinin yoğun olduğu sistemlerde gizlilik tehditleri için LINDDUN yaklaşımı eklenir; bu, KVKK kapsamındaki veri güvenliği tedbirlerini tasarım aşamasında düşünmeyi kolaylaştırır.
Devamını okuDaha az göster
Diyagramlar için OWASP Threat Dragon ya da Microsoft Threat Modeling Tool gibi araçlar kullanılabilir, ancak araç ikincildir; bir beyaz tahta fotoğrafı da iyi bir başlangıçtır. Önlemler, OWASP ASVS gibi doğrulama standartlarındaki maddelerle eşleştirilir; böylece hangi gereksinimin neden konduğu denetimde de açıklanabilir.
08Çalışma modelleri
Bu hizmette çalışma modelleri
- 01
Proje bazlı
Sabit kapsam, sabit fiyat ve belirli teslim tarihi
Kapsamı belli, teslim tarihi olan işler için.
- Yazılı kapsam ve kabul ölçütleri
- Sabit fiyat ve belirli teslim tarihi
- Teslim ve kabul adımları sözleşmede
- 02
Danışmanlık
Saatlik veya günlük teknik danışmanlık
Karar, denetim veya yön belirleme gereken durumlar için.
- Saatlik veya günlük çalışma
- Yazılı rapor ve öneriler
- Ekibinizle birlikte çalışma
09Sık sorulan sorular
Tehdit modelleme hakkında sık sorulan sorular
Sistemimiz yıllardır çalışıyor; tehdit modelleme için geç mi kaldık?
Hayır. Var olan sistemlerde çalışma mevcut mimarinin belgelenmesiyle başlar ve çoğu zaman ekibin bile farkında olmadığı veri akışlarını ortaya çıkarır. Özellikle büyük bir değişiklik ya da taşıma öncesinde değerlidir.
Tehdit modelleme fiyatları neye göre değişir?
Sistemin bileşen sayısı, dış entegrasyonlar, mevcut dokümantasyonun durumu, kaç oturum gerektiği ve çıktıların iş takip aracına aktarımı ya da sonraki güncellemeler için danışmanlık istenip istenmediği belirleyicidir.
Ekibimizden kimlerin katılması gerekir?
Sistemi en yakından tanıyan bir mimar ya da kıdemli geliştirici, ürünün iş kurallarını bilen bir ürün sahibi ve varsa altyapı sorumlusu. Küçük ve odaklı bir grup, kalabalık bir toplantıdan daha verimli sonuç verir.
Tehdit modelleme sızma testinin yerine geçer mi?
Geçmez; ikisi farklı soruları yanıtlar. Model, tasarımın hangi tehditlere açık olduğunu gösterir; sızma testi ise uygulamanın gerçekte nasıl davrandığını sınar. Modelden çıkan öncelikler, testin kapsamını daha isabetli kılar.
Çevik çalışan bir ekipte model nasıl güncel kalır?
Her sprintte baştan yapılmaz. Mimariyi değiştiren işler, yani yeni bir veri türü, yeni bir dış servis ya da yeni bir rol eklendiğinde ilgili parça kısa bir oturumla güncellenir.
Tehdit modelleme firmasına kod erişimi vermemiz gerekir mi?
Zorunlu değil. Çalışma büyük ölçüde mimari belgeler ve ekiple yapılan görüşmelerle yürür. Belirsiz bir noktayı netleştirmek için ilgili koda kısa bir bakış gerekirse bunu sizin belirlediğiniz erişimle yaparız.
10İlgili hizmetler