Threat Modeling dengan STRIDE: Dari Diagram ke Skenario Red Team

Kita sudah menemukan handler reports:export. Sekarang muncul pertanyaan yang lebih sulit: apakah keberadaannya berbahaya, siapa yang dapat memanggilnya, dan kontrol apa yang harus menahan penyalahgunaannya?

Threat modeling membantu menjawabnya dengan melihat sistem, data, aktor, serta asumsi yang menghubungkan mereka. STRIDE memberi enam sudut pandang untuk menemukan kemungkinan kegagalan. Hasil yang dicari adalah pertanyaan yang bisa ditindaklanjuti, lengkap dengan pemilik dan cara memeriksanya.

Ini bagian kedua dari seri:

Tree-sitter dan pembacaan struktur kode.
Threat modeling dengan STRIDE.
REA, reverse engineering, dan pengujian red team.

Contohnya tetap Laporan, aplikasi Electron untuk mengekspor laporan dari SaaS dengan banyak tenant. Semua ancaman di bawah adalah hipotesis pada arsitektur fiktif, bukan klaim adanya kerentanan pada produk tertentu.

Empat pertanyaan sebelum memilih tool

OWASP Threat Modeling Cheat Sheet menjelaskan empat pertanyaan dasar yang dapat diterjemahkan sebagai:

Sistem apa yang sedang kita bangun atau periksa?
Apa yang bisa gagal atau disalahgunakan?
Apa yang akan kita lakukan terhadap kemungkinan itu?
Bagaimana kita menilai apakah penanganannya sudah memadai?

STRIDE terutama membantu pertanyaan kedua. Diagram arsitektur membantu pertanyaan pertama; keputusan mitigasi dan pengujian menutup dua pertanyaan berikutnya. Karena itu, tabel STRIDE yang panjang belum tentu berarti threat modeling sudah selesai.

Bedakan aset, ancaman, kerentanan, dan risiko

Aset adalah sesuatu yang bernilai, seperti kerahasiaan laporan atau ketersediaan layanan. Ancaman adalah kemungkinan kejadian yang merugikan aset itu. Kerentanan adalah kelemahan yang memungkinkan ancaman terjadi. Risiko mempertimbangkan kemungkinan kejadian dan dampaknya dalam konteks organisasi.

Pada contoh kita, “laporan tenant B” adalah aset. “Akun tenant A membaca laporan tenant B” adalah ancaman. “Query backend tidak membatasi tenant” adalah kandidat kerentanan yang masih perlu dibuktikan. Kerugian pelanggan, luas data yang terbuka, dan kemudahan penyalahgunaan memengaruhi risikonya.

Mulai dari aset dan aturan yang harus selalu benar

Untuk fitur ekspor, kita dapat menyepakati aturan berikut:

Aset atau kemampuan	Aturan keamanan
Isi laporan	Hanya identitas yang memiliki akses ke tenant dan laporan terkait yang boleh membacanya.
Identitas pengguna	Actor ditetapkan dari sesi atau token yang diverifikasi layanan.
Pekerjaan ekspor	Job tetap terikat pada actor, tenant, dan objek yang telah diotorisasi.
File lokal	Penulisan mengikuti izin sistem dan pilihan lokasi yang disetujui pengguna.
Audit trail	Operasi dapat ditelusuri ke actor, objek, waktu, keputusan, dan hasilnya.
Kapasitas layanan	Satu pengguna atau tenant tidak bebas menghabiskan seluruh kapasitas ekspor.

Aturan ini lebih mudah diuji daripada pernyataan “fitur ekspor harus aman”. Ia juga memperjelas bahwa autentikasi pengguna saja belum menjawab semua pertanyaan otorisasi.

Catat asumsi secara terpisah: misalnya akun uji sudah login sebagai viewer, pengguna dapat mengendalikan request dari client miliknya, dan worker memakai identitas layanan sendiri. Asumsi adalah bagian yang perlu divalidasi, bukan fakta yang muncul hanya karena kita menggambarnya.

Gambar aliran data dan batas kepercayaan

Data flow diagram, atau DFD, membantu menampilkan proses, penyimpanan, entitas luar, dan data yang bergerak di antaranya. Berikut sketsa alur fitur ekspor; respons disederhanakan agar titik pemeriksaannya mudah dibaca:

