Part 005 — Threat Modeling for Java Systems

Security yang matang bukan dimulai dari library crypto, firewall, atau checklist scanner. Security yang matang dimulai dari kemampuan menjawab: apa yang kita lindungi, dari siapa, lewat jalur apa, dengan asumsi apa, dan kontrol mana yang benar-benar memutus attack path.

Part ini membangun cara berpikir threat modeling untuk sistem Java modern. Kita tidak akan menjadikannya ritual dokumentasi yang berat. Kita akan menjadikannya alat desain, review, dan debugging risiko.

Threat modeling adalah teknik untuk memahami sistem dari perspektif keamanan, mengidentifikasi ancaman yang relevan, memilih mitigasi, lalu memvalidasi apakah mitigasi tersebut cukup. OWASP Threat Modeling Cheat Sheet merangkum proses ini menjadi dekomposisi aplikasi, identifikasi/ranking ancaman, mitigasi, dan review/validasi. Dalam praktik engineering, empat langkah itu harus diterjemahkan menjadi artifact yang bisa dipakai di design review, pull request review, incident analysis, dan audit.

1. Posisi Part Ini dalam Framework Kaufman

Josh Kaufman menekankan bahwa skill kompleks harus dipecah menjadi subskill kecil, lalu dipraktikkan cukup agar kita bisa self-correct. Threat modeling cocok dengan pendekatan ini karena masalahnya bukan kurang tahu nama ancaman, tetapi tidak punya cara konsisten untuk melihat sistem.

Dalam konteks Java security, subskill threat modeling adalah:

Target part ini: setelah selesai, kamu mampu membuat threat model ringkas untuk service Java produksi dan menggunakannya untuk memandu desain security.

2. Threat Model Bukan Sekadar Dokumen

Threat model yang buruk biasanya berbentuk dokumen panjang berisi tabel ancaman generik:

• SQL injection
• XSS
• Broken authentication
• Insecure deserialization
• Sensitive data exposure

Itu belum threat model. Itu masih daftar kategori.

Threat model yang berguna menjawab pertanyaan konkret:

1. Asset apa yang bernilai?
2. Actor mana yang punya akses langsung/tidak langsung?
3. Boundary mana yang dilintasi data atau command?
4. Asumsi security apa yang harus benar?
5. Bagaimana attacker bisa mengubah asumsi itu menjadi exploit path?
6. Kontrol apa yang memutus path itu?
7. Bagaimana kita tahu kontrol itu masih bekerja di production?

Threat model yang baik tidak harus panjang. Ia harus tajam.

3. Mental Model: Dari Feature ke Attack Path

Software engineer biasanya memodelkan sistem sebagai feature path:

Security engineer memodelkan sistem sebagai attack path:

Perbedaannya penting.

Feature path bertanya: “Bagaimana user berhasil memakai sistem?”

Attack path bertanya: “Bagaimana actor dengan capability tertentu bisa mencapai state yang tidak seharusnya?”

Contoh:

Threat modeling mengubah diskusi dari “apakah endpoint ini sudah dibuat?” menjadi “state buruk apa yang tidak boleh terjadi?”

4. Artifact Minimum Threat Model

Untuk sistem Java produksi, threat model minimum sebaiknya punya 7 bagian:

1. Scope
2. Assets
3. Actors
4. Data flows
5. Trust boundaries
6. Threats and mitigations
7. Validation plan

Template ringkas:

## Threat Model: <System / Feature>

### Scope
- In scope:
- Out of scope:
- Assumptions:

### Assets
| Asset | Sensitivity | Integrity requirement | Availability requirement |
|---|---:|---:|---:|

### Actors
| Actor | Trust level | Capability | Notes |
|---|---:|---|---|

### Data Flow
<Mermaid diagram>

### Trust Boundaries
| Boundary | Crossing | Risk |
|---|---|---|

### Threats
| ID | Threat | Attack path | Impact | Mitigation | Validation |
|---|---|---|---|---|---|

### Open Risks
| Risk | Owner | Decision | Expiry |
|---|---|---|---|

Artifact ini cukup kecil untuk masuk pull request design doc, tetapi cukup kaya untuk review serius.

5. Scope: Jangan Mulai dari “Seluruh Sistem”

Threat model terlalu luas akan mati karena tidak actionable.

Mulai dari unit yang memiliki boundary jelas:

