Detection Rules

Detection rules adalah fondasi operasi keamanan siber yang memungkinkan organisasi mengidentifikasi aktivitas mencurigakan secara otomatis. Pengelolaan rule yang efektif membutuhkan pendekatan sistematis yang mencakup seluruh lifecycle, jaminan kualitas, pengujian, dan kolaborasi.

Lifecycle Detection Rules

Setiap detection rule melewati serangkaian tahapan sepanjang masa pakainya:

1. Design

Tahap awal di mana kebutuhan deteksi diidentifikasi berdasarkan threat intelligence, MITRE ATT&CK mapping, atau gap analysis. Output dari tahap ini adalah spesifikasi rule yang mencakup: teknik yang akan dideteksi, sumber log yang diperlukan, kondisi pemicu, dan tingkat keparahan yang diharapkan.

2. Implement

Penulisan rule dalam format yang sesuai (Sigma, YARA, query SIEM native). Rule harus mengikuti standar organisasi: penamaan konsisten, tagging MITRE yang akurat, metadata lengkap, dan dokumentasi yang jelas.

3. Test

Rule diuji terhadap dataset historis dan skenario eksplisit untuk memverifikasi bahwa rule menangkap true positive tanpa menghasilkan false positive berlebihan. Pengujian mencakup unit test, integration test, dan regression test.

4. Tune

Berdasarkan hasil testing dan operasi langsung, rule disesuaikan untuk meningkatkan presisi. Penyetelan dapat meliputi penambahan kondisi pengecualian, penyesuaian threshold, atau modifikasi logsource.

5. Deprecate

Jika rule tidak relevan lagi - karena perubahan infrastruktur, teknik serangan yang sudah usang, atau adanya rule baru yang lebih baik - rule ditandai sebagai deprecated dan akhirnya dihapus setelah masa transisi.

Rule Quality - Low False Positive, High Fidelity

Kualitas rule diukur dari kemampuannya menghasilkan alert yang akurat dan actionable:

Low False Positive (FP) - Rule yang baik meminimalkan false positive. Setiap FP mengurangi kredibilitas sistem deteksi dan membuang waktu analyst. Strategi mengurangi FP: exception list granular, whitelisting logika, contextual filtering (misalnya exclude host tertentu).
High Fidelity - Rule harus menghasilkan true positive yang konsisten dan relevan. Fidelity tinggi berarti rule secara tepat menangkap indikator aktivitas berbahaya tanpa overlap berlebihan dengan aktivitas normal.

Metrik Kualitas:

Precision = TP / (TP + FP) - Seberapa akurat rule saat menyatakan alert.
Recall = TP / (TP + FN) - Seberapa baik rule menangkap semua insiden.
Signal-to-Noise Ratio - Perbandingan alert berguna vs. noise.

Testing Methodology

Atomic Red Team

Framework open-source oleh Red Canary yang menyediakan test atomik untuk setiap teknik MITRE ATT&CK. Setiap atom adalah prosedur terisolasi yang dapat dieksekusi dengan aman di lingkungan test. Contoh: atom T1059.001 (PowerShell Execution) akan menjalankan perintah PowerShell tertentu dan rule deteksi seharusnya menangkapnya.

CALDERA

Framework otomatis oleh MITRE untuk simulasi adversary emulation. Berbeda dengan Atomic Red Team yang fokus pada teknik individual, CALDERA menjalankan rantai serangan penuh (campaign) yang mereplikasi perilaku threat actor nyata. Ini menguji tidak hanya satu rule tetapi bagaimana multiple rules bekerja bersama dalam skenario kompleks.

Detection Coverage

Pemetaan rule terhadap framework MITRE ATT&CK untuk mengidentifikasi gap coverage. Alat seperti Atomic Red Team mapping, MITRE Navigator, atau DeTT&CT digunakan untuk:

Memvisualisasikan coverage teknik per teknik.
Mengidentifikasi teknik yang belum memiliki deteksi.
Memprioritaskan pengembangan rule berdasarkan threat landscape.

Alert Enrichment

Enrichment menambahkan konteks pada alert mentah sebelum dikirim ke analyst:

Threat Intelligence - IP, domain, hash dicek terhadap feeds intel (VirusTotal, AlienVault OTX, MISP).
Asset Context - Informasi kepemilikan, kritikalitas, dan lingkungan host.
User Context - Role pengguna, aktivitas normal baseline, riwayat.
Geolocation - Lokasi geografis IP sumber.

Rule Tuning dan Suppression

Rule Tuning - Penyesuaian kontinu berdasarkan umpan balik analyst. Threshold dinaikkan jika FP tinggi, atau diturunkan jika FN terdeteksi. Exception logic ditambahkan untuk false positive yang diketahui.
Suppression Rules - Aturan pengecualian yang menekan alert dalam kondisi tertentu: known good host, scheduled maintenance window, software update cycles. Penting untuk menghindari alert fatigue.

Rollback dan Versioning

Versioning - Setiap perubahan rule harus didokumentasikan dengan versioning (semantic versioning atau date-based). Riwayat perubahan disimpan untuk audit trail.
Rollback - Kemampuan mengembalikan ke versi rule sebelumnya jika perubahan baru menyebabkan false positive massal atau missed detection. CI/CD pipeline harus menyimpan artefak versi sebelumnya untuk rollback cepat.

Collaboration

Detection engineering bukan upaya individu melainkan kolaborasi tim dan komunitas:

GitHub - Platform utama untuk berbagi detection rule publik. Repository seperti SigmaHQ, FlorianRoth/detection-rules, dan YARA-Rules memungkinkan kontribusi global, code review, issue tracking, dan fork untuk kustomisasi.
OpenDXL - Open Data Exchange Layer - framework untuk pertukaran data dan konten deteksi antar platform keamanan secara real-time. Memungkinkan distribusi rule, indikator, dan konteks threat ke berbagai produk keamanan (firewall, EDR, SIEM) dalam ekosistem yang saling terhubung.

Dengan menggabungkan lifecycle yang terstruktur, pengujian yang ketat, dan kolaborasi yang terbuka, organisasi dapat membangun program detection engineering yang mature, adaptif, dan efektif dalam menghadapi ancaman siber yang terus berkembang.