Security Theater: Kenapa Stack Lo yang "Aman" Gak Nyelamatin Lo

Ada satu hal yang bikin gue penasaran tiap audit security: startup yang punya semua checklist aman - 2FA, WAF, encryption at rest, pentest tahunan, SOC 2 compliance - tapi tetap kena hack. Bukannya teknologi yang gagal. Yang gagal: mereka melakukan security sebagai performance, bukan sebagai substance. Mereka punya armor yang kelihatan berat dari luar, tapi gak menutup celah yang sebenernya.

Ini bukan artikel "OWASP top 10" atau "X hal yang bikin lo aman." Ini soal security theater vs real security - beda antara hal yang bikin orang ngerasa aman, dan hal yang sebenernya ngurangin risk. Gue pernah di kedua sisi: pernah nulis checklist biar compliance, dan pernah nembus sistem yang compliance-nya sempurna.

---

Security Theater Itu Apa

Istilah ini dipopulerin Bruce Schneier tahun 2003. Security theater = tindakan yang kelihatan meningkatkan security tapi sebenernya gak ngurangin risk. Contoh klasik dunia fisik: TSA di bandara Amerika pas 9/11 - ngambil sepatu, scan laptop, liquids 100ml. Feel safe. Sebenernya attacker yang serius tetep bisa lewat. Tapi penumpang ngerasa aman, jadi politik puas.

Dunia software penuh security theater:

• "Force password complex" - user dipaksa P@ssw0rd123! tiap 90 hari. Hasilnya: user nulis password di sticky note, atau Password1 → Password2 → Password3. Complexity theater. Attacker brute force tetep bisa, user malah lebih lemah.

• "2FA mandatory" - tapi lewat SMS. SMS bisa di-sim-swapped. AT&T, Verizon pernah kena SS7 attack, 2FA SMS di-intercept. Lo pede "ada 2FA," padahal 2FA SMS itu paling gampang di-bypass.

• "Encryption at rest" - database di-encrypt. Tapi app layer punya service_role key yang full access. Attacker yang RCE app = dapet key = decrypt data. Encryption useless.

• "WAF" - Web Application Firewall dipasang. Tapi rules default, gak di-tune. False positive tinggi, false negative tinggi. Attacker pake request yang gak match signature WAF, lewat. Lo bayar $500/bulan buat ketenangan pikiran.

• "Pentest tahunan" - 1 minggu audit, dapet report 50 page, fix 80% finding. 51 minggu sisanya: code baru 100k lines ditulis tanpa audit. Window vulnerability-nya 51 minggu.

Filosofi security theater: fokus ke apa yang kelihatan, bukan apa yang ngurangin risk. Compliance checklist bikin lo ngerasa aman karena lo udah centang kotak. Tapi attacker gak peduli checklist lo. Attacker nyari gap.

---

Cerita Satu Audit yang Ngubah Cara Gue Mikir

Gue audit startup fintech 2024. Mereka bangga: SOC 2 Type II, ISO 27001, pentest tiap kuartal, bug bounty program. Stack-nya:

• AWS dengan KMS encryption at rest ✅
• Cloudflare WAF + DDoS protection ✅
• Auth0 dengan MFA + SSO ✅
• RDS dengan secret rotation ✅
• CloudTrail + GuardDuty ✅

Gue kagum dari luar. Terus gue nanya ke CTO: "Kalau lo anggap lo udah kena hack sekarang, apa yang bakal nge-batasin dampak?"

CTO diem 10 detik. "Maksud lo?"

Itu pertanda. Mereka design sistem buat "ng halau attacker." Mereka gak pernah design buat "ngurangin dampak kalau attacker udah masuk." Dua mindset itu beda banget.

Gue tunjukin: mereka punya 1 service role Postgres yang dipake semua service. Auth service, order service, billing service - semua pake credential yang sama. Full access ke semua tabel. Service A gak butuh akses ke tabel billing_invoices, tapi credential-nya punya akses itu.

Kalau attacker RCE service A (paling lewat, paling sering di-bypass), mereka dapet service role credential. Akses ke seluruh database. Semua user data, semua invoice, semua payment history.

Encryption at rest useless - app punya key. WAF useless - attacker udah di dalam, request-nya legitimate. 2FA useless - attacker udah authenticated via service role.

