Deteksi Insiden Dini — Tools dan Teknik Monitoring Keamanan

Jawab jujur: kalau server lo kena hack sekarang, berapa lama lo baru sadar?

Menurut data IBM, rata-rata waktu yang dibutuhkan organisasi untuk mendeteksi sebuah breach adalah 207 hari. Ya, dua ratus tujuh hari. Lebih dari setengah tahun. Selama itu attacker leluasa mondar-mandir di sistem lo, dan lo nggak tau apa-apa.

Ini yang disebut dwell time — waktu antara attacker berhasil masuk dan lo mendeteksi keberadaannya. Semakin lama dwell time, semakin besar kerusakan yang bisa dilakukan.

Nah, di artikel ini kita bakal bahas gimana caranya mempersingkat dwell time. Kita akan kupas teknik dan tools untuk mendeteksi insiden siber — idealnya sebelum kerusakan terjadi, atau setidaknya secepat mungkin setelahnya.

Ini bukan cuma tentang beli tools mahal. Ini tentang mindset, visibilitas, dan kemampuan membaca tanda-tanda bahaya di infrastruktur lo.

Kenapa Deteksi Dini Itu Kritis?

Coba lo bayangin dua skenario:

Skenario A: Attacker masuk via RDP hari Senin jam 2 pagi. Dia install malware, jalanin reconnaissance, nemuin database pelanggan, dan mulai exfiltrasi data. Lo baru sadar hari Jumat — setelah pelanggan ngeluh datanya bocor. Kerusakan: 200.000 record pelanggan bocor, denda UU PDP, reputasi hancur.

Skenario B: Attacker masuk via RDP hari Senin jam 2 pagi. SIEM lo detect 15x failed login dari IP asing dalam 3 menit, auto-alert ke tim CSIRT. Technical Lead langsung investigasi, isolasi akun yang diserang, blokir IP attacker. Selasa jam 10 pagi — insiden selesai. Kerusakan: 0 record bocor, 0 downtime.

Bedanya? Deteksi dini.

Tujuan dari semua tools monitoring yang akan kita bahas adalah: mengubah Skenario A menjadi Skenario B.

Piramida Deteksi: Dari Data ke Insight

Sebelum bahas tools, lo harus paham dulu konsep dasarnya. Data keamanan itu berlapis-lapis:

Level 1: Raw Data (Data Mentah)

Ini level paling bawah. Contoh: log server, event log Windows, packet capture. Sendirian, data mentah nggak berguna — lo nggak bisa baca jutaan baris log manual.

Level 2: Aggregation (Agregasi)

Mengumpulkan data dari berbagai sumber ke satu tempat. Tools: syslog server, Elasticsearch, Splunk. Ini memudahkan pencarian, tapi masih butuh analisis manual.

Level 3: Correlation (Korelasi)

Menghubungkan event-event yang terpisah menjadi satu cerita. Contoh: 15x failed login + 1x success login + command execution = kemungkinan brute force sukses. Tools: SIEM.

Level 4: Alerting (Peringatan)

Ketika korelasi mendeteksi pola serangan, generate alert ke tim CSIRT. Di sini penting banget untuk meminimalkan false positive — kalau alert kebanyakan, tim jadi kebal (alert fatigue).

Level 5: Automation (Otomatisasi)

Setelah alert, trigger automated response: blokir IP, isolasi endpoint, reset akun. Ini level tertinggi — SOAR (Security Orchestration, Automation, and Response).

Untuk pemula, target lo adalah mencapai Level 3-4: bisa ngumpulin dan mengkorelasikan log, lalu generate alert yang bermakna.

Tools #1: SIEM — Jantung Monitoring Keamanan

SIEM (Security Information and Event Management) adalah tools yang:

• Mengumpulkan log dari seluruh infrastruktur (server, firewall, aplikasi, endpoint).
• Menyimpan dan mengindeks log untuk pencarian cepat.
• Mengkorelasikan event dari berbagai sumber.
• Generate alert untuk pola mencurigakan.
• Menyediakan dashboard untuk visualisasi.

Pilihan SIEM:

Wazuh (Gratis, Open Source)

Wazuh adalah pilihan terbaik untuk pemula dan organisasi kecil-menengah. Fungsinya lengkap:

• Log collection & analysis
• File integrity monitoring (FIM)
• Vulnerability detection
• Security configuration assessment (SCA)
• Active response (auto-block IP)

Kelebihan: gratis, komunitas aktif, agent ringan, integrasi dengan Elastic Stack.
Kekurangan: setup awal agak kompleks, perlu tuning berkala.

ELK + ElastAlert (Gratis, Open Source)

Elasticsearch + Logstash + Kibana + ElastAlert. Lo bisa bikin SIEM dari nol:

• Elasticsearch: penyimpanan dan indexing log.
• Logstash: ingestion dan parsing log.
• Kibana: dashboard dan visualisasi.
• ElastAlert: alerting engine.

Kelebihan: fleksibel, scalable, banyak dokumentasi.
Kekurangan: butuh usaha lebih untuk setup korelasi rules.

Splunk (Berbayar)

