Belajar DevSecOps Engineer - Security Observability

#Pendahuluan

Sejauh ini kalian sudah menanam banyak kemampuan deteksi: Falco rules (ep 11), security event logging (ep 17), audit log K8s (ep 20). Episode ini menjawab pertanyaan integrasinya: bagaimana menyatukan semuanya menjadi sistem observability keamanan yang koheren — telemetry terpusat, deteksi yang dikelola sebagai kode, dan SIEM yang menerima data berkualitas.

Mengapa ini penting sekaligus sulit? Karena serangan nyata hampir selalu meninggalkan jejak di beberapa sumber sekaligus: login anomali di aplikasi, proses aneh di host, query aneh di database. Tanpa korelasi lintas-sumber, setiap jejak terlihat jinak sendiri-sendiri. Inilah alasan security observability bukan sekadar "kumpulkan log".

#Sumber Telemetry Security

Inventaris lengkap dari episode-episode sebelumnya:

Sumber	Isi	Episode
App security events	login, reset password, akses sensitif	17
Falco	syscall anomali runtime container	11
K8s audit log	API calls: siapa, aksi apa	20
Cloud audit (CloudTrail/Activity Log)	IAM changes, unusual API usage	9
WAF/edge	blocked requests, rate limit hits	17
CI/CD logs	pipeline failures, secret scan hits	3-5

Prinsip pengelolaannya satu kata: normalisasi. Setiap sumber punya format sendiri; tanpa skema konsisten (timestamp UTC, field identitas seragam, severity mapping), korelasi mustahil. Standar de facto untuk normalisasi saat ini adalah OpenTelemetry semantic conventions atau vendor schema (ECS).

#Detection-as-Code dengan Sigma

Episode 15 membentuk prinsipnya; episode ini menerapkannya pada detection. Sigma adalah format YAML terbuka untuk deskripsi rule deteksi log — "grep generic" yang bisa dikonversi ke query SIEM mana pun:

rules/suspicious-k8s-exec.yml

title: Exec ke pod produksi oleh user non-platform
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
logsource:
    product: kubernetes
    service: audit
detection:
    selection:
        verb: create
        objectRef.resource: pods/exec
        objectRef.namespace: prod
    filter_users:
        user.username|startswith: 'system:serviceaccount:platform'
    condition: selection and not filter_users
falsepositives:
    - debugging darurat oleh tim on-call (dokumentasikan di ticket)
level: high

Struktur rule Sigma memberi metadata yang berharga untuk operasi: falsepositives mendokumentasikan konteks sah, level menentukan routing alert, tags (MITRE ATT&CK) menghubungkan rule dengan framework ancaman.

#Pipeline Detection Repo

Detection dikelola persis seperti policy (episode 15):

Alur detection repo

rules/*.yml -> CI test & validasi -> convert ke format SIEM
            -> deploy ke staging index -> verifikasi firing
            -> deploy production -> dashboard coverage update

CI-nya melakukan tiga hal otomatis:

Validasi struktur (sigma check) — field wajib, UUID unik.
Test dengan fixture — sample log harus trigger / tidak trigger sesuai harapan.
Konversi & deploy (sigma convert) — ke query Elasticsearch/Splunk/Loki target.

Validasi dan konversi rule Sigma

sigma check rules/
sigma convert -t loki rules/suspicious-k8s-exec.yml

Tip

Ukur dua hal per rule: precision (berapa % alert yang true positive) dan volume (berapa alert per minggu). Rule dengan precision rendah atau volume tinggi adalah kandidat tuning — angka ini juga bahan utama rapor program deteksi kalian.

#Integrasi SIEM

SIEM (Elastic Security, Splunk, Wazuh, Grafana Loki+stack) adalah mesin korelasinya. Praktik integrasi yang sehat:

Ship semua sumber lewat collector standar (Fluent Bit/Vector/OTel Collector) — jangan agent ad-hoc per app.
Retensi bertingkat — hot 30 hari untuk investigasi, cold/archive 1-2 tahun untuk compliance (episode 16).
Korelasi lintas-sumber — contoh aturan komposit: login sukses dari IP baru + 10 menit kemudian exec pod prod + download secret = incident, bukan tiga noise terpisah.

Korelasi multi-sinyal (konsep query)

-- dalam window 15 menit, per user:
-- (login_failed >= 5 lalu login_success)
-- DAN (pods/exec create di namespace prod)
-- => raise security incident, severity critical

Aturan korelasi semacam ini adalah tempat nilai SIEM yang sesungguhnya — dan karena dikelola sebagai kode (Sigma composite / query versioned), ia ikut direview dan ditest.

#Metrik Observability Keamanan

Yang diukur menentukan yang dirawat. Tiga kelompok metrik:

Coverage — % sumber log kritis yang benar-benar masuk SIEM; % MITRE techniques yang punya rule deteksi (detection coverage matrix).
Kualitas deteksi — precision/rule, MTTD (mean time to detect) per kelas insiden.
Operasional — volume alert/hari, backlog triage, rasio auto-closed vs human-triaged.

Coverage matrix ATT&CK layak kalian lihat sekali sekarang: tabel teknik serangan × status deteksi kalian (punya rule? punya log? tertes?). Celah kolomnya adalah roadmap detection kalian.

#Penutup

Inti yang harus dibawa pulang:

Serangan nyata tersebar di banyak sumber; tanpa normalisasi + korelasi, tiap jejak terlihat jinak.
Sigma menjadikan deteksi portable dan versioned: check → test → convert → deploy di CI.
SIEM memberi nilai lewat korelasi multi-sinyal dan retensi bertingkat; ship via collector standar.
Ukur coverage, precision, dan MTTD — celah coverage matrix adalah roadmap kalian.

Di episode 25 selanjutnya kita membahas DevSecOps Maturity & Metrics — model kematangan untuk menilai posisi organisasi kalian, metrik DORA yang dipadu metrik security, cara menyusun dashboard leadership yang jujur, dan loop continuous improvement agar program ini tidak berhenti di level "sudah pasang tool". Sampai jumpa!