Incident Response Tidak Dimulai Saat Incident Terjadi

The Core Update

CISA, badan cybersecurity Amerika Serikat yang bertugas membantu melindungi jaringan federal dan infrastruktur kritikal, mengungkap hal yang cukup mengejutkan dalam laporan postmortem mereka.

Saat menghadapi incident pada bulan Mei, CISA ternyata belum punya response playbook yang siap dipakai untuk jenis situasi tersebut.

Incident ini bermula ketika seorang security researcher menemukan sensitive keys dan credentials untuk mengakses sistem pemerintah Amerika Serikat yang tersimpan di repository GitHub publik. Repository itu diunggah oleh pegawai kontraktor CISA.

Menurut laporan, researcher sempat mencoba menghubungi kontraktor, tetapi tidak mendapat respons. Setelah investigative reporter Brian Krebs menghubungi CISA, repository tersebut akhirnya diturunkan. CISA lalu mencabut dan mengganti credentials yang terekspos untuk mencegah potensi penyalahgunaan.

CISA menyatakan tidak ada customer data atau mission data yang terekspos. Mereka juga berterima kasih kepada researcher dan reporter yang membantu melaporkan masalah ini.

Namun bagian paling penting bukan hanya soal credentials yang bocor. Bagian paling penting adalah pengakuan bahwa tim CISA harus menghabiskan waktu membangun playbook saat tahap awal incident sedang berjalan.

Untuk organisasi cybersecurity nasional, ini terlihat ironis. Tetapi bagi banyak bisnis, pola ini sebenarnya sangat familiar.

Masalah baru dianggap perlu SOP ketika masalah sudah terjadi.

The Reality Check

Banyak organisasi merasa sudah siap menghadapi incident karena sudah punya tool security, cloud dashboard, access control, alert, logging, dan tim teknis.

Kadang memang begitu. Tool yang tepat bisa membantu mendeteksi masalah lebih cepat.

Tetapi tool tidak otomatis membuat organisasi siap merespons.

Saat incident terjadi, pertanyaan yang muncul biasanya bukan hanya pertanyaan teknis. Pertanyaannya lebih operasional:

siapa yang menerima laporan pertama?
laporan masuk lewat channel mana?
siapa yang berhak memutuskan revoke credential?
siapa yang menghubungi vendor atau kontraktor?
siapa yang menilai data apa saja yang terdampak?
siapa yang memberi update ke management?
kapan incident dianggap selesai?
apa yang harus dicatat untuk postmortem?

Kalau jawaban ini belum jelas, tim akan tetap bergerak. Tetapi geraknya banyak bergantung pada improvisasi.

Improvisasi bukan selalu buruk. Dalam situasi darurat, tim memang perlu fleksibel. Tetapi improvisasi tidak boleh menjadi sistem utama.

Kasus CISA menunjukkan hal yang sering terjadi di banyak organisasi: masalah teknis berubah menjadi masalah koordinasi.

Credentials bocor adalah masalah security. Repository publik adalah masalah engineering practice. Kontraktor yang tidak merespons adalah masalah vendor management. Channel laporan yang tidak jelas adalah masalah operasi. Playbook yang belum siap adalah masalah governance.

Satu incident kecil bisa membuka banyak kelemahan yang sebelumnya tidak terlihat.

Playbook bukan dokumen pajangan

Banyak perusahaan pernah membuat SOP, tetapi jarang memakainya. Dokumen ada di folder bersama, tetapi tidak menjadi cara kerja harian. Akhirnya ketika incident terjadi, tim tetap bertanya lewat chat: ini harus diapakan?

Playbook yang sehat tidak harus panjang. Ia harus bisa dipakai saat kondisi sedang panik.

Untuk incident seperti exposed credentials, playbook minimal perlu menjawab beberapa hal sederhana:

cara menerima dan memverifikasi laporan
cara menentukan tingkat risiko
daftar sistem yang mungkin terdampak
pemilik sistem yang harus dihubungi
langkah revoke dan rotate credential
cara memastikan repository atau file sudah tidak publik
cara mengecek log akses
cara menyimpan bukti
cara memberi update internal
cara menutup incident dan membuat postmortem

