Memahami ketersediaan data untuk penelusuran

Didukung di:

Google secops

Dokumen ini menjelaskan siklus proses penyerapan data, termasuk aliran data dan latensi end-to-end, serta bagaimana faktor-faktor ini memengaruhi ketersediaan data yang baru diserap untuk pembuatan kueri dan analisis.

Menyerap dan memproses data di Google SecOps

Bagian ini menjelaskan cara Google SecOps menyerap, memproses, dan menganalisis data keamanan.

Penyerapan data

Pipeline penyerapan data dimulai dengan mengumpulkan data keamanan mentah Anda dari sumber seperti:

• Log keamanan dari sistem internal Anda
• Data yang disimpan di Cloud Storage
• Pusat Operasi Keamanan (SOC) dan sistem internal lainnya

Google SecOps membawa data ini ke platform menggunakan salah satu metode penyerapan yang aman.

Metode penyerapan utama adalah:

• Penyerapan Google Cloud langsung

  Google SecOps menggunakan penyerapan Google Cloud langsung untuk otomatis menarik data log dan telemetri dari organisasi Anda Google Cloud, termasuk Cloud Logging, metadata Inventaris Aset Cloud, dan temuan Security Command Center Premium.

• API penyerapan

  Kirim data langsung ke Google SecOps menggunakan REST API Penyerapan publiknya . Anda menggunakan metode ini untuk integrasi kustom atau untuk mengirim data sebagai log tidak terstruktur atau peristiwa Model Data Terpadu (UDM) yang telah diformat sebelumnya.

• Agen Bindplane

  Anda dapat men-deploy agen Bindplane yang serbaguna di lingkungan Anda (lokal atau cloud lainnya) untuk mengumpulkan log dari berbagai sumber dan meneruskannya ke Google SecOps.

• Feed data

  Di Google SecOps, Anda mengonfigurasi feed data untuk menarik log dari sumber pihak ketiga, seperti bucket penyimpanan cloud pihak ketiga tertentu (seperti Amazon S3) atau API pihak ketiga (seperti Okta atau Microsoft 365).

Normalisasi dan pengayaan data

Setelah data tiba di Google SecOps, platform akan memprosesnya melalui tahap berikut:

1. Penguraian dan normalisasi

   Parser pertama-tama memproses data log mentah untuk memvalidasi, mengekstrak, dan mengubah data dari format aslinya ke UDM standar. Penguraian dan normalisasi memungkinkan Anda menganalisis sumber data yang berbeda (misalnya, log firewall, data endpoint, log cloud) menggunakan satu skema yang konsisten. Log mentah asli tetap disimpan bersama peristiwa UDM.

2. Pengindeksan

   Setelah normalisasi, Google SecOps mengindeks data UDM untuk memberikan kecepatan kueri yang cepat di seluruh set data yang besar, sehingga peristiwa UDM dapat ditelusuri.

3. Penggunaan alias dan pengayaan UDM

   • Google SecOps melakukan penggunaan alias dan pengayaan UDM untuk memperkaya peristiwa UDM dengan konteks yang berharga, dengan mengidentifikasi dan menambahkan data konteks dan indikator untuk entity log. Misalnya, Google SecOps menghubungkan pengguna login name ke berbagai IP addresses, hostnames, dan MAC addresses.
   • Geolokasi: Google SecOps memperkaya alamat IP dengan geolokasi data.

4. Pengayaan ECG

   • Google SecOps melakukan aliasing ECG yang menggabungkan konteks dari beberapa sumber (seperti IdP, CMDB, dan threat intelligence), untuk membuat profil entity gabungan dalam grafik konteks entity.

   • Kecerdasan ancaman: Google SecOps secara otomatis membandingkan data peristiwa dengan kecerdasan ancaman Google yang luas, termasuk sumber seperti Google Threat Intelligence dan Safe Browsing, untuk mengidentifikasi ancaman berbahaya yang diketahui, seperti domains, IP addresses, dan file hashes.

   • WHOIS: Google SecOps memperkaya nama domain dengan informasiWHOIS pendaftaran publiknya.

Ketersediaan data untuk analisis

Setelah diproses dan diperkaya, data UDM akan langsung tersedia untuk analisis:

• Deteksi real-time

  Detection Engine secara otomatis menjalankan aturan kustom dan aturan bawaan Google yang diaktifkan dengan Aturan Langsung terhadap data masuk langsung untuk mengidentifikasi ancaman dan membuat pemberitahuan.

• Penelusuran dan investigasi

  Analis dapat menggunakan metode Penelusuran untuk menelusuri semua data yang dinormalisasi dan diperkaya ini. Misalnya, menggunakan penelusuran UDM untuk beralih antara entity terkait (seperti user, ke asset, ke domain berbahaya), dan menyelidiki pemberitahuan.

Metode penelusuran

Google SecOps menyediakan beberapa metode berbeda untuk menelusuri data Anda, yang masing-masing memiliki tujuan yang berbeda.

Penelusuran UDM

Penelusuran UDM adalah metode penelusuran utama dan tercepat, yang digunakan untuk sebagian besar investigasi.

• Yang ditelusuri: Metode ini membuat kueri peristiwa UDM yang dinormalisasi dan diindeks. Karena semua data diuraikan ke dalam format standar ini, Anda dapat menulis satu kueri untuk menemukan aktivitas yang sama (seperti login) di semua produk Anda yang berbeda (misalnya, Windows, Okta, Linux).
• Cara kerjanya: Anda menggunakan sintaksis tertentu untuk membuat kueri kolom, operator, dan nilai.

• Contoh: principal.hostname = "win-server" AND target.ip = "10.1.2.3"

  Hasil biasanya tersedia dalam waktu 2–15 menit setelah penyerapan.

Penelusuran log mentah

Gunakan Penelusuran log mentah untuk menemukan sesuatu dalam pesan log asli yang tidak diuraikan yang mungkin belum dipetakan ke kolom UDM. Metode penelusuran ini dioptimalkan untuk perburuan berkecepatan tinggi, yang biasanya menampilkan hasil dalam waktu kurang dari 2 detik untuk indikator tertentu seperti hash file atau alamat IP.

• Yang ditelusuri: Metode ini memindai teks mentah asli log sebelum log diuraikan dan dinormalisasi. Hal ini berguna untuk menemukan string tertentu, argumen command line, atau artefak lain yang bukan kolom UDM yang diindeks.
• Cara kerjanya: Anda menggunakan awalan raw =. Metode ini bisa lebih lambat daripada penelusuran UDM karena tidak menelusuri kolom yang diindeks.
• Contoh (String): raw = "PsExec.exe"
• Contoh (Regex): raw = /admin\$/

Penelusuran statistik

Gunakan Penelusuran statistik untuk tren jangka panjang yang menggabungkan jutaan baris data. Karena platform harus melakukan analisis dan pengelompokan statistik, waktu pemuatan untuk kueri ini akan lebih lama.

Penelusuran bahasa alami (Gemini)

Penelusuran bahasa alami (Gemini) memungkinkan Anda menggunakan bahasa Inggris biasa untuk mengajukan pertanyaan, yang kemudian diterjemahkan oleh Gemini menjadi kueri UDM formal.

• Yang ditelusuri: Metode ini menyediakan antarmuka percakapan untuk membuat kueri data UDM.
• Cara kerjanya: Anda mengetik pertanyaan, dan Gemini akan membuat kueri penelusuran UDM yang mendasarinya untuk Anda, yang kemudian dapat Anda jalankan atau sempurnakan.
• Contoh: "Show me all failed logins from user 'bob' in the last 24 hours"

Penelusuran SOAR

Penelusuran SOAR khusus untuk komponen SOAR. Anda menggunakannya untuk mengelola insiden keamanan, bukan untuk mencari di log.

• Yang ditelusuri: Metode ini menelusuri Kasus dan Entity (seperti pengguna, aset, alamat IP) dalam platform SOAR.
• Cara kerjanya: Anda dapat menggunakan filter teks bebas atau berbasis kolom untuk menemukan kasus berdasarkan, misalnya, ID, nama pemberitahuan, status, dan pengguna yang ditetapkan.
• Contoh: Menelusuri CaseIds:180 atau AlertName:Brute Force

Pipeline penyerapan data ke ketersediaan penelusuran

Ketersediaan data end-to-end adalah total waktu antara saat peristiwa terjadi dan saat peristiwa tersebut tersedia untuk penelusuran atau eksekusi aturan di Google SecOps. Latensi ini adalah jumlah dari dua komponen berikut:

1. Penundaan ketersediaan sisi sumber: Waktu antara saat peristiwa terjadi dan saat sistem sumber menyediakan data log untuk penyerapan. Penundaan ini bergantung pada arsitektur, pemrosesan, pengelompokan, dan jadwal publikasi API sistem sumber. Google SecOps tidak dapat memengaruhi penundaan ini. Contohnya mencakup penundaan saat sistem menulis log ke bucket penyimpanan atau memublikasikannya ke endpoint API.

2. Waktu pemrosesan Google SecOps: Waktu yang diperlukan Google SecOps untuk memproses data setelah menerimanya. Durasi ini mencakup tahap pipeline internal seperti penyerapan, penguraian, normalisasi, pengindeksan, dan pengayaan.

Anda harus mempertimbangkan kedua komponen saat memecahkan masalah linimasa visibilitas data.

Penundaan yang berasal dari sumber data

Faktor-faktor berikut dapat memengaruhi penundaan ketersediaan sisi sumber:

• Pemrosesan batch: Beberapa sistem menghasilkan log dalam batch pada interval yang ditetapkan (misalnya, setiap jam).
• Latensi API: API sumber dapat mengalami penundaan inheren dalam membuat kueri peristiwa baru.
• Waktu pembuatan dan publikasi peristiwa: Stempel waktu peristiwa dalam log mungkin jauh lebih awal daripada stempel waktu saat log diselesaikan dan tersedia untuk pengumpulan.
• Pembatasan: Batas kapasitas API sisi sumber dapat memperlambat pengambilan data.
• Backfill awal: Menayangkan dan menyerap data historis dalam volume besar memerlukan waktu.

Penundaan ini bervariasi menurut sumber data dan jenis log. Untuk mengetahui detail selengkapnya tentang metode penyerapan, lihat Ringkasan penyerapan data. Referensi API pengelolaan Feed menjelaskan pertimbangan khusus untuk jenis log seperti Microsoft Graph, SentinelOne, Okta, dan CrowdStrike.

Waktu pemrosesan Google SecOps

Sistem memproses data yang baru diserap melalui beberapa langkah. Durasi langkah-langkah ini menentukan kapan data yang baru diserap tersedia untuk kueri dan analisis.

Tabel berikut menguraikan langkah-langkah pemrosesan untuk data yang baru diserap berdasarkan metode penelusuran. Data yang baru diserap dapat ditelusuri setelah langkah-langkah ini selesai.

Metode penelusuran	Data yang ditelusuri	Langkah-langkah pemrosesan yang berkontribusi pada waktu ketersediaan
Penelusuran UDM Penelusuran bahasa alami (Gemini)	Peristiwa UDM yang dinormalisasi dan diperkaya	Penyerapan: Log tiba di titik penyerapan Google SecOps. Penguraian: Log mentah diidentifikasi dan diproses oleh parser tertentu. Normalisasi: Data diekstrak dan dipetakan ke skema UDM. Pengindeksan (UDM): Data UDM yang dinormalisasi diindeks untuk penelusuran terstruktur yang cepat. Pengayaan: Konteks (kecerdasan ancaman, geolokasi, data pengguna atau aset) ditambahkan.
Penelusuran log mentah	Teks log asli yang tidak diuraikan	Penyerapan: Log tiba di titik penyerapan Google SecOps.
Detection Engine (Aturan)	Peristiwa yang dinormalisasi	Ketersediaan peristiwa UDM: Langkah-langkah yang sama seperti yang tercantum untuk penelusuran UDM. Evaluasi deteksi: Rules Engine mengevaluasi log dalam "batch mikro", yang biasanya memicu deteksi dalam waktu 5–10 menit setelah peristiwa tiba.
Penelusuran SOAR	Kasus dan entity	Ini adalah siklus proses yang berbeda, karena penelusuran dilakukan untuk pemberitahuan dan kasus, bukan log. Waktu didasarkan pada: Ketersediaan peristiwa UDM: Menggunakan langkah-langkah pemrosesan yang sama seperti yang tercantum untuk "penelusuran UDM". Deteksi: Aturan Detection Engine harus cocok dengan peristiwa UDM. Pembuatan pemberitahuan: Sistem membuat pemberitahuan formal dari deteksi. Pembuatan kasus: Platform SOAR menyerap pemberitahuan dan membuat kasus.

Contoh aliran data

