Incident Response untuk Developer — Security

Incident Response untuk Developer Meskipun kita berusaha mencegah, insiden keamanan tetap bisa terjadi. Yang membedakan tim yang profesional adalah seberapa…

Incident response adalah apa yang tim lakukan sejak insiden keamanan ketahuan sampai sistem aman lagi dan pelajarannya tercatat. Bayangin dapur kebakaran. Kamu gak nyari penyebabnya sambil api masih nyala: matikan gas dan padamkan dulu, foto kerusakannya buat asuransi sebelum dibersihkan, baru bersihkan, pakai dapurnya lagi, lalu cari tahu kenapa bisa kebakaran. Dan APAR serta nomor darurat harus sudah ada sebelum apinya muncul.

🧪 Tebakan cepat: kunci API produksi ketahuan bocor di repo GitHub publik. Mana yang duluan: hapus file .env dari repo, atau rotate kuncinya? Tebak dulu, jawabannya ada di bagian "Studi kasus: secret bocor di repo publik".

Empat fase menurut NIST

Panduan NIST SP 800-61 membagi incident response jadi empat fase:

Fase	Isinya	Di dapur
1. Preparation	runbook, daftar kontak, backup, logging, latihan	APAR dan nomor darurat
2. Detection & Analysis	alert masuk, pastikan nyata, ukur seberapa luas	sadar ada asap, cek dari mana
3. Containment, Eradication & Recovery	batasi dampak, buang penyebabnya, pulihkan	padamkan, bersihkan, masak lagi
4. Post-Incident Activity	post-mortem, lessons learned, perbaiki proses	kenapa kompornya bocor?

Banyak tim memecah fase 3 jadi tiga langkah sendiri, jadi kamu juga akan ketemu versi enam langkah: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. Isinya sama, cuma dipecah lebih halus.

Containment = menghentikan kerusakan biar gak meluas: rotate kunci, cabut token, isolasi server dari jaringan.
Eradication = membuang akar masalahnya: hapus secret dari repo, tambal bug, hapus akun backdoor.
Recovery = kembali normal dengan aman: deploy ulang, restore dari backup bersih, pantau ketat.

Begitu insiden terkonfirmasi, langkah pertama selalu containment. Akar masalah dicari setelah kerusakannya berhenti.

Studi kasus: secret bocor di repo publik

Ini skenario yang sama dengan Lab. Toko online TokoKita. Jam 09.12 seorang developer gak sengaja nge-push file .env ke repo publik. Jam 09.40 alert masuk: secret scanning GitHub menemukan kunci pembayaran, dan log (ingat pelajaran Security Logging & Monitoring) menunjukkan kunci itu dipakai dari IP asing, sekitar 40 request per menit.

Jam	Fase	Tindakan
09.40	Detection	alert masuk
09.45	Analysis	triage: buka commit-nya, ternyata `.env` berisi `PAYMENT_SECRET_KEY` dan `DB_PASSWORD`
09.50	Containment	rotate kedua secret: bikin yang baru, cabut yang lama
09.55	Containment	cabut semua session dan token yang aktif
10.05	Containment	amankan bukti: salin log, snapshot server
10.35	Eradication	hapus `.env` dari history, tambah ke `.gitignore`, pasang secret scanning
10.55	Recovery	deploy ulang dengan secret baru, pantau ketat 48 jam
11.10	Komunikasi	beri tahu user dan pihak terkait
H+2	Post-Incident	post-mortem tanpa menyalahkan

Kunci lama cuma hidup 10 menit setelah alert: kira-kira 400 request penyerang, bukan ribuan.

Jadi rotate dulu, baru hapus filenya. Itu jawaban tebakannya. Menghapus .env dari repo gak mencabut apa pun: bot pemindai GitHub menyalin secret dalam hitungan menit, dan salinan itu tetap berlaku sampai kuncinya dicabut di sisi penyedianya.

Bersihkan repo setelah containment:

# 1. Berhenti melacak .env dan cegah ke-commit lagi
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "Stop tracking .env"