Tidak semua bisnis perlu playbook setebal organisasi pemerintah. Tetapi setiap bisnis yang menyimpan data pelanggan, memakai cloud service, mengelola API key, atau bekerja dengan vendor perlu punya versi sederhananya.

Karena saat credential bocor, waktu pertama sangat mahal.

Tim tidak seharusnya baru mencari siapa pemilik AWS, siapa yang bisa akses GitHub, siapa yang pegang environment variable, atau siapa yang boleh menghubungi vendor saat incident sudah terjadi.

Jalur laporan sering lebih penting daripada dashboard

Salah satu poin menarik dari postmortem CISA adalah pengakuan bahwa channel untuk security researcher melapor belum terdefinisi dengan baik.

Ini masalah yang sangat umum.

Banyak bisnis punya halaman kontak, email support, WhatsApp sales, DM Instagram, form partnership, dan chat admin. Tetapi tidak punya jalur yang jelas untuk laporan security.

Akibatnya, laporan penting bisa masuk ke tempat yang salah.

Security researcher mungkin mengirim email ke alamat umum. Admin mungkin menganggapnya spam. Sales mungkin tidak paham urgensinya. Vendor mungkin lambat merespons. Laporan baru dianggap serius setelah masuk lewat orang yang lebih dikenal atau lebih berpengaruh.

Ini bukan hanya masalah perusahaan besar. Bisnis kecil pun bisa mengalaminya.

Misalnya ada orang menemukan file backup terbuka, endpoint API bocor, invoice bisa diakses tanpa login, atau token WhatsApp automation tersimpan di repository publik. Kalau tidak ada channel laporan yang jelas, orang yang menemukan masalah bisa bingung harus menghubungi siapa.

Di titik ini, website dan sistem kontak bukan hanya alat marketing. Ia juga bagian dari readiness.

Minimal, organisasi perlu punya cara yang jelas untuk menerima laporan keamanan. Tidak harus rumit. Bisa berupa halaman security contact, email khusus, atau instruksi sederhana di website.

Yang penting, laporan tidak jatuh ke lubang kosong.

Vendor dan kontraktor tetap bagian dari risiko internal

Dalam kasus ini, repository publik diunggah oleh pegawai kontraktor. Ini mengingatkan hal yang sering dilupakan: risiko security tidak berhenti di tim internal.

Vendor, freelancer, agency, system integrator, konsultan, dan kontraktor sering punya akses ke sistem penting. Mereka bisa memegang API key, credential cloud, akses CMS, akses database staging, akses GitHub, atau akses dashboard iklan.

Kalau governance lemah, akses itu bisa menjadi titik bocor.

Bukan berarti bisnis harus tidak percaya vendor. Tetapi bisnis perlu memperlakukan akses vendor sebagai bagian dari sistem, bukan pengecualian informal.

Beberapa kebiasaan dasar yang sering lebih bernilai daripada tool mahal:

akses vendor dibatasi sesuai kebutuhan
credential tidak dikirim lewat chat biasa
API key punya scope minimal
akses sementara punya tanggal review
repository tidak menyimpan secret
secret scanner aktif jika memungkinkan
offboarding vendor punya checklist
pemilik internal tetap jelas

Vendor boleh membantu pekerjaan. Tetapi tanggung jawab akhir tetap ada di organisasi yang memiliki sistem.

Kalau credential bocor dari kontraktor, pelanggan tetap melihatnya sebagai masalah organisasi utama.

The Havedev Way

Dari sudut pandang Havedev, pelajaran dari kasus ini bukan sekadar “jangan taruh secret di GitHub”. Itu benar, tetapi terlalu sempit.

Pelajaran yang lebih besar adalah: incident response harus diperlakukan sebagai alur kerja, bukan reaksi spontan.

Banyak bisnis sudah punya website, cloud, CRM, dashboard, payment gateway, WhatsApp automation, dan integrasi pihak ketiga. Namun belum punya jawaban sederhana untuk pertanyaan: kalau ada masalah security besok pagi, siapa melakukan apa?

