Belajar Cloud Security Engineer - Cloud Incident Response

#Pendahuluan

Setelah di episode 8 kita membangun deteksi — CloudTrail, GuardDuty, dan detection rules pertama — pertanyaannya bergeser: ketika alarm benar-benar bunyi, apa yang kalian lakukan dalam lima belas menit pertama? Insiden bukan soal jika, melainkan kapan; yang membedakan organisasi dewasa dari yang tidak adalah kecepatan dan keteraturan responsnya.

Mengapa IR di cloud berbeda dari IR tradisional? Karena infrastrukturnya elastis dan ephemeral: instance bisa hilang dalam autoscaling, log bisa berputar, dan penyerang bisa meluncurkan resource baru dengan kartu kredit kalian. Sebaliknya, cloud juga memberi senjata forensik yang dulu mahal: snapshot instan, log immutable, dan isolasi jaringan sekali klik.

#Siklus IR Cloud

Enam fase NIST yang diadaptasi untuk cloud:

Fokus episode ini pada tiga fase yang menentukan hasil: prepare (yang dilakukan sebelum insiden — playbook, izin break-glass, log terpusat), contain (menghentikan pendarahan tanpa menghapus evidence), dan recover (kembali normal tanpa membawa penyerang).

#Prinsip Forensik Cloud

Aturan nomor satu: jangan pernah terminate atau reboot instance yang terkompromi sebelum snapshot. Memory hilang saat stop, disk hilang saat terminate, dan dengan itu hilang pula bukti utama.

Urutan aman untuk workload EC2 yang dicurigai:

1. Snapshot EBS volume — cepat, point-in-time, konsisten cukup untuk analisis file system.
2. Isolasi jaringan — ganti SG menjadi quarantine (deny all).
3. Tag sebagai quarantine marker — agar autoscaling tidak mengganti instance terisolasi dan orang lain tidak menyentuhnya.
4. Baru kemudian investigasi offline dari salinan snapshot.

# 1. snapshot semua volume instance terkompromi
VOL_IDS=$(aws ec2 describe-volumes \
  --filters Name=attachment.instance-id,Values=i-0deadbeef \
  --query 'Volumes[].VolumeId' --output text)
for v in $VOL_IDS; do
  aws ec2 create-snapshot \
    --volume-id "$v" \
    --description "IR-20260816-i-0deadbeef" \
    --tag-specifications 'ResourceType=snapshot,Tags=[{Key=ir-case,Value=IR-20260816}]'
done
 
# 2. ganti security group ke quarantine (tanpa ingress/egress)
aws ec2 modify-instance-attribute \
  --instance-id i-0deadbeef \
  --groups sg-quarantine-all

SG sg-quarantine-all dibuat sebelumnya tanpa satu pun aturan — persiapkan sekarang, di tiap VPC produksi. Untuk capture memory (bila diperlukan analisis malware mendalam) gunakan tool acquisition khusus sebelum instance disentuh lebih jauh; snapshot disk tidak menyimpan RAM.

#Containment Identitas

Mayoritas insiden cloud adalah insiden identitas. Playbook containment per jenis kredensial:

Teknik mematikan semua token lama sebuah role seketika:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "DateLessThan": {"aws:TokenIssueTime": "2026-08-16T02:00:00Z"}
    }
  }]
}

Semua sesi yang diterbitkan sebelum waktu temuan langsung mati; sesi baru (workload normal) tetap jalan setelah policy dilepas. Simpan template ini di repo playbook — saat panik, kalian ingin copy-paste, bukan menulis JSON dari ingatan.

#Walkthrough: Access Key Bocor di GitHub

Skenario paling umum di industri — mari jalankan end-to-end.

Deteksi: GitHub secret scanning atau GuardDuty CredentialAccess menemukan pemakaian access key dari ASN asing.

Konfirmasi (menit 0-5): cari jejak pemakaian key tersebut:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
  --start-time 2026-08-15T00:00:00Z \
  --max-results 50 \
  --query 'Events[].{t:EventTime,e:EventName,ip:Username}'

Contain (menit 5-10):

aws iam update-access-key \
  --access-key-id AKIAIOSFODNN7EXAMPLE \
  --status Inactive --user-name ci-deployer

Assess (menit 10-30): jawab tiga pertanyaan dari log — apa yang sudah dilakukan penyerang (RunInstances? CreateAccessKey? GetSecretValue?), sampai mana blast radius, dan apakah ada persistence (key baru, role baru, resource baru di region eksotis).

Eradicate & recover: hapus persistence, rotasi semua secret yang bisa dibaca key itu, commit fix ke repo agar secret tidak ter-commit lagi (pre-commit hook gitleaks — episode 14), lalu aktifkan kembali key baru.

Lessons learned: tulis post-mortem blameless dengan timeline, root cause (secret statis di CI), dan action item permanen: migrasi CI ke OIDC federation sehingga class of problem ini hilang total.

#Break-Glass Access

Satu celah berbahaya dari hardening ketat: saat insiden, tidak ada yang punya izin darurat. Solusinya break-glass role: role admin tertutup SCP, hanya bisa diasumsikan setelah MFA kedua + approval dua orang, dan setiap pemakaiannya memicu alert otomatis. Uji jalurnya berkala — pintu darurat yang tidak pernah dites akan macet tepat saat dibutuhkan.

#Penutup

Inti yang harus dibawa pulang:

• IR cloud = prepare, detect, contain, eradicate, recover, learn — investasi terbesar ada di prepare.
• Forensik: snapshot dulu, isolasi lewat SG quarantine, jangan pernah terminate sebelum evidence aman.
• Containment identitas punya teknik spesifik: deactivate key, kill-switch TokenIssueTime, perketat trust policy.
• Latihan game day mengubah playbook dari dokumen menjadi kapabilitas nyata.

Di episode 10 selanjutnya kita naik ke lapisan organisasi: cloud compliance & frameworks — NIST, ISO 27001, SOC 2 di cloud, cara memetakan kontrol teknis ke requirement framework, dan otomatisasi audit evidence. Sampai jumpa!