Context Driven Analysis

Ringkasan

Context driven analysis adalah pendekatan analisis alert yang tidak berhenti pada IOC match atau rule fired, tetapi selalu menilai alert berdasarkan konteks di sekitarnya: siapa asetnya, siapa user-nya, proses apa yang berjalan, dari mana asal koneksi, apa baseline normalnya, apa dampak bisnisnya, dan apa hubungan event tersebut dengan sinyal lain di waktu yang sama.

Dalam SOC, pendekatan ini penting karena:

• alert dengan severity tinggi belum tentu incident
• alert dengan severity sedang bisa menjadi high-risk jika konteks aset sangat kritis
• indikator yang sama bisa benign di satu environment dan malicious di environment lain
• perbedaan tugas L1, L2, dan L3 terutama terletak pada kedalaman konteks yang digunakan dan keputusan yang diambil

Tujuan akhir dari context driven analysis adalah mengurangi false positive, mempercepat triage, meningkatkan kualitas eskalasi, dan membuat keputusan containment lebih tepat.

Definisi Praktis

Secara praktis, context driven analysis berarti setiap alert dijawab dengan tiga pertanyaan inti:

1. Apa yang terjadi?
2. Dalam konteks apa ini terjadi?
3. Apa keputusan paling tepat berdasarkan gabungan sinyal dan konteks tersebut?

Tanpa konteks, analis hanya membaca event. Dengan konteks, analis memahami kejadian.

Kenapa Pendekatan Ini Penting di SOC

Masalah paling umum pada SOC yang masih event-driven murni:

• triage hanya berdasarkan nama rule atau severity bawaan vendor
• keputusan close atau escalate tidak konsisten antar shift
• handoff ke L2/L3 miskin artefak sehingga investigasi diulang dari nol
• analyst fokus pada satu log source dan kehilangan korelasi lintas endpoint, identity, email, dan network
• waktu habis untuk validasi teknis, bukan penilaian risiko

Context driven analysis memperbaiki ini dengan memaksa analyst melihat alert sebagai bagian dari sebuah cerita operasional.

Model Konteks yang Wajib Dinilai

Gunakan matriks konteks berikut saat triage atau investigasi:

Jika minimal tiga domain konteks belum diperiksa, biasanya keputusan triage masih lemah.

Pembagian Fokus SOC L1 L2 L3

Perbedaan utama bukan hanya skill teknis, tetapi kedalaman konteks:

• L1 memakai konteks untuk memilah prioritas dengan cepat
• L2 memakai konteks untuk membangun narasi investigasi end-to-end
• L3 memakai konteks untuk membuktikan mekanisme serangan dan memperbaiki sistem deteksi

Tanggung Jawab Analisis per Level

SOC L1

Tugas context-driven L1:

• validasi apakah event benar-benar terjadi atau artefak parser/noise
• cek asset criticality dan user sensitivity
• cek apakah ada sinyal pendukung dari log source lain
• bandingkan dengan aktivitas yang normal atau sudah diketahui benign
• klasifikasikan cepat menjadi benign, needs monitoring, atau escalate

Checklist minimum L1:

1. Apakah host/user termasuk crown jewel atau privileged?
2. Apakah ada parent process, source IP, atau login context yang aneh?
3. Apakah alert berulang pada host lain atau hanya satu titik?
4. Apakah ada change ticket, maintenance, atau aktivitas admin resmi?
5. Apakah ada indikator yang membuat blast radius berpotensi membesar?

L1 tidak harus membuktikan root cause penuh. L1 harus memastikan eskalasi tidak kosong konteks.

SOC L2

Tugas context-driven L2:

• menyusun timeline kejadian
• mengkorelasikan endpoint, identity, network, email, dan cloud jika relevan
• melakukan scoping host/user/account tambahan yang terlibat
• menilai intent, persistence, privilege escalation, lateral movement, dan exfiltration risk
• memberi rekomendasi containment yang proporsional terhadap dampak bisnis

Checklist minimum L2:

