Menganalisis efektivitas dan efisiensi aturan

Didukung di:

Google SecOps SIEM

Panduan ini ditujukan bagi engineer keamanan yang membuat, men-deploy, dan memantau aturan di Google Security Operations. Bagian ini menjelaskan cara memantau aturan untuk memastikan aturan tersebut 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 untuk mendeteksi (MTTD) tertinggi.

Panduan ini memberikan dokumentasi tentang tugas-tugas berikut:

Cara mengevaluasi aturan selama rilis awalnya, menerima pemberitahuan, dan memeriksa Dasbor Aturan untuk memantau kondisinya.
Cara mengidentifikasi penyebab keterlambatan deteksi (misalnya, apakah 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 dengan baik 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 dimasukkan ke akun Google SecOps Anda.
Kouta: Batas pada volume penyerapan data, jumlah dan kompleksitas kueri yang dapat Anda jalankan terhadap data Anda, serta jumlah dan kompleksitas aturan yang aktif di akun Google SecOps Anda.
Peringatan 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:

Buka Dasbor
Telusuri Rule Observability.
Cari aturan baru di kolom Aturan. Dasbor Keteramati Aturan 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 berprioritas tinggi, Anda dapat menggunakan referensi skema untuk deteksi. Skema ini menentukan format terstruktur yang digunakan untuk memantau pemberitahuan keamanan. Dasbor ini dioptimalkan untuk melacak frekuensi deteksi, distribusi risiko, dan performa aturan. Anda dapat lebih memahami cara menggunakan skema dengan melihat Contoh kueri secara cermat.

Mengidentifikasi alasan penundaan hasil aturan

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

Buka Deteksi > Pemberitahuan & IOC.
Di tab Pemberitahuan, temukan kolom Jenis Deteksi.
Cari pemberitahuan dengan ikon bohlam kuning.
Arahkan kursor ke ikon untuk melihat apakah deteksi dipicu oleh salah satu dari berikut:
- Pemrosesan ulang aturan: Dipicu secara manual oleh pengguna.
- Retrohunt: Dipicu secara manual oleh pengguna.
- Data peristiwa yang tertunda: Menunjukkan apakah penundaan deteksi diperkirakan terjadi.

Memfilter pemberitahuan berdasarkan waktu deteksi

Buka Deteksi > Pemberitahuan & IOC.
Di tab Notifikasi, gunakan elemen filter untuk kolom Waktu deteksi guna mengurutkan deteksi berdasarkan waktu kedatangannya.
Klik ikon muat ulang di bagian atas tabel, lalu klik Muat Ulang Sekarang. Anda dapat melihat pemberitahuan terbaru yang masuk ke 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 danoldestIngestionTime.

Nilai waktu deteksi

Tabel berikut mencantumkan nilai yang di-enum terkait dengan DetectionTimingDetails:

Nilai	Deskripsi	Dampak MTTD
`UNSPECIFIED`	Deteksi dibuat dalam jangka waktu 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`	Dihasilkan melalui proses retrohunt historis.	Biasanya difilter dari pelaporan MTTD standar.

Contoh: Metadata `latencyMetrics`

Contoh latencyMetrics berikut menunjukkan selisih waktu antara saat peristiwa terjadi (oldestEventTime versus newestEventTime) dan saat peristiwa tersebut diproses (oldestIngestionTime versus newestIngestionTime). Latensi antara peristiwa dan pemrosesan 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 dan cara mengatasinya:

Masalah	Penyelesaian
Ikon bohlam muncul, tetapi enumerasinya adalah `UNSPECIFIED.`	Hal ini adalah perilaku normal saat selisih antara waktu peristiwa dan waktu penyerapan melebihi 30 menit. Gunakan metrik Hub Kesehatan Data untuk menyelidiki sumber penundaan penyerapan.
Deteksi muncul terlambat dibandingkan dengan waktu terjadinya 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 berlebih.	Aturan kemungkinan memindai terlalu banyak data atau memiliki logika yang tidak efisien. Buka Pengecualian Aturan atau gunakan Penghapusan Filter untuk menyesuaikan aturan guna mempersempit penelusuran datanya.

Batasan umum

Ketegasan nilai minimum: Petunjuk visual untuk data terlambat ditetapkan pada nilai minimum 30 menit dan tidak memperhitungkan periode latensi yang ditentukan pengguna.
Kondisi data: Kemampuan pengamatan aturan menginformasikan kondisi aturan, tetapi pemantauan kondisi data (lebih dekat dengan penyerapan) lebih efektif untuk mendeteksi 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.