Soatok’un Resmî Olmayan Tehdit Modellemesi Rehberi
(soatok.blog)- Tehdit modeli, yalnızca korunacak hedefleri ve saldırganları yazmakla bitmez; varlıklar arasındaki ilişkileri, varsayımları ve bilerek kapsam dışı bırakılan tehditleri de ortaya koyduğunda tasarım kararlarında kullanılabilir
- İyi bir model, varlıkları bir liste olarak değil graf olarak görür; bileşenlerin girdilerini, çıktıları ve bağımlılıklarını daralta daralta riskleri ve önkabulleri doğrular
- Varsayımlar bozulursa, kabul edilmiş riskler de yeniden gözden geçirilmelidir; Invisible Salamanders saldırısı, E2EE kötüye kullanım bildirim özelliği ile AEAD’in “mesaj başına tek geçerli anahtar” varsayımı çakıştığında sorun yaratır
- publickey.directory örneği varsayımları, varlıkları, aktörleri ve risk durumlarını ayırarak inceler, ancak kusursuz değildir; Matrix v1.18 tehdit modeli ise saldırı türleri listesine daha yakındır ve şifreleme ile anahtar yönetimi eksiktir
- Tehdit modelleme, passkey kimlik doğrulaması, dağıtık E2EE tasarımı ve PQC tartışmaları gibi konularda teknik seçimlerin kısıtlarını gerçek risklerden ayırarak daha iyi tasarım kararlarına yardımcı olur
Tehdit modelinin yanıtlaması gereken sorular
- Tehdit modeli resmî bir siber güvenlik süreci olabilir, ancak yeni bir ürün ya da hizmetin tasarım ve mimari aşamasında gayriresmî olarak da yürütülebilir
- En azından şu sorulara yanıt vermelidir
- Neyi koruyoruz?
- Kim ya da ne, korunacak şeyi zarar vermeye çalışıyor?
- Saldırgan hangi yollarla saldırabilir?
- Bu saldırıyı durdurmak için ne yapacağız?
- Bu dört başlıkla da buna tehdit modeli denebilir, ancak pratikte önemli ayrıntıların eksik kalması kolaydır
- Ek olarak gerekli sorular şunlardır
- Korunan varlıklar birbirine nasıl bağlı?
- Hangi varsayımları yapıyoruz?
- Hangi tehditleri bilerek ele almıyoruz?
- Tüm gelecekteki saldırıları kapsamak mümkün olmadığından, kapsam dışı bırakılan tehditler açıkça belirtilmelidir
- Varsayımlar yanlışsa model eksik hale gelir ve daha önce kabul edilmiş risk listesi de yeniden incelenmelidir
- Tehdit modeli, belirli bir anın anlık görüntüsü değil, gerektiğinde güncellenen yaşayan bir belge olmalıdır
Varsayımlar bozulduğunda ortaya çıkan sorunlar
- Invisible Salamanders attack, bazı E2EE mesajlaşma tasarımlarında kötüye kullanım bildirim özelliği eklendiğinde bu özelliği bozabilir
- Bu saldırı, AES-GCM ve ChaCha20-Poly1305 gibi AEAD şemalarının varsayımlarıyla bağlantılıdır
- Bu şemalarda, belirli bir mesaj için tek bir geçerli anahtar olduğu varsayılır
- Tek bir mesaja birden fazla geçerli anahtar getirmek veya confused deputies oluşturmak, algoritmanın güvenlik garantilerinin dışına çıkmak anlamına gelir
- Varsayımları açıkça yazmak, kişinin kendi unknown unknowns alanlarını belirlemesine yardımcı olur
- Kusursuz olmak gerekmez, ancak hangi önkabullere dayanıldığı net olmalıdır
Tehdit modellemeye başlama süreci
- Profesyonel olarak tehdit modelleme yapmak isteyenlere Threat Modeling Manifesto önerilir
- Pratikte önce, hızla kopyalanıp kullanılabilecek bir biçimde 7 maddeyi yazmakla başlanır
- Ardından incelenen sistemin bileşenleri kâğıda ya da dijital bir araca çizilir
- Bir widget başka bir widget ile doğrudan iletişim kuruyor, ona bağımlıysa ya da onunla etkileşiyorsa bu ilişki işaretlenir
- İlişkileri gösterme biçimi, işi yapan kişi için en kullanışlı yöntem neyse o olabilir
- Tüm graf bir kutu içine alınır, ardından kutular giderek daraltılarak her bileşene tek tek odaklanılır
- Her yinelemede bileşenin girdileri ve çıktıları kaydedilir
- Mümkün olduğunca 7 soruya yanıt verilir
- Soyutlama düzeyinin izin verdiği kadar derine inildikten sonra, daha derine inilmemiş katmanlar hakkında hangi varsayımların yapıldığı beyin fırtınasıyla düşünülür
- Veritabanı, yük dengeleyici ile aynı şekilde X25519 güvenliğine bağımlı olmayabilir
- Veritabanına RSS feed girmesi gibi uygunsuz ilişkileri kaydetmek ve mümkünse kesmek amaçlanır
publickey.directory örneği
- Fediverse’e anahtar şeffaflığı sağlama çalışması publickey.directory üzerinden takip ediliyor
- Bu çalışma public-key-directory-specification spesifikasyonuyla başladı ve spesifikasyon bir tehdit modeli içeriyor
- İlgili tehdit modeli şu bölümlerden oluşuyor
- Varsayımlar
- Varlıklar
- Saldırganlar ve korunmak istenen kişiler dahil aktörler ve rol adları
- Riskler ve risk durumları
- Risk durumları dört kategoriye ayrılıyor
- Prevented by design: Saldırı tasarım gereği çalışmaz
- Mitigated: Varsayımlar yanlış değilse saldırı başarılı olmamalıdır
- Addressable: Azaltma yöntemi vardır, ancak çaba veya dikkat gerektirir ve operatörün bunu bilmesi gerekir
- Open: Azaltılamayan ya da azaltılmayacak risktir; ilgili saldırı başarılı olur
- Bu tehdit modeli de kusursuz değil
- Varlıklar ile aktörler arasındaki ilişkiyi insanların kolay okuyabileceği bir graf halinde tam olarak bağlamıyor
- Risk bölümünde hesaba katılmamış kör noktalar olabilir
- Sistem güvenliği için önemli bazı varsayımlar atlanmış olabilir
Matrix ve Signal karşılaştırması
- Matrix v1.18’in Security Threat Model belgesi, hizmet engelleme, spoofing, spam ve gözetleme gibi saldırı türlerini sıralıyor
- Bu belgede şu sorunlar var
- Bir saldırı türleri listesine daha yakın
- Varsayımlar listesi yok
- Varlık listesi ve varlıklar arası ilişkiler yok
- Saldırı listesi eksik
- Matrix bir E2EE mesajlaşma sistemi olarak tanıtılmasına rağmen, tehdit modeli şifreleme veya anahtar yönetimini ele almıyor
- Matrix tehdit modeli v1.1’den bu yana büyük ölçüde değişmedi; bu arada açıklanan zafiyetler ve Lotte’nin iki ek kriptografik saldırısı ortaya çıktı
- Yine de Matrix’in bir tehdit modeli var
- Signal teknik spesifikasyonlar sunuyor, ancak tehdit modelini kullanıcıların kendilerinin çıkarması gerekiyor
- Kötü bir tehdit modeli bile hiç tehdit modeli olmamasından iyidir
Tehdit modelinin tasarımı iyileştirme biçimi
- Güvenlik pratiğinde sık geçen bir deyiş, savunmacının her zaman doğru yapmak zorunda olduğu, saldırganın ise yalnızca bir kez başarılı olmasının yeterli olduğudur
- Savunmacı yeterince hazırlıklıysa, saldırganın hareket edeceği araziyi belirleyebilir
- Gerçek defense-in-depth, tehdit modelini yeterince iyi anlayıp saldırganı öngörülebilir çıkmazlara zorlamayı da içerir
-
Credential stuffing önleme
- Credential stuffing, gerçek dünyada gereğinden fazla etkili olan basit bir saldırıdır
- Bunun nedeni insanların parolaları yeniden kullanmasıdır
- Kullanıcıların çok sayıda benzersiz ve güvenli parolayı hatırlaması zor olduğundan, parola yöneticileri bir süre uygun bir azaltma yöntemi oldu
- Bugün ise passkey daha iyi bir seçenek olarak görülüyor
- passkey, kimlik doğrulamada asimetrik kriptografi kullanımını daha kullanıcı dostu hale getirir
- En iyi durumda SoloKeys ya da YubiKeys gibi donanım güvenlik token’ları kullanılır
- Ortalama durumda bunu işletim sistemi veya parola yöneticisi sağlar
- credential stuffing ve benzeri basit saldırılardan kaçınmak için şu tasarım gerekir
- Uygulama, passkey gerektirecek şekilde tasarlanır
- Kullanıcının birden fazla passkey kaydetmesine izin verilir ya da en azından bir yedek zorunlu tutulur
- Tüm kimlik bilgilerini kaybeden kullanıcılar için yöneticinin yeni bir passkey ekleyebileceği bir break glass yolu sağlanır
- Bu yönetim işlemi, yöneticinin sansürleyemeyeceği şekilde loglanır
- Mümkünse kimlik doğrulama için parola desteği hiç verilmez
- Şifreleme anahtarı türetimi için kullanılan parolalar ayrı bir bağlamda kabul edilebilir
- passkey’de kayıt sırasında kimlik bilgileri alan adına kriptografik olarak bağlandığı için phishing mümkün değildir
- passkey’e geçişin bir onboarding maliyeti olsa da, credential stuffing ve phishing kaynaklı destek yükünü daha fazla azaltabilir
- İnsanların yüksek entropili sırları akılda tutması ve tekrar kullanmaması gerektiği yönündeki gerçekçi olmayan beklenti kaldırıldığında, birden çok saldırı sınıfı ortadan kalkar ve kullanılabilirlik de iyileşir
- Avi Douglen’in “Kullanılabilirliği feda eden güvenlik, güvenliği de feda eder” sözü alıntılanır
Dağıtık E2EE ve tehdit modeli
- Doğrudan mesajlaşma için E2EE konusunda iki öneri tartışılıyor
- Mastodon özel DM’leri gibi Fediverse yazılımlarını hedefleyen ActivityPub E2EE specification
- ATProto ve örneğin BlueSky için benzer hedef taşıyan Germ Network gibi projeler
- Her iki proje de bir aşamada E2EE konuşma anahtar yönetim protokolü olarak MLS kullanımını değerlendirdi
- Merkezi olmayan sistemlerde MLS’in iki önemli kısıtı var
- MLS, Authentication Service adlı soyut bir kavram tanımlar
- MLS epoch’larını destekleyen ratcheting tree yapısının güvenliğinde mesaj sıralaması önemlidir
- ActivityPub, ilk kısıt için anahtar şeffaflığını benimseyecekse, birden fazla sunucu üzerinde birden çok KeyUpdate mesajı yarıştığında bunların nasıl ele alınacağını tanımlamak zorunda
- ATProto ve BlueSky tarafında durum daha zor
- ATProto’da Fediverse’teki gibi instance yok
- Güvenlik analizinde neredeyse P2P gibi ele alınması gerekir
- Dağıtık sistemde mesaj sıralamasını garanti eden karmaşık bir protokole, örneğin Raft consensus algorithm benzeri bir yaklaşıma ihtiyaç duyulabilir
- Ya da MLS tamamen atlanıp pairwise E2EE seçilerek grup soyutlamasından vazgeçilebilir
- Kullanıcılar arası mesaj gizliliği güvenlik hedefiyse ve barındırmayı dağıtmak istiyorsanız, ATProto’nun blockchain-benzeri tasarımı bugün standartlaşmış verimli grup anahtar uzlaşma protokollerinin kullanımına engel olur
- Tehdit modelleme, bu tür tasarım kısıtlarını henüz ilk çizim aşamasında görünür kılabilir
PQC tartışmalarında tehdit modellemenin rolü
- hybrid post-quantum constructions ile ilgili olarak, IETF TLS çalışma grubu posta listesinde non-hybrid ML-KEM kod noktaları tanımlayan bir RFC taslağı tartışılıyor
- Tartışmanın dayanakları şunlar
- ML-KEM, NSA tasarımı değildir
- Ana başvuru sahibi Peter Schwabe’dir; Daniel J. Bernstein ve NaCl kripto kütüphanesiyle birlikte çalışmış, Almanya’da yaşamaktadır
- Diğer başvuru sahipleri de Avrupa’nın çeşitli bölgelerindendir
- Sophie Schmieg yazısında anlattığı gibi, bilgi kuramı ML-KEM’e arka kapı yerleştirilmesini dışlar
- ML-KEM, NIST’in açık ve 10 yıla yayılan uluslararası standardizasyon çabası sonucunda seçildi
- NIST, FIPS ve NSA gizli sistemlerde non-hybrid ML-KEM ile ML-DSA kullanılmasını şart koşuyor
- İlgili IETF taslağı non-hybrid ML-KEM’i belirtiyor ve Recommend=N olarak işaretliyor
- hybrid KEM RFC’sinin Recommend=Y olarak işaretlenmesi bekleniyor ve hybrid KEM, non-hybrid KEM’e tercih ediliyor
- Her zaman hybrid KEM kullanacak şekilde yapılandırılmış sistemlerde ML-KEM RFC’si çıksa bile güvenlikte bir düşüş olmaz
- Google Chrome hâlihazırda non-hybrid ML-KEM desteği sunuyor ve IETF RFC çıkmasa da bu gerçek değişmeyecek
- Bu RFC’nin fiilî etkisi, CNSA 2.0, FIPS 140-3 veya benzeri kurallara uyması gereken ve Internet Draft yerine kararlı bir IETF RFC numarasına ihtiyaç duyan kuruluşların süreç kısıtlarını gevşetmektir
- Bu tür bir ihtiyaç, özellikle devlete satış yapan bazı iş kollarında yaygın olabilir
-
Hybrid PQ+ECDH ile Pure PQ arasındaki fark
- KEM tarafında karşılaşılan risk, “Q-Day sonrasında şifreyi kırmak” değil, Harvest Now, Decrypt Later senaryosudur
- Q-Day, saldırganın kriptoyla ilgili kuantum bilgisayara sahip olacağı anı ifade eden kısa bir ifadedir
- Riskleri ayırırsak
- Sadece ECDH, yani PQ olmayan sistemler, Q-Day geldiğinde geriye dönük olarak kırılır
- Sadece PQ, PQ algoritmasının önce çökmediği varsayımıyla Q-Day’de kırılmaz
- Hybrid PQ+ECDH, Q-Day öncesi algoritma çöküşüne karşı bir hedge’dir, ancak Q-Day sonrasında Pure PQ’ye kıyasla ek fayda sağlamaz
- ECDH + ML-KEM savunmak, uzun vadede ML-KEM’in güvenli bir algoritma olduğunu kabul etmek anlamına gelir
- hybrid tercih etmek için iki neden öne sürülür
- Tamamen yabancı bir algoritmadan daha kolay benimsenir ve PQ geçişini hızlandırır
- ML-KEM’in veya genel olarak kafes tabanlı kriptografinin algoritmik çöküşüne karşı koruma sağlayabilir
- Kriptoyla ilgili kuantum bilgisayarlara karşı da dayanıklı bir hedge isteniyorsa, PQ+PQ hybrid gerekir
- Algoritma çeşitliliği önemseniyorsa, ML-KEM + HQC + ECDH içeren 3 yönlü hybrid daha dürüst bir iddia olur
- ML-KEM, kuantum saldırılarına dayanıklı kabul edilen kafes tabanlı bir KEM’dir
- HQC, kuantum saldırılarına dayanıklı kabul edilen kod tabanlı bir KEM’dir
- ECDH bugün kullanılan yöntemdir, ancak kuantum saldırılarına karşı zayıftır
- Tehdit modelleme, bu tür tartışmalarda ideolojik itirazları teknik risklerden ayırarak değerlendirme yapmaya yardımcı olabilir
Sonuç
- İnternette tehdit modelleri ve ilgili yöntemler hakkında resmî rehberler bolca bulunuyor
- Buradaki amaç, bir tehdit modeli belgesinin kalitesini ve etkisini hızla ayırt etmeye yarayacak bir smoke test oluşturmaktır
- İyi bir tehdit modeli; korunan şeyi, saldırganı, saldırı yöntemlerini ve savunmaları aşarak varlık ilişkilerini, varsayımları ve kabul edilmiş riskleri de görünür kılmalıdır
1 yorum
Lobste.rs görüşleri
“Kaba davranış” yorum şikâyeti için geçerli bir gerekçe sayılıyorsa, teknik interneti daha iyi hale getirmek için bu yazarın blogunda çok sık kullandığı saldırgan tonu artık tüketmemeli ve tavsiye etmeyi de bırakmamalıyız diye düşünüyorum. Hatta ilgili alan adını tamamen yasaklamayı bile değerlendirebiliriz
Ayrıca “her şey grafiktir” diyen protokolün gerçekten bir araştırma projesi gibi ele alınması gerektiğini düşünüyorum. Sonuçta varılan nokta, “vay canına, grafik algoritmaları üzerinde gerçekten akıl yürütmek çok zor” oldu