• satu endpoint penting,
• satu workflow approval,
• satu asynchronous command,
• satu integration dengan third-party,
• satu key management flow,
• satu artifact build pipeline,
• satu admin operation,
• satu data export/reporting job.

Contoh scope buruk:

Threat model untuk seluruh platform case management.

Contoh scope baik:

Threat model untuk workflow “case escalation approval” dari API request sampai audit event dan notification message.

Scope yang baik punya input, output, actor, dan state transition yang jelas.

6. Asset: Security Selalu Tentang Sesuatu yang Bernilai

Asset bukan hanya data. Asset adalah apa pun yang jika rusak, bocor, hilang, atau disalahgunakan akan menimbulkan dampak.

Dalam sistem Java enterprise, asset umum:

Asset harus diberi requirement, bukan hanya nama.

Asset: Enforcement approval decision
Confidentiality: medium
Integrity: critical
Availability: high
Non-repudiation: high
Retention: 7 years
Security invariant: once approved, decision must be attributable to exactly one authorized actor and must not be silently mutated.

Security invariant lebih berguna daripada label “critical”.

7. Actor: User Bukan Satu-Satunya Actor

Threat model sering gagal karena actor terlalu sempit.

Actor di sistem Java modern bisa berupa:

• anonymous internet client,
• authenticated user,
• privileged admin,
• support operator,
• batch job,
• message producer,
• message consumer,
• CI runner,
• dependency maintainer,
• cloud metadata service,
• third-party integration,
• malicious insider,
• compromised service account,
• compromised browser/session,
• attacker with read-only database access,
• attacker with log access,
• attacker with artifact repository access.

Actor perlu dimodelkan berdasarkan capability, bukan title.

Security bukan pertanyaan “siapa orangnya?”, melainkan “apa yang actor ini bisa lakukan terhadap boundary ini?”

8. Data Flow Diagram untuk Java Systems

Data-flow diagram bukan diagram arsitektur penuh. DFD hanya perlu menunjukkan:

• external entity,
• process,
• datastore,
• data flow,
• trust boundary.

Contoh untuk endpoint approval:

Trust boundary eksplisit:

Setiap boundary crossing adalah tempat pertanyaan security harus diajukan.

9. Trust Boundary: Titik Paling Mahal Jika Salah

Trust boundary terjadi saat data, command, identity, atau artifact berpindah dari satu level trust ke level lain.

Contoh Java-specific trust boundaries:

Rule sederhana:

Setiap boundary crossing harus memiliki validasi, autentikasi/otorisasi bila relevan, observability, dan failure mode yang aman.

10. Threat Enumeration: STRIDE sebagai Lensa, Bukan Agama

STRIDE membantu mengingat kategori ancaman:

Gunakan STRIDE per elemen DFD, bukan sebagai daftar global.

Contoh untuk approve command:

11. Java-Specific Threat Catalog

Berikut katalog ancaman yang sering muncul pada sistem Java. Ini bukan checklist final, tetapi starter untuk threat model.

11.1 HTTP/API Boundary

11.2 Domain Service Boundary

11.3 Persistence Boundary

11.4 Messaging Boundary

11.5 Build and Runtime Boundary

12. Abuse Case Lebih Berguna dari Happy Path

User story normal:

Sebagai case officer, saya ingin menyetujui escalation agar kasus dapat diproses ke tahap berikutnya.

Abuse case:

Sebagai actor dengan akses ke token case officer, saya mencoba menyetujui kasus di luar unit saya dengan mengganti caseId.

Sebagai support operator, saya mencoba mengekspor data kasus sensitif tanpa business justification.

Sebagai attacker yang bisa mengirim message ke broker, saya mencoba membuat consumer melakukan state transition tanpa approval API.

Sebagai insider dengan akses database read-only, saya mencoba merekonstruksi secret dari logs, audit event, dan config snapshot.

Abuse case memaksa desain kontrol menjadi konkret.

Format abuse case:

### Abuse Case: Cross-unit case approval

Actor capability:
- Authenticated as officer in Unit A
- Can observe or guess case IDs from Unit B

Attack path:
1. Calls GET /cases/{id} or POST /cases/{id}/approve
2. Replaces id with Unit B case id
3. Relies on endpoint checking role only, not resource scope

Expected invariant:
- Actor can approve only cases assigned to actor's authorized unit and role.

Required controls:
- Resource-level authorization in service layer
- Query scoped by actor's unit and assignment
- Audit denied attempts
- Negative authorization tests

13. Risk Ranking: Jangan Semua Jadi Critical

