Mengonfigurasi jadwal yang disesuaikan untuk aturan
Dokumen ini ditujukan untuk Admin Platform dan Analis SOC yang ingin mengonfigurasi dan memecahkan masalah jadwal yang dapat disesuaikan untuk aturan multi-peristiwa. Dokumen ini menjelaskan cara menetapkan jadwal pemrosesan dan menjalankan pemeriksaan tambahan untuk menyertakan data yang terlambat tiba.
Dengan mengikuti proses yang dijelaskan dalam dokumen ini, Anda akan mendapatkan kontrol yang akurat atas latensi deteksi dan integritas data. Penyelesaian yang berhasil memastikan deteksi Anda tepat waktu dan akurat, sehingga mengurangi negatif palsu yang disebabkan oleh penundaan penyerapan dan memastikan operasi keamanan yang konsisten.
Jadwal yang dapat disesuaikan memberikan transparansi dan kontrol atas cara aturan multi-peristiwa berjalan di Google Security Operations. Beberapa aturan Multi-peristiwa mungkin memerlukan periode buffer untuk menggabungkan data secara akurat. Metode ini memungkinkan Anda menentukan periode tersebut, bukan mengandalkan nilai default sistem.
Untuk melengkapi dokumen ini, pelajari cara mengelola jadwal operasi aturan.
Terminologi utama
- Operasi pertama (𝑇 + offset): Eksekusi awal logika aturan. Offset mewakili penundaan yang ditambahkan untuk memperhitungkan data yang terlambat tiba.
- Operasi penyesuaian: Evaluasi ulang latar belakang dari jangka waktu yang sama untuk menangkap log atau data pengayaan yang tiba setelah operasi pertama.
- Pengayaan: Metadata eksternal (seperti tag aset atau alias pengguna) yang ditambahkan ke log selama pemrosesan.
Sebelum memulai
Sebelum mencoba mengubah atau mengotomatiskan jadwal aturan, pastikan lingkungan dan akun Anda memenuhi persyaratan keamanan dan sistem yang diperlukan. Saat Anda memvalidasi prasyarat ini, hal ini akan membantu mencegah error deployment dan memastikan logika deteksi Anda selaras dengan kebijakan Pengelolaan Identitas dan Akses organisasi Anda.
Izin: Untuk mengubah jadwal aturan, Anda harus memiliki izin IAM berikut:
chronicle.ruleDeployments.updateuntuk penggunaan API untuk update jadwal individual.chronicle.rules.modifyRulesuntuk update API batch dan penggunaan UI.
Pemeriksaan lingkungan:
- Jenis aturan: Jadwal yang dapat disesuaikan hanya berlaku untuk aturan multi-peristiwa. Aturan peristiwa tunggal dan pilihan dikecualikan.
- Jendela
match: Aturan dengan jendelamatchlebih dari 48 jam dibatasi untuk frekuensi operasi Harian. - Migrasi: Memigrasikan jadwal lama ke jadwal yang dapat disesuaikan adalah proses satu arah dan tidak dapat dikembalikan.
Mengonfigurasi jadwal untuk aturan multi-peristiwa
Untuk mengonfigurasi jadwal untuk aturan multi-peristiwa, ikuti langkah-langkah berikut:
- Di Google SecOps, buka Detection > Rules & Detections.
- Klik Rules Dashboard.
- Temukan aturan Anda, klik More more_vert, lalu pilih Run schedule.
- Di tab Rule schedule, pilih nilai untuk kolom First run schedule, lalu pilih seberapa sering aturan dijalankan.
- Aktifkan tombol Adjust first run for late-arriving data.
- Kemungkinan kegagalan: Operasi pertama mungkin masih kehilangan log jika offset lebih pendek dari latensi penyerapan sebenarnya sumber Anda.
- Langkah korektif: Tingkatkan offset atau andalkan operasi Penyesuaian untuk validasi akhir.
- Aktifkan tombol Ensure enrichment completeness.
- Kemungkinan kegagalan: Pemberitahuan mungkin muncul jauh lebih lambat daripada stempel waktu peristiwa.
- Langkah korektif: Hanya gunakan opsi ini untuk aturan kepatuhan non-kritis yang mengutamakan akurasi daripada kecepatan.
- Tinjau Rule schedule preview untuk memahami linimasa operasi:
- Operasi pertama (𝑇 + offset): Sistem menjalankan logika aturan setelah penundaan yang Anda tentukan untuk data yang terlambat tiba.
- Operasi penyesuaian 1 (𝑇 + 4 jam): Sistem memindai ulang jendela 4 jam setelah operasi pertama untuk menangkap data yang terlewat atau terlambat. Jika Anda mengaktifkan tombol Ensure enrichment completeness, operasi ini juga akan menunggu semua data pengayaan terkait diproses.
- Operasi penyesuaian 2 (𝑇 + 30 jam): Operasi ini hanya muncul jika Anda mengaktifkan tombol Ensure enrichment completeness. Sistem melakukan pemindaian akhir 30 jam setelah operasi pertama untuk memberikan fidelitas data maksimum.
- Klik Save.
Memahami pratinjau jadwal
Pratinjau jadwal mengidentifikasi pencapaian tertentu untuk logika deteksi Anda. Gunakan operasi latar belakang ini untuk mengukur Waktu Rata-Rata hingga Deteksi (MTTD) secara akurat dan memverifikasi integritas pemberitahuan.
- Operasi pertama (𝑇 + offset): Mengidentifikasi ancaman secepat mungkin. Karena beberapa data mungkin masih dalam perjalanan atau sedang menjalani pengayaan, deteksi dalam operasi pertama mungkin tiba lebih lambat dari yang diharapkan.
Operasi penyesuaian: Mengevaluasi ulang jangka waktu secara proaktif. Operasi ini memungkinkan platform menangkap hal berikut:
- Log yang terlambat tiba: Data yang mencapai platform setelah operasi pertama selesai.
- Konteks pengayaan: Metadata, seperti identitas aset atau alias pengguna, yang memerlukan pemrosesan latar belakang tambahan.
Mengidentifikasi sumber deteksi
Google SecOps menggunakan indikator visual untuk membantu Anda membedakan antara deteksi awal dan deteksi yang muncul selama operasi ulang latar belakang.
Indikator deteksi
Di kolom Detection type, mengidentifikasi deteksi dari operasi penyesuaian, operasi pemrosesan ulang, atau retrohunt.
- Jika Anda melihat ikon ini, deteksi terjadi selama operasi penyesuaian (
𝑇+4$atau𝑇+30$) dan bukan operasi awal (𝑇). - Deteksi dengan ikon ini sering kali menunjukkan bahwa platform menangkap ancaman setelah penyerapan awal, biasanya karena log yang terlambat tiba atau penundaan pengayaan.
Memverifikasi integritas pemberitahuan di halaman pemberitahuan
Di halaman Alerts, menunjukkan sumber pemberitahuan. Gunakan indikator ini untuk memverifikasi sumber pemberitahuan saat Anda menyelidiki linimasa.
Pemecahan masalah
Selidiki masalah penjadwalan dengan meninjau waktu evaluasi dan konfigurasi aturan. Meskipun platform mengotomatiskan sebagian besar tugas penjadwalan, setelan atau penundaan data tertentu dapat memengaruhi waktu munculnya deteksi.
Deteksi hanya muncul dalam operasi penyesuaian
Jika deteksi tidak muncul selama operasi pertama (𝑇), tetapi muncul dalam operasi penyesuaian (𝑇+4$ atau 𝑇+30$), periksa hal berikut:
- Latensi penyerapan: Periksa apakah sumber log mengalami penundaan. Jika log tiba 15 menit setelah peristiwa terjadi, jadwal operasi pertama selama 10 menit akan melewatkannya. Operasi penyesuaian menangkap data yang terlambat tiba ini.
- Pengayaan konteks: Konfirmasi apakah aturan mengandalkan metadata eksternal, seperti tag aset atau alias pengguna. Jika proses pengayaan memerlukan waktu lebih lama daripada jendela operasi pertama, deteksi hanya akan muncul setelah sistem menyelesaikan pengayaan dalam operasi berikutnya.
Opsi yang dapat disesuaikan tidak ada
Jika tab Rule schedule tidak menampilkan opsi penyesuaian atau menu berwarna abu-abu:
- Periksa jenis aturan: Jadwal yang dapat disesuaikan hanya berlaku untuk aturan multi-peristiwa. Aturan peristiwa tunggal menggunakan mesin berkelanjutan (real-time) dan tidak mendukung jadwal kustom.
- Verifikasi jendela
match: Aturan dengan jendelamatchlebih dari 48 jam dibatasi untuk frekuensi operasi Harian dan tidak dapat disesuaikan. - Identifikasi aturan pilihan: Anda tidak dapat mengubah jadwal untuk aturan pilihan. Cari pesan
Curated rules uses a legacy scheduleuntuk mengonfirmasi apakah aturan tersebut adalah aturan sistem yang dilindungi.
Penundaan yang tidak terduga dalam pemberitahuan operasi pertama
Jika deteksi tiba lebih lambat dari interval yang dijadwalkan:
- Periode inisialisasi: Aturan baru atau yang baru-baru ini diubah memerlukan periode inisialisasi selama satu jam. Deteksi tidak muncul hingga platform menyelesaikan penyiapan awal ini dan memulai siklus terjadwal pertama.
- Waktu tunggu pengayaan: Jika Anda mengaktifkan tombol Ensure enrichment completeness, sistem dapat menyesuaikan waktu secara dinamis untuk menunggu proses pengayaan data selesai. Meskipun proses ini mencegah deteksi yang terlewat, proses ini dapat menyebabkan deteksi awal tiba lebih lambat dari stempel waktu
𝑇yang tepat.
Pengukuran MTTD tampak tinggi
Pengukuran MTTD mencakup periode buffering yang diperlukan untuk kelengkapan data.
- Tinjau buffer: Untuk jadwal satu jam, sistem mengevaluasi peristiwa satu hingga dua jam setelah peristiwa tiba.
- Optimalkan kecepatan: Jika Anda memerlukan latensi yang lebih rendah, transisikan aturan ke jadwal real-time. Catatan: Hal ini dapat meningkatkan jumlah deteksi yang mengandalkan operasi penyesuaian untuk akurasi penuh.
Batasan
- Hanya aturan multi-peristiwa: Fitur ini tidak tersedia untuk aturan peristiwa tunggal.
- Hanya aturan kustom: Aturan pilihan menggunakan jadwal tetap yang tidak dapat Anda ubah. Jika Anda melihat aturan pilihan, sistem akan menampilkan pesan:
Curated rules use a legacy schedule.
Perbaikan error
| Error | Masalah | Perbaikan |
|---|---|---|
| Opsi tidak ada | Tab jadwal aturan berwarna abu-abu atau opsi tidak ada. | Pastikan aturan tersebut adalah aturan kustom multi-peristiwa dan jendela kecocokan kurang dari 48 jam. |
| Pemberitahuan tertunda | Deteksi tiba lebih lambat dari interval yang dijadwalkan. | Periksa apakah tombol Ensure enrichment completeness aktif. Sistem mungkin menunggu pemrosesan metadata. |
| Hanya pemberitahuan penyesuaian | Deteksi tidak pernah muncul dalam operasi pertama (𝑇). |
Klik Ingestion Latency untuk memverifikasi. Jika log terlambat 15 menit, tetapi offset Anda adalah 10 menit, tingkatkan offset operasi pertama. |
Validasi dan pengujian
Untuk memverifikasi bahwa jadwal Anda berfungsi sesuai harapan, ikuti langkah-langkah berikut:
- Buka Rules Dashboard.
- Pilih aturan Anda dan lihat tab Detections.
- Filter menurut untuk melihat apakah operasi Penyesuaian Anda menangkap data yang terlewat oleh operasi pertama, lalu sesuaikan offset Anda.
Perlu bantuan lain? Dapatkan jawaban dari anggota Komunitas dan profesional Google SecOps.