Sebuah aplikasi menambahkan fitur ekspor data. Tidak ada server baru, database tidak diganti, dan diagram arsitektur masih memperlihatkan komponen yang sama. Dari sisi pengembangan, perubahan tersebut mungkin hanya dianggap sebagai penambahan tombol dan endpoint sederhana.

Namun, kemampuan sistem telah berubah.

Data yang sebelumnya hanya dapat dilihat satu per satu kini bisa diambil dalam jumlah besar. Apabila pembatasan akses tidak dirancang dengan tepat, satu kesalahan otorisasi dapat berkembang menjadi kebocoran data massal. Arsitektur utamanya memang tetap sama, tetapi jalur serangannya tidak lagi serupa.

Kondisi ini menunjukkan mengapa threat model dapat kedaluwarsa lebih cepat daripada yang diperkirakan. Penyebabnya bukan sekadar usia dokumen, melainkan perubahan perilaku sistem yang tidak lagi tercermin di dalam model tersebut.

Threat Model Tidak Kedaluwarsa karena Dokumennya Sudah Lama

Tanggal pembuatan bukan ukuran utama untuk menentukan apakah sebuah threat model masih relevan.

Threat model yang dibuat dua tahun lalu masih dapat digunakan apabila sistem tidak mengalami perubahan berarti. Sebaliknya, threat model yang baru dibuat beberapa bulan lalu bisa kehilangan relevansi setelah sejumlah fitur ditambahkan.

Sebuah threat model mulai kedaluwarsa ketika asumsi di dalamnya tidak lagi menggambarkan aplikasi yang sedang digunakan. Perubahan dapat terjadi pada jenis data, hak akses, alur proses, hubungan dengan layanan lain, atau tindakan yang dapat dilakukan pengguna.

Persoalannya, perubahan tersebut tidak selalu terlihat pada diagram arsitektur.

Diagram mungkin masih menampilkan pengguna, aplikasi, API, dan database yang sama. Tidak ada komponen besar yang ditambahkan. Akan tetapi, fitur baru dapat mengubah cara setiap komponen berinteraksi, siapa yang dapat mengaksesnya, serta seberapa besar dampak ketika kontrol keamanan gagal.

Threat model tidak seharusnya dinilai dari seberapa rapi dokumennya. Model tersebut perlu dinilai dari kemampuannya menjelaskan bagaimana sistem yang berjalan hari ini dapat disalahgunakan.

Fitur Kecil Tidak Selalu Menghasilkan Risiko Kecil

Besarnya perubahan kode tidak selalu sebanding dengan besarnya risiko keamanan.

Satu parameter baru pada API dapat memperluas data yang dapat diminta. Satu role baru dapat membuka kombinasi hak akses yang sebelumnya tidak tersedia. Satu fitur berbagi dokumen dapat mengubah data internal menjadi informasi yang dapat diakses melalui tautan.

Dari sudut pandang tim produk, perubahan tersebut mungkin terlihat sederhana. Dari sudut pandang penyerang, perubahan yang sama dapat menciptakan jalur menuju aset penting.

Beberapa contoh berikut menunjukkan bagaimana fitur kecil dapat mengubah attack surface aplikasi.

Fitur ekspor mengubah akses individual menjadi pengambilan massal

Sebelum tersedia fitur ekspor, pengguna mungkin hanya dapat melihat satu catatan pada satu waktu. Setelah fitur tersebut ditambahkan, aplikasi menyediakan mekanisme untuk mengambil ratusan atau ribuan catatan sekaligus.

Jika terdapat kelemahan otorisasi, dampaknya ikut berubah. Kerentanan yang sebelumnya hanya mengekspos satu data dapat berkembang menjadi kebocoran dalam skala besar.

Kolom URL membuat server berinteraksi dengan tujuan baru

Sebuah fitur dapat meminta pengguna memasukkan alamat URL untuk mengambil gambar, mengimpor data, atau mengirim notifikasi. Penambahan ini membuat server melakukan koneksi berdasarkan input pengguna.

Jika tujuan koneksi tidak dibatasi, fitur tersebut dapat dimanfaatkan untuk menjangkau layanan internal yang seharusnya tidak dapat diakses dari luar. Tidak ada perubahan besar pada arsitektur, tetapi muncul jalur komunikasi baru yang perlu dianalisis.