1. Apa initial trigger dan apa event yang mendahului atau mengikuti?
2. Apa process tree atau authentication chain lengkapnya?
3. Teknik ATT&CK apa yang benar-benar terkonfirmasi versus baru indikatif?
4. Berapa aset/akun yang sudah terpapar?
5. Kontrol apa yang berhasil memblokir dan mana yang gagal?

L2 harus bisa mengubah alert menjadi incident narrative yang bisa ditindaklanjuti.

SOC L3

Tugas context-driven L3:

• melakukan deep-dive teknis pada tradecraft atau malware behavior
• melakukan hypothesis testing untuk event yang ambigu atau evasive
• mencari gap pada rule logic, telemetry coverage, parser, dan enrichment
• menjalankan hunt retrospektif berdasarkan teknik yang ditemukan
• mengubah hasil incident menjadi detection engineering improvement

Checklist minimum L3:

1. Apa mekanisme teknis serangan yang sebenarnya?
2. Sinyal apa yang terlewat pada tahap sebelumnya?
3. Apakah ada telemetry blind spot, field mapping salah, atau threshold keliru?
4. Bagaimana mendeteksi teknik yang sama lebih awal di masa depan?
5. Apakah perlu rule baru, tuning, suppression, atau use case baru?

L3 fokus pada certainty, prevention of recurrence, dan peningkatan kapabilitas SOC.

Workflow Context Driven Analysis

1. Trigger

Alert masuk dari SIEM, EDR, NDR, email security, IAM, atau cloud detection.

Yang dibaca pertama bukan hanya severity, tetapi:

• alert source
• detection logic singkat
• entity utama: host, user, IP, process, mailbox, workload
• timestamp dan frequency

2. Rapid Context Pull

Tarik konteks cepat dalam 2-5 menit pertama:

• criticality aset
• privilege user
• geolokasi/source IP context
• process lineage atau auth flow
• apakah ada alert lain yang berdekatan waktunya

Jika konteks cepat sudah menunjukkan aktivitas normal, L1 bisa close dengan evidence yang cukup. Jika tidak, lanjut.

3. Hypothesis Framing

Buat 2-3 hipotesis sederhana, misalnya:

• admin activity yang valid
• automation/service behavior
• malicious execution atau account misuse

Tujuannya agar analyst tidak bias pada satu narasi terlalu awal.

4. Correlation

Korelasikan antar data source:

• endpoint: process, file, registry, module load
• identity: login, MFA, token, role change
• network: DNS, proxy, firewall, east-west traffic
• email: sender, URL click, attachment, mailbox rule
• cloud: console login, API call, role assumption, access key use

Semakin kritikal alert, semakin wajib korelasi lintas sumber.

5. Decision

Ambil salah satu hasil berikut:

• false positive atau benign true positive
• suspicious but unconfirmed
• confirmed malicious
• needs containment now
• needs deeper engineering analysis

Keputusan harus selalu menyebut why, bukan hanya label.

6. Handoff atau Closure

Jika close, catat konteks yang membenarkan closure.

Jika escalate, serahkan paket handoff yang lengkap:

• ringkasan singkat kejadian
• entitas terdampak
• timeline utama
• artefak kunci
• hipotesis yang sudah diuji
• gap atau unknowns
• rekomendasi next step

Decision Matrix Cepat

Analisis per Skenario

Skenario 1: Suspicious PowerShell di Windows Server

Alert awal:

• powershell.exe -enc ...
• host adalah application server produksi
• user yang menjalankan adalah service account

Context questions:

1. Apakah service account ini normal menjalankan PowerShell?
2. Parent process-nya apa? w3wp.exe, cmd.exe, services.exe, atau task scheduler?
3. Apakah command line terkait deployment script yang known-good?
4. Ada koneksi network outbound setelah execution?
5. Apakah hash/script block terkait IOC atau TTP berisiko?

Per level:

• L1: validasi host criticality, parent process, user context, frequency, existing change
• L2: susun process tree, cek lateral movement, persistence, network callback, file drop
• L3: decode payload, map ATT&CK, identifikasi exploit path atau LOLBin abuse, improve detection