Bukan teknologi yang lemah. Least privilege principle yang gak diterapin. AWS documentation bilang "use IAM role with minimal permissions." Mereka baca, tapi implementasinya: 1 role, full access, selesai. Aman karena compliance. Rapuh karena reality.

---

Real Security: Assume Breach, Design for Impact Reduction

Filosofi yang bener: assume lo udah kena hack. Bukan "assume lo bisa kena hack." Assume udah kena. Mau ngapa?

Pikiran ini nge-ubah cara lo design sistem:

1. Kalau attacker udah masuk app server, apa yang lo batasin?

• Service role credential? Musti scoped per service. Service A cuman bisa akses tabel users. Service B cuman orders. Beda credential, beda scope. Attacker RCE service A = akses users doang, bukan seluruh DB.

-- Bukan: satu role buat semua
CREATE ROLE app_service LOGIN PASSWORD '...';

-- Tapi: role per service, scoped
CREATE ROLE auth_service LOGIN PASSWORD '...';
GRANT SELECT, INSERT ON users TO auth_service;

CREATE ROLE order_service LOGIN PASSWORD '...';
GRANT SELECT, INSERT, UPDATE ON orders TO order_service;
-- order_service gak bisa akses users table

Postgres RLS bisa lebih granular lagi - policy per row, bukan per tabel.

2. Kalau attacker dapet JWT, berapa lama mereka punya akses?

• JWT long-lived (30 hari) = 30 hari window kalau di-steal.
• JWT short-lived (15 menit) + refresh token rotation = 15 menit window. Attacker masih bisa refresh, tapi refresh token rotation detect anomaly (refresh token reuse = alarm).

Trade-off: user musti re-login tiap 15 menit? Enggak. Refresh token auto-renew di background. UX sama, security lebih ketat.

3. Kalau attacker akses log system, apa yang mereka dapet?

• Log full request body (termasuk password, token, PII)? Game over.
• Log structured + redacted (lihat artikel asumsi sebelumnya)? Attacker dapet metadata doang.

Lo gak bisa cegah breach 100%. Lo bisa batasin dampak. Itu beda mindset sama "tambahin WAF biar aman."

4. Kalau attacker RCE, bisa lateral move ke service lain?

• Semua service di 1 VPC, gak ada network segmentation? Attacker scan internal, nemu service internal yang gak ada auth (karena "internal, gak perlu auth").
• Service mesh dengan mTLS (Istio, Linkerd)? Tiap service musti present cert sebelum call service lain. Attacker RCE service A = gak bisa langsung call service B tanpa cert.

5. Kalau attacker modify data, bisa lo detect?

• Audit log yang mutable (bisa di-DELETE)? Attacker hapus jejak.
• Audit log immutable (append-only, write ke S3 dengan Object Lock)? Attacker gak bisa ubah history. Lo tau siapa ngapin kapan.

Filosofi "assume breach": lo gak design buat nge-halau. Lo design buat nge-batasin blast radius dan detect cepet. Lo accept bahwa attacker bakal masuk. Yang lo design: saat mereka masuk, dampaknya minimal dan lo tau dalam hitungan menit, bukan bulan.

---

Kenapa Security Theater Begitu Common

Kalau security theater gak efektif, kenapa banyak yang ngelakuin?

Compliance-driven. SOC 2 butuh "encryption at rest." Auditor cek: "apakah data di-encrypt?" Yes. Pass. Auditor gak cek: "kalau attacker RCE app, bisa decrypt gak?" Itu gak di-scope audit. Lo pass compliance, tapi gak secure.

Vendor-driven. Cloudflare, Auth0, Datadog - mereka jual ketenangan. "Pake WAF kami, aman." "Pake MFA kami, selesai." Mereka jual checkbox, bukan risk reduction. Lo bayar, centang, merasa aman. Vendor puas, compliance puas, attacker tetep masuk.

Sulit diukur. Security yang bener itu ngurangin risk yang gak terjadi. Gak ada visible outcome. "Kita gak kena hack bulan ini" - karena kita aman, atau karena belum ada yang nyerang? Susah dibuktikan. Tapi "kita implementasi 2FA" - visible, measurable, reportable. Lo dapet pujian. Security theater dapet pujian, real security dapet "loh kok gak ada apa-apa?"

