Model ancaman yang berguna menjelaskan apa yang Anda lindungi, siapa atau apa yang dapat memengaruhinya, di mana kepercayaan berubah, dan bagaimana Anda akan mengurangi serta menguji risiko terpenting. Mulailah dengan proyek yang sebenarnya, bukan daftar alat yang generik.
Tetapkan cakupan yang cukup kecil untuk dianalisis
Mulailah dengan satu layanan yang berfungsi: portal pelanggan, situs penerbitan, atau aplikasi internal. Catat komponen yang Anda operasikan dan sistem eksternal yang Anda andalkan. Model ancaman harus membuat asumsi terlihat, bukan menyiratkan bahwa setiap kemungkinan serangan telah diatasi. Jaga versi pertama cukup kecil sehingga orang yang menerapkan aplikasi dapat menjelaskannya tanpa konsultan terpisah yang menafsirkan diagram.
Daftarkan hasil dan aset yang berharga. Ini dapat mencakup data pelanggan, akses administrasi, status pembayaran, konten yang diterbitkan, dan kemampuan memulihkan layanan. Ketersediaan dapat menjadi aset bahkan ketika informasinya publik. Tentukan kegagalan mana yang hanya merepotkan dan mana yang akan merugikan orang atau organisasi. Perbedaan itu membantu Anda memprioritaskan kontrol alih-alih memperlakukan setiap peringatan secara setara.
Gambarkan tempat-tempat di mana kepercayaan berubah
Panduan model ancaman OWASP menggunakan aliran data dan batas kepercayaan untuk membuat desain dapat dipahami. Untuk aplikasi hosting kecil, gambarkan browser, proses web, basis data, administrator, tujuan cadangan, dan integrasi eksternal. Tandai informasi yang bergerak di antara mereka. Permintaan yang melintasi dari klien yang tidak tepercaya ke operasi server yang memiliki hak istimewa memerlukan validasi dan otorisasi yang eksplisit.
Jangan berasumsi bahwa berada di dalam mesin yang sama membuat setiap komponen sama-sama tepercaya. Proses unggahan publik tidak boleh memiliki izin yang sama dengan administrasi basis data. Tugas cadangan mungkin memerlukan akses baca tanpa kemampuan mengubah catatan aplikasi langsung. Memisahkan peran tersebut membuat efek komponen yang disusupi lebih mudah dibatasi dan izin yang diperlukan lebih mudah ditinjau.
Pilih skenario kegagalan yang konkret
Gunakan beberapa peristiwa yang masuk akal untuk menguji desain. Penyerang mencuri kata sandi administrator; pengguna meminta catatan pengguna lain; unggahan memenuhi disk; penerapan mengekspos file konfigurasi; salinan pemulihan tidak dapat dipulihkan. Jelaskan kondisi awal, komponen yang terpengaruh, dan konsekuensinya. Skenario yang spesifik lebih mudah diuji daripada instruksi umum untuk meningkatkan keamanan.
Sertakan kesalahan dan penyalahgunaan alur kerja yang sah serta intrusi eksternal. Percobaan ulang dapat membuat dua operasi yang berharga, atau dua permintaan dapat berlomba mengubah objek yang sama. Panduan logika bisnis OWASP menyoroti asumsi proses ini. Periksa siapa yang diizinkan memindahkan alur kerja ke keadaan berikutnya dan apakah mengulang atau mengubah urutan permintaan mengubah hasil secara tak terduga.
| Skenario | Kontrol yang perlu diselidiki | Bukti yang dikumpulkan |
|---|---|---|
| Kredensial administrasi dicuri | Akses terbatas dan faktor kedua jika didukung | Login tidak sah tidak dapat diselesaikan |
| Objek pengguna lain diminta | Otorisasi objek di sisi server | Uji terisolasi mengembalikan hasil ditolak |
| Disk habis karena unggahan | Kontrol ukuran, kuota, dan retensi | Batas diberlakukan sebelum kegagalan layanan |
| Permintaan alur kerja duplikat | Idempotensi dan batas transaksi | Permintaan berulang menghasilkan satu hasil |
Prioritaskan berdasarkan dampak dan jalur yang kredibel
Untuk setiap skenario, catat dampak potensialnya dan kondisi yang diperlukan agar hal itu terjadi. Hindari berpura-pura bahwa skor numerik yang ditebak adalah probabilitas yang tepat. Anda tetap dapat membedakan kata sandi lemah yang terpapar internet dari peristiwa lokal yang sangat bersyarat. Tetapkan pemilik dan langkah berikutnya yang praktis untuk risiko penting agar model menghasilkan pekerjaan yang benar-benar dapat diselesaikan seseorang.
Pertimbangkan siklus hidup informasi serta kompromi aplikasi. Ekspor diagnostik dapat mengungkap data yang tidak perlu selama operasi normal. Bidang akun yang disimpan dapat menimbulkan paparan jauh setelah tujuannya berakhir. Tinjauan privasi karena itu dapat menghapus informasi atau memperpendek retensi, sementara tinjauan keamanan membatasi akses ke apa yang tersisa. Kedua perubahan itu termasuk dalam model ketika melindungi proyek.
Uji kontrol di lingkungan yang diizinkan
Buat lingkungan staging dengan izin yang representatif dan catatan yang dibuat-buat. Uji akses yang ditolak, batas permintaan, percobaan ulang alur kerja, dan pemulihan. Jangan gunakan data pelanggan nyata ketika data sintetis dapat menunjukkan perilakunya. Tujuannya adalah memverifikasi kontrol, bukan menghasilkan lalu lintas serangan yang mengesankan. Tetap dalam sistem yang Anda miliki atau secara eksplisit diizinkan untuk dinilai.
Catat apa yang lulus, apa yang gagal, dan apa yang masih belum diketahui. Hasil pemindai dapat menjadi bukti tetapi tidak menggantikan pengujian aturan bisnis aplikasi. Demikian pula, opsi perlindungan jaringan tidak memverifikasi otorisasi objek atau penanganan file rahasia. Lampirkan hasil yang berguna ke skenario agar pemelihara di masa depan memahami mengapa kontrol tertentu ada.
Jaga model tetap terhubung dengan perubahan
Tinjau bagian yang relevan saat Anda menambahkan integrasi, mengekspos endpoint baru, mengubah hak istimewa, atau memindahkan data ke tujuan lain. Anda tidak perlu menggambar ulang seluruh arsitektur untuk perubahan teks kecil. Pemicunya adalah perubahan asumsi tentang akses, informasi, atau perilaku sistem. Simpan model di samping dokumentasi penerapan dan pemulihan, bukan membiarkannya sebagai keluaran lokakarya satu kali.
SwissOctet menyediakan katalog pilihan infrastruktur, bukan model ancaman aplikasi yang sudah selesai. Pilih konfigurasi dan opsi yang mendukung kontrol Anda, lalu verifikasi penerapan yang Anda bangun. Model kecil yang terpelihara dengan tindakan yang teruji lebih berguna daripada kumpulan besar produk keamanan tanpa penjelasan jelas tentang risiko yang ditanganinya.
Daftar periksa praktis Anda.
- Daftarkan aset dan konsekuensi kegagalan.
- Gambarkan aliran data dan batas kepercayaan.
- Pilih skenario intrusi, kesalahan, dan alur kerja yang spesifik.
- Tetapkan kontrol dan pemilik untuk risiko penting.
- Uji dengan data sintetis di lingkungan yang diizinkan.
- Tinjau model saat asumsi yang relevan berubah.
Detail yang penting.
Apakah saya perlu kerangka kerja formal untuk memulai?+
Tidak. Diagram kecil dan serangkaian skenario yang didokumentasikan dapat berguna. Kerangka kerja membantu memastikan Anda meninjau risiko secara konsisten.
Apakah pemindai kerentanan menggantikan pemodelan ancaman?+
Tidak. Pemindai dapat menemukan kelemahan teknis, sementara model ancaman juga memeriksa asumsi desain, izin, dan alur kerja bisnis.
Seberapa sering saya harus memperbarui model?+
Perbarui bagian yang terpengaruh ketika aliran data, integrasi, hak istimewa, atau fungsionalitas yang terpapar berubah, dan tinjau risiko yang belum terselesaikan secara teratur.
Kunjungi sumbernya.
Referensi ini mendukung konsep teknis dalam panduan ini. Ikuti dokumentasi terkini sebelum mengubah sistem produksi.
- OWASP: Lembar Contekan Pemodelan Ancaman cheatsheetseries.owasp.org
- OWASP: Pemodelan ancaman dalam praktik devguide.owasp.org
- OWASP: Keamanan Logika Bisnis cheatsheetseries.owasp.org
Panduan editorial oleh SwissOctet. Contoh bersifat ilustratif. Spesifikasi layanan, opsi yang tersedia, dan ketentuan kontraktual harus diverifikasi secara terpisah.