Praktik terbaik terkait penelusuran

Didukung di:

Google secops SIEM

Dokumen ini menjelaskan praktik terbaik yang direkomendasikan Google untuk menggunakan fitur Penelusuran di Google Security Operations. Penelusuran dapat memerlukan resource komputasi yang besar jika tidak dibuat dengan cermat. Performa juga bervariasi bergantung pada ukuran dan kompleksitas data di instance Google SecOps Anda.

Catatan: Untuk penelusuran log mentah, kolom Penelusuran dibatasi hingga 150 karakter.

Menggunakan filter tertentu dalam kueri untuk kecepatan dan performa maksimum

Satu-satunya cara paling efektif untuk meningkatkan performa penelusuran adalah membuat kueri menggunakan kolom Model Data Terpadu (UDM) yang spesifik dan dioptimalkan. Kolom ini dioptimalkan untuk pengambilan cepat, sehingga penelusuran Anda berjalan dengan cepat dan menggunakan lebih sedikit resource komputasi.

Bagian berikut mencantumkan kolom UDM berperforma tinggi yang dapat digunakan sebagai filter dalam kueri Anda.

Kolom utama

• principal.asset.hostname
• principal.asset.ip
• principal.asset.mac
• principal.file.md5
• principal.file.sha1
• principal.file.sha256
• principal.hostname
• principal.ip
• principal.mac
• principal.process.file.md5
• principal.process.file.sha1
• principal.process.file.sha256
• principal.process.parent_process.file.md5
• principal.process.parent_process.file.sha1
• principal.process.parent_process.file.sha256
• principal.user.email_addresses
• principal.user.product_object_id
• principal.user.userid
• principal.user.windows_sid

Kolom sumber

• source.user.userid
• src.asset.hostname
• src.hostname
• src.ip

Kolom target

• target.asset.hostname
• target.file.md5
• target.file.sha1
• target.file.sha256
• target.hostname
• target.ip
• target.process.file.md5
• target.process.file.sha1
• target.process.file.sha256
• target.user.email_addresses
• target.user.product_object_id
• target.user.userid
• target.user.windows_sid

Kolom tambahan

• about.file.md5
• about.file.sha1
• about.file.sha256
• intermediary.hostname
• intermediary.ip
• network.dns.questions.name
• network.email.from
• network.email.to
• observer.hostname
• observer.ip

Cara membuat kueri data entity dan konteks

Jika Anda menelusuri jenis log entity atau konteks (seperti AZURE_AD_CONTEXT atau WORKSPACE_USERS) menggunakan metadata.log_type = "<LOG_TYPE>", penelusuran tidak akan menampilkan hasil meskipun log mentah terlihat di Penelusuran Log Mentah. Hal ini karena penelusuran UDM hanya mengkueri catatan peristiwa UDM.

Untuk menelusuri data entity dan konteks, gunakan sintaksis graph:

• Untuk menelusuri jenis log entity atau konteks, kueri kolom metadata graph. Contoh:

  graph.metadata.event_metadata.log_type = "<LOG_TYPE>"

• Untuk menelusuri kolom entity, gunakan awalan graph.entity.noun.field. Contoh:

  graph.entity.user.email_addresses = "foo_email"

Untuk mengetahui informasi selengkapnya, lihat Melakukan penelusuran data konteks entity.

Membuat kueri penelusuran yang efektif untuk performa

Menulis kueri yang dioptimalkan adalah kunci untuk memaksimalkan kecepatan dan meminimalkan penggunaan resource di seluruh data keamanan Anda. Semua kondisi kueri harus benar-benar mematuhi struktur dasar ini:

udm-field operator value

Contoh: principal.hostname = "win-server"

Catatan: Semakin fokus dan akurat kueri Anda, semakin cepat kueri tersebut berjalan dan semakin sedikit resource komputasi yang diperlukan.

Mempersempit rentang waktu untuk penelusuran Anda

Karena Google SecOps dapat menyerap data dalam jumlah besar selama penelusuran, meminimalkan rentang waktu dan mempersempit cakupan kueri dapat meningkatkan performa penelusuran.

Menggunakan ekspresi reguler dalam kueri penelusuran

Anda dapat menggunakan operator logis dan perbandingan standar saat membuat kueri penelusuran UDM untuk membuat ekspresi yang kompleks:

• Operator logis: Gunakan AND, OR, dan NOT untuk menggabungkan kondisi. AND diasumsikan jika Anda menghilangkan operator di antara dua kondisi.
• Prioritas operator: Gunakan tanda kurung () untuk mengganti urutan prioritas default. Ada batas maksimum 169 operator logis (OR, AND, NOT) yang dapat Anda gunakan dalam tanda kurung.
• Operator perbandingan: Bergantung pada jenis kolom UDM (string, bilangan bulat, stempel waktu), operator kolom dapat mencakup: =, !=, >=, >, <, <=

Google SecOps menggunakan mesin ekspresi reguler RE2.

Catatan: Untuk performa yang dapat diprediksi, mesin RE2 sengaja menghilangkan fitur lanjutan tertentu, seperti pernyataan lookahead dan lookbehind. Untuk mengetahui informasi selengkapnya, lihat Sintaksis RE2.

Atau, untuk penelusuran yang efisien dari kumpulan nilai yang besar, Anda dapat menggunakan daftar referensi.

**Catatan:** Kueri yang berisi beberapa ekspresi reguler mungkin memerlukan waktu lebih lama untuk diselesaikan.

Menggunakan nocase sebagai pengubah penelusuran

Anda dapat menambahkan pengubah nocase ke kondisi perbandingan string untuk membuat penelusuran tidak peka huruf besar/kecil, yang mengabaikan penggunaan huruf besar.

