Belajar Technical Product Manager - Security by Design

#Pendahuluan

Setelah di episode 17 kita melepas settlement T+0 lewat rollout berlapis dengan flag, canary, dan criteria rollback yang teruji, episode ini mundur satu langkah ke fase desain — tempat masalah keamanan paling murah untuk dicegah. Topiknya: security by design, atau memikirkan penyerang dengan disiplin yang sama seperti memikirkan user.

Mengapa ini ranah TPM, bukan hanya tim security? Karena threat model tanpa konteks produk menghasilkan kontrol generik yang salah sasaran. Hanya pemilik produk yang tahu aset mana paling bernilai bagi penyerang, aliran uang bagaimana bisa dialihkan, dan abuser mana yang sudah pernah menyerang. TPM adalah penerjemah antara niat bisnis dan permukaan serangan.

#Shift-Left: Ekonomi Menemukan Bug Terlambat

Aturan ekonominya sederhana dan brutal: kerentanan yang ditemukan saat desain diganti dengan revisi dokumen; yang ditemukan saat development diganti refactor seminggu; yang ditemukan pasca-rilis diganti insiden, postmortem, dan potensi headline berita. Keamanan yang diminta di akhir selalu bentrok dengan deadline — keamanan yang dirancang di awal hanya butuh pertanyaan yang benar di rapat yang sudah ada.

Itulah kenapa security by design bukan menambah proses baru, melainkan menyuntikkan pertanyaan baru ke proses yang sudah kalian jalankan: discovery, design review, dan PRD.

#Threat Modeling dengan STRIDE

STRIDE adalah checklist kategori ancaman. Terapkan pada fitur payout massal NusaPay:

Huruf	Ancaman	Contoh konkret payout	Kontrol tipikal
S — Spoofing	Identitas palsu	API key merchant bocor dipakai kirim payout	Rotasi key, IP allowlist opsional
T — Tampering	Data dimodifikasi	Nominal payout diubah di tengah jalan	Signature request, TLS
R — Repudiation	Bisa menyangkal aksi	Merchant klaim tidak pernah minta payout Rp 500 jt	Audit log immutable + approval
I — Information disclosure	Data bocor	Rekening tujuan terlihat via response IDOR	Authorization per object ID
D — Denial of service	Layanan lumpuh	Spam create-payout menguras worker	Rate limit, queue isolasi
E — Elevation of privilege	Naik otoritas	Staff merchant jadi finance-admin	RBAC ketat, MFA

Cara menjalankannya sebagai TPM: gambar alur fitur (request masuk dari mana, data apa yang lewat, siapa boleh apa), lalu lewati tiap huruf sambil bertanya "bagaimana jika...". Satu sesi 45 menit dengan eng lead + security champion cukup untuk fitur ukuran payout massal. Dokumen hasilnya pendek: tabel di atas plus keputusan kontrol per baris.

Perhatikan kolom contoh: dua ancaman paling mahal bagi NusaPay adalah repudiation (uang bergerak tanpa jejak sah) dan information disclosure via IDOR — prioritas kontrol berbeda antar produk inilah yang membuat threat model pekerjaan produk, bukan template IT.

#Peta Alur Sebelum STRIDE

STRIDE hanya sebaik peta yang dianalisisnya. Sebelum mengisi tabel, gambar empat hal dalam 15 menit:

Entri points: dari mana request masuk (API publik, dashboard, webhook, file batch)?
Aset: data/aksi bernilai apa yang lewat di sini (dana, token kartu, PII, kredensial)?
Trust boundaries: di mana tingkat kepercayaan berubah (internet ke gateway, service ke ledger, admin ke produksi)?
Aktor dan wewenang: siapa boleh melakukan apa, termasuk aktor internal.

Sebagian besar temuan threat modeling lahir dari langkah ini saja — garis trust boundary yang tidak terpikir adalah celah favorit penyerang, jauh sebelum huruf-huruf STRIDE dipakai.

#Abuse Cases: Saudara Gelap User Story

User story mendeskripsikan orang baik bekerja; abuse case mendeskripsikan penyerang bekerja. Formatnya mirip sehingga mudah masuk backlog:

Contoh abuse case fitur payout

