Purple Team Mini Drill di Linux: Cara Ngebangun Detection Engineering untuk Tim Kecil

Monthly keyword cluster: cyber security linux, incident response linux, deteksi intrusi linux, security monitoring tim kecil
Weekly intent rotation: Problem-solving + implementation checklist (MOFU)

Banyak tim kecil ngerasa topik cyber security itu berat karena identik sama SOC besar, SIEM mahal, atau tim khusus 24/7. Padahal di dunia nyata, banyak insiden awalnya sederhana: brute-force SSH, credential bocor, service kena misconfig, atau user ngasih izin berlebihan ke proses yang salah.

Masalahnya bukan karena tim kamu “kurang jago”, tapi karena belum ada loop latihan yang rutin dan realistis. Nah, di sinilah konsep purple team mini drill kepakai banget.

Singkatnya: kamu bikin simulasi serangan ringan (red mindset), lalu langsung validasi kemampuan deteksi + respon (blue mindset) di lingkungan Linux kamu sendiri. Nggak perlu nunggu insiden beneran dulu baru panik.

Di artikel ini, kita bahas cara implementasi purple team mini drill yang ringan, murah, dan repeatable buat tim kecil.

Kenapa purple team mini drill penting untuk tim kecil?

Kalau security cuma mengandalkan checklist, biasanya hasilnya “kelihatan aman” tapi minim bukti. Begitu ada kejadian, tim bingung:

• log mana yang harus dicek dulu,
• alert mana yang noise,
• siapa pegang keputusan isolasi,
• dan rollback mana yang paling aman.

Purple drill ngubah itu jadi kebiasaan operasional.

Manfaat paling terasa:

1. Deteksi jadi terukur — bukan “harusnya kelihatan”, tapi “beneran kelihatan di log X dalam Y menit”.
2. Respon lebih cepat — runbook diuji, bukan cuma disimpan di Notion.
3. False positive turun — rule deteksi makin tajam tiap minggu.
4. Kerja lintas peran lebih rapi — DevOps, backend, dan security ngomong pakai data yang sama.

Kalau kamu belum punya baseline hardening, mulai dari sini dulu:

• Linux Security Baseline Audit Checklist for Small Teams
• Linux Incident Response Playbook: Practical Troubleshooting and Containment

Scope mini drill: kecil dulu, konsisten dulu

Kesalahan paling umum adalah pengen simulasi terlalu kompleks padahal alert dasar belum stabil. Untuk tim kecil, lebih efektif pakai format ini:

• Durasi: 45–90 menit per minggu
• Target: 1 teknik serangan per sesi
• Output wajib: 1 rule deteksi diperbaiki + 1 action item operasional

Contoh teknik realistis: brute-force SSH, privilege escalation sederhana, atau eksekusi command mencurigakan.

Arsitektur minimum yang cukup

Kamu nggak butuh SIEM enterprise buat mulai. Stack minimum:

1. Sumber log: journald, auth.log, auditd (kalau tersedia)
2. Agregasi: rsyslog/loki/ELK ringan (sesuaikan kemampuan)
3. Alerting: rule sederhana (threshold + pattern)
4. Runbook respon: markdown checklist yang bisa diikuti siapa pun

Untuk pondasi telemetry Linux, baca juga:

• Threat Hunting Linux dengan auditd dan journald untuk Tim Kecil
• Linux Log Integrity Monitoring Playbook: journald, auditd, remote syslog

Langkah 1 — Tentukan skenario serangan mingguan

Pilih skenario yang paling dekat sama risiko nyata tim kamu. Misalnya banyak server expose SSH? Ya mulai dari brute-force + login anomali.

Template pemilihan skenario:

• Asset target: VM app, bastion, atau host CI
• Teknik: contoh T1110 (brute force)
• Tujuan drill: deteksi dalam <5 menit + notifikasi ke channel ops
• Batas aman: tidak mengganggu service produksi

Contoh pseudo-plan:

Scenario: SSH brute-force from known test IP
Success criteria:
- auth failure spike terdeteksi
- source IP tercatat jelas
- alert terkirim
- host tidak terkunci permanen (no self-DoS)

Kuncinya: jangan terlalu “kreatif”. Fokus ke skenario yang bisa diulang berkali-kali.

Langkah 2 — Definisikan telemetry yang wajib keluar

Sering kejadian tim bikin alert duluan, tapi log dasarnya nggak lengkap. Akhirnya alert “misterius” tanpa konteks.

Minimal telemetry untuk drill awal:

• timestamp UTC konsisten,
• hostname dan environment (prod/staging),
• user/process/source IP,
• event outcome (success/fail).

Contoh cek cepat di Linux:

# cek auth events (Debian/Ubuntu)
sudo journalctl -u ssh --since "-30 min"

# cek failed login dari auth.log (jika ada)
sudo grep "Failed password" /var/log/auth.log | tail -n 50

# cek proses mencurigakan berdasarkan parent-child sederhana
ps -eo pid,ppid,user,cmd --sort=-%cpu | head -n 30

Kalau event penting belum muncul konsisten, jangan lanjut ke rule kompleks. Beresin pipeline log dulu.

Langkah 3 — Tulis rule deteksi versi awal (simple > perfect)

Rule bagus itu bukan yang paling canggih, tapi yang:

• bisa dijelaskan,
• bisa diuji,
• dan bisa ditingkatkan.

Contoh rule awal brute-force:

• Trigger jika gagal login SSH > 20 kali dalam 2 menit dari IP yang sama.
• Suppress untuk IP internal tertentu (mis. scanner internal yang sah).
• Severity “medium” untuk percobaan, “high” kalau ada success login setelah brute-force.