Tautan berbagi mengubah batas akses

Dokumen yang awalnya hanya tersedia bagi pengguna terautentikasi dapat dibagikan melalui tautan. Fitur ini mempermudah kolaborasi, tetapi sekaligus mengubah model akses.

Keamanan tidak lagi hanya bergantung pada identitas dan role pengguna. Siapa pun yang memperoleh tautan mungkin dapat membuka dokumen tersebut. Masa berlaku tautan, kemungkinan penerusan, pencabutan akses, serta informasi yang tertanam di dalamnya menjadi bagian dari threat model baru.

Penambahan webhook mengubah hubungan antarsistem

Webhook sering dianggap sebagai integrasi sederhana. Padahal, fitur ini menambah proses autentikasi antar sistem, validasi sumber, pengelolaan secret, mekanisme retry, dan potensi serangan replay.

Apabila aplikasi mengirimkan data ke alamat yang dapat ditentukan pengguna, muncul pula risiko kebocoran informasi atau koneksi menuju tujuan yang tidak tepercaya.

Contoh-contoh tersebut memperlihatkan bahwa attack path dibentuk oleh kemampuan dan hubungan, bukan hanya oleh jumlah komponen dalam diagram.

Perubahan Perilaku Lebih Penting daripada Perubahan Tampilan

Fitur baru sering dibahas berdasarkan tampilan dan fungsi yang diterima pengguna. Tim menilai letak tombol, alur navigasi, validasi formulir, dan keberhasilan proses.

Pendekatan tersebut penting untuk kualitas produk, tetapi belum cukup untuk keamanan aplikasi.

Security review perlu menilai apa yang berubah di balik fungsi tersebut. Setidaknya terdapat empat unsur yang perlu diperhatikan.

Pertama adalah aset. Tim perlu mengetahui apakah fitur membuat data baru dapat dilihat, dipindahkan, disalin, diunduh, atau dihapus.

Kedua adalah aktor. Fitur mungkin memberi akses kepada role, vendor, perangkat, aplikasi, atau service account yang sebelumnya tidak terlibat.

Ketiga adalah alur data. Informasi dapat mulai bergerak menuju sistem lain, perangkat pengguna, penyimpanan eksternal, atau layanan pihak ketiga.

Keempat adalah kewenangan. Pengguna mungkin memperoleh kemampuan baru untuk menyetujui transaksi, mengubah status, menjalankan otomatisasi, atau mengekspor data.

Jika salah satu unsur tersebut berubah, threat model perlu ditinjau kembali. Arsitektur besar tidak harus berubah terlebih dahulu agar risiko baru muncul.

Business Logic Dapat Membuka Jalur Serangan yang Tidak Terlihat pada Diagram

Banyak serangan aplikasi tidak membutuhkan eksploitasi server atau library. Penyerang cukup menggunakan fungsi yang memang tersedia, tetapi menjalankannya dalam urutan, volume, atau konteks yang tidak direncanakan.

Pengguna dapat mengulang penggunaan promosi, melewati tahapan persetujuan, meminta refund lebih dari sekali, atau memanipulasi status transaksi. Pada aplikasi multi-tenant, perubahan filter pencarian dapat membuat data milik pelanggan lain ikut ditampilkan.

Seluruh permintaan tersebut mungkin dianggap valid oleh sistem. Tidak ada karakter berbahaya, malware, atau eksploitasi teknis yang terlihat. Masalahnya terletak pada logika dan asumsi bisnis.

Threat model lama mungkin menyatakan bahwa data pelanggan telah dipisahkan berdasarkan tenant. Namun, fitur pencarian baru dapat menggabungkan data melalui query yang berbeda. Kontrol pada fitur lama masih bekerja, tetapi jalur baru tidak menerapkan pembatasan yang sama.

Hal serupa dapat terjadi saat perusahaan menambahkan proses persetujuan. Sebuah role yang awalnya hanya membaca data kemudian diberi kemampuan menyetujui tindakan tertentu. Tanpa analisis ulang, kombinasi permission dapat menciptakan privilege escalation yang tidak direncanakan.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Masalah tersebut memperlihatkan bahwa perubahan business logic perlu diperlakukan sebagai perubahan keamanan, bukan hanya penyesuaian proses operasional.