Sebagai penyerang yang mencuri session staff merchant,
saya ingin mengubah rekening tujuan payout yang pending,
sehingga dana merchant mengalir ke rekening saya.
 
Deteksi   : perubahan rekening pada payout > Rp 10 jt wajib
            re-approval finance-admin (bukan editor yang sama).
Mitigasi  : notifikasi ke email owner + cooling period 30 menit.
Metrik    : jumlah re-approval anomali dipantau mingguan.

Kebiasaan praktis: untuk setiap epik sensitif, tulis minimal satu abuse case dan masukkan sebagai story tersendiri dengan acceptance criteria — bukan catatan kaki yang hilang saat refactoring. Tim QA juga langsung punya bahan test negatif.

#Klasifikasi Data

Keputusan kontrol selalu turunan dari nilai data. Empat tingkat yang kita pakai di NusaPay:

Klasifikasi data NusaPay

Public      : harga, docs, status page        -> bebas cache CDN
Internal    : metrik agregat, dashboard       -> auth internal
Confidential: data merchant PII, transaksi    -> enkripsi at rest,
              akses least privilege
Restricted  : full PAN (via vault), kredensial -> restricted zone,
              tidak pernah di-log, akses berapproval

Nilai praktisnya bagi produk: klasifikasi menentukan apa yang boleh muncul di mana. Notifikasi chat merchant menampilkan nominal? Itu Confidential yang dibawa ke kanal eksternal — masking wajib (ingat requirement C3 di episode 14). Fitur export CSV ledger? Restricted tidak boleh ikut. Tanpa klasifikasi tertulis, diskusi ini berlarut berdasarkan selera.

Important

Aturan log yang tak pernah boleh dilanggar: data Restricted tidak pernah masuk log aplikasi. Log tersebar ke banyak sistem dan retensinya panjang — satu debug statement ceroboh bisa mengubah lingkup audit kalian seluruhnya.

#Security Review yang Tidak Membunuh Velocity

Proses review yang gagal punya pola sama: semua fitur direview mendalam di akhir, antrean menumpuk, tim mulai menghindari review. Desain yang sehat berjenjang:

Tiering fitur: fitur menyentuh Restricted/money-movement → review penuh; read-only public → self-check checklist. Antrean review hanya berisi yang berisiko.
Review di design phase, bukan pre-release: temuan masih murah diubah.
Checklist PRD: bagian security selalu ada — aset yang dilindungi, klasifikasi data, abuse case, kontrol STRIDE terpilih, dan logging keamanan.
Security champion: satu engineer per squad terlatih menangani temuan level satu; tim security fokus pada level dua ke atas.

Metrik kesehatan proses: waktu tunggu review median, dan persentase fitur tier-sensitif yang lolos review sebelum merge. Kalau keduanya buruk, masalahnya proses — tambah headcount security tidak menyembuhkannya.

#Praktik: Threat Model Fitur Kartu Tersimpan

Lanjut studi kasus episode 14 (vault tokenization untuk recurring payment): susun threat model satu halaman — diagram alur sederhana, tabel STRIDE dengan contoh serangan konkret per baris, satu abuse case lengkap, klasifikasi data yang terlibat, dan rekomendasi tier review. Simpan di 05-quality/threat-model-vault.md.

#Penutup

Inti yang harus dibawa pulang:

Ekonomi shift-left: temuan di desain murah, di rilis mahal — suntikkan pertanyaan keamanan ke proses yang sudah ada.
STRIDE memberi checklist enam ancaman; nilai utamanya muncul saat contohnya spesifik domain kalian.
Abuse case adalah user story sang penyerang: tulis sebagai story dengan acceptance criteria, bukan catatan kaki.
Klasifikasi data empat tingkat menentukan kontrol dan batasan tampilan; Restricted tidak pernah masuk log.
Review berjenjang dengan tiering + security champion menjaga velocity tanpa membuka celah.

Di episode 19 selanjutnya kita bahas tetangga dekat security: Data Privacy Product — privacy sebagai fitur, UU PDP dan GDPR dalam bahasa produk, consent, minimization, retention, DSAR self-service, dan bagaimana trust menjadi keunggulan kompetitif. Sampai jumpa!