Panduan Tidak Resmi Soatok tentang Threat Model
(soatok.blog)- Threat model tidak berhenti pada menuliskan apa yang dilindungi dan siapa penyerangnya; model ini baru bisa dipakai untuk keputusan desain ketika juga mengungkap hubungan antar aset, asumsi, dan ancaman yang sengaja dikecualikan
- Model yang baik melihat aset bukan sebagai daftar melainkan graf, lalu mempersempit input, output, dan dependensi tiap komponen untuk memeriksa risiko dan premis
- Jika asumsi runtuh, maka risiko yang sudah diterima juga perlu ditinjau ulang, dan serangan Invisible Salamanders menjadi masalah ketika fitur pelaporan penyalahgunaan E2EE berbenturan dengan asumsi AEAD tentang “1 kunci valid per pesan”
- Kasus publickey.directory membagi asumsi, aset, aktor, dan status risiko, tetapi belum sempurna, sementara threat model Matrix v1.18 lebih mirip daftar jenis serangan dan tidak mencakup enkripsi maupun manajemen kunci
- Threat modeling membantu memisahkan batasan pilihan teknis dan risiko nyata dalam hal seperti autentikasi passkey, desain E2EE terdistribusi, dan perdebatan PQC sehingga keputusan desain bisa lebih baik
Pertanyaan yang harus dijawab oleh threat model
- Threat model bisa menjadi proses keamanan siber formal, tetapi juga bisa dilakukan secara informal pada tahap desain dan arsitektur produk atau layanan baru
- Setidaknya harus menjawab pertanyaan berikut
- Apa yang dilindungi
- Siapa atau apa yang mencoba merusak hal yang dilindungi
- Dengan cara apa penyerang bisa menyerang
- Apa yang akan dilakukan untuk mencegah serangan itu
- Dengan empat hal ini saja memang sudah bisa disebut threat model, tetapi dalam praktik detail penting sering mudah terlewat
- Pertanyaan tambahan yang diperlukan adalah sebagai berikut
- Bagaimana aset-aset yang dilindungi saling terhubung
- Asumsi apa yang digunakan
- Ancaman mana yang sengaja tidak ditangani
- Karena tidak mungkin mencakup semua serangan masa depan, ancaman yang dikecualikan harus dinyatakan dengan jelas
- Jika asumsi salah, model menjadi tidak lengkap, dan daftar risiko yang sudah diterima juga harus ditinjau lagi
- Threat model seharusnya bukan snapshot pada satu waktu tertentu, melainkan dokumen hidup yang diperbarui saat diperlukan
Masalah yang muncul ketika asumsi runtuh
- Invisible Salamanders attack dapat merusak fitur tersebut ketika fungsi pelaporan penyalahgunaan diperkenalkan pada beberapa desain pesan E2EE
- Serangan ini terkait dengan asumsi pada skema AEAD seperti AES-GCM dan ChaCha20-Poly1305
- Pada skema tersebut ada asumsi bahwa untuk pesan tertentu hanya ada satu kunci yang valid
- Jika memperkenalkan beberapa kunci valid untuk satu pesan atau membuat confused deputies, maka kita keluar dari jaminan keamanan algoritme
- Menuliskan asumsi secara jelas membantu mengidentifikasi unknown unknowns milik kita sendiri
- Tidak harus sempurna, tetapi harus jelas apa yang dijadikan premis
Prosedur untuk mulai melakukan threat modeling
- Untuk melakukan threat modeling secara profesional, disarankan membaca Threat Modeling Manifesto
- Dalam praktik, mulailah dengan menuliskan 7 butir terlebih dahulu dalam format yang bisa cepat disalin dan digunakan
- Setelah itu, gambarkan komponen sistem yang akan dianalisis di kertas atau alat digital
- Jika suatu widget berkomunikasi langsung, saling bergantung, atau berinteraksi dengan widget lain, tandai hubungan tersebut
- Cara menandai hubungan bebas selama itu paling berguna bagi orang yang mengerjakannya
- Setelah seluruh graf dibungkus dalam kotak, secara bertahap persempit kotaknya untuk fokus pada tiap komponen
- Pada setiap iterasi, catat input dan output komponen
- Jawab 7 pertanyaan sebisa mungkin
- Setelah turun sedalam yang diizinkan tingkat abstraksi, lakukan brainstorming tentang asumsi apa yang digunakan pada lapisan yang tidak digali lebih dalam
- Database mungkin tidak bergantung pada keamanan X25519 dengan cara yang sama seperti load balancer
- Relasi yang tidak semestinya, seperti database menerima RSS feed, perlu dicatat dan bila memungkinkan diputus; itulah tujuannya
Kasus publickey.directory
- Pekerjaan untuk menyediakan transparansi kunci bagi Fediverse dilacak di publickey.directory
- Pekerjaan ini dimulai dari spesifikasi public-key-directory-specification, dan spesifikasi itu mencakup threat model
- Threat model tersebut terdiri dari bagian-bagian berikut
- Asumsi
- Aset
- Aktor dan nama peran, termasuk penyerang dan orang yang ingin dilindungi
- Risiko dan status risiko
- Status risiko dibagi menjadi empat
- Prevented by design: serangan tidak dapat berjalan karena desainnya
- Mitigated: selama asumsi tidak salah, serangan seharusnya tidak berhasil
- Addressable: ada cara mitigasi, tetapi butuh upaya atau perhatian dan operator harus mengetahuinya
- Open: risiko yang tidak bisa atau tidak akan dimitigasi, sehingga serangan tersebut berhasil
- Threat model ini juga belum sempurna
- Hubungan antara aset dan aktor belum terhubung sepenuhnya dalam bentuk graf yang mudah dibaca manusia
- Bagian risiko mungkin masih memiliki blind spot yang belum dipertimbangkan
- Bisa jadi ada asumsi penting bagi keamanan sistem yang belum dicantumkan
Kontras antara Matrix dan Signal
- Security Threat Model di Matrix v1.18 mencantumkan jenis serangan seperti denial-of-service, spoofing, spam, dan spionase
- Dokumen tersebut memiliki masalah berikut
- Lebih dekat ke daftar jenis serangan
- Tidak ada daftar asumsi
- Tidak ada daftar aset maupun hubungan antar aset
- Daftar serangannya tidak lengkap
- Matrix dipromosikan sebagai messenger E2EE, tetapi threat model-nya tidak membahas enkripsi atau manajemen kunci
- Threat model Matrix tidak banyak berubah sejak v1.1, padahal di antaranya sudah ada pengungkapan kerentanan dan dua serangan kriptografi tambahan dari Lotte
- Meski begitu, Matrix setidaknya punya threat model
- Signal menyediakan spesifikasi teknis, tetapi pengguna harus menyimpulkan sendiri threat model-nya
- Threat model yang buruk pun lebih baik daripada tidak ada threat model sama sekali
Cara threat model memperbaiki desain
- Dalam praktik keamanan sering muncul pepatah bahwa pihak bertahan harus selalu benar, sementara penyerang hanya perlu berhasil sekali
- Jika pihak bertahan cukup siap, mereka bisa menentukan medan gerak penyerang
- Defense-in-depth yang nyata mencakup pemahaman threat model secara cukup mendalam untuk mendorong penyerang ke jalan buntu yang dapat diprediksi
-
Mencegah credential stuffing
- Credential stuffing adalah serangan sederhana yang dalam kenyataan terlalu efektif
- Penyebabnya adalah orang sering memakai ulang kata sandi
- Karena pengguna sulit mengingat banyak kata sandi yang unik dan aman, password manager sempat menjadi mitigasi yang layak
- Kini passkey dianggap sebagai pilihan yang lebih baik
- Passkey adalah cara yang lebih ramah pengguna untuk memakai kriptografi asimetris dalam autentikasi
- Dalam skenario terbaik, digunakan hardware security token seperti SoloKeys atau YubiKeys
- Dalam skenario rata-rata, fitur ini disediakan oleh sistem operasi atau password manager
- Untuk menghindari credential stuffing dan serangan sederhana serupa, desain berikut diperlukan
- Aplikasi dirancang untuk mewajibkan passkey
- Pengguna diizinkan mendaftarkan beberapa passkey, atau setidaknya diwajibkan memiliki satu cadangan
- Sediakan jalur break glass agar admin bisa menambahkan passkey baru bagi pengguna yang kehilangan semua kredensial
- Tindakan admin tersebut dicatat dalam log dengan cara yang tidak bisa disensor oleh admin
- Jika memungkinkan, jangan dukung kata sandi untuk autentikasi sama sekali
- Kata sandi untuk derivasi kunci enkripsi tetap dapat diterima dalam konteks terpisah
- Passkey tidak bisa dipakai untuk phishing karena saat registrasi kredensialnya terikat secara kriptografis ke nama domain
- Meski ada biaya onboarding passkey, hal itu bisa lebih banyak mengurangi beban dukungan akibat credential stuffing dan phishing
- Dengan menghapus harapan yang tidak realistis bahwa manusia harus mengingat rahasia berentropi tinggi dan tidak menggunakannya ulang, beberapa kelas serangan dapat dihilangkan sekaligus sambil meningkatkan kegunaan
- Dikutip pernyataan Avi Douglen: “Keamanan yang mengorbankan kegunaan akan mengorbankan keamanan”
E2EE terdistribusi dan threat model
- Dua proposal sedang dibahas untuk E2EE pada pesan langsung
- ActivityPub E2EE specification yang menargetkan software Fediverse, misalnya DM privat di Mastodon
- Proyek seperti Germ Network yang memiliki tujuan serupa untuk ATProto, misalnya di BlueSky
- Kedua proyek pada suatu titik mempertimbangkan penggunaan MLS sebagai protokol manajemen kunci percakapan E2EE
- Dalam sistem terdesentralisasi, MLS memiliki dua batasan penting
- MLS mendefinisikan konsep abstrak bernama Authentication Service
- Keamanan ratcheting tree yang menopang epoch MLS bergantung pada urutan pesan
- Untuk batasan pertama, ActivityPub dapat mengadopsi transparansi kunci, tetapi harus menentukan bagaimana menangani beberapa pesan KeyUpdate yang saling berlomba di banyak server
- Situasi ATProto dan BlueSky lebih rumit
- ATProto tidak memiliki instance seperti Fediverse
- Dalam analisis keamanan, sistem ini hampir harus diperlakukan seperti P2P
- Bisa jadi dibutuhkan protokol kompleks untuk menjamin urutan pesan dalam sistem terdistribusi, misalnya pendekatan seperti algoritme konsensus Raft
- Atau MLS dilewati dan dipilih E2EE pairwise dengan mengorbankan abstraksi grup
- Jika kerahasiaan pesan antar pengguna adalah tujuan keamanan dan hosting ingin didistribusikan, desain ala blockchain pada ATProto menjadi hambatan untuk memakai protokol kesepakatan kunci grup yang efisien dan sudah distandardisasi saat ini
- Threat modeling dapat mengungkap batasan desain seperti ini sejak tahap rancangan awal
Peran threat modeling yang terlihat dalam perdebatan PQC
- Terkait hybrid post-quantum constructions, mailing list IETF TLS working group sedang membahas RFC untuk menetapkan code point ML-KEM non-hybrid
- Premis diskusinya adalah sebagai berikut
- ML-KEM bukan desain NSA
- Pengusul utama adalah Peter Schwabe, yang pernah berkolaborasi dengan Daniel J. Bernstein dan pustaka kriptografi NaCl, dan tinggal di Jerman
- Pengusul lain juga berada di berbagai wilayah Eropa
- Seperti dijelaskan dalam tulisan Sophie Schmieg, teori informasi menyingkirkan kemungkinan backdoor pada ML-KEM
- ML-KEM dipilih melalui upaya standardisasi internasional terbuka NIST selama 10 tahun
- NIST, FIPS, dan NSA mewajibkan ML-KEM dan ML-DSA non-hybrid untuk sistem rahasia
- Draft IETF tersebut menetapkan ML-KEM non-hybrid dengan penanda Recommend=N
- RFC hybrid KEM akan diberi Recommend=Y, dan hybrid KEM lebih disukai daripada non-hybrid KEM
- Sistem yang selalu dikonfigurasi memakai hybrid KEM tidak mengalami penurunan keamanan walaupun RFC ML-KEM diterbitkan
- Google Chrome sudah mendukung ML-KEM non-hybrid, dan hal ini tidak berubah meskipun RFC IETF belum terbit
- Efek praktis RFC ini adalah melonggarkan batasan prosedural bagi organisasi yang harus mengikuti CNSA 2.0, FIPS 140-3, atau aturan serupa, dan membutuhkan nomor RFC IETF yang stabil alih-alih Internet Draft
- Masalah ini mungkin terutama umum di sebagian lini bisnis yang menjual ke pelanggan pemerintah
-
Perbedaan antara Hybrid PQ+ECDH dan Pure PQ
- Risiko yang dihadapi pada KEM bukan “memecahkan kripto setelah Q-Day”, melainkan Harvest Now, Decrypt Later
- Q-Day dipakai sebagai singkatan untuk waktu ketika penyerang memperoleh komputer kuantum yang relevan untuk kriptografi
- Jika risikonya dipecah, hasilnya seperti berikut
- ECDH murni, yaitu tanpa PQ, akan bisa dibobol secara retroaktif saat Q-Day
- PQ murni tidak akan jebol saat Q-Day dengan asumsi algoritme PQ itu sendiri tidak runtuh lebih dulu
- Hybrid PQ+ECDH adalah lindung nilai terhadap runtuhnya algoritme sebelum Q-Day, tetapi setelah Q-Day tidak memberi manfaat dibanding Pure PQ
- Mengadvokasi ECDH + ML-KEM berarti mengakui bahwa dalam jangka panjang ML-KEM adalah algoritme yang aman
- Alasan memilih hybrid diringkas menjadi dua
- Lebih mudah diterima daripada algoritme yang sepenuhnya asing, sehingga mempercepat adopsi PQ
- Dapat menjadi lindung nilai terhadap runtuhnya ML-KEM atau seluruh kriptografi berbasis lattice
- Untuk lindung nilai yang juga tahan terhadap komputer kuantum yang relevan untuk kriptografi, dibutuhkan hybrid PQ+PQ
- Jika yang ditekankan adalah keragaman algoritme, hybrid 3-arah ML-KEM + HQC + ECDH adalah klaim yang lebih jujur
- ML-KEM adalah KEM berbasis lattice dan diyakini tahan terhadap serangan kuantum
- HQC adalah KEM berbasis kode dan diyakini tahan terhadap serangan kuantum
- ECDH adalah pendekatan yang dipakai saat ini, tetapi rentan terhadap serangan kuantum
- Threat modeling dapat dipakai dalam perdebatan seperti ini untuk memisahkan penolakan ideologis dari risiko teknis saat mengambil keputusan
Penutup
- Di internet sudah banyak panduan yang secara formal membahas threat model dan metodologi terkait
- Tujuan di sini adalah memiliki smoke test untuk dengan cepat menyaring kualitas dan efektivitas dokumen threat model
- Threat model yang baik harus mengungkap apa yang dilindungi, siapa penyerangnya, bagaimana serangannya dilakukan, dan apa pertahanannya, serta melampaui itu dengan menunjukkan hubungan aset, asumsi, dan risiko yang diterima
1 komentar
Komentar Lobste.rs
“Tidak ramah” memang alasan yang sah untuk melaporkan komentar, tetapi kalau ingin membuat internet teknis jadi lebih baik, bukankah seharusnya kita berhenti mengonsumsi dan merekomendasikan nada agresif yang terlalu sering dipakai penulis ini di blognya? Bahkan bisa dipertimbangkan untuk melarang domain itu sama sekali
Dan saya memang berpikir bahwa protokol “semuanya adalah grafik” seharusnya diperlakukan sebagai semacam proyek riset. Kesimpulannya pada dasarnya adalah, “waduh, algoritma graf ternyata memang sangat sulit untuk dipikirkan secara masuk akal”