Memantau performa aturan

Didukung di:

Panduan ini ditujukan untuk engineer keamanan yang membuat, men-deploy, dan memantau aturan di Google Security Operations. Panduan ini menjelaskan cara memantau aturan untuk memastikan aturan berfungsi sebagaimana mestinya dan tidak menggunakan resource secara berlebihan menggunakan data yang tersedia di instance Google SecOps Anda. Data ini membantu Anda men-debug deteksi yang tertunda, memahami dampak data pengayaan yang terlambat tiba pada aturan, dan mengidentifikasi aturan mana yang memiliki waktu rata-rata tertinggi untuk mendeteksi (MTTD).

Panduan ini menyediakan dokumentasi tentang tugas berikut:

  • Cara mengevaluasi aturan selama rilis awal, menerima pemberitahuan, dan memeriksa Dasbor Aturan untuk memantau kondisinya.

  • Cara mengidentifikasi penyebab penundaan deteksi (misalnya, apakah penundaan tersebut disebabkan oleh penyerapan yang terlambat atau logika yang tidak efisien) dan menyesuaikan pelaporan Waktu Rata-Rata untuk Mendeteksi (MTTD) atau menyesuaikan aturan dengan Pengecualian aturan tambahan.

Sebelum memulai

Untuk melihat dan mengubah aturan seperti yang dijelaskan dalam dokumen ini, Anda harus menjadi Editor Chronicle API. Untuk mengetahui informasi selengkapnya, lihat Peran dan izin Google Security Operations.

Sebelum menganalisis efektivitas aturan di Google SecOps, Anda harus memahami bahasa YARA-L, kueri YARA-L, cara membuat dan mengelola aturan, serta cara membuat dasbor:

Terminologi utama

  • Aturan: Mengidentifikasi ancaman secara otomatis saat data log diserap ke akun Google SecOps Anda.
  • Kuota: Batas volume penyerapan data Anda, jumlah dan kompleksitas kueri yang dapat Anda jalankan terhadap data Anda, serta jumlah dan kompleksitas aturan yang aktif di akun Google SecOps Anda.
  • Pemberitahuan dan deteksi: Masalah keamanan yang diidentifikasi oleh Google SecOps dan infrastruktur keamanan Anda sendiri yang memerlukan perhatian Anda.
  • Penyerapan: Proses mengimpor data keamanan Anda ke Google SecOps dan mengonversinya ke UDM.
  • Pemutaran ulang aturan: Pemutaran ulang aturan secara otomatis terhadap data yang ada jika data konteks yang relevan tiba atau diproses setelah data peristiwa awal.
  • Retrohunt: Menerapkan aturan baru ke data yang ada untuk mengidentifikasi ancaman yang sebelumnya tidak terdeteksi.

Cara menganalisis aturan

Bagian berikut menjelaskan cara menganalisis performa aturan Anda.

Menguji dan mengevaluasi aturan setelah deployment

Saat pertama kali men-deploy aturan ke produksi, pantau aturan tersebut di dasbor Rule Observability selama 24 hingga 48 jam:

  1. Buka Dasbor

  2. Telusuri Rule Observability.

  3. Telusuri aturan baru di kolom Aturan. Dasbor Rule Observability mencakup statistik seperti jumlah deteksi, latensi penyerapan, dan waktu dari penyerapan hingga deteksi.

Untuk memastikan logika aturan tidak menyebabkan penundaan buatan sebelum mulai membuat pemberitahuan prioritas tinggi, Anda dapat menggunakan referensi skema untuk deteksi. Skema menentukan format terstruktur yang digunakan untuk memantau pemberitahuan keamanan. Skema ini dioptimalkan untuk melacak frekuensi deteksi, distribusi risiko, dan performa aturan. Anda dapat memahami cara menggunakan skema dengan melihat contoh Kueri.

Mengidentifikasi alasan penundaan hasil aturan

Selesaikan langkah-langkah berikut untuk menentukan apakah hasil aturan tertunda dan, jika ya, mengapa:

  1. Buka Deteksi > Pemberitahuan & IOC.
  2. Di tab Pemberitahuan, temukan kolom Jenis Deteksi.
  3. Telusuri pemberitahuan dengan ikon bola lampu kuning.
  4. Arahkan kursor ke ikon untuk melihat apakah deteksi dipicu oleh salah satu hal berikut:
    • Pemrosesan ulang aturan: Dipicu secara manual oleh pengguna.
    • Retrohunt: Dipicu secara manual oleh pengguna.
    • Data peristiwa yang tertunda: Menunjukkan apakah penundaan deteksi diharapkan.