Semua risiko tidak bisa dianggap critical. Itu membuat engineering kehilangan sinyal.

Gunakan ranking praktis:

Contoh scoring sederhana:

public enum RiskLevel {
    LOW, MEDIUM, HIGH, CRITICAL
}

public record ThreatScore(
        int impact,
        int exposure,
        int exploitability,
        int prevalence,
        int poorDetectability,
        int poorRecoverability
) {
    public RiskLevel level() {
        int total = impact + exposure + exploitability
                + prevalence + poorDetectability + poorRecoverability;

        if (impact >= 5 && exposure >= 4 && exploitability >= 4) {
            return RiskLevel.CRITICAL;
        }
        if (total >= 24) return RiskLevel.CRITICAL;
        if (total >= 18) return RiskLevel.HIGH;
        if (total >= 11) return RiskLevel.MEDIUM;
        return RiskLevel.LOW;
    }
}

Ini bukan model matematis sempurna. Tujuannya menyamakan percakapan risiko.

14. Control Selection: Kontrol Harus Memutus Attack Path

Kontrol security sering gagal karena tidak ditempatkan pada path yang tepat.

Contoh ancaman:

User mengganti caseId untuk mengakses kasus unit lain.

Kontrol lemah:

• menyembunyikan tombol UI,
• menambah log,
• mengenkripsi ID,
• menggunakan UUID.

Kontrol kuat:

• resource-level authorization di service layer,
• query scoped by actor capability,
• deny-by-default,
• negative test untuk cross-unit access,
• audit denied attempts.

Kontrol kuat memutus attack path.

15. Security Invariant: Inti Threat Modeling untuk Engineer Senior

Security invariant adalah kondisi yang harus selalu benar.

Contoh invariant yang bagus:

A case approval transition may occur only if:
1. The actor is authenticated.
2. The actor has active approval capability for the case's current unit.
3. The case is in an approvable state.
4. The actor is not approving their own restricted submission when segregation-of-duty applies.
5. The transition, actor, policy version, timestamp, and request correlation id are appended to audit storage in the same logical operation.

Invariant membuat security bisa diuji.

Contoh implementasi guard:

public final class CaseApprovalGuard {

    private final AuthorizationPolicy authorizationPolicy;
    private final SegregationOfDutyPolicy segregationPolicy;

    public CaseApprovalGuard(
            AuthorizationPolicy authorizationPolicy,
            SegregationOfDutyPolicy segregationPolicy
    ) {
        this.authorizationPolicy = authorizationPolicy;
        this.segregationPolicy = segregationPolicy;
    }

    public void assertCanApprove(Actor actor, CaseRecord caseRecord) {
        if (!actor.isAuthenticated()) {
            throw new SecurityException("Unauthenticated actor cannot approve case");
        }

        if (!authorizationPolicy.canApprove(actor, caseRecord)) {
            throw new SecurityException("Actor is not authorized to approve this case");
        }

        if (!caseRecord.status().isApprovable()) {
            throw new IllegalStateException("Case is not in an approvable state");
        }

        if (segregationPolicy.violates(actor, caseRecord)) {
            throw new SecurityException("Segregation-of-duty policy violation");
        }
    }
}

Perhatikan: guard tidak bergantung pada UI. Guard hidup di domain/service boundary.

16. Threat Model untuk Asynchronous Java Systems

Banyak sistem Java enterprise memakai messaging. Threat model async berbeda karena tidak ada request/response langsung.

Pertanyaan threat model:

Security invariant untuk consumer:

A worker must not treat a message as authority by itself.
A message is an input claim, not a proof of authorization, unless it is produced by a trusted control plane with verifiable authenticity and scoped semantics.

17. Threat Model untuk File Upload

File upload adalah contoh bagus karena melibatkan banyak boundary.

Threats:

Java-specific principle:

Never let a user-controlled filename become a filesystem path.
Never let an uploaded file be parsed by a privileged long-lived JVM without resource limits and isolation.

18. Threat Model untuk Admin Features

Admin feature sering lebih berbahaya daripada public feature karena privilege besar.

Contoh admin actions:

• reset MFA,
• unlock account,
• change role,
• export data,
• update case status,
• delete document,
• trigger reprocessing,
• rotate secret,
• change policy configuration.

Threat model admin harus menanyakan:

Admin endpoint tanpa abuse-case review adalah sumber privilege escalation yang umum.

19. Threat Model untuk Build Pipeline

