Detection Engineering Linux untuk Tim Kecil: Playbook Praktis Wazuh + osquery

Target keyword: detection engineering linux
Monthly keyword cluster: cyber security linux, threat detection linux, incident response linux, security monitoring linux
Weekly intent rotation: practical implementation / best-practice playbook (MOFU)

Kalau kamu ngerasa “alert security banyak, tapi yang beneran bisa ditindak dikit banget”, kamu nggak sendirian.

Banyak tim kecil sudah punya monitoring, sudah pasang firewall, bahkan sudah jalanin patching. Tapi pas insiden kejadian, masalahnya sering sama: sinyal kebanyakan noise, prioritas nggak jelas, dan tim bingung langkah pertama harus ngapain.

Di sinilah detection engineering Linux jadi penting. Fokusnya bukan sekadar “punya tool”, tapi merancang deteksi yang relevan sama risiko nyata di environment kamu.

Di artikel ini kita bahas playbook praktis buat tim kecil dengan kombinasi Wazuh + osquery mindset: gimana milih use-case deteksi, nulis rule yang berguna, tuning false positive, dan nyambungin alert ke runbook respons insiden.

Kalau fondasi hardening kamu belum rapi, baca dulu ini:

• Linux Security Baseline Audit Checklist for Small Teams
• Zero-Trust SSH Access Linux: Practical Hardening for Small Teams
• UFW vs Fail2ban vs SSH Hardening: Kombinasi Keamanan Server Linux

Apa itu detection engineering (versi praktis)?

Singkatnya, detection engineering adalah proses merancang deteksi ancaman secara terstruktur supaya alert kamu:

1. relevan sama ancaman prioritas,
2. punya konteks buat triage cepat,
3. dan bisa ditindak lewat langkah respons yang jelas.

Jadi bukan cuma “kalau ada login gagal kirim notif”, tapi lebih ke:

• event apa yang penting,
• korelasi apa yang bikin event itu berisiko,
• siapa owner responsnya,
• dan SLA tindakan berapa menit.

Untuk tim kecil, pendekatan ini ngebantu banget biar energi nggak habis buat ngejar alert yang ujungnya bukan insiden.

Kenapa kombinasi Wazuh + osquery menarik buat tim kecil?

Bukan berarti harus tool ini doang, tapi secara praktis:

• Wazuh enak buat ngumpulin log, FIM (file integrity monitoring), dan rule alert dari host Linux.
• osquery mindset ngebiasain tim berpikir endpoint state secara query-driven (proses, user, cron, autorun, package, network artifacts).

Kamu bisa anggap:

• Wazuh = saluran deteksi + alerting,
• osquery = lensa investigasi cepat untuk validasi hipotesis.

Hasil akhirnya: deteksi jadi lebih contextual, bukan sekadar hitungan event mentah.

Step 1 — Mulai dari 8 use-case prioritas (jangan kebanyakan dulu)

Kesalahan paling umum: aktifin semua rule bawaan, lalu tenggelam di noise.

Mulai dari use-case yang paling dekat ke risiko tim kecil. Contoh shortlist:

1. Brute-force SSH yang melewati threshold tertentu.
2. Successful login dari IP/ASN/geo yang tidak biasa.
3. Eksekusi binary dari path rawan (/tmp, /dev/shm).
4. Perubahan file sensitif (/etc/passwd, /etc/sudoers, SSH config).
5. Pembuatan user baru non-standar.
6. Proses web server spawn shell (nginx/apache -> bash/sh).
7. Cron job mencurigakan yang baru muncul.
8. Outbound connection aneh dari host yang harusnya minim egress.

Kalau use-case ini sudah stabil, baru scale ke deteksi lanjutan.

Step 2 — Definisikan format alert yang siap triage

Alert tanpa konteks = tiket yang bikin panik.

Setiap alert high/critical minimal harus bawa field ini:

• hostname + environment (prod/staging),
• timestamp UTC + lokal,
• user/process/parent process,
• command line,
• source IP/destination IP (kalau relevan),
• rule name + severity,
• link ke runbook.

Contoh template ringkas:

[HIGH] Suspicious execution from /tmp
Host: app-prod-01
User: www-data
Process: /tmp/.x/run.sh
Parent: nginx
Source: 10.10.1.24
Time: 2026-03-29T08:14:21Z
Runbook: IR-DET-003

Dengan format begini, on-call nggak buang waktu buat cari info dasar dulu.

Step 3 — Tulis severity matrix yang realistis

Jangan semua event jadi critical. Bikin level biar tim bisa fokus.

Contoh matrix sederhana:

• Critical: indikasi compromise aktif (reverse shell, credential theft, privilege escalation sukses).
• High: perilaku sangat mencurigakan dan butuh triage cepat.
• Medium: anomaly yang perlu validasi dalam jam kerja.
• Low: event observability untuk baseline, tidak paging.

SLA praktis untuk tim kecil:

• Critical: triage < 10 menit,
• High: triage < 30 menit,
• Medium: review harian,
• Low: review mingguan.

Kalau kamu sering kelelahan alert, artikel ini nyambung banget:

• Alert Fatigue Linux: Cara Triage Alert Security untuk Tim Kecil Tanpa Burnout

Step 4 — Gunakan query investigasi cepat ala osquery mindset

Saat alert masuk, tujuan pertama bukan langsung “bersihin”, tapi verifikasi scope dan dampak.

Contoh pertanyaan investigasi:

• proses ini jalan sejak kapan?
• parent process-nya normal nggak?
• ada persistence baru di cron/systemd?
• user ini biasanya memang akses host ini?