Contoh disposition:

• jika w3wp.exe -> powershell.exe -enc tanpa maintenance window pada server produksi, treat as high-risk sampai terbukti sebaliknya

Skenario 2: Impossible Travel pada Akun M365

Alert awal:

• user login dari Indonesia dan 12 menit kemudian dari Jerman

Context questions:

1. Apakah salah satu IP milik VPN perusahaan?
2. Apakah device ID, user agent, atau session token sama?
3. Apakah ada MFA success, MFA fatigue, atau legacy auth?
4. Apakah setelah login ada mailbox rule creation, OAuth consent, atau download spike?
5. Apakah user termasuk finance, exec, atau admin?

Per level:

• L1: cek VPN/proxy exception, user criticality, alert tetangga lain
• L2: cek sign-in logs lengkap, token replay possibility, mailbox activity, risky user events
• L3: telusuri conditional access gap, identity protection tuning, detection correlation improvement

Catatan penting:

• impossible travel tanpa konteks VPN sering menjadi noisy alert
• impossible travel plus mailbox rule plus abnormal download adalah escalation yang jauh lebih kuat

Skenario 3: AWS IAM Activity Anomali

Alert awal:

• CreateAccessKey dilakukan terhadap user yang jarang dipakai

Context questions:

1. Siapa actor-nya, via console atau API?
2. Source IP internal, VPN, atau ASN asing?
3. Apakah user ini human account atau automation?
4. Apa event sebelum dan sesudahnya: ListUsers, AttachUserPolicy, AssumeRole, GetCallerIdentity?
5. Apakah account ini punya akses ke data sensitif atau production?

Per level:

• L1: tandai high-risk jika account privileged atau dormant
• L2: bangun timeline CloudTrail, cek role assumption chain, policy changes, region spread
• L3: telusuri misuse pattern, access path, dan tambahkan detection sequence untuk IAM abuse

Context Enrichment yang Paling Bernilai

Urutan enrichment dengan nilai praktis tertinggi:

1. Asset criticality
2. Account privilege level
3. Parent-child process atau auth chain
4. Nearby alerts dalam rentang waktu yang sama
5. Known change window atau maintenance
6. External reputation atau TI match
7. Blast radius sementara

Jika SOC Anda kekurangan waktu, prioritaskan tujuh item ini terlebih dahulu.

Tanda Bahwa Alert Harus Segera Diekskalasi

Eskalasi cepat meski belum lengkap jika salah satu kondisi berikut ada:

• melibatkan domain admin, global admin, atau break-glass account
• terjadi pada crown jewel asset atau internet-facing production system
• ada indikasi interactive execution yang tidak sesuai baseline
• ada kombinasi execution + credential access + outbound connection
• ada persistence indicator seperti scheduled task, mailbox rule, startup item, atau new access key
• ada penyebaran ke banyak host atau banyak account dalam waktu singkat
• ada dampak bisnis langsung atau potensi data exposure

Prinsipnya: ketidaklengkapan data bukan alasan menunda eskalasi pada high-risk context.

Tanda Bahwa Alert Bisa Ditutup dengan Aman

Alert dapat ditutup bila evidence cukup menunjukkan:

• aktivitas benar-benar sesuai change ticket atau admin workflow yang tervalidasi
• entity dan perilaku konsisten dengan baseline historis
• tidak ada sinyal pendukung dari source lain
• command, binary, IP, atau user action memiliki penjelasan operasional yang kuat
• tidak ada blast radius tambahan setelah scoped check minimum

Closure yang baik selalu menyertakan alasan kontekstual, bukan sekadar false positive.

Template Handoff L1 ke L2

