Incident Response Tidak Seharusnya Dibangun Saat Insiden Berjalan

The Core Update

CISA, badan cybersecurity Amerika Serikat yang bertugas membantu menjaga jaringan federal dan infrastruktur penting, mengungkapkan bahwa mereka belum memiliki response plan yang siap ketika sebuah insiden keamanan terjadi pada Mei lalu.

Insiden ini bermula ketika seorang reporter investigatif memberi tahu CISA bahwa kontraktor agensi tersebut telah mengekspos key dan credential sensitif secara publik. Credential itu disebut dapat digunakan untuk mengakses sistem pemerintah Amerika Serikat.

Dalam laporan postmortem, CISA mengatakan timnya harus menghabiskan waktu untuk membangun playbook pada tahap awal insiden. Dengan kata lain, sebagian energi respons tidak langsung dipakai untuk menutup risiko, tetapi untuk menyusun cara merespons risiko itu sendiri.

Menurut laporan dari Brian Krebs, credential tersebut tersimpan di repository GitHub yang dapat diakses publik. Seorang security researcher dari GitGuardian sebelumnya mencoba menghubungi kontraktor terkait, tetapi tidak mendapatkan respons. Setelah Krebs menghubungi CISA, repository akhirnya diturunkan, credential dicabut, dan credential baru diterbitkan.

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

Namun ada catatan yang lebih penting dari sekadar apakah data sempat disalahgunakan atau tidak: jalur pelaporan dari security researcher ke CISA ternyata belum cukup jelas. CISA menyebut kanal tersebut sebelumnya tidak well defined, lalu melakukan perubahan agar researcher bisa menghubungi agensi dengan lebih mudah dan cepat.

The Reality Check

Banyak organisasi ingin terlihat siap menghadapi insiden keamanan karena sudah punya tool monitoring, cloud security, password manager, secret scanner, atau dashboard compliance.

Tool seperti itu memang penting.

Tetapi insiden CISA mengingatkan satu hal yang sering kurang nyaman dibahas: kesiapan keamanan bukan hanya soal punya alat. Kesiapan keamanan juga soal tahu siapa melakukan apa, kapan, lewat jalur mana, dan dengan prioritas apa ketika sesuatu benar-benar terjadi.

Credential yang bocor adalah masalah teknis. Tetapi respons terhadap credential yang bocor adalah masalah operasional.

Kalau organisasi belum punya playbook, tim akan kehilangan waktu untuk menjawab pertanyaan dasar saat tekanan sedang tinggi:

• siapa yang menerima laporan pertama?
• siapa yang memvalidasi temuan?
• siapa yang berwenang menurunkan repository atau akses publik?
• siapa yang mencabut credential?
• siapa yang menerbitkan credential baru?
• siapa yang mengecek log penggunaan?
• siapa yang memberi update ke leadership, vendor, client, atau regulator?
• kapan insiden dianggap terkendali?

Pertanyaan seperti ini terdengar sederhana ketika dibaca dalam kondisi tenang. Tetapi dalam insiden nyata, setiap menit bisa berubah menjadi risiko tambahan.

Masalahnya bukan karena tim tidak mampu. Sering kali tim mampu, tetapi sistem kerja belum memberi mereka jalur yang jelas.

Ini mirip dengan banyak masalah operasional bisnis lain. Saat volume kecil dan risiko rendah, semua bisa diselesaikan lewat chat, ingatan, dan inisiatif personal. Begitu insiden besar terjadi, pola informal mulai retak.

Orang yang tahu akses sedang cuti. Vendor tidak merespons. Repository harus diturunkan, tetapi siapa pemiliknya tidak jelas. Credential sudah dicabut, tetapi belum semua service dikonfirmasi aman. Tim teknis sudah bekerja, tetapi tim bisnis belum tahu apa yang boleh disampaikan ke pelanggan.

Di titik itu, organisasi tidak hanya menghadapi insiden keamanan. Organisasi juga menghadapi ketidakjelasan proses.

Ada hal lain yang perlu diperhatikan: laporan awal justru datang lewat researcher dan reporter. Ini bukan hal buruk. Banyak celah keamanan memang ditemukan oleh pihak eksternal. Yang menjadi masalah adalah jika organisasi belum menyediakan pintu masuk yang jelas untuk laporan seperti itu.

Security disclosure channel bukan dekorasi. Ia adalah bagian dari sistem pertahanan.

Jika researcher tidak tahu harus melapor ke mana, laporan bisa tertunda. Jika email tidak dipantau, risiko tetap terbuka. Jika vendor tidak punya SLA respons, masalah bisa berputar tanpa pemilik. Jika tidak ada proses triage, laporan penting bisa diperlakukan seperti pesan biasa.

Banyak bisnis tidak merasa masalah ini relevan karena mereka bukan badan pemerintah atau perusahaan besar. Padahal pola risikonya sama.

Website bisnis bisa membocorkan API key. Repository internal bisa tidak sengaja menjadi public. Spreadsheet berisi data pelanggan bisa dibagikan dengan permission yang salah. Token WhatsApp, payment gateway, CRM, email marketing, atau cloud storage bisa tersebar di tempat yang tidak seharusnya.

Ketika itu terjadi, pertanyaan yang paling menentukan bukan hanya “tool apa yang mendeteksi?” tetapi “tim tahu harus melakukan apa setelah tahu?”