Pengguna
   |
Renderer + preload
   | payload IPC
   | -------- TB1: renderer ke main process --------
Main process
   | request HTTPS + token pengguna
   | -------- TB2: client ke layanan --------
API ekspor
   | job dengan konteks otorisasi
   | -------- TB3: API ke pemroses asinkron --------
Queue -> Worker -> Database / Object storage
            |
            +-> hasil ekspor -> API -> Main -> file lokal

API dan Worker -> layanan audit

Trust boundary adalah batas tempat tingkat kepercayaan, identitas, atau kewenangan berubah. Ia tidak harus sama dengan batas jaringan. Renderer dan main process berada di komputer yang sama, tetapi memiliki kemampuan yang berbeda. API dan worker berada di infrastruktur organisasi yang sama, tetapi tidak boleh sembarang saling mempercayai payload.

Preload digabung dengan renderer pada sketsa untuk meringkas alur pesan. Keduanya tetap perlu diperiksa sebagai konteks berbeda: ketika contextIsolation aktif, API yang diekspos preload menjadi penghubung ke dunia renderer. Detail batas ini perlu ditambahkan pada diagram yang lebih rinci saat meninjau bridge tersebut.

Tenant A dan B juga dipisahkan oleh batas kepercayaan logis meskipun memakai database yang sama. Keduanya tidak perlu digambar sebagai dua server agar isolasi datanya menjadi persyaratan keamanan.

Untuk setiap panah, tanyakan: siapa pengirimnya, bagaimana identitasnya dibuktikan, data apa yang boleh ia pilih, dan komponen mana yang memutuskan izin? Dari sini STRIDE mulai berguna.

Enam kategori STRIDE

Microsoft mendokumentasikan STRIDE sebagai kategori untuk merumuskan ancaman. Berikut makna ringkas dan properti keamanan yang terkait:

Kategori	Kemungkinan kegagalan	Properti terkait
S — Spoofing	Pihak mengaku sebagai identitas lain.	Autentikasi
T — Tampering	Data atau operasi diubah tanpa kewenangan.	Integritas
R — Repudiation	Tindakan disangkal karena bukti tidak memadai.	Akuntabilitas
I — Information Disclosure	Informasi terbuka ke pihak yang tidak berhak.	Kerahasiaan
D — Denial of Service	Layanan atau sumber daya tidak tersedia bagi pihak yang berhak.	Ketersediaan
E — Elevation of Privilege	Pihak memperoleh kewenangan di atas yang diberikan.	Otorisasi

Satu skenario dapat masuk beberapa kategori. STRIDE bukan skor severity, urutan serangan, atau kewajiban menemukan tepat enam celah pada setiap komponen. Gunakan kategori untuk memancing pertanyaan, lalu ikuti alur data dan konsekuensinya.

Spoofing: siapa yang dipercaya sebagai actor?

Bayangkan payload IPC membawa userId, lalu main process meneruskannya ke API. Pertanyaan pentingnya: apakah layanan menganggap nilai itu sebagai identitas yang sah, atau menetapkan actor dari token yang sudah diverifikasi?

Hipotesis ancamannya: pengguna A dapat mengirim identitas B dan operasi dijalankan atau dicatat sebagai B. Pengujiannya memakai dua akun uji dan memeriksa identitas yang benar-benar dipakai untuk keputusan serta audit.

Mitigasi yang sesuai adalah menetapkan identitas dari mekanisme autentikasi yang dipercaya. Field client boleh menyatakan objek yang diminta, tetapi tidak boleh menjadi bukti identitasnya sendiri. Di TB1, pemeriksaan pengirim IPC juga perlu dinilai sesuai desain aplikasi.

Tampering: data apa yang berubah setelah disetujui?

API mungkin sudah memeriksa izin saat membuat job, tetapi worker kemudian mengambil tenantId atau reportId dari payload lain yang dapat diganti. Keputusan awal dan pekerjaan yang dijalankan akhirnya menunjuk objek berbeda.

Di sini, ancamannya adalah perubahan konteks job tanpa kewenangan. Kita perlu memeriksa siapa yang boleh membuat atau mengubah pesan queue, field mana yang dianggap otoritatif, dan bagaimana worker mengikat pekerjaan ke keputusan akses yang sah.

