Kenapa Security Gagal: Bukan Hacker, Tapi Keputusan yang Terus Ditunda

TL;DR

• Mayoritas breach berasal dari hal mendasar — password default, patch telat, misconfiguration — bukan serangan sophisticated.

• Narasi "hacker canggih" melindungi ego organisasi, tapi menghalangi perbaikan akar masalah.

• Tools mahal tanpa proses dan kapasitas tim adalah pemborosan, bukan investasi security.

• Yang dibutuhkan bukan teknologi baru, tapi disiplin, visibility, dan kejujuran untuk mengakui apa yang selama ini ditunda.

---

Pembukaan: Breach yang Sebenarnya

Sebagian besar security breach yang pernah saya tangani bukan karena hacker jenius.

Bukan karena zero-day exploit. Bukan karena APT group dengan custom malware. Bukan karena serangan sophisticated yang butuh budget jutaan dollar.

Yang bikin sistem jebol itu justru hal-hal mendasar yang dianggap sepele:

Password default yang nggak pernah diganti. Patch yang telat berbulan-bulan. Cloud storage yang dibiarkan terbuka untuk publik. Firewall rule "sementara" yang sudah jalan bertahun-tahun tanpa ada yang berani mencabut.

Ini bukan teori. Ini yang saya lihat di lapangan — berulang-ulang, di berbagai skala organisasi, di berbagai industri.

Dan polanya selalu sama: kegagalan bukan di teknologi, tapi di keputusan.

Kalau Anda bekerja di security cukup lama, Anda akan sampai pada kesimpulan yang sama. Yang menghancurkan organisasi bukan musuh di luar.

Yang menghancurkan adalah apa yang terjadi — atau lebih tepatnya, tidak terjadi — di dalam.

---

Kita Terobsesi Sama Musuh yang Salah

Setiap kali ada breach besar, narasi yang keluar selalu sama: "Kita diserang oleh threat actor sophisticated."

Kedengarannya kayak force majeure. Kayak bencana alam yang nggak bisa dicegah. Nyaman. Nggak ada yang perlu disalahkan.

Board of directors mengangguk. Regulator menerima penjelasan. Dan semua orang di ruangan bisa pulang dengan karir masih utuh.

Padahal data berbicara sebaliknya.

Verizon DBIR — yang berbasis analisis ribuan insiden nyata setiap tahunnya — konsisten menunjukkan: mayoritas breach berasal dari credential lemah, misconfiguration, dan human error. Hal-hal yang sepenuhnya bisa dicegah dengan proses yang benar dan keputusan yang tepat waktu.

Tapi narasi "hacker canggih" punya fungsi politik yang kuat. Lebih enak disampaikan ke board. Lebih mudah diterima regulator.

Dan yang paling penting — lebih aman buat karir semua orang yang seharusnya bertanggung jawab.

Tidak ada yang dipecat karena "diserang hacker negara." Tapi orang bisa kehilangan jabatan kalau ketahuan bahwa breach terjadi karena server belum di-patch selama 8 bulan.

Perlu dicatat, tentu ada breach yang benar-benar melibatkan zero-day atau aktor negara. Tapi kasus-kasus ini adalah minoritas. Ironisnya, justru kasus paling dasar yang terus berulang dan memakan korban terbesar.

Dan selama kita mempercayai narasi itu, kita nggak pernah memperbaiki akar masalahnya. Kita sibuk membangun benteng untuk musuh yang salah, sementara pintu belakang dibiarkan terbuka lebar.

---

Tiga Pola Kegagalan — dan Siapa yang Seharusnya Memutuskan

Dari pengalaman menangani insiden di berbagai organisasi, ada tiga pola kegagalan yang muncul berulang-ulang.

Ketiganya bukan masalah teknis. Ketiganya adalah masalah keputusan.

1. Patch yang Ditunda Tanpa Batas

"Jangan di-update, nanti down."

Kalimat ini sudah menghancurkan lebih banyak organisasi daripada kebanyakan malware yang pernah ditulis.

Saya paham kekhawatiran di baliknya. Patching memang bisa menyebabkan downtime. Aplikasi legacy bisa break. Ada dependency yang rumit.

Tapi mari kita bicara soal matematika risiko yang sebenarnya.

Recovery dari ransomware itu hitungannya minggu — kadang bulan, kadang nggak pernah fully recovered. Downtime dari patching itu hitungannya menit, paling lama beberapa jam kalau direncanakan dengan benar.

Yang lebih mengkhawatirkan: keputusan untuk menunda patch sering dibuat oleh orang yang nggak menanggung risikonya.

Sysadmin yang bilang "jangan update" biasanya bukan orang yang harus menjelaskan ke regulator kenapa data customer bocor. Manager yang approve penundaan bukan orang yang harus hadir di war room jam 3 pagi saat ransomware menyebar.

Pertanyaannya bukan teknis — kita sudah punya teknologi dan methodology untuk patching yang aman.

Pertanyaannya: siapa di organisasi yang bertanggung jawab memutuskan "patch sekarang" vs "tunda" — dan siapa yang menanggung konsekuensinya kalau keputusan itu salah?

Kalau jawaban itu nggak jelas, Anda sudah menemukan sumber masalahnya.

2. Shadow IT: Keputusan yang Nggak Pernah Diambil