Contoh logika (pseudo):

IF failed_ssh_attempts_by_ip >= 20 within 120s
THEN alert severity=medium

IF condition_above AND success_login_same_ip_within_10m
THEN alert severity=high

Simple rule kayak gini udah cukup buat mayoritas tim kecil, asalkan rutin dievaluasi.

Langkah 4 — Jalankan drill + ukur metrik inti

Saat drill berjalan, capture metrik ini (wajib):

1. TTD (Time to Detect): berapa lama event terdeteksi?
2. TTA (Time to Acknowledge): berapa lama ada yang respon?
3. Signal quality: alert relevan atau noise?
4. Context completeness: data cukup untuk ambil keputusan?

Contoh format ringkas hasil drill:

Drill date: 2026-03-12
Scenario: SSH brute-force
TTD: 2m 40s
TTA: 4m 10s
False positives: 1
Gaps:
- source geo tidak tercatat
- runbook isolasi host belum jelas PIC

Dengan format sederhana, kamu punya bukti kemajuan tiap minggu.

Langkah 5 — Lakukan perbaikan kecil

Setelah drill, hindari godaan “rombak total”. Lebih efektif pakai prinsip 1 sesi = 1 improvement nyata.

Contoh improvement cepat:

• Tambah field env dan service ke alert.
• Rapikan threshold berdasarkan baseline trafik.
• Tambah langkah isolasi host di runbook.
• Mapping severity ke SLA respon.

Kalau tim kamu sering berurusan sama credential risk, ini relevan:

• Defense Credential Stuffing Playbook: Rate Limit + Risk-Based Auth
• Linux API Key Leak Incident Response Playbook for Small DevOps Teams

Contoh runbook mini yang bisa langsung dipakai

Template runbook 1 halaman:

# Runbook: SSH Brute-force Detection

Trigger: >20 failed SSH login/2 menit dari IP sama
Validasi: cek host/user/source IP + success login setelah burst
Containment: block IP sementara, rotasi credential bila perlu
Evidence: simpan log + timestamp + command investigasi
Escalation: notify on-call, naikkan level jika meluas >1 host
Recovery: buka blokir sesuai evaluasi, update rule

Kesalahan umum yang perlu dihindari

1) Drill terlalu jarang

Kalau cuma per kuartal, tim lupa konteks. Minimal mingguan/dua mingguan.

2) Tidak ada owner per action item

Semua setuju, tapi nggak ada yang ngerjain. Tetapkan PIC + deadline.

3) Fokus alat, lupa proses

Tool mahal nggak menyelesaikan runbook yang kabur.

4) Tidak ukur metrik

Tanpa TTD/TTA, kamu nggak tahu makin baik atau jalan di tempat.

5) Menganggap false positive itu gagal total

False positive itu bahan tuning. Yang penting frekuensinya turun dari sesi ke sesi.

Checklist implementasi cepat

• Sudah pilih 1 skenario serangan realistis
• Sudah identifikasi log source wajib
• Sudah punya rule deteksi v0 (simple)
• Sudah tetapkan metrik TTD/TTA
• Sudah siapkan runbook 1 halaman
• Sudah assign PIC untuk improvement pasca-drill

FAQ

1) Tim kecil tanpa security engineer bisa jalanin purple drill?

Bisa banget. Mulai dari skenario sederhana dan bagi peran: satu orang simulasi, satu orang observasi, satu orang eksekusi runbook.

2) Harus pakai MITRE ATT&CK dulu dari awal?

Nggak wajib. Boleh pakai mapping ringan biar konsisten istilah, tapi prioritas awal tetap ke risiko nyata di infra kamu.

3) Gimana kalau alert masih noisy?

Normal di fase awal. Kurangi noise dengan baseline trafik, whitelist yang valid, dan enrichment context sebelum menaikkan kompleksitas rule.

4) Berapa lama sampai kelihatan hasilnya?

Biasanya 2–4 minggu sudah terasa: respon lebih cepat, diskusi insiden lebih rapi, dan rule deteksi makin relevan.

5) Apa bedanya dengan tabletop exercise?

Tabletop fokus diskusi keputusan. Purple mini drill menambah komponen teknis nyata: event dibuat, log terbaca, rule dites, lalu diperbaiki.

FAQ Schema (JSON-LD, schema-ready)

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Tim kecil tanpa security engineer bisa jalanin purple drill?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Bisa. Mulai dari skenario sederhana dan bagi peran dasar: simulasi, observasi, serta eksekusi runbook."
      }
    },
    {
      "@type": "Question",
      "name": "Harus pakai MITRE ATT&CK dulu dari awal?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Tidak wajib. Mapping boleh dipakai secukupnya, tetapi prioritas awal adalah risiko paling nyata di lingkungan Linux tim Anda."
      }
    },
    {
      "@type": "Question",
      "name": "Gimana kalau alert masih noisy?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Itu normal. Kurangi noise lewat baseline trafik, whitelist yang valid, dan penambahan konteks alert sebelum menaikkan kompleksitas rule."
      }
    }
  ]
}

Penutup

Buat tim kecil, keamanan yang efektif itu bukan soal punya tooling paling mahal, tapi punya loop belajar yang konsisten. Purple team mini drill ngasih cara praktis buat nyambungin simulasi serangan, deteksi log, dan keputusan operasional dalam siklus yang pendek.

Mulai dari satu skenario minggu ini. Ukur TTD/TTA. Perbaiki satu hal kecil. Ulangi. Dalam beberapa minggu, kemampuan detection engineering tim kamu bakal jauh lebih matang—tanpa harus nunggu insiden besar dulu.