Java security tidak berhenti di source code. Artifact yang dijalankan di production berasal dari supply chain.

Threats:

Controls:

• protected branches,
• mandatory review,
• pinned dependencies,
• dependency verification,
• isolated CI permissions,
• signed artifacts,
• SBOM,
• provenance,
• deployment admission policy.

Bagian supply chain akan dibahas lebih dalam di Part 025–027. Di sini cukup pahami bahwa build pipeline adalah bagian dari threat model aplikasi.

20. Threat Model Review dalam Pull Request

Threat modeling tidak harus selalu meeting besar. Untuk perubahan kecil, gunakan PR checklist:

## Security Review

### Changed Trust Boundaries
- [ ] New external input
- [ ] New internal service call
- [ ] New message/event producer or consumer
- [ ] New datastore access
- [ ] New file/network/process interaction
- [ ] New dependency or build step

### Actor and Authorization
- [ ] Actor identity is explicit
- [ ] Resource-level authorization exists
- [ ] Deny path is tested
- [ ] Privileged action is audited

### Data and Integrity
- [ ] Input is canonicalized/validated
- [ ] Sensitive output is minimized
- [ ] State transition invariant is enforced
- [ ] Idempotency/replay behavior is defined

### Operational Safety
- [ ] Failure mode is safe
- [ ] Logs do not leak secrets/PII
- [ ] Monitoring/detection exists for abuse path

PR review harus fokus pada perubahan boundary dan invariant, bukan hanya formatting.

21. Security Decision Record

Threat model sering menghasilkan keputusan trade-off. Simpan sebagai Security Decision Record.

# SDR-012: Case Approval Requires Resource-Level Authorization in Domain Layer

## Context
Approval endpoint receives caseId from client. Role-only authorization is insufficient because officers from Unit A must not approve Unit B cases.

## Decision
Authorization will be enforced in CaseApprovalGuard using actor, case unit, assignment, status, and segregation-of-duty policy. Controller-level annotations are not considered sufficient.

## Consequences
- All approval paths must call CaseApprovalGuard.
- Negative tests must cover cross-unit approval.
- Audit denied attempts with actor, caseId, unit, policy version, and correlationId.

## Open Risks
Batch repair jobs bypass normal approval path. Separate privileged job policy required.

Senior engineer tidak hanya memilih kontrol. Senior engineer meninggalkan jejak keputusan yang bisa diaudit.

22. Common Pitfalls

23. Practice: 20 Jam Pertama Threat Modeling Java

Rencana latihan Kaufman-style:

Tujuan 20 jam bukan menjadi security expert penuh. Tujuannya membangun refleks: setiap feature dilihat sebagai boundary, invariant, dan attack path.

24. Checklist Ringkas

Sebelum menyatakan threat model cukup:

• Scope jelas dan tidak terlalu besar.
• Asset diberi requirement, bukan hanya nama.
• Actor dimodelkan berdasarkan capability.
• DFD menunjukkan data flow dan trust boundary.
• Threat ditulis sebagai attack path konkret.
• Mitigasi memutus attack path.
• Security invariant bisa diuji.
• Open risk punya owner dan expiry.
• Validation plan mencakup test, review, monitoring, atau drill.
• Keputusan penting disimpan sebagai SDR.

25. Ringkasan

Threat modeling untuk sistem Java bukan ritual compliance. Ia adalah teknik desain untuk menemukan tempat di mana sistem berubah dari “menerima input” menjadi “mempercayai sesuatu”.

Mental model utama:

Feature = intended path.
Threat = unintended path to protected asset.
Control = mechanism that breaks the unintended path.
Validation = proof that the mechanism still works.

Jika kamu bisa menggambar actor, asset, data flow, trust boundary, attack path, control, dan validation plan, kamu sudah punya fondasi yang kuat untuk semua topik security berikutnya: authentication, authorization, cryptography, platform hardening, dan supply-chain integrity.

References

• OWASP, Threat Modeling Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
• OWASP, Threat Modeling Process — https://owasp.org/www-community/Threat_Modeling_Process
• OWASP, Application Security Verification Standard — https://owasp.org/www-project-application-security-verification-standard/
• Oracle, Secure Coding Guidelines for Java SE — https://www.oracle.com/java/technologies/javase/seccodeguide.html
• Oracle, Java Cryptography Architecture Reference Guide — https://docs.oracle.com/en/java/javase/25/security/java-cryptography-architecture-jca-reference-guide.html