Tim marketing bikin server sendiri di AWS untuk campaign. Developer pakai database gratisan yang ternyata berisi data production. Divisi HR langganan SaaS tool yang langsung konek ke Active Directory tanpa sepengetahuan IT Security.

Shadow IT bukan fenomena baru. Tapi yang sering salah kaprah adalah respons terhadapnya: kita menyalahkan user.

"Mereka nakal." "Mereka nggak ikut prosedur."

Padahal shadow IT muncul bukan karena orang nakal — tapi karena proses resmi terlalu lambat.

Butuh server untuk testing? Isi form, tunggu approval 3 minggu. Butuh tools kolaborasi baru? Masuk antrian procurement 2 bulan.

Orang butuh solusi sekarang, dan mereka mengambil jalan tercepat yang tersedia.

Yang absen di sini bukan kontrol teknis. Firewall dan DLP bisa dipasang.

Yang absen adalah keputusan organisasi yang lebih fundamental: bagaimana kita menyediakan jalur resmi yang cukup cepat supaya orang nggak perlu cari jalan pintas?

Bagaimana kita membuat "cara yang benar" juga menjadi "cara yang mudah"?

Selama gap itu ada, shadow IT akan terus tumbuh. Dan setiap instance shadow IT adalah blind spot yang menunggu untuk dieksploitasi.

3. Default Credential: Keputusan yang Dihindari

Di tahun 2026, saya masih menemukan router dengan `admin/admin`. Database production tanpa password. API key yang di-hardcode di repository publik.

Bukan karena teknologinya nggak mendukung perubahan. Bukan karena nggak ada tools untuk credential management.

Tapi karena nggak ada yang merasa itu tugasnya.

Siapa yang bertanggung jawab memastikan setiap device yang masuk ke environment sudah di-harden sebelum go-live? Siapa yang melakukan verifikasi? Siapa yang memegang checklist dan benar-benar menjalankannya — bukan cuma menandatanganinya?

Kalau jawabannya "nggak ada" — itu masalahnya. Bukan masalah hacker. Masalah ownership.

---

Tools Mahal, Proses Kosong

Ada fenomena yang saya sebut security spending illusion: perusahaan merasa aman karena sudah invest miliaran di teknologi security.

SIEM enterprise-grade. EDR di setiap endpoint. Threat intelligence feed dari multiple vendor. Lengkap. Mahal. Dashboard-nya cantik.

Tapi realitanya?

SIEM generate 10.000 alert per hari. Tim SOC cuma 3 orang — yang masing-masing juga pegang tanggung jawab lain. Alert yang benar-benar di-review dan di-investigate mungkin 5%.

Sisanya? Masuk log, nggak pernah dibaca, dan berharap yang terlewat bukan insiden sungguhan.

EDR terpasang, tapi policy-nya masih default karena nggak ada yang sempat tuning. Threat intelligence feed aktif, tapi nggak ada proses untuk mengubah intelligence menjadi action.

Tools tanpa proses dan kapasitas tim yang memadai bukan investasi — itu pemborosan.

Dan ini bukan salah tools-nya. Ini adalah keputusan procurement yang dibuat tanpa memperhitungkan kapasitas operasional.

Apakah kita membeli tools ini untuk benar-benar meningkatkan security, atau untuk punya sesuatu yang bisa ditunjukkan saat audit?

---

Yang Sebenarnya Dibutuhkan

Jawabannya membosankan. Nggak ada yang glamour. Nggak ada silver bullet.

Dan justru karena itu, jawabannya sering diabaikan.

Disiplin. Patch management yang konsisten dan terukur — bukan cuma ada di slide presentasi. Proses yang benar-benar berjalan, dengan accountability yang jelas, setiap minggu, tanpa pengecualian yang nggak terdokumentasi.

Visibility. Kita nggak bisa melindungi apa yang nggak kita ketahui ada. Asset inventory yang akurat dan up-to-date bukan nice-to-have — ini fondasi.

Kultur. Security bukan tanggung jawab satu tim yang duduk di pojok kantor — ini keputusan organisasi yang harus dipahami di setiap level. Dari developer yang menulis kode, sampai CEO yang menentukan seberapa serius security diperlakukan.

Kejujuran. Audit internal yang jujur — yang benar-benar mencari kelemahan, bukan mengkonfirmasi bahwa semuanya baik-baik saja — jauh lebih berguna daripada sertifikasi yang hanya jadi pajangan di website.

Sertifikasi punya tempatnya. Tapi kalau dijadikan pengganti keamanan yang sesungguhnya, kita sedang membohongi diri sendiri.

---

Cermin, Bukan Teropong

Sebelum invest di threat intelligence mahal. Sebelum hire red team. Sebelum beli platform security terbaru yang dijanjikan vendor bisa menyelesaikan semua masalah.

Tanya dulu pertanyaan yang paling mendasar:

Semua server sudah di-patch? Semua default password sudah diganti? Seluruh asset tercatat dan punya penanggung jawab?

Tim tahu harus ngapain kalau ada insiden jam 2 pagi?

Kalau jawabannya "belum" — atau lebih jujur lagi, "nggak tahu" — kita belum butuh tools baru.

Kita butuh cermin.

Security bukan perang melawan hacker. Security itu perang melawan keputusan-keputusan yang terus kita tunda.

---

Artikel pertama dari seri tentang realita security di lapangan. Bukan framework. Bukan checklist. Tapi hal-hal yang perlu kita akui sebelum bisa maju.