Contoh berikut menunjukkan cara Google SecOps menyerap, memproses, meningkatkan, dan menganalisis data keamanan Anda, sehingga data tersebut tersedia untuk penelusuran dan analisis lebih lanjut.

Contoh langkah-langkah pemrosesan data

1. Mengambil data keamanan dari layanan cloud seperti Amazon S3 atau dari the Google Cloud. Google SecOps mengenkripsi data ini saat dalam pengiriman.
2. Memisahkan dan menyimpan data keamanan terenkripsi Anda di akun Anda. Akses terbatas untuk Anda dan sejumlah kecil personel Google untuk dukungan produk, pengembangan, dan pemeliharaan.
3. Menguraikan dan memvalidasi data keamanan mentah, sehingga lebih mudah diproses dan dilihat.
4. Menormalisasi dan mengindeks data untuk penelusuran cepat.
5. Menyimpan data yang diuraikan dan diindeks dalam akun Anda.
6. Memperkaya dengan data konteks.
7. Menawarkan akses yang aman bagi pengguna untuk menelusuri dan meninjau data keamanan mereka.
8. Membandingkan data keamanan Anda dengan database malware Google Threat Intelligence untuk mengidentifikasi kecocokan. Dalam tampilan peristiwa Google SecOps, seperti tampilan Aset, klik Konteks VT untuk melihat informasi Google Threat Intelligence. Google SecOps tidak membagikan data keamanan Anda kepada Google Threat Intelligence.

Contoh waktu yang diharapkan hingga ketersediaan Penelusuran

Waktu yang diharapkan hingga data yang baru diserap tersedia untuk Penelusuran adalah jumlah durasi aliran di sepanjang aliran data.

Misalnya, waktu rata-rata yang umum untuk ketersediaan data dalam penelusuran UDM adalah sekitar 5 menit 30 detik sejak data dikirim ke layanan penyerapan Google SecOps.

Langkah aliran data	Deskripsi	Durasi aliran
Cloud Storage ke Log mentah	Menyerap log mentah dari Cloud Storage.	Kurang dari 30 detik
Log keamanan ke Layanan penerusan data	Mengirim log keamanan dari sistem internal ke platform.	T/A
Layanan penerusan data ke Log mentah	Mengirim data keamanan mentah yang diterima dari berbagai sumber ke pipeline penyerapan.	Kurang dari 30 detik
Log mentah ke Menguraikan dan memvalidasi	Menguraikan dan memvalidasi log mentah ke dalam format UDM.	Kurang dari 3 menit
Menguraikan dan memvalidasi ke Indeks	Mengindeks data UDM yang diuraikan untuk penelusuran cepat.	T/A
Indeks ke Data pelanggan yang diuraikan	Membuat data yang diindeks tersedia sebagai data pelanggan yang diuraikan untuk analisis.	Kurang dari 2 menit

Pemecahan masalah

Bagian ini memberikan panduan pemecahan masalah.

Latensi dan batas

Penundaan pemrosesan dan visualisasi dalam platform Google SecOps tunduk pada batas arsitektur berikut setelah Google SecOps menerima data:

• Visibilitas penelusuran: 2 hingga 15 menit setelah penyerapan.
• Eksekusi aturan: 5 hingga 10 menit setelah peristiwa tiba.
• Visualisasi UI: Untuk mempertahankan performa browser, data log bervolume tinggi tunduk pada batas visualisasi 10.000 baris.

Catatan: Untuk rentang penelusuran yang lebih besar dari 30 hari, peristiwa yang baru diserap mungkin memerlukan waktu lebih lama untuk muncul. Untuk hasil yang hampir real-time, pilih rentang waktu 30 hari atau kurang.

Catatan: Waktu ini dimulai setelah Google SecOps menerima data. Ketersediaan data end-to-end juga bergantung pada penundaan yang berasal dari sumber data yang terjadi sebelum data masuk ke pipeline Google SecOps.

Perhatian: Jika perubahan tidak langsung muncul di UI, hal ini tidak selalu menunjukkan kegagalan sinkronisasi. Jika peristiwa terjadi kurang dari 15 menit yang lalu untuk penelusuran atau 10 menit yang lalu untuk aturan, data kemungkinan masih berada dalam pipeline pemrosesan standar. Penundaan ini tidak menunjukkan kegagalan sistem.

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