The Havedev Way

Dari sudut pandang Havedev, pelajaran utama dari kasus ini bukan bahwa setiap bisnis harus langsung membeli lebih banyak tool security.

Pelajaran yang lebih dasar adalah: jangan menunggu insiden untuk merancang cara menangani insiden.

Untuk banyak organisasi, playbook awal tidak perlu rumit. Ia hanya perlu cukup jelas untuk mengurangi kebingungan pada jam-jam pertama.

Mulai dari skenario yang paling mungkin dan paling berdampak:

• credential atau API key bocor
• repository tidak sengaja public
• akses admin dipakai orang yang salah
• data pelanggan terkirim ke pihak yang salah
• website terkena defacement atau malware
• payment atau form lead berhenti bekerja
• vendor melaporkan potensi kebocoran

Setelah itu, tulis alur respons yang bisa dipakai tim tanpa menunggu meeting panjang.

Untuk kasus credential bocor, misalnya, playbook sederhana bisa berisi:

• validasi credential benar-benar aktif atau tidak
• cabut atau rotate credential secepat mungkin
• cek log penggunaan sejak credential terekspos
• identifikasi sistem yang terdampak
• ganti secret di environment yang relevan
• konfirmasi service berjalan normal setelah rotasi
• dokumentasikan timeline dan keputusan
• tentukan apakah perlu notifikasi ke pihak lain

Ini bukan dokumen untuk terlihat matang. Ini alat kerja agar tim tidak berpikir dari nol saat kondisi sedang buruk.

Hal yang sama berlaku untuk kanal pelaporan. Bisnis sebaiknya punya jalur yang jelas untuk menerima laporan keamanan, bahkan jika bentuknya sederhana.

Misalnya:

• alamat email security yang dipantau
• halaman contact dengan kategori security issue
• pemilik internal yang menerima eskalasi
• aturan respons awal dalam 24 atau 48 jam
• daftar vendor yang harus dihubungi jika sistem terkait mereka bermasalah

Untuk bisnis yang belum besar, ini mungkin terasa berlebihan. Tetapi biaya membuat jalur pelaporan yang jelas biasanya jauh lebih kecil daripada biaya kehilangan waktu saat insiden terjadi.

Website juga punya peran di sini. Banyak bisnis memperlakukan website hanya sebagai alat marketing, padahal website sering menjadi pintu masuk data, lead, integrasi, tracking script, form, file upload, dan koneksi ke layanan eksternal.

Jika website punya form, API, dashboard admin, CMS, atau integrasi pihak ketiga, maka website juga perlu dipikirkan sebagai bagian dari permukaan risiko.

Pertanyaan praktisnya:

• credential apa saja yang dipakai website?
• di mana secret disimpan?
• siapa yang bisa mengakses hosting, CMS, DNS, dan analytics?
• apakah akses lama dari mantan vendor atau karyawan sudah dicabut?
• apakah ada backup?
• siapa yang dihubungi jika website down atau dicurigai bocor?
• apakah form menyimpan data sensitif yang tidak perlu?

Tidak semua jawaban harus sempurna hari ini. Tetapi jika tidak ada yang tahu jawabannya, bisnis sedang bergantung pada keberuntungan.

Automation juga perlu dilihat dengan hati-hati. Secret scanning, alert, monitoring, dan notifikasi bisa sangat membantu. Namun automation tidak menggantikan keputusan operasional.

Alert tanpa pemilik hanya menjadi noise. Scanner tanpa proses rotasi hanya menghasilkan daftar masalah. Dashboard tanpa playbook hanya memperlihatkan bahwa sesuatu buruk sedang terjadi, tetapi tidak memberi tahu siapa yang harus bergerak.

Karena itu, urutan yang sehat biasanya bukan langsung membeli tool baru.

Mulai dari inventaris sederhana. Lalu buat playbook ringan. Lalu rapikan akses. Lalu pasang automation untuk membantu proses yang sudah jelas.

Di banyak bisnis, langkah paling berguna dalam minggu pertama bukan membangun sistem besar, tetapi menulis satu halaman incident response:

• kontak utama
• sistem kritis
• vendor penting
• jenis insiden umum
• langkah respons pertama
• aturan komunikasi
• tempat mencatat timeline

Dokumen ini tidak akan membuat bisnis kebal dari insiden. Tetapi ia membuat bisnis tidak mulai dari kosong.

Kasus CISA menunjukkan bahwa bahkan organisasi besar yang sangat dekat dengan dunia cybersecurity bisa tetap menemukan celah dalam kesiapan operasionalnya. Itu bukan alasan untuk sinis. Itu alasan untuk jujur mengecek proses sendiri.

Keamanan bukan hanya kemampuan mencegah masalah. Keamanan juga kemampuan merespons dengan tertib ketika pencegahan tidak cukup.

Sebelum menambah tool security baru, cek dulu satu hal sederhana: jika credential penting bocor hari ini, apakah tim Anda tahu siapa yang harus bergerak dalam 15 menit pertama?

Kalau jawabannya belum jelas, mulai dari sana.

Dapatkan Audit Teknis Gratis untuk meninjau risiko website, akses, integrasi, dan alur respons insiden sebelum bisnis Anda menunggu masalah terjadi lebih dulu.

---

Sumber referensi berita: TechCrunch