Perbaikan dapat berupa izin queue yang lebih sempit, referensi job yang diverifikasi ke penyimpanan tepercaya, dan validasi konteks di worker. Menandatangani pesan saja tidak membuktikan bahwa keputusan akses awalnya benar; integritas pesan dan otorisasi operasi adalah dua hal yang perlu dipenuhi.

Repudiation: bisakah rangkaian tindakan direkonstruksi?

Misalnya log hanya berisi export success. Ketika ada laporan kebocoran, tim tidak tahu siapa pemintanya, tenant mana yang dipakai, atau job mana yang menghasilkan file tersebut.

Untuk contoh ini, audit event perlu menghubungkan actor terautentikasi, tenant, objek, request ID, job ID, keputusan akses, waktu, dan hasil. Catat juga penolakan yang relevan. Lindungi akses serta integritas log, dan jangan memasukkan token atau isi laporan sensitif ke dalamnya. Lihat OWASP Logging Cheat Sheet untuk pertimbangan desain logging.

Log membantu investigasi, tetapi satu baris log tidak otomatis menjadi bukti yang tidak bisa dipalsukan. Kredibilitasnya bergantung pada sumber, kontrol akses, integritas, dan konteks pengumpulan.

Information Disclosure: laporan siapa yang dikembalikan?

Pengguna dapat memiliki token valid dan tetap tidak berhak membaca objek tertentu. Jika API mencari laporan hanya berdasarkan reportId, akses lintas tenant mungkin terjadi ketika kontrol kepemilikan tidak memadai.

Pertanyaan yang perlu dijawab: apakah lookup objek dibatasi pada konteks tenant yang diizinkan, apakah worker mempertahankan pembatasan itu, dan apakah pengambilan hasil ekspor memeriksa izin kembali sesuai kebijakan?

Gunakan laporan sintetis tenant B dengan marker unik untuk menguji akses dari akun tenant A. Bukti berupa marker di hasil lebih kuat daripada hanya status HTTP. Respons 200 bisa berisi pesan error; respons 403 juga belum menjamin job sensitif tidak terlanjur berjalan di belakangnya.

OWASP Multi-Tenant Security membahas isolasi tenant pada data, pekerjaan asinkron, penyimpanan, dan konteks akses. Pembatasan harus bertahan di seluruh jalur ekspor.

Denial of Service: siapa yang membayar pekerjaan mahal?

Satu request ekspor bisa memicu query besar, render dokumen, dan penulisan objek. Membatasi jumlah request per detik belum tentu membatasi biaya komputasi jika satu request sangat mahal.

Untuk contoh kita, pertimbangkan batas rentang tanggal, jumlah baris, ukuran hasil, durasi kerja, jumlah job bersamaan, serta kuota per tenant. Periksa juga retry: pekerjaan yang gagal tidak seharusnya terus mengulang tanpa batas. Prinsip pembatasan sumber daya dijelaskan dalam OWASP DoS Cheat Sheet.

Validasinya dapat berupa pengujian batas di staging dengan jumlah job yang disepakati. Tidak perlu membuat layanan sungguhan tidak tersedia untuk membuktikan bahwa validasi ukuran atau kuota tidak bekerja.

Elevation of Privilege: apakah viewer mendapat kemampuan admin?

Misalnya role viewer boleh mengunduh laporannya sendiri, sedangkan ekspor seluruh organisasi hanya boleh dilakukan admin. Tombol admin disembunyikan di renderer, tetapi handler atau API tetap menerima operasi tersebut.

Jika viewer berhasil menjalankannya, ada pelanggaran kewenangan. Pemeriksaan harus berada pada komponen yang dapat menegakkan keputusan, termasuk API yang tetap menerima request dari client yang telah dimodifikasi. Prinsip deny by default dan pemeriksaan izin pada setiap request dibahas oleh OWASP Authorization Cheat Sheet.

Akses lintas tenant pada bagian sebelumnya adalah contoh kegagalan otorisasi horizontal dengan dampak kerahasiaan. Ia tidak perlu dipaksa menjadi “pengguna mendapat admin” agar dianggap serius. Pilih kategori yang membantu menjelaskan mekanisme dan dampaknya.

Tulis ancaman sebagai skenario yang dapat diperiksa

