Proses Sederhana untuk Membuat Threat Modeling Relevan bagi Tim Developer

Arreza MP Januari 25, 2026 0 Komentar

baca juga: Laporan Indeks Keamanan Informasi (Indeks KAMI) untuk Instansi Pemerintah Daerah

Proses Sederhana untuk Membuat Threat Modeling Relevan bagi Tim Developer

Pernahkah Anda membangun sebuah rumah? Sebelum meletakkan batu bata pertama, Anda pasti memikirkan banyak hal: "Apakah pintu depan cukup kokoh?", "Bagaimana jika ada pencuri masuk lewat jendela belakang?", atau "Apakah instalasi listriknya aman agar tidak terjadi korsleting?"

Dalam dunia pengembangan perangkat lunak, proses berpikir "apa yang bisa salah dan bagaimana cara mencegahnya" ini disebut dengan Threat Modeling.

Sayangnya, bagi banyak tim developer, threat modeling sering dianggap sebagai monster birokrasi yang membosankan. Ia sering dilihat sebagai tumpukan dokumen tebal yang memperlambat proses rilis fitur. Padahal, jika dilakukan dengan benar, threat modeling adalah alat paling ampuh untuk membangun aplikasi yang aman sejak awal.

Artikel ini akan mengupas bagaimana cara mengubah threat modeling dari "beban administrasi" menjadi "proses sederhana" yang relevan dan disukai oleh tim developer.

Bagian 1: Mengapa Developer Sering "Alergi" terhadap Threat Modeling?

Sebelum kita masuk ke solusinya, kita harus jujur tentang masalahnya. Mengapa banyak developer merasa enggan melakukan threat modeling?

Terlalu Akademis: Banyak metode threat modeling yang menggunakan bahasa keamanan yang sangat teknis dan kaku, sehingga developer merasa itu bukan "pekerjaan" mereka.
Menghambat Kecepatan (Velocity): Dalam budaya Agile, kecepatan adalah segalanya. Jika sebuah sesi keamanan memakan waktu berjam-jam tanpa hasil yang jelas, developer akan menganggapnya sebagai gangguan.
Dilakukan Terlambat: Seringkali, pengecekan keamanan baru dilakukan saat aplikasi sudah hampir selesai. Akibatnya, saat ditemukan celah, tim harus membongkar ulang kode yang sudah jadi—sebuah mimpi buruk bagi setiap programmer.

Mindset Baru: Keamanan sebagai Fitur, Bukan Hambatan

Kunci utamanya adalah mengubah perspektif. Keamanan bukanlah sesuatu yang ditambahkan di akhir, melainkan kualitas dari kode itu sendiri. Threat modeling yang sukses adalah yang terasa seperti bagian dari proses desain, bukan audit kepatuhan.

Bagian 2: Kerangka Kerja 4 Pertanyaan (Sederhana Namun Powerfull)

Adam Shostack, salah satu pakar keamanan terkemuka, menyederhanakan threat modeling menjadi empat pertanyaan dasar yang bisa dijawab oleh siapa saja, bahkan tanpa latar belakang keamanan yang mendalam:

Apa yang sedang kita kerjakan? (Cakupan/Scope)
Apa yang bisa salah? (Identifikasi Ancaman)
Apa yang akan kita lakukan terhadapnya? (Mitigasi)
Apakah kita sudah melakukan pekerjaan dengan baik? (Validasi)

Mari kita bedah bagaimana cara menerapkan empat pertanyaan ini ke dalam alur kerja harian tim developer.

Bagian 3: Langkah Demi Langkah Proses Threat Modeling yang Relevan

Langkah 1: Memvisualisasikan Apa yang Kita Bangun

Anda tidak bisa mengamankan apa yang tidak Anda pahami. Developer sangat terbiasa dengan diagram arsitektur. Gunakanlah itu. Jangan gunakan diagram keamanan yang rumit; mulailah dengan Data Flow Diagram (DFD) sederhana.

Dalam diagram ini, fokuslah pada:

Aktor: Siapa yang menggunakan aplikasi? (User, Admin, Sistem lain).
Proses: Apa yang dilakukan aplikasi? (Login, Proses pembayaran, Update profil).
Data Store: Di mana data disimpan? (Database, Cloud Storage).
Aliran Data: Bagaimana data berpindah dari satu titik ke titik lain?

Tips untuk Developer: Jangan menggambar seluruh sistem sekaligus. Cukup gambar fitur baru yang sedang Anda kerjakan dalam sprint ini.

Langkah 2: Menggunakan Metode STRIDE untuk Identifikasi Ancaman

Setelah melihat diagram, saatnya bertanya: "Apa yang bisa salah?" Agar tidak bingung, gunakan kerangka kerja STRIDE. Ini adalah cara mudah untuk mengelompokkan jenis ancaman:

S - Spoofing (Penyamaran): Bisakah seseorang berpura-pura menjadi orang lain? (Contoh: Menggunakan akun orang lain).
T - Tampering (Pengrusakan): Bisakah seseorang mengubah data secara ilegal? (Contoh: Mengubah harga barang di URL).
R - Repudiation (Penyangkalan): Bisakah seseorang menyangkal bahwa mereka melakukan suatu aksi? (Contoh: "Bukan saya yang menghapus data itu, tidak ada log-nya").
I - Information Disclosure (Kebocoran Informasi): Bisakah data rahasia terlihat oleh orang yang tidak berhak? (Contoh: Password tersimpan dalam teks biasa).
D - Denial of Service (Gangguan Layanan): Bisakah seseorang membuat aplikasi mati? (Contoh: Membanjiri server dengan request palsu).
E - Elevation of Privilege (Peningkatan Hak Akses): Bisakah user biasa melakukan tindakan admin?

Contoh Praktis: Saat membangun fitur "Unggah Foto Profil", developer bisa bertanya: "Bisakah user melakukan Tampering dengan mengunggah file script berbahaya alih-alih foto?"

Langkah 3: Menentukan Mitigasi (Rencana Aksi)

Setelah tahu ancamannya, apa yang harus dilakukan? Tidak semua ancaman harus diperbaiki saat itu juga. Tim developer harus memprioritaskan berdasarkan risiko:

Mitigasi: Memperbaiki kode (misalnya: menambahkan validasi input).
Transfer: Menyerahkan risiko ke pihak lain (misalnya: menggunakan layanan payment gateway pihak ketiga yang sudah tersertifikasi).
Terima: Jika risikonya sangat kecil dan biaya perbaikannya sangat mahal, tim mungkin memutuskan untuk menerima risiko tersebut (dengan persetujuan manajemen).

Langkah 4: Validasi dalam Review Kode

Pertanyaan terakhir: "Apakah kita sudah melakukannya dengan benar?" Ini dilakukan saat Code Review atau Pull Request (PR).

Pastikan rekan setim Anda bertanya: "Ingat ancaman Tampering yang kita diskusikan kemarin? Di bagian mana di kode ini kita sudah menangkalnya?"

Bagian 4: Cara Membuatnya "Relevan" dan "Menyenangkan"

Agar threat modeling tidak terasa seperti tugas sekolah, kita perlu menyuntikkan elemen relevansi ke dalamnya.

1. Masukkan ke dalam "Definition of Ready"

Jangan biarkan sebuah fitur masuk ke tahap pengembangan jika belum melewati sesi threat modeling singkat (15-30 menit). Jadikan ini syarat agar sebuah kartu di papan Trello atau Jira bisa dikerjakan.

2. Gamifikasi dengan "Elevation of Privilege"

Microsoft menciptakan permainan kartu bernama Elevation of Privilege (EoP). Ini adalah cara yang sangat menyenangkan untuk mengajarkan threat modeling. Developer bermain kartu, dan setiap kartu berisi skenario ancaman yang harus mereka hubungkan dengan sistem yang mereka bangun. Tiba-tiba, keamanan bukan lagi tentang dokumen, tapi tentang memenangkan permainan.

3. Gunakan Bahasa Developer, Bukan Bahasa Auditor

Gunakan istilah yang dipahami developer. Alih-alih mengatakan "Kita perlu mengaudit integritas data pada endpoint API ini," katakanlah "Gimana kalau ada orang iseng yang ganti ID user di URL buat ngintip data orang lain?"

Bagian 5: Peralatan (Tools) yang Tidak Membebani

Jangan paksa tim menggunakan software threat modeling yang kompleks di awal. Mulailah dengan alat yang sudah mereka gunakan:

Papan Tulis & Spidol: Cara terbaik untuk kolaborasi real-time.
Excalidraw atau Miro: Untuk tim remote yang ingin menggambar diagram dengan cepat.
Threat Dragon (OWASP): Alat open-source yang sangat ramah developer.
Code-based Threat Modeling: Gunakan alat seperti Pytm atau Threagile di mana developer bisa menulis "ancaman" dalam bentuk kode (YAML/Python), sehingga bisa masuk ke dalam repositori Git.

Kesimpulan: Keamanan adalah Kerjasama Tim

Threat modeling yang efektif bukanlah tentang menemukan setiap kemungkinan ancaman di dunia. Tujuannya adalah membangun kesadaran (awareness). Ketika seorang developer sedang menulis baris kode dan tiba-tiba terpikir, "Wah, kalau saya tidak validasi input ini, mungkin seseorang bisa melakukan SQL Injection," di situlah threat modeling telah berhasil.

Mulailah dari yang kecil. Jangan mencoba untuk sempurna. Lakukan sesi 15 menit pada fitur yang paling krusial. Seiring berjalannya waktu, tim Anda akan melihat bahwa threat modeling bukan hanya tentang keamanan, tapi tentang membangun perangkat lunak yang lebih baik, lebih stabil, dan lebih profesional.

Ingat, lebih baik menemukan "lubang di kapal" saat masih di pelabuhan daripada saat sudah berada di tengah samudra luas.