Threat Model Lama Dapat Memberikan Keyakinan yang Keliru

Memiliki threat model yang kedaluwarsa terkadang lebih berbahaya daripada menyadari bahwa perusahaan belum mempunyai model sama sekali.

Dokumen yang terlihat lengkap dapat menciptakan kesan bahwa seluruh risiko telah dianalisis. Tim keamanan kemudian menyusun pengujian berdasarkan jalur serangan lama. Developer juga membangun fitur dengan mengandalkan asumsi desain yang tidak lagi sesuai.

Akibatnya, security testing mungkin terus memeriksa autentikasi yang sama, sementara perubahan otorisasi pada fitur baru terlewat. Tim dapat memastikan server telah dikonfigurasi dengan aman, tetapi tidak menguji apakah pengguna mampu mengekspor data dari tenant lain.

Risk register pun dapat menunjukkan risiko yang sudah dikendalikan, meskipun kontrol tersebut tidak diterapkan pada alur baru.

Dalam kondisi ini, threat model berhenti menjadi alat untuk menguji asumsi. Dokumen tersebut hanya menjadi catatan bahwa proses keamanan pernah dilakukan.

NIST melalui Secure Software Development Framework mendorong organisasi untuk memasukkan pemodelan risiko ke dalam proses desain perangkat lunak. Kerangka tersebut juga menekankan pentingnya melacak security requirement, risiko, dan keputusan desain selama pengembangan.

OWASP menyarankan threat modeling dilakukan secara berkelanjutan dan bertahap. Model tingkat tinggi dapat disusun pada tahap awal, kemudian diperbarui ketika detail sistem, teknologi, fitur, serta alur data berkembang.

Sementara itu, Microsoft Security Development Lifecycle menempatkan threat model sebagai artefak yang perlu dipelihara sepanjang siklus hidup produk. Perubahan fungsi dan desain perlu diikuti dengan penilaian ulang terhadap ancaman serta efektivitas mitigasinya.

Ketiga pendekatan tersebut mengarah pada kesimpulan yang sama: threat model bukan dokumen sekali jadi.

Pembaruan Threat Model Tidak Harus Mengulang Semuanya

Keberatan yang sering muncul adalah waktu. Jika setiap perubahan membutuhkan sesi threat modeling penuh, proses development dikhawatirkan menjadi lambat.

Kekhawatiran tersebut dapat dipahami, tetapi threat modeling tidak harus selalu mengulang analisis seluruh aplikasi.

Pendekatan incremental threat modeling memungkinkan tim hanya memeriksa bagian yang berubah. Jika sebuah sprint menambahkan fitur ekspor, pembahasan dapat difokuskan pada data yang diekspor, otorisasi, pembatasan volume, pencatatan aktivitas, dan potensi akses lintas tenant.

Tim tidak perlu memodelkan kembali proses login, pengelolaan profil, atau fitur lain yang tidak terdampak.

Setiap perubahan dapat diawali dengan beberapa pertanyaan:

• Kemampuan baru apa yang diberikan oleh fitur ini?
• Siapa yang dapat menggunakannya?
• Data apa yang dapat dibaca, diubah, atau dikirim?
• Apakah terdapat input baru yang tidak tepercaya?
• Apakah informasi melewati trust boundary baru?
• Apakah aplikasi terhubung dengan layanan eksternal?
• Apakah fungsi dapat digunakan berulang kali atau dalam volume besar?
• Apakah kontrol keamanan lama masih berlaku?
• Bagaimana fitur dapat digunakan di luar tujuan awalnya?
• Pengujian keamanan apa yang perlu ditambahkan?

Jawaban atas pertanyaan tersebut membantu tim menentukan apakah perubahan cukup ditangani melalui checklist atau membutuhkan threat modeling yang lebih mendalam.

Jadwal Tahunan Tidak Sesuai untuk Aplikasi yang Berubah Setiap Minggu

Sebagian perusahaan meninjau threat model hanya ketika melakukan audit tahunan atau proyek besar. Pendekatan ini menciptakan jarak antara kecepatan perubahan aplikasi dan kecepatan evaluasi keamanan.