Memfilter pemberitahuan berdasarkan waktu deteksi

  1. Buka Deteksi > Pemberitahuan & IOC.

  2. Di tab Pemberitahuan, gunakan elemen filter untuk kolom Waktu deteksi guna mengurutkan deteksi berdasarkan waktu kedatangannya.

  3. Klik ikon muat ulang di bagian atas tabel, lalu klik Muat Ulang Sekarang. Anda dapat melihat pemberitahuan terbaru yang tiba di akun Google SecOps Anda dan aturan yang terkait dengan setiap pemberitahuan (periksa kolom Nama aturan).

Memeriksa metadata

Untuk mendapatkan insight tambahan tentang performa aturan Anda, Anda dapat memeriksa JSON deteksi mentah menggunakan latencyMetrics untuk menemukan perbedaan antara oldestEventTime dan oldestIngestionTime.

Nilai waktu deteksi

Tabel berikut mencantumkan nilai yang dihitung yang terkait dengan DetectionTimingDetails:


Nilai

Deskripsi

Dampak MTTD

UNSPECIFIED


Deteksi dibuat dalam periode penjadwalan standar.

Kebenaran dasar untuk MTTD.

REPROCESSING


Dibuat karena pemutaran ulang aturan (misalnya, data yang terlambat tiba).

Mewakili risiko operasional; harus diperhitungkan dalam laporan.

RETROHUNT


Dibuat melalui retrohunt historis yang dijalankan.

Biasanya difilter dari pelaporan MTTD standar.

Contoh: metadata latencyMetrics

Contoh berikut latencyMetrics menunjukkan perbedaan waktu antara saat peristiwa terjadi (oldestEventTime versus newestEventTime) dan saat peristiwa diserap (oldestIngestionTime versus newestIngestionTime). Latensi antara peristiwa dan penyerapan ke akun Google SecOps adalah sekitar 53 menit.

"detectionTimingDetails": ["DETECTION_TIMING_DETAILS_REPROCESSING"],
"latencyMetrics": {
  "oldestIngestionTime": "2025-12-09T16:54:14Z",
  "newestIngestionTime": "2025-12-09T16:54:14Z",
  "oldestEventTime": "2025-12-09T16:01:06Z",
  "newestEventTime": "2025-12-09T16:01:06Z"
}

Pemecahan masalah

Tabel berikut mencantumkan beberapa masalah yang mungkin Anda alami terkait aturan Anda dan cara menyelesaikannya:


Masalah

Penyelesaian

Ikon bola lampu muncul, tetapi enumerasinya adalah UNSPECIFIED.

Ini adalah perilaku normal saat delta antara waktu peristiwa dan waktu penyerapan melebihi 30 menit. Gunakan metrik Hub Kondisi Data untuk menyelidiki sumber penundaan penyerapan.

Deteksi muncul terlambat dibandingkan dengan waktu peristiwa.

Periksa detectionTimingDetails. Jika nilai enumerasi adalah REPROCESSING, penundaan kemungkinan disebabkan oleh data pengayaan yang terlambat tiba, bukan latensi eksekusi aturan. Jika UNSPECIFIED, selidiki efisiensi logika aturan.

Komputasi berlebihan.

Aturan kemungkinan memindai terlalu banyak data atau memiliki logika yang tidak efisien. Buka Pengecualian Aturan atau gunakan Filter Offloading untuk menyesuaikan aturan guna mempersempit penelusuran datanya.

Batasan umum

  • Kekakuan nilai minimum: Petunjuk visual untuk data yang terlambat ditetapkan pada nilai minimum 30 menit dan tidak memperhitungkan jendela latensi yang ditentukan pengguna.
  • Kondisi data: Observabilitas aturan memberi tahu kondisi aturan, tetapi pemantauan kondisi data (lebih dekat ke penyerapan) lebih efektif untuk menangkap masalah data yang terlambat tiba secara umum.
  • Penerapan kuota: Meskipun dasbor menampilkan penggunaan resource, dasbor tidak memberikan notifikasi real-time saat aturan mendekati batas kuota.

Langkah berikutnya

Untuk mengetahui informasi tentang pemutaran ulang aturan dan penundaan deteksi aturan, lihat artikel berikut:

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