Belajar Application Security Engineer - Secure SDLC & Threat Modeling
Membangun Secure SDLC dengan security gates di tiap fase dan menguasai threat modeling STRIDE dari diagram hingga daftar mitigasi; episode ini mempraktikkan threat model lengkap terhadap fitur login aplikasi nyata menggunakan OWASP Threat Dragon sehingga kalian bisa langsung menerapkannya pada fitur tim kalian
#Pendahuluan
Setelah di episode 1 kita memahami peran AppSec engineer dan posisinya di sepanjang SDLC, episode ini membahas dua instrumen paling fundamental untuk menjalankan peran itu: Secure SDLC (SSDLC) sebagai kerangka proses, dan threat modeling sebagai teknik analisisnya. Mengapa ini datang lebih dulu sebelum OWASP atau secure coding? Karena threat modeling menentukan apa yang perlu diamankan; tool dan teknik selanjutnya hanya bagaimana.
Kerentanan termahal adalah yang lahir dari desain yang salah — tidak ada patch yang bisa memperbaiki arsitektur tanpa authorization check. Menemukannya saat desain butuh satu rapat; setelah production, biayanya bisa lipat seratus. Di sinilah nilai AppSec engineer paling terasa.
#Secure SDLC: Security Gates di Setiap Fase
SSDLC pada intinya sederhana: masukkan aktivitas security ke setiap fase pengembangan yang sudah ada, bukan sebagai fase terpisah di akhir. Bentuk paling praktisnya adalah security gates — kondisi yang harus lolos sebelum artifact berpindah fase:
| Fase | Aktivitas Security | Gate |
|---|---|---|
| Requirements | Definisi security requirements, klasifikasi data | Data sensitif teridentifikasi |
| Design | Threat modeling, review arsitektur | Mitigasi risiko HIGH didokumentasikan |
| Development | Secure coding standard, pre-commit hooks | Linter & secret scan bersih |
| Build/CI | SAST, SCA, image scan | Tidak ada critical baru |
| Testing | DAST, integration security test | Temuan HIGH diperbaiki |
| Release | Review akhir, sign artifact | Provenance & approval lengkap |
| Operations | Monitoring, patch SLA | Patch kritis ≤ SLA |
Prinsip penting: gate harus otomatis dan proporsional. Gate manual yang lambat akan disiasati; gate yang terlalu ketat akan dimatikan. Mulailah dari yang murah (secret scanning, dependency check) sebelum menambah yang mahal (full DAST per PR).
Note
SSDLC bukan dokumen formalitas. Jika organisasi kalian belum punya, mulailah dari versi minimalis: satu gate otomatis di CI + satu ritual threat modeling per fitur besar. Itu sudah melampaui mayoritas industri.
#Threat Modeling: Berpikir Seperti Penyerang Secara Terstruktur
Threat modeling adalah proses sistematis menjawab empat pertanyaan (kerangka Adam Shostack):
- What are we building? — peta komponen dan aliran data.
- What can go wrong? — daftar ancaman per komponen.
- What are we going to do about it? — mitigasi untuk tiap ancaman.
- Did we do a good job? — verifikasi dan pembelajaran.
Kuncinya kata sistematis. Tanpa metode, "berpikir seperti penyerang" hanya olah pikir acak yang hasilnya bergantung mood. Dengan metode, dua orang berbeda akan menemukan ancaman yang kurang lebih sama.
#Langkah 1: Gambar Data Flow Diagram
Mulailah dengan DFD sederhana: entitas eksternal, proses, penyimpanan data, dan trust boundary — garis tempat data melewati zona kontrol berbeda. Mayoritas kerentanan lahir tepat di trust boundary, karena di sanalah input tak terpercaya masuk ke zona tepercaya.
#Langkah 2: Enumerasi Ancaman dengan STRIDE
STRIDE adalah mnemonik enam kategori ancaman, masing-masing bertentangan dengan satu properti keamanan:
| Huruf | Ancaman | Melanggar | Contoh pada Fitur Login |
|---|---|---|---|
| Spoofing | Pemalsuan identitas | Autentikasi | Penyerang menebak/mencuri password |
| Tampering | Modifikasi data | Integritas | Manipulasi token sesi atau cookie |
| Repudiation | Penyangkalan aksi | Non-repudiation | Login gagal tidak dicatat log |
| Information Disclosure | Kebocoran data | Kerahasiaan | Pesan error membocorkan user valid |
| Denial of Service | Mematikan layanan | Availability | Flood endpoint login tanpa limit |
| Elevation of Privilege | Naik hak | Otorisasi | User biasa jadi admin via parameter |
Cara pakainya: telusuri tiap elemen DFD, tanyakan keenam kategori untuk masing-masing. Proses dengan input eksternal rentan Spoofing/Tampering; datastore rentan Information Disclosure; antrean rentan DoS. Ada heuristik bawaan Microsoft Threat Modeling Tool yang otomatis menyarankan ancaman per tipe elemen.
#Praktik: Threat Model Fitur Login
Mari kita jalankan lengkap pada fitur login standar: form email+password, session cookie, rate limiting via Redis, log audit.
Ancaman yang wajib muncul dalam daftar kalian:
- S: brute force password → mitigasi: rate limit per akun+IP, lockout progresif, MFA.
- T: manipulasi cookie
role=admin→ mitigasi: session state server-side, cookie ditandatangani. - R: insiden tidak bisa direkonstruksi → mitigasi: audit log semua attempt sukses/gagal dengan IP.
- I: error "email tidak terdaftar" vs "password salah" → mitigasi: pesan error generik.
- D: flood
/loginmenghabiskan koneksi DB → mitigasi: rate limit di edge, captcha bertingkat. - E: IDOR setelah login → mitigasi: authorization check per request, uji dengan dua akun.
Setiap baris ancaman harus punya mitigasi konkret dan pemiliknya. Ancaman tanpa mitigasi bukan temuan — itu cuma keluhan.
#Tools Pendukung
# Unduh dari owasp.org/www-project-threat-dragon
# Alternatif web: threatdragon.org (bisa simpan di GitHub repo)Pilihan lain: Microsoft Threat Modeling Tool (Windows, template Azure), OWASP pytm (threat model as code — bagus untuk versioning di Git), atau cukup whiteboard + template markdown jika tim kalian kecil. Format tidak penting; konsistensi yang penting.
Tip
Simpan threat model sebagai file di repository fitur terkait (markdown atau pytm). Ketika arsitektur berubah lewat PR, threat model ikut ter-review — inilah jembatan natural antara threat modeling dan code review yang kita bahas di episode 12.
#Common Pitfalls Threat Modeling
- Terlalu detail sampai mati: DFD dengan 40 kotak tidak akan pernah selesai. Mulai dari level konteks, turun hanya jika perlu.
- Hanya engineer yang hadir: ancaman business logic butuh orang yang paham alur bisnis — libatkan PM/backend lead.
- One-shot document: threat model yang tidak di-update saat fitur berubah menjadi dokumen menyesatkan.
- Melompat ke mitigasi tanpa enumerasi: tim langsung bilang "pakai WAF saja" padahal belum tahu ancaman apa yang dicover dan yang lolos.
Ukuran sukses threat modeling bukan kelengkapannya, tapi keputusan desain yang berubah karenanya. Jika tidak ada satu pun keputusan yang berubah, kemungkinan modelnya terlalu dangkal.
#Penutup
Inti yang harus dibawa pulang:
- SSDLC = aktivitas security tertanam di tiap fase, diejekusi sebagai security gates otomatis dan proporsional.
- Threat modeling menjawab 4 pertanyaan Shostack: bangun apa, apa yang bisa salah, mitigasinya apa, sudah baik?
- STRIDE memberi struktur enumerasi: Spoofing, Tampering, Repudiation, Info Disclosure, DoS, Elevation of Privilege.
- Setiap ancaman wajib punya mitigasi konkret; simpan model di repo agar hidup.
Di episode 3 selanjutnya kita bedah OWASP Top 10 secara detail — sepuluh kategori kerentanan aplikasi paling kritis, akar penyebabnya, dampak nyata, dan mitigasi konkretnya — fondasi kosakata yang akan dipakai di seluruh episode berikutnya. Sampai jumpa di episode 3!