Belajar DevSecOps Engineer - Runtime Security & Detection

#Pendahuluan

Di episode 10 kita mengotomasi perbaikan kerentanan. Namun ada batas fundamental semua scanner statis: mereka memeriksa kode dan image sebelum jalan. Mereka buta terhadap apa yang terjadi setelah itu — shell yang di-spawn di dalam web server, file /etc/passwd yang ditulis saat runtime, outbound connection aneh jam 3 pagi.

Runtime security mengisi celah ini: mendeteksi (dan kadang mencegah) perilaku abnormal pada sistem yang benar-benar berjalan. Tool inti episode ini adalah Falco — CNCF project yang memakai eBPF untuk mengawasi syscall Linux dengan overhead rendah, lalu mencocokkannya terhadap aturan.

#Mengapa Perlu Lapisan Runtime

Pertimbangkan serangan sederhana: attacker menemukan RCE di aplikasi kalian, lalu menjalankan curl untuk download payload. Tidak ada scanner CI yang bisa mencegahnya — image-nya bersih, dependency-nya aman, kerentanannya baru diketahui. Yang bisa mendeteksinya hanyalah observasi runtime:

Sinyal runtime vs statis

Statis  : "image ini membawa CVE-X"        -> risiko potensial
Runtime : "proses nginx baru saja spawn sh -> curl"  -> indikasi kompromi NYATA

Ini disebut shift-right — pendamping dari shift-left, bukan penggantinya. Keduanya diperlukan; shift-left menyusutkan peluang, shift-right menangkap yang lolos.

#Memasang Falco

Falco tersedia sebagai package, daemon, atau Helm chart untuk Kubernetes. Untuk lab lokal kalian:

curl -s https://falco.org/repo/falcosecurity-3672BA8F.asc | apt-key add -
echo "deb https://download.falco.org/packages/deb stable main" > /etc/apt/sources.list.d/falco.list
apt update && apt install -y falco
falco --version

Mode eBPF dipilih karena kompatibel lebih luas dibanding kernel module. Di K8s, Falco jalan sebagai DaemonSet — satu pod per node, mengawasi semua container di node tersebut.

#Rule Pertama Kalian

Falco punya ribuan rule bawaan. Contoh bawaan klasik — terminal shell di dalam container:

Rule bawaan Falco: shell di container

- rule: Terminal Shell in Container
  desc: Shell spawn di dalam container
  condition: >
    spawned_process and container
    and proc.name in (bash, sh, zsh)
  output: "Shell di container (user=%user.name %container.name
    parent=%proc.pname cmdline=%proc.cmdline)"
  priority: WARNING

Struktur rule selalu sama: condition (macro event syscall), output (pesan + field konteks), priority. Sekarang tulis rule custom organisasi kalian — alert jika ada proses melakukan network connection ke IP publik non-standard:

custom-rules.yaml — rule custom

- macro: app_image
  condition: (container.image.repository = "registry.internal.example/api")
 
- rule: Outbound to Suspicious Port
  desc: Aplikasi API melakukan koneksi keluar port tak wajar
  condition: >
    evt.type = connect and app_image
    and fd.sport != 443 and fd.sport != 53
    and not fd.sip in (rfc_1918_addresses)
  output: "Outbound mencurigakan (cmd=%proc.cmdline dst=%fd.sip:%fd.sport)"
  priority: CRITICAL

Uji langsung dengan simulasi serangan:

Uji rule: spawn shell di dalam container

docker run -d --name test-web nginx
docker exec test-web sh -c "whoami"   # Falco harusnya alert

Tip

Jalankan mode dry-run/audit dulu: log semua temuan tanpa memblokir, selama 1-2 minggu, sebelum mengaktifkan respons otomatis. Data periode tuning inilah yang membedakan alerting yang dipercaya tim dari noise yang di-mute.

#Drift Detection

Drift = perbedaan antara state yang dideklarasikan (image, manifest) dan state nyata di cluster. Contoh: seseorang kubectl exec lalu mengedit file config langsung di pod, atau deployment diedit manual lewat console. Drift security-relevan karena:

Patch/hardening yang kalian deploy bisa diam-diam dibatalkan.
Konfigurasi ad-hoc tidak pernah masuk review, scan, maupun Git history.

Cara mendeteksi:

GitOps (ArgoCD/Flux) secara alami drift-aware: state cluster terus dibandingkan dengan repo, dan auto-sync mengembalikan perubahan liar.
Falco rule seperti Write below etc atau modifikasi binary di container menangkap manipulasi filesystem runtime.
Scheduled rescan image di registry (episode 6) menangkap tag yang diganti isinya.

#Dari Alert ke Respons

Alert tanpa jalur tindakan hanya membuat deaf. Pola routing yang sehat:

Priority	Tujuan	SLA Respon
CRITICAL	Pager on-call + auto-containment	Menit
WARNING	Ticket triage harian	Hari
NOTICE	Dashboard agregat	Mingguan review

Untuk CRITICAL, pertimbangkan containment otomatis — misal webhook yang mengisolasi pod (kubectl label → NetworkPolicy default-deny) sambil tetap menyimpan forensik (snapshot, dump). Detail incident automation lengkap kita bahas di episode 20.

#Pitfall Umum

Semua rule bawaan ON sekaligus — ratusan alert hari pertama membuat semuanya dimatikan besoknya; aktifkan bertahap sesuai relevansi workload.
Tidak ada baseline — aplikasi yang memang spawn subprocess (worker, script) akan memicu false positive; dokumentasikan perilaku normal per service.
Log runtime tidak dipertahankan — insiden investigasi butuh riwayat; ship event Falco ke SIEM/Loki dengan retensi memadai (lanjutan episode 24).
Lupa update ruleset — threat baru butuh rule baru; perlakukan ruleset seperti dependensi: versioned dan diupdate rutin.

#Penutup

Inti yang harus dibawa pulang:

Scanner statis melihat potensi; runtime detection melihat kompromi nyata — keduanya wajib.
Falco + eBPF mengawasi syscall semua container dengan rule YAML mudah ditulis.
Drift detection menjaga state production tetap identik dengan deklarasi Git.
Tuning dulu (audit mode), baru blocking; routing alert per priority dengan SLA jelas.

Di episode 12 selanjutnya kita masuk Fase 3 dengan topik supply chain: SBOM & Software Supply Chain — kenapa setiap build harus punya daftar isi resmi, format SPDX vs CycloneDX, cara mendeteksi apakah kalian terdampak CVE seperti kasus xz-utils, dan praktik dependency risk management. Sampai jumpa!