Gold standard SIEM enterprise. Powerful, scalable, mahal. Harga dihitung per GB data yang di-ingest per hari.

Kelebihan: fitur lengkap, UI bagus, community support besar.
Kekurangan: mahal banget untuk volume data besar.

Setup Cepat Wazuh:

# Install Wazuh server (all-in-one)
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
curl -sO https://packages.wazuh.com/4.7/config.yml

# Edit config.yml sesuai kebutuhan, lalu:
sudo bash wazuh-install.sh --generate-config-files
sudo bash wazuh-install.sh --wazuh-server

# Install agent di endpoint yang mau dimonitor
# (tersedia untuk Windows, Linux, macOS)

Setelah install, lo bisa langsung lihat dashboard Kibana dengan visualisasi security events.

Tools #2: EDR — Mata di Setiap Endpoint

Kalau SIEM itu CCTV yang ngawasin seluruh gedung, EDR (Endpoint Detection and Response) itu sensor gerak di setiap ruangan. EDR fokus ke aktivitas di endpoint (laptop, server):

• Proses creation & termination
• Network connection
• File modification
• Registry changes
• DLL loading

Pilihan EDR:

• Wazuh (lagi) — FIM + log analysis + anomaly detection.
• Microsoft Defender for Endpoint — built-in di Windows 10/11 Enterprise.
• Velociraptor — open source DFIR platform, bisa query ribuan endpoint.
• CrowdStrike / SentinelOne — enterprise (mahal).

Apa yang Bisa Dideteksi EDR?

• PowerShell dijalankan dengan encoded command (obfuscation).
• Proses aneh dijalankan dari folder Temp atau Downloads.
• Koneksi keluar ke IP/domain yang dikenal sebagai malicious.
• Process injection (satu proses nyuntikin kode ke proses lain).
• Persistence via registry Run key atau scheduled task.

Log Windows yang Wajib Dimonitor

Windows punya event logging yang lumayan lengkap. Ini Event ID yang harus lo perhatikan:

Account Activity:

• 4624 — Successful logon. Cek: siapa? jam berapa? dari IP mana? Logon type berapa? (Type 10 = Remote Interactive/RDP, Type 3 = Network).
• 4625 — Failed logon. >10x dari IP yang sama dalam 5 menit = brute force.
• 4648 — Logon with explicit credentials (RunAs). Sering dipakai attacker untuk lateral movement.
• 4768 & 4769 — Kerberos TGT & service ticket request. Anomali = possible Kerberoasting atau Golden Ticket attack.

Process Activity:

• 4688 — Process creation. Cek command line-nya.
• 1 (Sysmon) — Process creation (lebih detail dari 4688).
• 3 (Sysmon) — Network connection. Bisa liat proses apa yang konek ke IP mana.

Security Policy Changes:

• 4719 — Audit policy changed. Attacker mungkin matiin audit untuk nutup jejak.
• 4670 — Permissions changed on an object.

Service & Task:

• 7045 (System log) — New service installed. Malware sering create service.
• 4698 & 4702 — Scheduled task created/updated. Persistence mechanism favorit.

Tips:

Install Sysmon di Windows. Sysmon nge-log jauh lebih detail daripada Windows Security log bawaan. Konfigurasi Sysmon pakai config dari SwiftOnSecurity di GitHub — itu udah optimal untuk deteksi ancaman.

Log Linux yang Wajib Dimonitor

Di Linux, log biasanya ada di /var/log/. Yang paling penting:

Auth Log (/var/log/auth.log)

• Failed/successful SSH login
• sudo usage
• su attempts

# Cek brute force SSH
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr

Syslog (/var/log/syslog)

• System messages, service start/stop
• Cron job execution

Web Server Log (/var/log/nginx/access.log, /var/log/apache2/access.log)

