Runtime Security Linux dengan eBPF: Playbook Falco + Tetragon untuk Tim Kecil

Target keyword: runtime security linux
Keyword cluster bulanan: linux security hardening, threat detection linux, incident response linux, security monitoring linux
Search intent mingguan: practical implementation / best-practice guide

Kalau security di Linux cuma fokus ke firewall + patching, itu bagus… tapi belum cukup.

Kenapa? Karena banyak serangan modern lolos bukan dari “port kebuka”, tapi dari aktivitas mencurigakan yang terjadi setelah attacker berhasil dapat pijakan awal. Misalnya:

• proses tiba-tiba spawn shell dari service web,
• binary asing jalan dari /tmp,
• container akses file sensitif host,
• atau ada reverse shell dari proses yang harusnya “jinak”.

Di titik ini, kamu butuh runtime security Linux: kemampuan melihat perilaku proses secara real-time, bukan cuma scan statis.

Di artikel ini kita bahas playbook praktis buat tim kecil pakai pendekatan eBPF, dengan kombinasi Falco dan Tetragon. Fokusnya bukan teori berat, tapi cara pakai yang realistis biar:

1. deteksi anomali lebih cepat,
2. alert lebih relevan (nggak noisy),
3. respon insiden lebih rapi.

Kalau baseline hardening kamu belum beres, rapikan dulu dari sini:

• Linux Security Baseline Audit Checklist for Small Teams
• Zero-Trust SSH Access on Linux: Practical Hardening for Small Teams

Kenapa runtime security penting untuk tim kecil?

Tim kecil sering punya masalah yang sama:

• server nggak banyak, tapi fungsi campur aduk,
• alert tools banyak, tapi actionable signal sedikit,
• insiden jarang, jadi SOP respon belum kebentuk.

Runtime security bantu menutup gap itu karena kamu bisa mendeteksi perilaku berbahaya dari level proses/syscall, contohnya:

• nginx tiba-tiba menjalankan /bin/bash,
• proses non-admin membaca /etc/shadow,
• binary baru mencoba konek outbound ke IP aneh,
• workload container mount path host yang sensitif.

Artinya kamu nggak nunggu “damage dulu baru sadar”.

Falco vs Tetragon: bedanya apa dan kapan dipakai?

Singkatnya:

• Falco: rule-based detection, matang, enak buat mulai cepat, ekosistem rule banyak.
• Tetragon: event observability + enforcement berbasis eBPF untuk Kubernetes/Linux modern, kuat untuk policy granular.

Untuk tim kecil, strategi paling masuk akal biasanya bukan pilih salah satu, tapi:

• start dengan Falco buat deteksi cepat,
• tambah Tetragon untuk use-case yang butuh visibility lebih detail dan kebijakan level proses.

Bayangin Falco sebagai alarm siap pakai, Tetragon sebagai kamera + kontrol akses yang lebih presisi.

Arsitektur simpel yang realistis

Implementasi minimum yang aman:

1. Agent runtime security di host penting (atau node Kubernetes).
2. Event dikirim ke log pipeline (journald/syslog/ELK/Loki, sesuaikan stack kamu).
3. Alert route ke channel operasional (Slack/Telegram/email on-call).
4. Ada runbook triage untuk tiap alert high severity.

Jangan langsung pasang di semua server. Mulai dari:

• bastion/host admin,
• server internet-facing,
• node yang pegang data sensitif.

Prinsip ini sejalan dengan playbook prioritas risiko di:

• Vulnerability Management Linux untuk Tim Kecil

Step 1 — Tetapkan threat scenario yang ingin dideteksi dulu

Kesalahan paling umum: install tool dulu, bingung alert-nya buat apa.

Sebelum deploy, list 5–10 skenario prioritas. Contoh untuk tim kecil:

1. Web process spawn shell (bash, sh, python -c, dll).
2. Write/execute dari directory rawan (/tmp, /dev/shm).
3. Akses credential file non-wajar.
4. Reverse shell outbound ke internet.
5. Privilege escalation mencurigakan (setuid, sudo anomali).

Kalau skenarionya jelas, tuning jadi jauh lebih gampang.

Step 2 — Deploy Falco dengan rule baseline dulu

Contoh instalasi beda-beda tergantung distro/environment, jadi fokus ke pola operasionalnya:

• aktifkan default rules,
• matikan rules yang jelas irrelevant untuk environment kamu,
• tambahkan custom rules bertahap.

Contoh rule yang sering kepakai untuk deteksi awal:

• shell spawned by web server,
• suspicious network tool execution,
• write below binary directories,
• terminal shell in container.

Workflow aman untuk tim kecil:

1. Minggu 1: mode observasi (tanpa paging keras).
2. Minggu 2: klasifikasikan alert (true/benign/noise).
3. Minggu 3: aktifkan paging untuk rule high-confidence.

Biar nggak burnout alert, baca juga:

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

Step 3 — Tambahkan Tetragon untuk visibility dan policy yang lebih tajam

Kalau kamu sudah butuh kontrol lebih granular (terutama di container/K8s), Tetragon jadi layer lanjutan yang powerful.

Use-case praktis:

• monitor process execution berdasarkan label workload,
• deteksi binary tertentu jalan di namespace sensitif,
• blok/deny action tertentu via policy enforcement (sesuai kebutuhan).

Tips penting: jangan langsung enforcement full. Jalankan dulu dalam mode observability supaya kamu paham baseline normal aplikasi.

Step 4 — Bangun severity matrix biar alert bisa ditindak

Kalau semua alert dianggap “critical”, ujungnya nggak ada yang ditindak tepat waktu.

Contoh matrix ringan:

• Critical: indikasi compromise aktif (reverse shell, credential dump, privilege escalation sukses).
• High: perilaku anomali kuat (web spawn shell, binary asing execute dari /tmp).
• Medium: policy deviation tapi belum indikasi serangan langsung.
• Low: event informatif untuk baseline.

Setiap severity wajib punya SLA respons. Misalnya:

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

Step 5 — Tulis runbook triage yang benar-benar bisa dipakai jam 2 pagi

Alert bagus tanpa runbook = panik saat insiden.

Template runbook minimal:

1. Konteks alert: host, proses, user, command line, parent process.
2. Validasi cepat: ini expected behavior atau tidak?
3. Containment awal: isolate host/workload bila indikator kuat.
4. Evidence capture: process tree, network connection, log 2 jam terakhir.
5. Escalation: siapa PIC security/ops/app owner.

Contoh command triage cepat di Linux:

# 1) proses paling boros CPU/mencurigakan
ps aux --sort=-%cpu | head -n 25

# 2) koneksi aktif
ss -tupn

# 3) cek event system terbaru
journalctl -S -2h --no-pager | tail -n 300

# 4) service fail
systemctl --failed

Untuk alur investigasi yang lebih detail, kamu bisa gabungkan dengan:

• Playbook Deteksi Intrusi Linux
• Threat Hunting Linux dengan auditd + journald untuk Tim Kecil

Step 6 — Tuning anti-noise: bagian paling penting tapi paling sering di-skip

Runtime detection gagal bukan karena tool jelek, tapi karena alert terlalu noisy.

Praktik tuning yang kebukti efektif:

• whitelist proses known-good per service,
• exclude job terjadwal yang memang “berisik tapi valid”,
• gunakan konteks user/namespace/path sebelum naikin severity,
• review top 20 alert mingguan dan prune rule yang tidak actionable.

Patokan sederhana: kalau rule tidak pernah menghasilkan tindakan selama 30 hari, kemungkinan rule itu perlu diturunkan levelnya, dituning, atau dimatikan.

Step 7 — Hubungkan runtime security ke incident response

Deteksi cepat harus nyambung ke respons cepat.

Integrasi minimum:

• alert critical otomatis buka tiket insiden,
• attach metadata penting (host, proses, cmdline, hash, network destination),
• on-call checklist langsung muncul di tiket.

Kalau tim kamu sudah punya latihan tabletop, masukkan skenario runtime alert ke drill bulanan:

• Tabletop Exercise Cyber Security Linux untuk Tim Kecil

Contoh roadmap 30-60-90 hari untuk tim kecil

Hari 0–30: Foundation

• deploy Falco di 1–3 host prioritas,
• aktifkan baseline rules,
• siapkan channel alert + owner on-call,
• buat severity matrix awal.

Hari 31–60: Signal quality

• tuning whitelist/exceptions,
• mapping 10 skenario ancaman utama,
• mulai write runbook per alert high/critical,
• ukur metrik false-positive.

Hari 61–90: Maturity

• tambah Tetragon untuk visibility lanjutan,
• uji policy enforcement terbatas,
• integrasikan ke incident workflow,
• lakukan drill bulanan berbasis alert runtime nyata.

KPI yang sebaiknya dipantau

Biar program runtime security nggak jadi “tool pajangan”, pantau metrik ini:

1. MTTD (mean time to detect).
2. MTTR (mean time to respond/contain).
3. Rasio true positive vs false positive.
4. Jumlah alert high/critical yang punya runbook.
5. Persentase alert yang ditutup dengan root-cause jelas.

Kalau KPI membaik 2–3 bulan berturut-turut, berarti implementasi kamu on track.

Kesalahan umum saat implementasi runtime security Linux

1. Langsung aktifkan semua rule → alert meledak, tim cuek.
2. Tidak ada owner alert → semua lihat, tidak ada yang eksekusi.
3. Tidak punya baseline aplikasi normal → semua kelihatan anomali.
4. Tidak latihan insiden → pas kejadian nyata, respon lambat.
5. Tidak review berkala → rule jadi usang saat arsitektur berubah.

Penutup

Buat tim kecil, runtime security Linux bukan soal punya stack paling canggih. Yang penting adalah kombinasi ini:

• rule deteksi yang relevan,
• tuning anti-noise yang disiplin,
• runbook yang jelas,
• dan latihan respons yang rutin.

Mulai dari kecil dulu: deploy terbatas, ukur signal quality, baru scale. Dengan pendekatan ini, Falco dan Tetragon bisa jadi “early warning system” yang benar-benar ngebantu, bukan sekadar dashboard tambahan.

Kalau sekarang kamu sudah punya hardening dasar, menambahkan runtime security linux adalah langkah logis berikutnya untuk mengurangi blind spot saat serangan bergerak cepat.

---

FAQ (Schema-ready)

1) Tim kecil harus pilih Falco atau Tetragon dulu?

Mulai dari Falco kalau mau time-to-value cepat. Tambahkan Tetragon saat butuh observability dan kebijakan proses yang lebih granular, terutama di environment container/Kubernetes.

2) Apakah runtime security bikin server berat?

Ada overhead, tapi umumnya bisa dikelola kalau rule dan scope-nya tepat. Mulai dari host prioritas dulu, ukur dampak performa, lalu scale bertahap.

3) Gimana cara ngurangin false positive paling efektif?

Gunakan baseline aplikasi normal, whitelist proses known-good, dan review rutin alert terbanyak. Fokuskan paging ke rule high-confidence.

4) Kapan enforcement policy aman diaktifkan?

Setelah fase observability stabil dan kamu paham pola normal workload. Aktifkan enforcement per use-case, jangan sekaligus.

5) Runtime security ini menggantikan SIEM/EDR?

Bukan menggantikan, tapi melengkapi. Runtime security memberi sinyal perilaku proses real-time yang sangat berguna untuk triage dan incident response.