Misalnya, penelusuran berikut mengabaikan huruf besar/kecil dan cocok dengan semua kombinasi yang berisi tim.smith terlepas dari huruf besar/kecil:

target.user.userid = "TIM.SMITH" nocase

Menghindari penggunaan ekspresi reguler di kolom yang dihitung

Anda tidak dapat menggunakan ekspresi reguler saat menelusuri kolom yang dihitung (kolom dengan rentang nilai yang telah ditentukan) seperti metadata.event_type atau network.ip_protocol

Contoh berikut adalah penelusuran yang tidak valid: metadata.event_type = /NETWORK_*/

Sedangkan, contoh berikut adalah penelusuran yang valid: (metadata.event_type = "NETWORK_CONNECTION" atau metadata.event_type = "NETWORK_DHCP")

Catatan: Untuk menelusuri beberapa nilai yang dihitung, Anda harus mencantumkan setiap nilai secara eksplisit dengan operator OR." Lihat kueri sebelumnya sebagai contoh.

Menggunakan operator apa pun dan semua operator di kolom Peristiwa

Di Penelusuran, beberapa kolom UDM (seperti principal.ip atau target.file.md5) diberi label berulang, karena dapat menyimpan daftar nilai atau jenis pesan dalam satu peristiwa. Kolom berulang selalu diperlakukan dengan operator any secara default (tidak ada opsi untuk menentukan all).

Saat operator any digunakan, predikat dievaluasi sebagai true jika ada nilai dalam kolom berulang yang memenuhi kondisi. Misalnya, jika Anda menelusuri principal.ip != "1.2.3.4" dan peristiwa dalam penelusuran Anda menyertakan principal.ip = "1.2.3.4" dan principal.ip = "5.6.7.8", kecocokan akan dibuat. Hal ini memperluas penelusuran Anda untuk menyertakan hasil yang cocok dengan salah satu operator, bukan mencocokkan semuanya.

Setiap elemen di kolom berulang diperlakukan secara terpisah. Jika kolom berulang ditemukan dalam peristiwa dalam penelusuran, peristiwa akan dievaluasi untuk setiap elemen di kolom. Hal ini dapat menyebabkan perilaku yang tidak terduga, terutama saat menelusuri menggunakan operator !=.

Saat menggunakan operator any, predikat dievaluasi sebagai true jika ada nilai dalam kolom berulang yang memenuhi kondisi.

Menggunakan waktu epoch Unix untuk stempel waktu atau menggunakan fungsi YARA-L untuk konversi tanggal

Kolom stempel waktu dicocokkan menggunakan waktu epoch Unix (jumlah total detik yang telah berlalu sejak Kamis, 1 Januari 1970 00.00.00 UTC), atau Anda dapat menggunakan fungsi YARA-L untuk konversi tanggal.

Saat menelusuri stempel waktu tertentu, hal berikut (dalam waktu epoch) akan valid:

metadata.ingested_timestamp.seconds = 1660784400

Stempel waktu berikut tidak valid:

metadata.ingested_timestamp = "2022-08-18T01:00:00Z"

Saat menelusuri stempel waktu tertentu, hal berikut (menggunakan fungsi YARA-L untuk konversi tanggal) akan valid:

metadata.event_type = "NETWORK_CONNECTION"
timestamp.get_date(metadata.ingested_timestamp.seconds) = "2026-03-15"

Contoh YARA-L berikut menggunakan fungsi timestamp untuk memeriksa rentang waktu penyerapan:

metadata.event_type = "NETWORK_CONNECTION"
$date = timestamp.get_date(metadata.ingested_timestamp.seconds)
$date > "2026-03-15" AND $date < "2026-03-17"

Cara membuat kueri data yang baru diserap dengan stempel waktu yang lebih lama

Anda tidak dapat menelusuri peristiwa yang baru diserap yang memiliki stempel waktu yang lebih lama kecuali jika Anda menentukan rentang waktu peristiwa untuk dikueri. Hal ini karena rentang waktu didasarkan pada stempel waktu peristiwa yang diuraikan, bukan stempel waktu penyerapan peristiwa log mentah.

Untuk menelusuri peristiwa UDM untuk log yang diserap dengan stempel waktu peristiwa yang lebih lama, Anda dapat menggunakan opsi Semua waktu untuk menelusuri dan membuat kueri atas metadata.ingested_timestamp.

**Catatan:** Anda tidak dapat memetakan waktu penyerapan dengan rentang waktu penelusuran.

Kolom yang dikecualikan dari filter

Kolom berikut sengaja dikecualikan dari filter penelusuran:

• metadata.id
• metadata.product_log_id
• *.timestamp

Meskipun kolom ini berisi metadata penting, nilai uniknya memperkenalkan kardinalitas dan varians yang tinggi dalam statistik, yang berdampak negatif pada performa penelusuran.

Pemecahan masalah

Jika Anda menerima pesan error umum, seperti "Error: Search has encountered an error and couldn't load data", lakukan langkah-langkah berikut untuk mengatasi masalah ini. Jika error berlanjut, hubungi Dukungan Pelanggan.

• Hubungkan ke Google SecOps dari jaringan lain. Misalnya, gunakan VM cloud untuk membantu mengidentifikasi masalah jaringan.
• Pastikan panggilan Chronicle API diizinkan oleh konfigurasi atau kebijakan firewall atau proxy organisasi Anda.
• Pastikan tidak ada batas data yang dikonfigurasi untuk panggilan Search API, karena penelusuran dapat menampilkan set data yang besar.
• Kueri penelusuran dapat berjalan secara asinkron dan mungkin memerlukan lebih banyak waktu untuk menampilkan data. Anda dapat melihat penelusuran yang sebelumnya dijalankan di histori penelusuran dan memilihnya untuk melihat hasilnya nanti.

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