Slow burn. Security theater hasilnya instant (centang checklist). Real security hasilnya long-term (tiap kali incident, dampaknya kecil). Org ngelihatin instant, gak ngelihatin long-term. Padahal yang bener itu long-term.

---

Tanda-Tanda Lo Lakukan Security Theater

Bukan checklist. Tapi pertanyaan buat self-audit:

• Kalau CTO nanya "kenapa kita pake WAF ini?" jawaban lo "karena compliance" atau "karena vendor X merekomendasi"? Kalau iya, itu theater. Real answer musti: "karena ngurangin attack vector Y sebesar Z%, dan ini alternative-nya."

• Lo pernah test kalau 2FA lo di-bypass pake phishing simulation? Kalau gak pernah, 2FA lo = asumsi, bukan verified.

• Lo pernah simulate "attacker RCE service A, seberapa dalam mereka bisa masuk"? Kalau gak pernah, lo gak tau blast radius lo. Lo assume, bukan know.

• Pentest lo: apakah finding di-fix, atau di-document sebagai "accepted risk"? Kalau banyak accepted risk, pentest = checkbox, bukan risk reduction.

• Lo pernah restore backup beneran (gak cuma verify file ada)? Kalau gak, backup lo = assumption, bukan verified recovery capability.

Tiap "yes" = tanda lo mungkin main security theater, bukan real security.

---

Yang Gue Lakuin Sekarang

Bukan checklist. Filosofi yang gue bawa tiap design decision:

Threat modeling dulu, baru tool. Sebelum "kita pake WAF," nanya: "apa threat yang kita takutin? SQL injection? XSS? DDoS?" Beda threat, beda mitigation. WAF cocok buat SQL injection signature, gak cocok buat logic flaw (misal IDOR). Jangan pasang tool sebelum tau threat.

Defense in depth dengan each layer addressing specific vector. Bukan "tambah layer buat banyak layer." Tiap layer musti nge-jawab: "attack vector apa yang lo cover? Kenapa layer sebelumnya gak cukup?" Kalau jawabannya "biar lebih aman," itu theater.

Assume breach, measure blast radius. Tiap service: kalau ini kena compromise, data apa yang accessible? Credential apa yang bocor? Service mana yang bisa di-lateral-moved? Design buat minimize itu.

Recovery capability over prevention. Prevention gak pernah 100%. Yang pasti: lo bakal kena. Lo bakal recover. Seberapa cepet? Seberapa much data loss? Itu yang musti didesign. Backup yang di-test restore. Runbook incident response yang di-drill. Chaos engineering buat simulate failure.

Security yang measurable. Bukan "kita aman karena compliance." Tapi: "mean time to detect (MTTD) 5 menit, mean time to respond (MTTR) 30 menit, blast radius last incident = 2 service, 1000 row." Itu metric. Compliance = checkbox, bukan metric.

---

Penutup yang Jujur

Security theater menang dalam politik. Real security menang dalam incident. Lo gak bisa duanya.

Gue pernah di sisi theater: nulis checklist, centang compliance, report ke board "kita SOC 2 certified, aman." 6 bulan kemudian kena breach. Sistem yang "aman" tadi gak nahan. Yang nahan: backup yang bener-bener bisa di-restore, audit log immutable yang nge-allow forensic, dan segmentation yang ng-batasin attacker cuma di 1 service. Yang gue anggap "overkill" pas design ternyata yang nyelamatin.

Filosofi yang gue bawa sekarang: jangan tanya "apakah kita aman?" Tanya "kalau kita kena, seberapa cepet kita recover dan seberapa kecil dampaknya?" Yang pertama pertanyaan yang gak terjawab. Yang kedua pertanyaan yang bisa di-design.

Kalau lo CTO atau tech lead, audit diri sendiri: dari semua "security measure" yang lo pake, berapa banyak yang lo pake karena ngurangin risk spesifik, dan berapa banyak yang lo pake karena compliance / vendor / peer pressure? Yang kedua itu theater. Yang pertama itu real.

Kalau jawaban lo "semua karena compliance," lo mungkin theater. Bukan berarti lo gak aman - tapi lo gak tau aman atau gak. Dan di security, gak tau = gak aman.

---

Sumber

• OWASP Authorization Cheat Sheet
• OWASP Developer Guide: Security Principles