# 2. Buang .env dari seluruh history (butuh git-filter-repo)
git filter-repo --invert-paths --path .env
git remote add origin [email protected]:tokokita/toko.git
git push origin --force --all

git rm --cached .env menghapus file dari repo tapi file di laptopmu tetap ada.
echo ".env" >> .gitignore bikin Git mengabaikannya mulai sekarang (pelajaran Environment Variables & Secrets).
git filter-repo --invert-paths --path .env menulis ulang history tanpa file itu. Ini cuma bersih-bersih: kunci yang sudah tersalin tetap harus di-rotate.
git remote add origin ... perlu karena filter-repo sengaja melepas remote origin setelah menulis ulang history.
git push origin --force --all mengganti history di remote. Semua anggota tim perlu clone ulang.

Jangan langsung matikan server

Refleks pertama banyak orang: cabut kabelnya. Masalahnya, mematikan server menghilangkan bukti forensik yang cuma ada di RAM: proses yang sedang jalan, koneksi jaringan yang terbuka, program penyerang yang gak pernah ditulis ke disk. Bukti itu yang menjawab "apa saja yang sudah diakses?".

Lakukan ini sebagai gantinya:

Isolasi server dari jaringan (firewall, security group), jangan dimatikan.
Amankan bukti: snapshot disk dan memory, salin log ke tempat lain.
Baru setelah itu bersihkan, ganti, atau matikan.

Di kasus TokoKita, mematikan server bahkan gak menolong: penyerang memakai kunci pembayaran langsung ke API payment provider, bukan lewat server kita.

Runbook, pemberitahuan, dan post-mortem

Runbook adalah resep tertulis untuk skenario umum (secret bocor, akun admin dibobol, DDoS): siapa dihubungi, perintah apa dijalankan, urutannya. Ditulis saat Preparation, diuji lewat latihan tabletop (simulasi di atas meja).
Catat semuanya saat kejadian: jam, tindakan, siapa. Catatan ini jadi timeline post-mortem.
Pemberitahuan: kalau data pribadi user mungkin ikut terakses, UU PDP (UU No. 27 Tahun 2022) mewajibkan pemberitahuan tertulis ke user dan lembaga pengawas paling lambat 3 x 24 jam (di Eropa, GDPR juga memberi 72 jam untuk lapor ke otoritas pengawas). Beri tahu setelah kamu tahu data apa yang kena, biar pesannya jelas.
Post-mortem blameless: yang dicari proses yang bolong ("kenapa .env bisa ter-commit tanpa ada yang mencegah?"), bukan orang yang disalahkan. Hasilnya tindakan nyata: pre-commit hook, secret scanning di CI, runbook yang diperbarui.

⚠️ Jebakan yang sering ketemu

Hapus file, lupa rotate. File yang dihapus dari repo gak mencabut kunci. Rotate dulu, bersihkan history sesudahnya.
Rotate tanpa triage. Kamu ganti kunci pembayaran, tapi DB_PASSWORD di file yang sama masih berlaku. Lima menit melihat commit-nya menghemat insiden kedua.
Mematikan server atau deploy ulang sebelum bukti diamankan. Server baru menggantikan yang lama, dan jejak penyerang ikut hilang.
Post-mortem mencari kambing hitam. Orang jadi menyembunyikan kesalahan, dan insiden berikutnya ketahuan lebih lambat.

TL;DR: Incident response menurut NIST punya empat fase: Preparation, Detection & Analysis, Containment, Eradication & Recovery, lalu Post-Incident Activity. Setelah insiden terkonfirmasi, langkah pertama adalah containment: hentikan kerusakannya dulu (rotate secret, cabut session, isolasi server), baru buang penyebabnya dan pulihkan. Secret bocor? Rotate dulu, hapus dari history kemudian. Jangan langsung matikan server karena bukti forensik di RAM hilang; isolasi dan amankan bukti dulu. Beri tahu user paling lambat 3 x 24 jam kalau data pribadi terdampak, dan tutup dengan post-mortem tanpa menyalahkan.