Entri Jurnal
Logging & Alerting Failures adalah kondisi di mana aplikasi dan infrastruktur gagal mencatat aktivitas keamanan yang penting, atau mencatatnya tetapi tidak menghasilkan alert yang tepat waktu dan tepat sasaran kepada pihak yang harus merespons.
Ini adalah satu-satunya kategori dalam OWASP Top 10 yang bukan tentang bagaimana penyerang masuk ke sistem, melainkan tentang mengapa kita tidak mengetahuinya ketika mereka masuk. Logging dan alerting yang baik tidak mencegah serangan — tetapi menentukan apakah serangan tersebut ditemukan dalam hitungan menit atau bertahun-tahun kemudian.
Dalam bahasa bisnis: ini adalah perbedaan antara mengetahui bahwa kebakaran terjadi di menit pertama (dengan detektor asap dan sprinkler) versus mengetahuinya setelah gedung sudah rata dengan tanah. Sistem keamanan tanpa logging dan alerting yang efektif tidak memiliki kemampuan deteksi dan respons — dan dalam keamanan modern, kemampuan deteksi sama pentingnya dengan kemampuan pencegahan.
Paradoks Kesederhanaan
Logging terlihat mudah: tinggal catat semua kejadian. Namun logging keamanan yang efektif membutuhkan keputusan yang tidak trivial: apa yang dicatat, seberapa detail, disimpan di mana, berapa lama, dan kapan harus menghasilkan alert. Setiap keputusan ini memiliki trade-off antara visibilitas, storage cost, dan signal-to-noise ratio.
Alert Fatigue
Sistem yang menghasilkan terlalu banyak alert palsu (false positive) menghasilkan tim yang akhirnya mengabaikan semua alert — termasuk yang nyata. Ini adalah paradoks yang sangat umum: lebih banyak monitoring kadang menghasilkan lebih sedikit deteksi efektif.
Kurangnya Standar
Tidak ada standar logging yang universal diadopsi oleh semua aplikasi. Setiap tim, setiap aplikasi, setiap vendor memiliki format dan level detail logging yang berbeda — membuat korelasi lintas sistem menjadi sangat sulit.
Logging Dianggap Overhead
Dalam banyak tim engineering, logging diperlakukan sebagai fitur non-fungsional yang bisa "ditambahkan nanti" — dan sering kali "nanti" tidak pernah datang.
Authentication Events:
Login berhasil: user, timestamp, IP, device, lokasi
Login gagal: semua percobaan, termasuk username yang dicoba
Logout
Perubahan password atau kredensial
Aktivasi/deaktivasi MFA
Permintaan dan penggunaan reset password
Authorization Events:
Akses yang ditolak (403 Forbidden)
Upaya akses ke resource yang tidak seharusnya (force browsing attempt)
Perubahan hak akses atau peran pengguna
Penggunaan fungsi administratif
Data Access Events:
Akses ke data yang sangat sensitif (data kartu, data medis, data finansial)
Export atau download dalam jumlah besar
Modifikasi atau penghapusan data kritis
Application Events:
Input validation failures
Error kriptografi
Kegagalan integritas
Exception yang tidak tertangani
Infrastructure Events:
Perubahan konfigurasi sistem
Akses ke server melalui SSH atau RDP
Perubahan firewall rules
Start/stop layanan kritis
Sama pentingnya adalah mengetahui apa yang tidak boleh masuk dalam log:
Password atau kredensial dalam bentuk apapun
Token autentikasi atau session ID lengkap
Nomor kartu kredit penuh
Data pribadi yang tidak perlu untuk investigasi
Secrets atau API keys
Log yang mengandung data sensitif dapat mengubah security incident menjadi data breach yang jauh lebih serius.
Setiap log entry yang bermakna untuk investigasi keamanan harus mengandung:
{
"timestamp": "2025-01-15T08:23:41.123Z", // ISO 8601, UTC
"event_type": "AUTH_FAILURE",
"severity": "WARNING",
"user_id": "USR-10234", // anonymized jika perlu
"session_id": "SES-abc123", // partial/hashed
"source_ip": "203.0.113.42",
"user_agent": "Mozilla/5.0...",
"resource": "/api/user/login",
"action": "POST",
"result": "FAILURE",
"reason": "INVALID_PASSWORD",
"request_id": "REQ-uuid-here", // untuk korelasi
"environment": "production",
"application": "banking-portal"
}
Timestamp yang akurat
Pastikan semua sistem menggunakan waktu yang tersinkronisasi (NTP). Log dengan timestamp yang salah membuat korelasi dan forensik menjadi sangat sulit atau tidak mungkin.
Authentication failures, authorization denials, dan input validation errors tidak dicatat sama sekali. Penyerang dapat melakukan ribuan percobaan brute force atau IDOR enumeration tanpa meninggalkan jejak.
Log mencatat bahwa ada login failure tetapi tidak mencatat IP address, username yang dicoba, atau pola lain yang diperlukan untuk investigasi.
Log dikumpulkan tetapi tidak ada rule atau threshold yang menghasilkan alert ketika pola mencurigakan terdeteksi. Tim keamanan tidak akan pernah tahu ada serangan aktif kecuali mereka kebetulan melihat log.
Penyerang yang berhasil mengkompromikan sistem sering menghapus atau memodifikasi log untuk menghapus jejak mereka. Log yang dapat ditulis oleh aplikasi yang dikompromikan adalah log yang tidak dapat dipercaya.
Log dihapus setelah beberapa hari karena storage concerns. Investigasi insiden yang baru ditemukan sering membutuhkan log dari berbulan-bulan yang lalu — yang sudah tidak ada.
Penyerang memanipulasi input yang masuk ke dalam log untuk menyisipkan entri palsu atau mengaburkan aktivitas berbahaya:
Input berbahaya: "admin\nINFO: Login successful for admin"
Hasil di log:
WARNING: Login failed for admin
INFO: Login successful for admin ← entri palsu yang disisipkan
Sistem yang menghasilkan ribuan alert per hari untuk event yang tidak signifikan menyebabkan tim SOC mengabaikan semua alert — termasuk yang benar-benar kritis.
Log ada di berbagai sistem tetapi tidak dikorelasikan. Serangan yang tersebar di beberapa sistem (lateral movement) tidak terdeteksi karena tidak ada mekanisme untuk menghubungkan event dari sumber yang berbeda.
Efektivitas logging dan alerting diukur terutama melalui dua metrik:
MTTD (Mean Time to Detect) — Rata-rata waktu dari awal serangan hingga tim menyadari ada insiden. Berdasarkan laporan Verizon DBIR dan IBM Cost of Data Breach:
Rata-rata global 2024: 194 hari untuk mendeteksi breach
Organisasi dengan logging dan monitoring matang: < 30 hari
Organisasi terbaik: < 24 jam
MTTR (Mean Time to Respond) — Rata-rata waktu dari deteksi hingga insiden terkontainment.
Rata-rata global 2024: 64 hari untuk mengandung setelah deteksi
Korelasi kuat: semakin cepat deteksi, semakin rendah biaya insiden
Biaya insiden berdasarkan MTTD:
Breach terdeteksi dalam < 200 hari: rata-rata $4,45 juta
Breach terdeteksi dalam > 200 hari: rata-rata $5,36 juta
Selisih: lebih dari $900.000 — hanya dari perbedaan kecepatan deteksi
SIEM (Security Information and Event Management) adalah platform yang mengumpulkan, menormalisasi, mengkorelasikan, dan menganalisis log dari seluruh lingkungan untuk mendeteksi ancaman dan menghasilkan alert yang actionable.
Kemampuan inti SIEM:
Log aggregation: Mengumpulkan log dari semua sumber dalam format terpusat
Normalization: Mengubah berbagai format log ke skema yang seragam
Correlation rules: Mendeteksi pola serangan yang tersebar di beberapa event
Alerting: Menghasilkan alert berdasarkan rule atau anomali statistik
Investigation: Menyediakan antarmuka untuk investigasi forensik
Reporting: Laporan kepatuhan dan postur keamanan
Generasi SIEM Modern — SIEM terbaru menggabungkan kemampuan UEBA (User and Entity Behavior Analytics) yang menggunakan machine learning untuk mendeteksi anomali yang tidak ter-cover oleh rule berbasis signature.
Rule deteksi yang baik adalah fondasi dari alerting yang efektif. Prinsip rule yang baik:
Specific: Rule harus cukup spesifik untuk meminimalkan false positive tanpa melewatkan true positive.
Actionable: Setiap alert harus menghasilkan tindakan yang jelas — bukan hanya "ada sesuatu yang aneh."
Tunable: Rule harus dapat disesuaikan berdasarkan feedback dari SOC analyst — meningkatkan threshold untuk alert yang terlalu noisy, menurunkan untuk yang melewatkan serangan nyata.
Contoh detection rules berbasis OWASP A09:
Rule: Brute Force Login Detection
Kondisi: Lebih dari 10 AUTH_FAILURE dari IP yang sama dalam 5 menit
Severity: HIGH
Action: Alert ke SOC + Auto-block IP selama 1 jam
Rule: Privilege Escalation Attempt
Kondisi: User dengan role 'user' mencoba mengakses endpoint '/admin/*'
Severity: HIGH
Action: Alert ke SOC + Log ke incident queue
Rule: Unusual Data Export
Kondisi: Single user mengunduh > 1000 records dalam 10 menit
Severity: MEDIUM
Action: Alert ke SOC untuk review
Equifax (2017)
Penyerang berada dalam jaringan Equifax selama 78 hari sebelum terdeteksi. Selama itu, 147 juta catatan penduduk Amerika dicuri. Investigasi menemukan bahwa traffic inspeksi SSL telah dinonaktifkan selama hampir setahun karena sertifikat expired — sehingga penyerang bergerak dalam blind spot monitoring selama berbulan-bulan. Total kerugian: lebih dari $1,4 miliar.
Target (2013)
Sistem monitoring Target mendeteksi aktivitas mencurigakan dan menghasilkan alert. Alert tersebut diabaikan oleh tim keamanan yang kewalahan dengan volume notifikasi. 40 juta data kartu kredit dicuri. Ini adalah contoh bukan kegagalan deteksi teknis, tetapi kegagalan proses respons terhadap alert.
SolarWinds (2020)
Penyerang berada dalam ribuan jaringan selama rata-rata 6–9 bulan sebelum terdeteksi — dan hanya terdeteksi karena firma keamanan FireEye menyadari alat red team mereka sendiri dicuri.
Perusahaan Finansial Indonesia (Anonimisasi)
Dalam beberapa kasus yang diinvestigasi oleh BSSN dan tim respons insiden nasional, ditemukan bahwa penyerang telah memiliki akses ke sistem selama 3–6 bulan sebelum terdeteksi. Tidak ada monitoring real-time — hanya audit berkala yang menemukan anomali secara kebetulan.
Regulasi | Persyaratan Logging |
|---|---|
UU PDP Indonesia | Kewajiban mampu mendeteksi dan melaporkan breach dalam 14 hari kerja — tidak mungkin tanpa logging yang memadai |
POJK MRTI | Log transaksi dan akses sistem perbankan wajib disimpan minimal 5 tahun |
PCI-DSS v4.0 | Log semua akses ke cardholder data, audit trail lengkap, retensi minimal 12 bulan |
ISO 27001:2022 | Control 8.15: Logging; Control 8.16: Monitoring activities |
BSSN Standar Keamanan | Log keamanan sebagai komponen wajib sistem elektronik strategis |
Tentukan Apa yang Harus Dicatat
Mulai dari event keamanan kritis (auth failures, authz denials, data access) dan tambahkan secara bertahap. Jangan mencoba mencatat segalanya sekaligus — mulai dari yang paling bernilai untuk deteksi.
Centralize Log Management
Kirim semua log ke platform terpusat yang terpisah dari sistem yang menghasilkannya. Log yang disimpan hanya di sistem sumber dapat dimanipulasi atau dihapus oleh penyerang yang mengkompromikan sistem tersebut.
Implement SIEM dengan Detection Rules
Log tanpa alerting hanya berguna untuk forensik pasca-insiden. SIEM dengan detection rules yang tepat memungkinkan deteksi real-time.
Lindungi Integritas Log
Gunakan log forwarding yang one-way (append-only), tanda tangani log entries secara kriptografis, dan simpan di platform yang tidak dapat dimodifikasi (WORM storage).
Tetapkan Retention Policy
Minimum: 90 hari online (searchable), 12 bulan archive. Untuk regulated industries: sesuaikan dengan persyaratan regulasi.
Tuning Berkelanjutan
Review false positive rate secara berkala dan sesuaikan rule. Lakukan purple team exercise untuk memverifikasi bahwa serangan nyata menghasilkan alert yang diharapkan.
Kategori | Vendor / Solusi | Kehadiran Indonesia |
|---|---|---|
SIEM | IBM QRadar | ✅ Tier 1 |
SIEM | Microsoft Sentinel | ✅ Tier 1 |
SIEM | Splunk (Cisco) | ✅ Tier 1 |
SIEM | Elastic SIEM (open-source) | Self-managed |
SIEM | Wazuh (open-source) | Self-managed |
SOAR | IBM Security QRadar SOAR | ✅ Tier 1 |
SOAR | Microsoft Sentinel (Automation) | ✅ Tier 1 |
Log Management | Elastic Stack (ELK) | Self-managed |
Log Management | Grafana Loki | Self-managed |
UEBA | Microsoft Sentinel UEBA | ✅ Tier 1 |
MSSP / SOC | Xynexis (SOC) | ✅ Lokal |
MSSP / SOC | IBM Managed Security Services | ✅ Tier 1 |
Network Detection | Palo Alto (Cortex XDR) | ✅ Tier 1 |
Network Detection | Fortinet (FortiSIEM) | ✅ Tier 1 |
Network Detection | Trend Micro (Vision One) | ✅ Tier 1 |
Catatan Indonesia: SIEM sudah cukup banyak diadopsi di sektor perbankan dan telekomunikasi — didorong regulasi OJK dan BSSN. Namun kualitas implementasi sangat bervariasi: banyak SIEM yang "berjalan" tetapi dengan detection rules minimal dan tanpa tuning berkala — menjadikannya koleksi log yang mahal tanpa kemampuan deteksi nyata.
Entri Jurnal
Logging & Alerting Failures adalah kondisi di mana aplikasi dan infrastruktur gagal mencatat aktivitas keamanan yang penting, atau mencatatnya tetapi tidak menghasilkan alert yang tepat waktu dan tepat sasaran kepada pihak yang harus merespons.
Ini adalah satu-satunya kategori dalam OWASP Top 10 yang bukan tentang bagaimana penyerang masuk ke sistem, melainkan tentang mengapa kita tidak mengetahuinya ketika mereka masuk. Logging dan alerting yang baik tidak mencegah serangan — tetapi menentukan apakah serangan tersebut ditemukan dalam hitungan menit atau bertahun-tahun kemudian.
Dalam bahasa bisnis: ini adalah perbedaan antara mengetahui bahwa kebakaran terjadi di menit pertama (dengan detektor asap dan sprinkler) versus mengetahuinya setelah gedung sudah rata dengan tanah. Sistem keamanan tanpa logging dan alerting yang efektif tidak memiliki kemampuan deteksi dan respons — dan dalam keamanan modern, kemampuan deteksi sama pentingnya dengan kemampuan pencegahan.
Paradoks Kesederhanaan
Logging terlihat mudah: tinggal catat semua kejadian. Namun logging keamanan yang efektif membutuhkan keputusan yang tidak trivial: apa yang dicatat, seberapa detail, disimpan di mana, berapa lama, dan kapan harus menghasilkan alert. Setiap keputusan ini memiliki trade-off antara visibilitas, storage cost, dan signal-to-noise ratio.
Alert Fatigue
Sistem yang menghasilkan terlalu banyak alert palsu (false positive) menghasilkan tim yang akhirnya mengabaikan semua alert — termasuk yang nyata. Ini adalah paradoks yang sangat umum: lebih banyak monitoring kadang menghasilkan lebih sedikit deteksi efektif.
Kurangnya Standar
Tidak ada standar logging yang universal diadopsi oleh semua aplikasi. Setiap tim, setiap aplikasi, setiap vendor memiliki format dan level detail logging yang berbeda — membuat korelasi lintas sistem menjadi sangat sulit.
Logging Dianggap Overhead
Dalam banyak tim engineering, logging diperlakukan sebagai fitur non-fungsional yang bisa "ditambahkan nanti" — dan sering kali "nanti" tidak pernah datang.
Authentication Events:
Login berhasil: user, timestamp, IP, device, lokasi
Login gagal: semua percobaan, termasuk username yang dicoba
Logout
Perubahan password atau kredensial
Aktivasi/deaktivasi MFA
Permintaan dan penggunaan reset password
Authorization Events:
Akses yang ditolak (403 Forbidden)
Upaya akses ke resource yang tidak seharusnya (force browsing attempt)
Perubahan hak akses atau peran pengguna
Penggunaan fungsi administratif
Data Access Events:
Akses ke data yang sangat sensitif (data kartu, data medis, data finansial)
Export atau download dalam jumlah besar
Modifikasi atau penghapusan data kritis
Application Events:
Input validation failures
Error kriptografi
Kegagalan integritas
Exception yang tidak tertangani
Infrastructure Events:
Perubahan konfigurasi sistem
Akses ke server melalui SSH atau RDP
Perubahan firewall rules
Start/stop layanan kritis
Sama pentingnya adalah mengetahui apa yang tidak boleh masuk dalam log:
Password atau kredensial dalam bentuk apapun
Token autentikasi atau session ID lengkap
Nomor kartu kredit penuh
Data pribadi yang tidak perlu untuk investigasi
Secrets atau API keys
Log yang mengandung data sensitif dapat mengubah security incident menjadi data breach yang jauh lebih serius.
Setiap log entry yang bermakna untuk investigasi keamanan harus mengandung:
{
"timestamp": "2025-01-15T08:23:41.123Z", // ISO 8601, UTC
"event_type": "AUTH_FAILURE",
"severity": "WARNING",
"user_id": "USR-10234", // anonymized jika perlu
"session_id": "SES-abc123", // partial/hashed
"source_ip": "203.0.113.42",
"user_agent": "Mozilla/5.0...",
"resource": "/api/user/login",
"action": "POST",
"result": "FAILURE",
"reason": "INVALID_PASSWORD",
"request_id": "REQ-uuid-here", // untuk korelasi
"environment": "production",
"application": "banking-portal"
}
Timestamp yang akurat
Pastikan semua sistem menggunakan waktu yang tersinkronisasi (NTP). Log dengan timestamp yang salah membuat korelasi dan forensik menjadi sangat sulit atau tidak mungkin.
Authentication failures, authorization denials, dan input validation errors tidak dicatat sama sekali. Penyerang dapat melakukan ribuan percobaan brute force atau IDOR enumeration tanpa meninggalkan jejak.
Log mencatat bahwa ada login failure tetapi tidak mencatat IP address, username yang dicoba, atau pola lain yang diperlukan untuk investigasi.
Log dikumpulkan tetapi tidak ada rule atau threshold yang menghasilkan alert ketika pola mencurigakan terdeteksi. Tim keamanan tidak akan pernah tahu ada serangan aktif kecuali mereka kebetulan melihat log.
Penyerang yang berhasil mengkompromikan sistem sering menghapus atau memodifikasi log untuk menghapus jejak mereka. Log yang dapat ditulis oleh aplikasi yang dikompromikan adalah log yang tidak dapat dipercaya.
Log dihapus setelah beberapa hari karena storage concerns. Investigasi insiden yang baru ditemukan sering membutuhkan log dari berbulan-bulan yang lalu — yang sudah tidak ada.
Penyerang memanipulasi input yang masuk ke dalam log untuk menyisipkan entri palsu atau mengaburkan aktivitas berbahaya:
Input berbahaya: "admin\nINFO: Login successful for admin"
Hasil di log:
WARNING: Login failed for admin
INFO: Login successful for admin ← entri palsu yang disisipkan
Sistem yang menghasilkan ribuan alert per hari untuk event yang tidak signifikan menyebabkan tim SOC mengabaikan semua alert — termasuk yang benar-benar kritis.
Log ada di berbagai sistem tetapi tidak dikorelasikan. Serangan yang tersebar di beberapa sistem (lateral movement) tidak terdeteksi karena tidak ada mekanisme untuk menghubungkan event dari sumber yang berbeda.
Efektivitas logging dan alerting diukur terutama melalui dua metrik:
MTTD (Mean Time to Detect) — Rata-rata waktu dari awal serangan hingga tim menyadari ada insiden. Berdasarkan laporan Verizon DBIR dan IBM Cost of Data Breach:
Rata-rata global 2024: 194 hari untuk mendeteksi breach
Organisasi dengan logging dan monitoring matang: < 30 hari
Organisasi terbaik: < 24 jam
MTTR (Mean Time to Respond) — Rata-rata waktu dari deteksi hingga insiden terkontainment.
Rata-rata global 2024: 64 hari untuk mengandung setelah deteksi
Korelasi kuat: semakin cepat deteksi, semakin rendah biaya insiden
Biaya insiden berdasarkan MTTD:
Breach terdeteksi dalam < 200 hari: rata-rata $4,45 juta
Breach terdeteksi dalam > 200 hari: rata-rata $5,36 juta
Selisih: lebih dari $900.000 — hanya dari perbedaan kecepatan deteksi
SIEM (Security Information and Event Management) adalah platform yang mengumpulkan, menormalisasi, mengkorelasikan, dan menganalisis log dari seluruh lingkungan untuk mendeteksi ancaman dan menghasilkan alert yang actionable.
Kemampuan inti SIEM:
Log aggregation: Mengumpulkan log dari semua sumber dalam format terpusat
Normalization: Mengubah berbagai format log ke skema yang seragam
Correlation rules: Mendeteksi pola serangan yang tersebar di beberapa event
Alerting: Menghasilkan alert berdasarkan rule atau anomali statistik
Investigation: Menyediakan antarmuka untuk investigasi forensik
Reporting: Laporan kepatuhan dan postur keamanan
Generasi SIEM Modern — SIEM terbaru menggabungkan kemampuan UEBA (User and Entity Behavior Analytics) yang menggunakan machine learning untuk mendeteksi anomali yang tidak ter-cover oleh rule berbasis signature.
Rule deteksi yang baik adalah fondasi dari alerting yang efektif. Prinsip rule yang baik:
Specific: Rule harus cukup spesifik untuk meminimalkan false positive tanpa melewatkan true positive.
Actionable: Setiap alert harus menghasilkan tindakan yang jelas — bukan hanya "ada sesuatu yang aneh."
Tunable: Rule harus dapat disesuaikan berdasarkan feedback dari SOC analyst — meningkatkan threshold untuk alert yang terlalu noisy, menurunkan untuk yang melewatkan serangan nyata.
Contoh detection rules berbasis OWASP A09:
Rule: Brute Force Login Detection
Kondisi: Lebih dari 10 AUTH_FAILURE dari IP yang sama dalam 5 menit
Severity: HIGH
Action: Alert ke SOC + Auto-block IP selama 1 jam
Rule: Privilege Escalation Attempt
Kondisi: User dengan role 'user' mencoba mengakses endpoint '/admin/*'
Severity: HIGH
Action: Alert ke SOC + Log ke incident queue
Rule: Unusual Data Export
Kondisi: Single user mengunduh > 1000 records dalam 10 menit
Severity: MEDIUM
Action: Alert ke SOC untuk review
Equifax (2017)
Penyerang berada dalam jaringan Equifax selama 78 hari sebelum terdeteksi. Selama itu, 147 juta catatan penduduk Amerika dicuri. Investigasi menemukan bahwa traffic inspeksi SSL telah dinonaktifkan selama hampir setahun karena sertifikat expired — sehingga penyerang bergerak dalam blind spot monitoring selama berbulan-bulan. Total kerugian: lebih dari $1,4 miliar.
Target (2013)
Sistem monitoring Target mendeteksi aktivitas mencurigakan dan menghasilkan alert. Alert tersebut diabaikan oleh tim keamanan yang kewalahan dengan volume notifikasi. 40 juta data kartu kredit dicuri. Ini adalah contoh bukan kegagalan deteksi teknis, tetapi kegagalan proses respons terhadap alert.
SolarWinds (2020)
Penyerang berada dalam ribuan jaringan selama rata-rata 6–9 bulan sebelum terdeteksi — dan hanya terdeteksi karena firma keamanan FireEye menyadari alat red team mereka sendiri dicuri.
Perusahaan Finansial Indonesia (Anonimisasi)
Dalam beberapa kasus yang diinvestigasi oleh BSSN dan tim respons insiden nasional, ditemukan bahwa penyerang telah memiliki akses ke sistem selama 3–6 bulan sebelum terdeteksi. Tidak ada monitoring real-time — hanya audit berkala yang menemukan anomali secara kebetulan.
Regulasi | Persyaratan Logging |
|---|---|
UU PDP Indonesia | Kewajiban mampu mendeteksi dan melaporkan breach dalam 14 hari kerja — tidak mungkin tanpa logging yang memadai |
POJK MRTI | Log transaksi dan akses sistem perbankan wajib disimpan minimal 5 tahun |
PCI-DSS v4.0 | Log semua akses ke cardholder data, audit trail lengkap, retensi minimal 12 bulan |
ISO 27001:2022 | Control 8.15: Logging; Control 8.16: Monitoring activities |
BSSN Standar Keamanan | Log keamanan sebagai komponen wajib sistem elektronik strategis |
Tentukan Apa yang Harus Dicatat
Mulai dari event keamanan kritis (auth failures, authz denials, data access) dan tambahkan secara bertahap. Jangan mencoba mencatat segalanya sekaligus — mulai dari yang paling bernilai untuk deteksi.
Centralize Log Management
Kirim semua log ke platform terpusat yang terpisah dari sistem yang menghasilkannya. Log yang disimpan hanya di sistem sumber dapat dimanipulasi atau dihapus oleh penyerang yang mengkompromikan sistem tersebut.
Implement SIEM dengan Detection Rules
Log tanpa alerting hanya berguna untuk forensik pasca-insiden. SIEM dengan detection rules yang tepat memungkinkan deteksi real-time.
Lindungi Integritas Log
Gunakan log forwarding yang one-way (append-only), tanda tangani log entries secara kriptografis, dan simpan di platform yang tidak dapat dimodifikasi (WORM storage).
Tetapkan Retention Policy
Minimum: 90 hari online (searchable), 12 bulan archive. Untuk regulated industries: sesuaikan dengan persyaratan regulasi.
Tuning Berkelanjutan
Review false positive rate secara berkala dan sesuaikan rule. Lakukan purple team exercise untuk memverifikasi bahwa serangan nyata menghasilkan alert yang diharapkan.
Kategori | Vendor / Solusi | Kehadiran Indonesia |
|---|---|---|
SIEM | IBM QRadar | ✅ Tier 1 |
SIEM | Microsoft Sentinel | ✅ Tier 1 |
SIEM | Splunk (Cisco) | ✅ Tier 1 |
SIEM | Elastic SIEM (open-source) | Self-managed |
SIEM | Wazuh (open-source) | Self-managed |
SOAR | IBM Security QRadar SOAR | ✅ Tier 1 |
SOAR | Microsoft Sentinel (Automation) | ✅ Tier 1 |
Log Management | Elastic Stack (ELK) | Self-managed |
Log Management | Grafana Loki | Self-managed |
UEBA | Microsoft Sentinel UEBA | ✅ Tier 1 |
MSSP / SOC | Xynexis (SOC) | ✅ Lokal |
MSSP / SOC | IBM Managed Security Services | ✅ Tier 1 |
Network Detection | Palo Alto (Cortex XDR) | ✅ Tier 1 |
Network Detection | Fortinet (FortiSIEM) | ✅ Tier 1 |
Network Detection | Trend Micro (Vision One) | ✅ Tier 1 |
Catatan Indonesia: SIEM sudah cukup banyak diadopsi di sektor perbankan dan telekomunikasi — didorong regulasi OJK dan BSSN. Namun kualitas implementasi sangat bervariasi: banyak SIEM yang "berjalan" tetapi dengan detection rules minimal dan tanpa tuning berkala — menjadikannya koleksi log yang mahal tanpa kemampuan deteksi nyata.