Command Linux cepat (sebagai fallback investigasi host):

# proses mencurigakan
ps aux --sort=-%cpu | head -n 25

# koneksi aktif
ss -tupn

# service gagal
systemctl --failed

# auth event 2 jam terakhir
journalctl -S -2h -u ssh --no-pager | tail -n 200

Kalau mau pendekatan hunting yang lebih sistematis, lanjut baca:

• Threat Hunting Linux dengan auditd dan journald untuk Tim Kecil

Step 5 — Tuning false positive dengan disiplin mingguan

Detection engineering gagal bukan karena tool jelek, tapi karena tim skip tuning.

Ritual mingguan 30–45 menit yang wajib:

1. Ambil top 20 alert terbanyak minggu ini.
2. Labeli: true positive, benign, noisy, duplicate.
3. Turunkan severity atau whitelist event benign yang konsisten.
4. Naikkan confidence untuk rule yang berkali-kali benar.
5. Update runbook kalau ada pola insiden baru.

Rule of thumb:

• Kalau rule tidak pernah menghasilkan aksi 30 hari, evaluasi ulang.
• Kalau rule sering benar, pastikan dia punya jalur eskalasi cepat.

Step 6 — Hubungkan alert ke runbook respons (wajib)

Deteksi tanpa runbook itu setengah jadi.

Setiap alert high/critical harus punya runbook minimal:

1. cara validasi cepat,
2. langkah containment awal,
3. bukti apa yang harus diambil,
4. kriteria eskalasi,
5. owner + backup owner.

Contoh alur IR mini:

• Triage 10 menit: valid/false?
• Jika valid dan berdampak: isolate host/workload.
• Capture evidence (log, process tree, network connection).
• Rotate credential jika ada indikasi kebocoran.
• Restore service dan lakukan post-incident review.

Referensi yang bisa langsung dipraktikkan:

• Linux Incident Response Playbook: Practical Troubleshooting and Containment
• Tabletop Exercise Cyber Security Linux untuk Tim Kecil

Roadmap 30-60-90 hari (biar nggak over-engineering)

Hari 0–30: Foundation

• pilih 8 use-case prioritas,
• standarkan format alert,
• tetapkan severity matrix,
• assign owner on-call.

Hari 31–60: Signal Quality

• tuning false positive mingguan,
• tambahkan field konteks untuk triage,
• ukur MTTD/MTTR baseline,
• rapikan runbook 5 alert terpenting.

Hari 61–90: Maturity

• tambahkan korelasi event lintas host,
• latih tabletop bulanan,
• evaluasi coverage ATT&CK yang relevan,
• audit kualitas deteksi per bulan.

KPI yang wajib dipantau

Biar program kamu bukan sekadar “pasang dashboard”, pantau metrik ini:

1. MTTD (mean time to detect).
2. MTTR (mean time to respond/contain).
3. Rasio true positive vs false positive.
4. Persentase alert high/critical yang punya runbook.
5. Jumlah rule yang dituning per bulan.

Kalau 2–3 bulan metriknya membaik, berarti detection engineering kamu jalan di arah yang benar.

Kesalahan paling sering saat mulai detection engineering

1. Tool-first mindset: beli/pasang tool dulu, use-case belakangan.
2. No owner: alert masuk, tapi nggak ada PIC yang jelas.
3. No SLA: semua dianggap penting, akhirnya tidak ada prioritas.
4. No review loop: rule dibiarkan usang meski arsitektur berubah.
5. No exercise: insiden nyata datang, tim baru belajar saat kejadian.

Penutup

Untuk tim kecil, detection engineering Linux yang bagus itu bukan yang paling kompleks, tapi yang:

• relevan sama risiko utama,
• minim noise,
• punya runbook actionable,
• dan dievaluasi rutin.

Mulai dari sedikit use-case dulu, rapikan kualitas sinyal, lalu scale bertahap. Dengan pola ini, Wazuh + osquery mindset bisa bantu tim kamu bergerak dari “kebanjiran alert” jadi “deteksi cepat, respons tepat”.

Kalau minggu ini kamu cuma punya waktu satu jam, pakai buat ini: pilih 3 alert paling berisik, tune sampai actionable, lalu dokumentasikan runbook-nya. Dampaknya biasanya langsung kerasa.

---

FAQ

1) Tim kecil wajib pakai Wazuh dan osquery sekaligus?

Nggak wajib. Kamu bisa mulai dari satu stack dulu. Yang penting adalah proses detection engineering-nya: use-case jelas, alert contextual, dan runbook siap pakai.

2) Berapa jumlah rule ideal untuk awal implementasi?

Untuk tahap awal, 8–15 rule high-value lebih baik daripada ratusan rule tanpa tuning. Fokus kualitas sinyal dulu, baru kuantitas.

3) Bagaimana cara tahu rule kita bagus atau tidak?

Lihat outcome-nya: apakah alert membantu keputusan triage, apakah ada tindakan yang diambil, dan apakah false positive turun dari minggu ke minggu.

4) Detection engineering ini cocok untuk server non-Kubernetes?

Cocok banget. Banyak use-case dasar (SSH abuse, perubahan file sensitif, suspicious process) sangat relevan untuk VM/bare metal Linux biasa.

5) Kapan waktunya scale ke detections-as-code yang lebih advance?

Saat baseline rule stabil, proses tuning sudah disiplin, dan tim siap mengelola lifecycle rule (versioning, testing, review) secara konsisten.