Aplikasi dapat menerima puluhan pembaruan dalam satu tahun. Selama periode tersebut, role pengguna dapat berubah, API baru ditambahkan, data sensitif mulai diproses, dan integrasi pihak ketiga bertambah.

Ketika review tahunan dilakukan, tim harus menelusuri kembali banyak perubahan sekaligus. Sebagian keputusan mungkin tidak lagi terdokumentasi, sedangkan orang yang mengerjakan fitur sudah berpindah proyek.

Karena itu, perusahaan membutuhkan pemicu pembaruan, bukan hanya jadwal.

Threat model perlu ditinjau ketika terjadi:

• penambahan atau perubahan fitur;
• perubahan business logic;
• penambahan role dan permission;
• perubahan mekanisme autentikasi;
• penambahan jenis data yang diproses;
• integrasi API baru;
• perubahan cara data dibagikan;
• penambahan proses otomatis;
• perubahan teknologi atau dependency;
• perubahan hubungan dengan vendor;
• insiden keamanan;
• temuan vulnerability assessment atau penetration testing.

Tidak semua pemicu membutuhkan analisis dengan tingkat kedalaman yang sama. Namun, setiap pemicu perlu dinilai untuk memastikan asumsi keamanan lama masih berlaku.

Threat Modeling Perlu Masuk ke Proses Development

Threat modeling akan mudah tertinggal apabila hanya menjadi tanggung jawab tim keamanan. Developer dan product owner merupakan pihak yang paling memahami perubahan fungsi, sedangkan tim keamanan membantu menerjemahkan perubahan tersebut menjadi risiko.

Kolaborasi ini dapat dimasukkan ke dalam proses yang sudah berjalan.

Pada tahap refinement, tim dapat mengidentifikasi apakah user story mengubah aset, aktor, alur data, atau kewenangan. Pada tahap design review, perubahan berisiko tinggi dapat dianalisis lebih lanjut.

Security requirement kemudian dimasukkan ke acceptance criteria. Dengan demikian, fitur tidak dianggap selesai hanya karena fungsi utamanya berjalan.

Definition of Done dapat mencakup beberapa pemeriksaan:

• perubahan data flow telah ditinjau;
• threat model diperbarui jika diperlukan;
• skenario penyalahgunaan telah diidentifikasi;
• kontrol autentikasi dan otorisasi telah diuji;
• aktivitas sensitif telah dicatat;
• security test telah ditambahkan;
• risiko yang belum dimitigasi telah didokumentasikan;
• pemilik risiko telah ditentukan.

Pendekatan tersebut membuat threat modeling menjadi bagian dari pengembangan, bukan pekerjaan tambahan menjelang release.

Kajian akademik mengenai security requirements dalam agile development menunjukkan bahwa keamanan masih sulit dimasukkan ke proses yang bergerak cepat. Beberapa pendekatan mengatasi masalah ini dengan memperluas user story menjadi abuse story atau menambahkan artefak keamanan ke dalam sprint.

Namun, artefak tambahan tidak akan berguna jika tidak berhubungan dengan keputusan development. Karena itu, hasil threat modeling perlu diterjemahkan menjadi pekerjaan yang dapat dilaksanakan tim.

Threat Model Harus Mengarahkan Pengujian Keamanan

Threat model yang hanya menghasilkan diagram belum memberikan perlindungan nyata.

Setiap ancaman yang relevan perlu diterjemahkan menjadi security requirement, abuse case, test case, kontrol, atau monitoring. Hubungan ini memastikan risiko yang telah dibahas benar-benar diperiksa pada aplikasi.

Jika fitur ekspor data menimbulkan risiko kebocoran lintas tenant, pengujian harus memastikan pengguna tidak dapat mengganti identifier untuk mengambil data pelanggan lain.

Jika webhook membuka komunikasi dengan layanan eksternal, pengujian perlu memeriksa validasi tujuan, autentikasi, integritas pesan, pencegahan replay, dan perlindungan terhadap koneksi menuju jaringan internal.

Jika role baru dapat menyetujui transaksi, pengujian harus memastikan pengguna tidak dapat menyetujui transaksi miliknya sendiri atau melewati batas nominal.