• HTTP requests
• Cari pattern mencurigakan: SQL injection (union select, ' or 1=1), path traversal (../../../etc/passwd), encoded payload (%27, eval%28)

# Top IP yang mengakses endpoint sensitif
grep "wp-admin" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -10

Auditd (/var/log/audit/audit.log)

Auditd adalah auditing framework Linux yang lebih detail dari syslog. Lo bisa atur rules spesifik:

# Monitor akses ke /etc/shadow
sudo auditctl -w /etc/shadow -p wa -k shadow_access

# Monitor execution command
sudo auditctl -a always,exit -S execve

Threat Hunting: Mencari Ancaman Secara Proaktif

SIEM dan EDR bekerja secara reaktif — menunggu alert. Threat hunting adalah pendekatan proaktif — lo yang aktif mencari ancaman, bukan nunggu alert muncul.

Apa Itu Threat Hunting?

Threat hunting adalah proses iteratif mencari ancaman di jaringan yang mungkin lolos dari tools otomatis. Lo bikin hipotesis, query data, analisis hasil, dan iterasi.

Contoh Hipotesis Threat Hunting:

1. "Mungkin ada malware yang komunikasi dengan C2 via DNS, bukan HTTP. Coba cek DNS query ke domain yang baru diregistrasi (<30 hari)."

2. "Mungkin ada PowerShell execution dengan encoded command. Coba cek Sysmon Event ID 1 dengan powershell -enc."

3. "Mungkin ada user yang login dari geolokasi yang nggak biasa. Coba korelasikan IP login dengan GeoIP database."

4. "Mungkin ada file .exe yang dijalankan dari folder %TEMP%. Coba cek process creation dari path mencurigakan."

Tools untuk Threat Hunting:

• Velociraptor — query endpoint secara real-time dengan VQL (Velociraptor Query Language).
• Kibana — search dan filter log di Elastic.
• Jupyter Notebooks + Pandas — analisis data log secara programatis.
• CyberChef — decode/encode, data analysis manual.

False Positive vs True Positive

Ini masalah terbesar dalam deteksi insiden. Bikin rules terlalu sensitif → false positive banjir → alert fatigue → tim mulai ignore alert. Bikin rules terlalu longgar → insiden lolos.

Cara Mengurangi False Positive:

1. Whitelist — proses yang legitimate (misalnya backup script yang jalan tiap jam 3 pagi) jangan di-alert.
2. Threshold — jangan alert untuk 1x failed login. Alert kalau >15x dalam 5 menit.
3. Context — gabungkan beberapa event. 1x failed login + 1x success + 1x process creation dari IP yang sama = lebih meyakinkan.
4. Tuning berkala — setiap bulan, review rules. Mana yang banyak false positive? Diperbaiki rules-nya.
5. Machine learning (untuk SIEM yang lebih advanced) — auto-baseline normal behavior dan alert untuk anomali.

Triage: Apa yang Harus Dilakukan Setelah Alert?

Setiap alert harus melalui triage:

1. Verifikasi — apakah ini benar-benar insiden? Cek source data, cek apakah ada pola serupa.
2. Klasifikasi severity — Low / Medium / High / Critical.
3. Eskalasi ke tim yang tepat — kalau severity High/Critical, langsung aktifkan Incident Manager.
4. Dokumentasi — catat alert, hasil triage, keputusan.

Membangun Kemampuan Deteksi di Organisasi Kecil

Lo nggak punya budget buat SIEM enterprise. Tenang. Ini langkah realistisnya:

1. Minggu 1-2: Setup Wazuh di satu server. Install agent di 3-5 endpoint penting.
2. Minggu 3-4: Setup Sysmon di semua Windows endpoint. Pakai SwiftOnSecurity config.
3. Minggu 5-6: Konfigurasi alert dasar — brute force, suspicious process, malware hash.
4. Minggu 7-8: Bikin dashboard Kibana untuk visualisasi.
5. Minggu 9+: Mulai threat hunting ringan — seminggu sekali, cek anomali di dashboard.

Dengan setup ini, lo udah punya visibilitas yang jauh lebih baik daripada nggak ada monitoring sama sekali.

Penutup

Deteksi dini bukan tentang punya tools paling mahal. Ini tentang:

1. Visibilitas — lo harus bisa melihat apa yang terjadi di infrastruktur lo.
2. Baseline — lo harus tau apa yang "normal" supaya bisa mengenali yang "tidak normal".
3. Alert yang bermakna — lebih baik 5 alert akurat per hari daripada 500 false positive.
4. Response time — deteksi tanpa respons itu percuma. Setiap alert harus ada tindak lanjutnya.

Di artikel berikutnya, kita bakal bahas komunikasi krisis saat insiden siber — gimana caranya ngomong ke manajemen, pelanggan, dan media tanpa bikin keadaan tambah parah. Stay tuned!

Ada pertanyaan? Kontak aja. Butuh referensi lain? Cek Respons Insiden.

Sekarang, install Wazuh. Seriously. Jangan tunda.

Ah, satu lagi sebelum gue tutup. Kalau lo udah setup SIEM dan EDR, jangan langsung puas dan bilang "selesai". Monitoring keamanan itu bukan proyek one-time setup — ini proses berkelanjutan. Lo harus terus tuning rules, update threat intelligence, dan belajar dari alert yang muncul. Tools yang nggak pernah di-tuning bakal jadi noise generator — banyak alert tapi nggak bermakna. Luangkan waktu minimal 2 jam seminggu untuk review dashboard, cek alert yang muncul, perbaiki rules yang terlalu sensitif atau terlalu longgar, dan baca threat intelligence terbaru. Konsistensi lebih penting daripada setup awal yang sempurna. Karena ancaman berubah setiap hari — malware baru muncul, teknik attacker berkembang, infrastruktur lo berubah — dan monitoring lo harus ikut beradaptasi. Threat intelligence feed yang lo pakai bulan ini mungkin sudah outdated bulan depan. Rules yang akurat sekarang mungkin menghasilkan false positive setelah lo upgrade aplikasi. Jadi jadikan tuning sebagai ritual mingguan. Block 2 jam di kalender. Tidak bisa dinego. Itu investasi waktu yang return-nya tidak terlihat sekarang, tapi akan sangat terasa saat lo berhasil mendeteksi serangan sebelum jadi bencana. Tim yang disiplin tuning seminggu sekali bakal jauh lebih efektif daripada tim yang setup sekali terus ditinggal setahun. Pantau.