Sebelum membeli tool security tambahan, bisnis sebaiknya memetakan alur incident paling dasar.

Mulai dari skenario yang paling masuk akal:

API key bocor di repository
akses admin dipakai orang yang tidak berhak
data pelanggan terkirim ke pihak yang salah
website berubah tanpa izin
form mengirim data ke email yang salah
invoice atau file bisa diakses publik
vendor masih punya akses setelah project selesai

Untuk setiap skenario, jangan mulai dari tool. Mulai dari status dan keputusan.

Tanyakan:

bagaimana masalah pertama kali diketahui?
siapa penerima laporan?
siapa incident owner?
sistem mana yang harus dicek dulu?
akses apa yang harus dicabut?
credential apa yang harus diganti?
siapa yang perlu diberi tahu?
bukti apa yang harus disimpan?
kapan incident naik level?
kapan incident dianggap selesai?

Jawaban ini tidak harus sempurna. Tetapi harus cukup jelas agar tim tidak membangun playbook dari nol saat sedang panik.

Mulai dari playbook kecil yang benar-benar dipakai

Banyak organisasi gagal membuat incident response karena langsung membayangkan dokumen besar, simulasi rumit, dan standar enterprise.

Padahal untuk awal, playbook kecil lebih baik daripada dokumen besar yang tidak pernah dibaca.

Untuk banyak bisnis, satu halaman sudah cukup sebagai titik awal:

channel laporan security
daftar pemilik sistem utama
daftar akses kritikal
langkah revoke credential
langkah rotate secret
template update internal
checklist postmortem

Setelah itu, uji dengan skenario sederhana. Misalnya: “kalau API key production muncul di GitHub, apa yang kita lakukan dalam 30 menit pertama?”

Kalau tim tidak bisa menjawab tanpa debat panjang, berarti readiness belum cukup.

Bukan karena tim tidak kompeten. Biasanya karena keputusan belum ditulis, peran belum dibagi, dan jalur eskalasi belum disepakati.

Automation hanya sehat setelah responsibility jelas

Di dunia AI dan automation, mudah sekali tergoda membuat alert otomatis, ticket otomatis, scanner otomatis, dan report otomatis.

Semua itu berguna. Tetapi automation tidak menggantikan ownership.

Alert tanpa pemilik hanya menjadi noise. Ticket tanpa SLA hanya menjadi antrean. Scanner tanpa proses revoke hanya menjadi daftar rasa bersalah. Dashboard tanpa keputusan hanya menjadi layar yang terlihat sibuk.

Jika bisnis ingin memakai automation untuk security, mulai dari alur manual yang jelas dulu.

Misalnya:

secret scanner menemukan key
notifikasi masuk ke channel security
ticket dibuat otomatis
incident owner ditentukan
key di-revoke
key baru dibuat
service dicek ulang
log akses ditinjau
postmortem dicatat

Kalau alur ini belum jelas secara manual, automation hanya mempercepat kebingungan.

Penutup

Kasus CISA menunjukkan bahwa bahkan organisasi yang tugasnya membantu melindungi sistem nasional pun bisa tidak siap pada bagian operasional incident response.

Ini bukan alasan untuk sinis. Ini pengingat bahwa kesiapan security bukan hanya soal tool, jabatan, atau nama besar organisasi.

Kesiapan muncul dari hal yang lebih membosankan: playbook, channel laporan, pemilik sistem, akses yang dibatasi, credential yang bisa diganti cepat, dan kebiasaan membuat postmortem.

Bisnis tidak perlu menunggu menjadi besar untuk menyiapkan hal ini. Justru saat sistem masih sederhana, playbook lebih mudah dibuat.

Sebelum menambah dashboard security baru, cek dulu satu pertanyaan sederhana: kalau ada credential bocor hari ini, apakah tim Anda tahu siapa yang harus bergerak dalam 30 menit pertama?

Kalau jawabannya belum jelas, mulai dari sana.

Dapatkan Audit Teknis Gratis untuk meninjau kesiapan website, akses, integrasi, dan alur incident response sebelum masalah kecil berubah menjadi krisis operasional.

Sumber referensi berita: TechCrunch