Title: Suspicious PowerShell on PROD-APP-01
Summary: EDR memicu alert PowerShell encoded command pada server produksi. Aktivitas dijalankan oleh service account dan tidak ditemukan change window aktif.
Priority: High
Entities:
- Host: PROD-APP-01
- User: svc_app_web
- Parent process: w3wp.exe
- Destination IP: 198.51.100.24
Timeline:
- 09:14:21 powershell.exe started
- 09:14:24 outbound TLS connection observed
- 09:15:10 new scheduled task created
Context checked:
- Asset criticality: Production app server
- User privilege: Service account with local admin
- Change window: None found
- Nearby alerts: 2 similar alerts on same host
Unknowns:
- Full decoded payload not yet analyzed
- Lateral movement scope not yet confirmed
Recommendation:
- L2 to validate persistence, outbound destination, and account misuse scope

Template Handoff L2 ke L3

Incident hypothesis: Web server exploitation leading to PowerShell execution and persistence.
Confirmed observations:
- w3wp.exe spawned powershell.exe with encoded command
- outbound callback to rare external IP
- scheduled task persistence created
- no approved deployment/change window
Scope so far:
- 1 confirmed host
- 1 service account involved
- no confirmed lateral movement yet
Likely ATT&CK:
- T1059 PowerShell
- T1053 Scheduled Task
- T1105 Ingress Tool Transfer or related command retrieval pattern
Open questions:
- Initial access vector from web tier
- Payload family and command objective
- Whether rule should detect earlier pre-execution indicators
Requested L3 actions:
- decode payload and identify intrusion path
- perform retrospective hunt on similar web-to-powershell chain
- recommend detection improvements

Kesalahan Umum yang Harus Dihindari

• menilai alert hanya dari severity vendor
• menganggap satu IOC match sudah cukup untuk incident declaration
• terlalu cepat close karena satu artefak terlihat benign
• terlalu lama menahan eskalasi demi mencari kepastian absolut
• tidak membedakan antara benign true positive dan false positive
• tidak mencatat konteks yang sudah diperiksa sehingga shift berikutnya mengulang pekerjaan yang sama
• gagal membedakan absence of evidence dengan evidence of absence

KPI yang Relevan untuk Pendekatan Ini

Jika SOC ingin mengukur kematangan context driven analysis, gunakan metrik seperti:

• false positive rate setelah enrichment L1
• rasio eskalasi L1 yang diterima L2 tanpa bounce back
• rata-rata waktu dari alert ke keputusan triage
• persentase handoff yang menyertakan asset, identity, timeline, dan blast radius context
• jumlah detection tuning yang lahir dari temuan L3
• penurunan repeat investigation untuk noise pattern yang sama

Playbook Praktis 5 Menit untuk L1

Saat alert masuk, jalankan urutan ini:

1. Identifikasi entity utama: host, user, IP, process, mailbox, workload.
2. Cek asset criticality dan privilege level.
3. Cek satu artefak teknis utama: process tree atau sign-in chain.
4. Cek satu source pendukung lain: EDR, IAM, email, firewall, atau CloudTrail.
5. Putuskan: close, monitor, atau escalate dengan alasan jelas.

Jika langkah 2, 3, dan 4 semua menunjukkan anomali, jangan tunggu lama untuk eskalasi.

Heuristik Singkat

• Low signal + high-risk context tetap bisa berarti high priority.
• High signal + strong benign context belum tentu incident.
• Single alert + multi-source support lebih kuat daripada multiple alerts + no supporting context.
• Unknown on crown jewel lebih berbahaya daripada known weirdness on low-value asset.
• Fast good escalation lebih berharga daripada slow perfect escalation pada kasus berisiko tinggi.

Kesimpulan

Context driven analysis adalah cara berpikir, bukan sekadar langkah playbook. SOC L1, L2, dan L3 sama-sama melakukan analisis, tetapi kedalaman konteks dan keputusan yang mereka hasilkan berbeda.

Jika dijalankan konsisten, pendekatan ini akan:

• meningkatkan kualitas triage
• mengurangi noise yang tidak perlu dieskalasi
• mempercepat identifikasi incident nyata
• memperbaiki mutu handoff antar level
• menghasilkan feedback loop yang lebih baik ke detection engineering

Prinsip paling penting: jangan tanya hanya alert ini bunyi karena apa, tetapi tanya alert ini berarti apa dalam konteks environment kita.