Belajar Cloud Security Engineer - Detection Engineering Cloud

#Pendahuluan

Episode 8 memberi kalian detection rules pertama — satu query Athena untuk console login tanpa MFA. Episode ini mengangkatnya menjadi disiplin engineering penuh: detection-as-code — aturan deteksi yang ditulis, ditest, direview, dideploy lewat pipeline, dan diukur efektivitasnya persis seperti software produksi.

Mengapa penting? Karena quality deteksi menentukan segalanya di fase response: alert palsu membunuh perhatian tim, alert bolong membunuh organisasi. Tim SOC yang baik tidak "punya banyak rule" — mereka punya portfolio rule yang setiap anggotanya diketahui tujuan, coverage, dan tingkat kebisingannya.

#Sigma: Bahasa Universal Deteksi

Sigma adalah format YAML terbuka untuk deskripsi deteksi — tulis sekali, convert ke query engine mana pun (Athena, Splunk SPL, Sentinel KQL, Elastic). Struktur rule-nya:

title: Console Login Tanpa MFA
id: 7f5c2b1e-9d44-4a11-a0f3-console-nomfa
status: stable
description: >
  Login konsol berhasil tanpa MFA - indikasi sesi dicuri atau MFA
  dinonaktifkan diam-diam. MITRE ATT&CK: T1078 Valid Accounts.
logsource:
  product: aws
  service: cloudtrail
detection:
  selection_event:
    eventName: ConsoleLogin
  selection_mfa:
    additionalEventData.MFAUsed: 'No'
  condition: selection_event and selection_mfa
falsepositives:
  - Akun break-glass dengan pengecualian CA (verifikasi tiket)
level: high
tags:
  - attack.t1078
  - attack.persistence

Perhatikan nilai engineering-nya: id stabil untuk tracking, description menjelaskan kenapa rule ada, falsepositives mendokumentasikan noise yang diketahui, tags memetakan ATT&CK. Metadata inilah yang membedakan portfolio deteksi dari tumpukan regex.

Konversi ke engine target:

pip install sigma-cli pySigma-backend-athena
sigma convert -t sql -p athena \
  rules/cloud/suspicious_console_login.yaml > detections/console_login_nomfa.sql

Repo kalian kini memiliki satu sumber kebenaran rule, dengan output per-platform digenerate — bukan disalin manual dan cepat divergen.

#Pipeline Detection-as-Code

Struktur repo standar:

detections-repo/
├── rules/            # Sigma sources (satu file per rule)
├── tests/
│   ├── fixtures/     # log sampel positif & negatif per rule
│   └── test_rules.py # unit test: rule match positif, lolos negatif
├── generated/        # hasil konversi per backend (CI generate)
└── .github/workflows/deploy.yml

Unit test rule dengan fixture log — pola paling sederhana namun paling efektif mencegah rule rusak saat schema log berubah:

tests/test_console_login.py

import json, subprocess
 
def run_rule(log_line):
    with open("/tmp/log.json", "w") as f:
        f.write(json.dumps(log_line))
    return subprocess.run(
        ["sigma", "check", "--file", "/tmp/log.json",
         "rules/cloud/suspicious_console_login.yaml"],
        capture_output=True,
    ).returncode
 
def test_matches_login_without_mfa():
    assert run_rule({"eventName": "ConsoleLogin",
                     "additionalEventData": {"MFAUsed": "No"}}) == 0
 
def test_ignores_login_with_mfa():
    assert run_rule({"eventName": "ConsoleLogin",
                     "additionalEventData": {"MFAUsed": "Yes"}}) != 0

CI pipeline: lint Sigma → unit test fixtures → regenerate queries → deploy ke engine (Athena named query / Sentinel AR) → catat versi. Rule yang gagal test tidak pernah sampai produksi — sama seperti kode aplikasi.

#Validasi Purple Team

Rule yang lolos unit test tetap harus divalidasi end-to-end: apakah teknik nyata menghasilkan log nyata yang memicu alert nyata? Siklusnya:

Contoh sesi validasi:

stratus detonate aws.persistence.iam_create_admin_user
# tunggu pipeline log -> Athena -> scheduled query -> SNS
# ukur: apakah alert datang? berapa menit? field mana yang cocok?

Catat hasilnya dalam matriks coverage: teknik ATT&CK cloud × status (covered/gap/noise). Matriks ini adalah bahasa manajerial untuk "seberapa baik kita mendeteksi" — jauh lebih informatif daripada jumlah rule.

#Threat Hunting Berhipotesis

Hunting ≠ mencari acak. Metode hipotesis-dorong (hypothesis-driven):

1. Hipotesis: "Penyerang dengan kredensial role akan menghindari CloudTrail management events dengan bekerja lewat data-plane saja."
2. Sumber data: S3 server access logs + data events (yang jarang dikueri).
3. Query eksplorasi:

SELECT requester, key, count(*) AS hits
FROM s3_access_logs
WHERE key LIKE '%restricted/%'
  AND date_day BETWEEN '2026-08-01' AND '2026-08-15'
GROUP BY requester, key
ORDER BY hits DESC LIMIT 50;

4. Hasil: temuan → jadi rule baru (promote hunt to detection) atau didokumentasikan benign baseline.

Prinsip penting: hasil kosong tetap bernilai — ia jadi baseline ("role X memang mengakses folder Y tiap Senin") yang membuat alert masa depan lebih presisi. Simpan notebook hunting di repo bersama rule.

#Tuning False Positive Secara Metodis

Cara salah: matikan rule yang berisik. Cara benar:

1. Kuantifikasi: hitung alert/rule/minggu dan rasio benign.
2. Klasifikasi penyebab: baseline normal belum tercakup? Field log salah? Threshold terlalu sensitif?
3. Perbaiki di tempat tepat: tambahkan kondisi pengecualian eksplisit (misal principal break-glass + verifikasi tiket), bukan menaikkan level severity.
4. Ukur ulang: target industri sehat ± noise rate di bawah 20% per rule aktif.

Setiap perubahan tuning lewat PR juga — dengan alasan tertulis. Enam bulan kemudian, tim baru bisa membaca kenapa rule berbentuk sekarang tanpa archaeology Slack.

#Penutup

Inti yang harus dibawa pulang:

• Detection-as-code: Sigma sebagai sumber, konversi otomatis ke engine, CI dengan fixture test.
• Metadata rule (id, description, falsepositives, ATT&CK tags) adalah aset — bukan formalitas.
• Purple team dengan Stratus Red Team memvalidasi rantai penuh: teknik → log → alert → waktu.
• Hunting berhipotesis menghasilkan rule baru atau baseline; keduanya bernilai.
• Tuning metodis lewat PR menjaga portfolio sehat; ukur noise ratio per-rule.

Di episode 25 selanjutnya kita naik ke level desain: cloud security architecture review — framework Well-Architected, pattern landing zone, guardrail design, dan cara menemukan gap arsitektur sebelum jadi insiden. Sampai jumpa!