Belajar DevSecOps Engineer - Threat Modeling in DevSecOps

#Pendahuluan

Semua tool pada episode 3-13 punya batas yang sama: mereka menganalisis kode atau infrastruktur yang sudah ada. Tidak satu pun bisa menjawab pertanyaan paling mahal dalam security: apakah desainnya benar dari awal? Fitur dengan arsitektur cacat — misal token reset password yang dikirim lewat URL tanpa expiry — akan lolos semua scanner karena tidak ada "vulnerability pattern" di kodenya; desainnya memang begitu.

Threat modeling adalah disiplin menemukan masalah ini saat fase desain, ketika memperbaikinya masih berarti menggeser kotak diagram, bukan menulis ulang sistem. Ini juga skill yang membedakan senior DevSecOps engineer: ia tahu scanner tidak cukup.

#Empat Pertanyaan Dasar

Adam Shostack merangkum threat modeling menjadi empat pertanyaan:

What are we building? — gambar sistemnya (data flow diagram).
What can go wrong? — enumerasi ancaman (STRIDE).
What are we going to do about it? — mitiasi per ancaman.
Did we do a good job? — review & follow-up.

Kerangka ini penting karena threat modeling sering gagal jadi sesi filosofis tanpa output. Dengan empat pertanyaan ini, hasilnya selalu konkret: diagram + daftar ancaman + keputusan mitigasi.

#Data Flow Diagram

Mulai dari gambar sederhana: proses, datastore, external entity, dan aliran data — plus trust boundary (garis tempat tingkat kontrol berubah):

100%

Aturan membacanya: setiap panah yang melintasi trust boundary adalah calon titik serangan; setiap datastore punya pertanyaan authN/authZ/enkripsi sendiri. Diagram ini juga menjadi bahasa bersama antara developer, security, dan architect — diskusi "di mana input user divalidasi?" langsung punya objek visual.

#STRIDE

STRIDE adalah taksonomi enam kategori ancaman — mnemonic dari inisialnya:

Huruf	Ancaman	Contoh Nyata	Mitigasi Tipikal
S	Spoofing	Token API dicuri dipakai penyerang	MFA, mutual TLS, short-lived credential
T	Tampering	Payload order dimodifikasi di transit	Signature/HMAC, integritas transport
R	Repudiation	User menyangkal transaksi	Audit log tamper-proof
I	Information Disclosure	Error message bocorkan stack trace	Minimalkan verbose error, enkripsi at rest
D	Denial of Service	Flood endpoint search mahal	Rate limit, autoscaling, WAF
E	Elevation of Privilege	IDOR jadi admin access	RBAC ketat, authorization check terpusat

Cara pakainya sistematis: telusuri setiap elemen DFD, cocokkan keenam huruf, tulis apa pun yang relevan. Proses → S/T/R/E; Datastore → T/I/R; Aliran lintas boundary → semuanya. Tool seperti OWASP Threat Dragon otomatis menyodorkan checklist STRIDE per elemen diagram.

#Praktik: Threat Model Fitur Nyata

Contoh ringkas untuk fitur "upload avatar":

Threat model: upload avatar (ringkas)

Elemen     : Browser -> API /upload -> S3 bucket avatars
 
S          : Upload atas nama user lain?      -> wajib session check server-side
T          : Content-Type dipalsukan (.exe)   -> validasi magic bytes + re-encode
I          : Bucket publik membocorkan foto   -> private bucket + signed URL TTL
D          : Upload 2GB x 1000 concurrent     -> limit ukuran + presigned POST limit
E          : Path traversal menulis keluar dir-> generate nama file server-side
R          : Sangkalan upload ilegal          -> log audit user+file hash+timestamp

Perhatikan bentuk output idealnya: tabel pendek, tiap baris = ancaman + mitigasi spesifik. Ini bukan dokumen puluhan halaman — threat model yang terpakai adalah yang bisa ditulis dalam satu sesi 30-60 menit.

Tip

Jalankan threat modeling sebagai bagian dari design review PR/dokumen RFC: tambahkan section "Security considerations & threat model" di template design doc. Tim yang sudah terbiasa akan menuliskannya sendiri — dan di situlah budaya security benar-benar shift-left.

#Threat Modeling sebagai Artefak Pipeline

Agar tidak mati sebagai dokumen sekali-baca:

Simpan di repo (docs/threat-model/) bersama kode yang dimodelkan — ikut tereview, ikut versi.
Link ke mitigasi nyata — tiap ancaman merujuk issue/policy/scan yang mengimplementasikan mitigasinya.
Trigger update otomatis — perubahan besar di area sensitif (auth, payment, file handling) menandai threat model stale via CODEOWNERS atau label CI.
Feed ke testing — tiap ancaman jadi test case: SAST rule custom, integration test authorization, chaos/DAST scenario.

Poin 4 adalah jembatan paling kuat antara threat modeling dan DevSecOps automation: daftar ancaman hari ini menjadi daftar gate esok hari.

#Pitfall Umum

Big design up front — threat model raksasa tahunan yang tak pernah diupdate lebih buruk daripada model kecil per-fitur yang hidup.
Tanpa developer di ruangan — sesi security-only menghasilkan ancaman fiktif; siapa yang tahu kode, dia yang harus hadir.
Mitigasi abstrak — "gunakan best practice" bukan mitigasi; tulis mekanisme konkretnya.
Mencatat lalu melupakan — tanpa link ke issue/test/policy, temuan threat model akan menguap.

#Penutup

Inti yang harus dibawa pulang:

Scanner mencari bug di kode; threat modeling mencari kesalahan desain sebelum kode ada.
Empat pertanyaan Shostack menjaga sesi tetap produktif: bangun apa → apa yang salah → mitigasi → evaluasi.
DFD + trust boundary adalah bahasa visualnya; STRIDE adalah checklist enumerasinya.
Simpan threat model di repo, hubungkan ke gate/test nyata — jadikan artefak hidup pipeline.

Di episode 15 selanjutnya kita membahas Security as Code — prinsip yang menyatukan semua episode sebelumnya: policy, detection, konfigurasi security diperlakukan persis seperti software — versioned, direview, ditest, dan dirilis dari satu repo security. Sampai jumpa!