Belajar Cloud Security Engineer - Cloud Threat Detection & Monitoring

#Pendahuluan

Setelah di episode 7 kita membangun CSPM — mesin yang mengawasi postur (konfigurasi statis) — ada kelas ancaman lain yang tidak terlihat dari konfigurasi: perilaku. Kredensial yang dicuri dipakai pada jam 3 pagi, role yang diasumsikan dari ASN asing, instance yang tiba-tiba mining crypto. Mengawasi perilaku inilah tugas threat detection.

Mengapa episode ini penting? Karena rata-rata waktu untuk menyadari adanya breach masih dihitung mingguan, bukan menit. Selisih antara deteksi hari-0 dan hari-30 adalah selisih antara satu insiden kecil dan headline berita. Sebagai Cloud Security Engineer, sistem deteksi adalah produk utama kalian.

#Lapisan Log yang Wajib Ada

Deteksi hanya sebaik sumber datanya. Empat lapisan minimum di AWS:

Prinsip penting: management events adalah non-negotiable — tanpa itu, insiden tidak bisa direkonstruksi sama sekali.

#Org Trail dan Akun Logging Terpusat

Log di akun yang sama dengan workload adalah masalah: penyerang yang menguasai akun bisa mematikan lognya sendiri. Pola yang benar: organizational trail yang ditujukan ke bucket di akun logging terpisah, dengan Object Lock (WORM) agar log tidak bisa dihapus bahkan oleh admin akun asal.

aws cloudtrail create-trail \
  --name org-trail \
  --bucket-name acme-security-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation
aws cloudtrail start-logging --name org-trail

Di akun logging, kunci bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSCloudTrailWrite",
      "Effect": "Allow",
      "Principal": {"Service": "cloudtrail.amazonaws.com"},
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::acme-security-logs/AWSLogs/*",
      "Condition": {"StringEquals": {"s3:x-amz-acl": "bucket-owner-full-control"}}
    },
    {
      "Sid": "NoDeleteForAnyone",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:DeleteObject", "s3:PutBucketPolicy"],
      "Resource": ["arn:aws:s3:::acme-security-logs/*"]
    }
  ]
}

Pola serupa berlaku di GCP (log sink ke project terpisah) dan Azure (Diagnostic Settings → Log Analytics workspace dedikasi).

#GuardDuty: Managed Detection

GuardDuty menganalisis CloudTrail, Flow Logs, dan DNS logs dengan machine learning + intel threat feed, lalu menghasilkan finding siap-pakai: crypto mining, credential exfiltration, reconnaissance IAM, EC2 malicious IP. Untuk tim kecil-menengah, ini ROI tertinggi di security cloud — aktifkan di level organization:

aws guardduty create-detector --enable --features '[
  {"Name":"S3_DATA_EVENTS","Status":"ENABLED"},
  {"Name":"EKS_AUDIT_LOGS","Status":"ENABLED"},
  {"Name":"RDS_LOGIN_EVENTS","Status":"ENABLED"}
]'

Finding GuardDuty formatnya standar (OCSF), sehingga mudah dikirim ke SIEM atau EventBridge untuk otomasi. Jangan lupa: GuardDuty mendeteksi, bukan mencegah — ia butuh jalur respons (episode 9).

#Integrasi SIEM

Kapan butuh SIEM eksternal? Ketika kalian perlu korelasi lintas sumber (cloud + on-prem + aplikasi), retensi panjang murah, atau tim SOC sudah bekerja di sana. Pilihan umum:

• Cloud native: Amazon Security Lake / OpenSearch, Microsoft Sentinel (Azure).
• Vendor: Splunk, Elastic, Chronicle.
• Open source: Wazuh, Graylog untuk kasus ringan.

Aturan arsitektur: raw logs tetap di cloud storage murah (S3 + Object Lock); SIEM mengindeks salinan untuk pencarian cepat. Dengan begitu biaya SIEM tidak meledak oleh volume Flow Logs, tetapi evidence forensik tetap lengkap.

#Detection Rule Pertama dengan Athena

Mari tulis deteksi klasik: konsol login sukses tanpa MFA — sinyal kuat sesi dicuri atau MFA dimatikan diam-diam.

Aktifkan dulu integrasi CloudTrail → Athena (via Glue table), lalu:

SELECT
  eventtime,
  useridentity.username AS who,
  sourceipaddress AS from_ip
FROM cloudtrail_logs_org_trail
WHERE eventname = 'ConsoleLogin'
  AND eventtime >= date_add('day', -1, now())
  AND json_extract_scalar(additionaleventdata, '$.MFAUsed') = 'No'
ORDER BY eventtime DESC;

Jika tabel belum ada, buat via konsol "Create Athena table" dari trail, atau gunakan IaC. Jadikan query ini scheduled (EventBridge Scheduler → Athena → SNS saat ada hasil) dan kalian punya detection rule produksi pertama — tanpa SIEM sekalipun.

#Desain Alert yang Tidak Melukai Tim

Detection yang buruk lebih merusak daripada tidak ada deteksi: alert fatigue membuat tim mati rasa. Prinsip desainnya:

1. Setiap alert harus actionable — ada langkah respons jelas; kalau tidak, turunkan jadi log/dashboards.
2. Prioritas = eksposur × kepastian — login anomali dari negara baru (kepastian rendah) ≠ RootLogin sukses (kepastian tinggi, prioritas maksimum).
3. Ukur noise ratio mingguan — jika lebih dari separuh alert ternyata benign, tuning threshold atau tambahkan konteks (baseline per-user).
4. Tutup loop — alert masuk tiket, tiket punya owner dan SLA; deteksi tanpa respons hanyalah dekorasi.

#Penutup

Inti yang harus dibawa pulang:

• Deteksi dibangun di atas empat lapisan data: CloudTrail (management wajib, data selektif), Flow Logs, DNS logs.
• Sentralkan log ke akun logging terpisah dengan WORM — log yang bisa dimatikan penyerang bukan kontrol.
• GuardDuty memberi managed detection ROI tertinggi; aktifkan organization-wide.
• Detection rule pertama bisa dibuat dengan Athena saja: console login tanpa MFA.
• Alert harus actionable dan diukur noise ratio-nya — kualitas deteksi dinilai dari respons, bukan jumlah alarm.

Di episode 9 selanjutnya kita latih momen paling kritis: cloud incident response — siklus IR, forensik snapshot tanpa merusak evidence, containment identitas, dan walkthrough skenario kredensial bocor. Sampai jumpa!