Mengoptimalkan performa deteksi dan pelaporan

Didukung di:

Dokumen ini menjelaskan cara mengoptimalkan performa deteksi dan pelaporan.

Total latensi deteksi

Untuk pusat operasi keamanan (SOC), total mean time to detect (MTTD) adalah jumlah penundaan waktu di seluruh pipeline keamanan. Untuk mengukur dan mengurangi MTTD secara akurat, Anda perlu melacak tiga komponen utama:

Latensi penyerapan log (pembuatan log hingga penyerapan data)

Latensi penyerapan log adalah waktu yang berlalu antara saat peristiwa keamanan terjadi di sistem sumber (metadata.event_timestamp) dan saat log berhasil diserap dan diuraikan di Google Security Operations (metadata.ingested_time).

Faktor kontribusi:

  • Masalah pengumpul atau penerusan (misalnya, backlog atau pembatasan jaringan).
  • Masalah parsing sumber log (misalnya, keterlambatan dalam normalisasi UDM).

Untuk mengurangi latensi penyerapan log, lakukan hal berikut:

  • Pantau kondisi sumber log dan optimalkan konfigurasi pengumpul atau penerus.
  • Untuk memantau perbedaannya, di YARA-L atau Data Lake, bandingkan stempel waktu UDM—metadata.ingested_timestamp versus metadata.event_timestamp.

Latensi pemrosesan aturan (penyerapan data hingga pembuatan deteksi)

Latensi pemrosesan aturan adalah waktu yang berlalu antara penyerapan data dan saat mesin deteksi berhasil membuat pemberitahuan (detection.creation_time). Komponen ini sangat dipengaruhi oleh konfigurasi aturan YARA-L Anda.

Faktor kontribusi:

  • Frekuensi menjalankan aturan: hampir real-time (terbaik), 10 menit, 1 jam, atau 24 jam. Makin tinggi frekuensi, makin tinggi latensi pemrosesan minimum. Untuk mengetahui informasi selengkapnya, lihat Menetapkan frekuensi eksekusi.
  • Jenis dan kompleksitas aturan: aturan multi-peristiwa memerlukan jendela kecocokan untuk memprosesnya sepenuhnya, yang menimbulkan latensi bawaan. Aturan komposit yang mengandalkan deteksi non-real-time lainnya juga menyebabkan penundaan. Untuk mengetahui informasi selengkapnya, lihat Deteksi komposit.

Untuk mengurangi latensi pemrosesan aturan, lakukan hal berikut:

  • Gunakan aturan peristiwa tunggal yang berjalan hampir secara real-time jika memungkinkan.
  • Untuk aturan multi-peristiwa, tetapkan ukuran periode sekecil mungkin.

Untuk mengetahui informasi selengkapnya, lihat Contoh kueri YARA-L 2.0 untuk Dasbor.

Aturan YARA-L untuk memantau latensi pemrosesan aturan

Aturan YARA-L berikut mengidentifikasi instance saat selisih antara waktu log diserap dan waktu deteksi dibuat melebihi nilai minimum tertentu. Gunakan aturan untuk mengidentifikasi hambatan performa di pipeline deteksi Anda.

Deploy aturan ini di lingkungan pengujian Anda untuk membuat tolok ukur sumber log Anda.

Anda dapat mengekspor hasil ini ke dasbor untuk memvisualisasikan tren latensi di berbagai jenis log.

Aturan membandingkan metadata.event_timestamp (saat aktivitas terjadi) dengan metadata.ingested_time (saat Google SecOps menerima log).

rule rule_processing_latency_monitor {
  meta:
    author = "SecOps Engineering"
    description = "Alerts when the gap between ingestion and detection creation is greater than 15 minutes."
    severity = "Low"

  events:
    $event.metadata.event_timestamp.seconds = $event_ts
    $event.metadata.ingested_time.seconds = $ingest_ts
    
    // Calculate the delta in seconds
    $latency_delta = $ingest_ts - $event_ts

    // Threshold: 900 seconds (15 minutes)
    $latency_delta > 900

  match:
    $event.metadata.log_type over 1h

  outcome:
    $max_latency = max($latency_delta)
    $log_source = array_distinct($event.metadata.log_type)

  condition:
    $event
}

Latensi pengakuan kasus (pembuatan deteksi hingga penugasan analis)

Bagian ini tidak relevan bagi pelanggan yang menggunakan platform mandiri Google SecOps SIEM.

Latensi konfirmasi kasus adalah waktu yang berlalu antara deteksi yang membuat pemberitahuan dan pemberitahuan yang dikonfirmasi oleh analis untuk triase dalam komponen SOAR.

Metrik rata-rata waktu untuk mengonfirmasi (MTTA) secara khusus melacak efisiensi tim SOC dalam merespons pemberitahuan yang dihasilkan.

  • Untuk mengurangi latensi konfirmasi kasus, optimalkan perutean, penyesuaian, dan otomatisasi pemberitahuan (misalnya, menggunakan playbook untuk penetapan atau pengayaan otomatis) agar pemberitahuan dapat dipindahkan dengan cepat ke tahap triase.

Langkah berikutnya

  • Untuk mempelajari cara pemutaran ulang aturan (juga disebut penyelesaian pembersihan) mengelola data yang terlambat tiba dan pembaruan konteks, serta pengaruhnya terhadap metrik MTTD, lihat Memahami pemutaran ulang aturan dan MTTD.
  • Untuk mempelajari lebih lanjut penundaan deteksi aturan di Google SecOps, faktor-faktor penyebab, pemecahan masalah, dan teknik untuk mengurangi penundaan, lihat Memahami penundaan deteksi aturan.

Perlu bantuan lain? Dapatkan jawaban dari anggota Komunitas dan profesional Google SecOps.