Format yang berguna adalah: aktor, dengan kemampuan awal tertentu, dapat melakukan tindakan, melalui batas yang gagal dijaga, sehingga terjadi dampak. Tambahkan bukti, asumsi, dan ketidakpastiannya.

Berikut contoh entri lengkap untuk ancaman akses lintas tenant:

ID: TM-01
Status: hipotesis, belum divalidasi
Aktor: pengguna terautentikasi tenant A dengan role viewer
Kemampuan awal: dapat mengubah request dari client miliknya
Aset: kerahasiaan laporan tenant B
Entry point: reports:export -> API ekspor
Boundary: client ke API, dilanjutkan API ke worker
Hipotesis: reportId dipakai tanpa pemeriksaan akses objek yang memadai
Dampak: laporan tenant lain dapat dikembalikan ke peminta
Kategori utama: Information Disclosure
Bukti awal: handler menerima identitas laporan dari renderer
Yang belum diketahui: implementasi otorisasi API dan worker
Pemilik validasi: tim aplikasi bersama tim keamanan
Kriteria: akses lintas tenant ditolak; isi dan hasil job tidak bocor

Perhatikan jarak antara bukti awal dan hipotesisnya. Menerima reportId dari client adalah kebutuhan umum aplikasi. Itu belum membuktikan backend mengabaikan otorisasi. Status ancaman harus berubah setelah bukti bertambah.

Prioritaskan berdasarkan dampak dan kelayakan jalur

Untuk menentukan urutan pemeriksaan, nilai sensitivitas aset, jumlah tenant yang terdampak, kemampuan awal yang dibutuhkan, keterjangkauan entry point, serta kontrol yang sudah ada. Pisahkan perkiraan risiko dari keyakinan terhadap bukti. Hipotesis berdampak besar dapat menjadi prioritas validasi meskipun belum menjadi temuan yang pasti.

Jangan menjumlah huruf STRIDE untuk menentukan severity. Ancaman yang masuk empat kategori tidak otomatis lebih parah daripada satu kebocoran data besar. Demikian juga, keberadaan log mengurangi ketidakpastian investigasi, tetapi tidak menggantikan kontrol akses.

Ubah threat model menjadi rencana pengujian

Untuk TM-01, siapkan tenant A dan B, akun dengan role berbeda, serta laporan sintetis yang mudah dibedakan. Matriks awalnya:

Skenario	Hasil yang diharapkan
Viewer A meminta laporan yang diizinkan di tenant A	Berhasil sesuai kebijakan.
Viewer A meminta laporan tenant B	Ditolak tanpa mengungkap isi atau hasil ekspor.
Viewer A meminta operasi khusus admin	Ditolak meskipun UI dapat dilewati.
Pengguna mengambil hasil setelah aksesnya dicabut	Mengikuti kebijakan pencabutan akses yang telah ditetapkan.

Tentukan juga kebijakan job yang sudah berjalan: izin dapat diperiksa saat pengajuan, saat eksekusi, dan saat pengambilan hasil dengan konsekuensi berbeda. Tim produk dan keamanan perlu memilih perilakunya secara eksplisit, lalu menguji implementasinya.

Pada kegiatan red team, tambahkan sasaran pertahanan: apakah percobaan tercatat, apakah alert relevan muncul, dan apakah tim dapat menghubungkan request ke pengguna serta objek yang benar? Pengujian kontrol aplikasi menjawab apakah akses ditahan; pengujian deteksi dan respons menjawab bagaimana organisasi menangani perilaku tersebut.

Rawat model saat bukti dan sistem berubah

Threat model perlu diperbarui ketika alur ekspor, role, penyimpanan, atau komponen pemroses berubah. Setiap ancaman sebaiknya memiliki keputusan: ditangani, diterima dengan alasan dan pemilik, atau menunggu informasi tertentu. Catat sisa risiko dan tanggal peninjauannya. OWASP juga menempatkan pemeliharaan model sebagai kegiatan sepanjang lifecycle.

Ada satu pertanyaan tersisa: apakah aplikasi yang diterima pengguna benar-benar mengikuti diagram dan source yang baru kita periksa? Bundle, preload, konfigurasi, atau native module dapat berbeda dari asumsi kita.

Bagian ketiga memakai REA untuk memeriksa artefak distribusi, membedakan pengamatan dari inferensi, dan menutup rangkaian ini dengan pengujian red team serta retest yang jelas.