Threat model membantu menentukan bagian mana yang perlu diuji lebih dalam. NIST juga menempatkan threat modeling sebagai metode untuk menemukan target pengujian yang berpotensi terlewat dan mengidentifikasi masalah keamanan pada tingkat desain.

Tanpa hubungan antara threat model dan security testing, perusahaan hanya mengetahui ancaman secara teoritis tanpa memastikan mitigasinya benar-benar bekerja.

Tanda Threat Model Perlu Segera Ditinjau

Perusahaan dapat menggunakan beberapa pertanyaan untuk menilai apakah threat model masih menggambarkan sistem saat ini:

• Apakah seluruh data flow terbaru sudah tercantum?
• Apakah terdapat fitur baru sejak review terakhir?
• Apakah role dan permission mengalami perubahan?
• Apakah aplikasi memproses jenis data baru?
• Apakah ada integrasi pihak ketiga yang belum dianalisis?
• Apakah kemampuan ekspor atau berbagi data bertambah?
• Apakah terdapat proses yang sekarang berjalan otomatis?
• Apakah sistem membuat koneksi berdasarkan input pengguna?
• Apakah kontrol keamanan lama masih digunakan pada fitur baru?
• Apakah temuan penetration testing telah dimasukkan ke model?
• Apakah skenario penyalahgunaan fitur sudah diperiksa?
• Apakah tim development mengenali threat model sebagai gambaran sistem saat ini?

Jika beberapa jawaban tidak dapat dipastikan, persoalannya bukan sekadar dokumentasi. Ada kemungkinan attack surface baru telah muncul tanpa disertai evaluasi keamanan.

Perubahan Kecil Perlu Dilihat dari Dampaknya, Bukan Ukurannya

Tidak semua pembaruan fitur akan menciptakan risiko besar. Namun, ukuran perubahan tidak dapat digunakan sebagai satu-satunya dasar untuk menentukan kebutuhan security review.

Satu tombol dapat membuka akses terhadap ribuan data. Satu parameter dapat mengubah ruang lingkup query. Satu webhook dapat menghubungkan aplikasi dengan layanan eksternal. Satu permission dapat memberikan kewenangan yang sebelumnya tidak tersedia.

Threat model yang relevan bukan model yang paling kompleks atau paling banyak memiliki diagram. Threat model yang baik mampu menjelaskan kondisi sistem saat ini, menunjukkan jalur serangan yang masuk akal, dan membantu tim menentukan kontrol serta pengujian yang diperlukan.

Perusahaan tidak harus mengulang seluruh proses ketika aplikasi berubah. Namun, setiap perubahan yang memengaruhi aset, aktor, alur data, dan kewenangan harus menjadi alasan untuk memeriksa kembali asumsi keamanan.

Arsitektur mungkin tetap sama. Cara penyerang mencapai aset di dalamnya belum tentu demikian.

Evaluasi Keamanan Aplikasi Bersama Fourtrezz

Threat modeling membantu perusahaan mengidentifikasi risiko sejak tahap desain. Namun, asumsi keamanan tetap perlu diuji terhadap aplikasi yang benar-benar berjalan.

Fourtrezz membantu perusahaan menemukan dan mengevaluasi kerentanan melalui layanan penetration testing dan vulnerability assessment. Pengujian dapat dilakukan pada web application, desktop application, Android, iOS, API, jaringan, dan server.

Melalui penetration testing, perusahaan dapat menguji apakah perubahan fitur telah menciptakan kelemahan autentikasi, kesalahan otorisasi, akses lintas tenant, kebocoran data, atau celah pada business logic.

Fourtrezz juga menyediakan layanan IT Development yang mencakup custom enterprise solution, integrasi sistem dan API, transformasi sistem legacy, serta perancangan arsitektur IT. Pengembangan dilakukan dengan pendekatan secure by design agar kebutuhan keamanan dipertimbangkan sejak tahap perencanaan, development, testing, hingga deployment.

Diskusikan kebutuhan pengujian maupun pengembangan sistem perusahaan Anda bersama Fourtrezz. Pastikan fitur yang terlihat sederhana tidak menciptakan jalur serangan baru yang luput dari perhatian.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]