Membuat analisis kontekstual

Chronicle memungkinkan Anda melihat telemetri, konteks entitas, hubungan, dan kerentanan sebagai satu deteksi dalam akun Chronicle. Hal ini memberikan kontekstualisasi entitas agar Anda dapat memahami pola perilaku dalam telemetri dan konteks entity yang terpengaruh tersebut dari pola tersebut.

Contoh:

• Memunculkan izin untuk akun tempat dicoba untuk login dengan brute force.
• Pentingnya data yang dihosting oleh aset yang juga merupakan sumber aktivitas jaringan keluar.

Pelanggan dapat menggunakan kontekstualisasi ini untuk pemfilteran deteksi, penentuan prioritas pemberitahuan heuristik, triase, dan investigasi.

Analis keamanan dan engineer deteksi biasanya bekerja untuk membuat deteksi pada pola dasar telemetri peristiwa (koneksi jaringan keluar), sehingga menghasilkan banyak deteksi untuk ditriase oleh analis mereka. Para analis mencoba menggabungkan pemahaman tentang apa yang terjadi untuk memicu peringatan dan seberapa signifikan ancaman itu.

Analisis kontekstual menggabungkan kemampuan pengayaan lanjutan di tahap awal alur kerja pembuatan dan eksekusi deteksi, sehingga Anda dapat memberikan kemampuan tambahan berikut:

• Menyediakan konteks yang relevan untuk penilaian risiko deteksi kontekstual berdasarkan heuristik pada waktu eksekusi deteksi, bukan pada tahap triase manusia
• Mengurangi waktu yang dihabiskan untuk menentukan prioritas dan menggabungkan informasi dari sistem keamanan IT yang berbeda secara manual (konsol EDR, log firewall/proxy, konteks CMDB dan IAM, hasil pemindaian kerentanan)
• Memungkinkan analis dan engineer deteksi memfilter seluruh cluster ancaman yang mungkin diperkirakan atau merupakan bahaya kecil/tidak membahayakan perusahaan (pengujian malware di lingkungan sandbox, kerentanan dan aktivitas anomali di jaringan pengembangan tanpa data atau akses sensitif, dan banyak lagi)

Menulis aturan untuk analisis kontekstual

Anda dapat menggunakan aturan Detection Engine untuk menelusuri data konteks entity di akun Chronicle Anda.

Untuk menelusuri data konteks entity, selesaikan hal berikut:

1. Tentukan sumber menggunakan udm atau entity.

   $eventname.[<source>].field1.field2 Untuk konteks entity, <source> adalah 'graph'. Untuk peristiwa UDM, <source> adalah 'udm'. Jika dihilangkan, <source> akan ditetapkan secara default ke udm.

2. Tentukan data entity:

   $e1.graph.entity.hostname = "my-hostname"

   $e1.graph.entity.relations.relationship = "OWNS"

3. Tentukan data peristiwa UDM. Pernyataan berikut setara.

   $e1.udm.principal.asset_id = "my_asset_id"

   $e1.principal.asset_id = "my_asset_id"

Anda dapat membuat banyak jenis aturan yang sama untuk konteks entitas seperti yang Anda lakukan untuk peristiwa UDM, termasuk aturan berikut:

• Beberapa aturan peristiwa

  Catatan: Semua aturan multi-peristiwa harus menggunakan peristiwa UDM. Anda dapat memiliki aturan yang hanya menggunakan UDM atau Anda dapat memiliki aturan yang menggunakan UDM dan Entitas. Tidak mungkin memiliki aturan yang hanya menggunakan Entity.

• Membandingkan konteks entitas dengan konteks entitas lainnya

• Membandingkan konteks entitas dengan peristiwa UDM

• Kolom berulang dalam konteks entity

• Jendela geser

• Menghitung skor risiko untuk deteksi

  Catatan: Konteks entity tidak dapat digunakan sebagai pivot untuk jendela geser.

Tidak seperti peristiwa UDM, konteks entity tidak memiliki stempel waktu tertentu. Setiap data konteks entity memiliki interval waktu, entity.metadata.interval, yang mencakup konteks entity yang valid. Interval waktu ini mungkin bukan batas hari dan dapat berupa durasi berapa pun.

Peristiwa UDM akan dikorelasikan dengan data konteks entity hanya jika stempel waktu peristiwa UDM berada dalam interval waktu catatan konteks entity. Jika kondisi ini tidak terpenuhi, UDM dan entity tidak dievaluasi untuk deteksi. Mesin deteksi secara implisit memberlakukan ini dan Anda tidak perlu menetapkannya sebagai kondisi dalam aturan.

• Saat membandingkan peristiwa UDM dengan konteks entity melalui windowing, konteks entity merepresentasikan nilai konstanta di atas periode yang ditentukan.
• Jika ada bucket hari yang berdekatan dengan konteks entitas yang mengubah nilainya, Chronicle akan mencoba mencocokkan semua nilai konteks entity, lalu menampilkan setiap dan semua kecocokan yang ditemukan.

Contoh aturan

Menelusuri entity dengan konteks administrator

Aturan berikut menelusuri entitas yang juga terkait dengan hak istimewa administrator. Mencari saat seseorang dengan hak istimewa administrator berupaya untuk login atau logout dari sistem.

rule LoginLogout {
  meta:
  events:
    $log_in.metadata.event_type = "USER_LOGIN"
    $log_in.principal.user.user_display_name = $user

    $log_out.metadata.event_type = "USER_LOGOUT"
    $log_out.principal.user.user_display_name = $user

    $log_in.metadata.event_timestamp.seconds <=
     $log_out.metadata.event_timestamp.seconds

    $context.graph.entity.user.user_display_name = $user
    $context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"

  match:
    $user over 2m

  condition:
    $log_in and $log_out and $context
}

Contoh jendela geser

Contoh jendela geser berikut valid.

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Using e2 (a UDM event) as a pivot.
    $host over 3h after $e2

  condition:
    $e1 and $e2
}

Contoh jendela geser tidak valid

Contoh jendela geser berikut tidak valid. Konteks entity tidak dapat digunakan sebagai pivot untuk jendela geser.

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Attempting to use $e1 (an entity context) as a pivot. Invalid.
    $host over 3h after $e1

  condition:
    $e1 and $e2
}

Contoh login menggunakan bagian hasil

Contoh berikut menggunakan bagian outcome untuk menghitung skor risiko deteksi.

rule Detection {
  meta:
  events:
    $auth.metadata.event_type = "USER_LOGIN"
    $auth.metadata.vendor_name = "Acme"
    $auth.metadata.product_name = "Acme SSO"
    $auth.target.user.userid = $user
    $auth.target.user.termination_date.seconds > 0

    $auth.metadata.event_timestamp.seconds >
       $context.graph.entity.user.termination_date.seconds

    $context.graph.metadata.vendor_name = "Microsoft"
    $context.graph.metadata.product_name = "Azure Active Directory"
    $context.graph.metadata.entity_type = "USER"
    $context.graph.entity.user.userid = $user
    $context.graph.entity.user.termination_date.seconds > 0

  match:
    $user over 15m

  outcome:
    $risk_score = max(
        if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
        if (
            $context.graph.entity.user.title = "Remote" nocase or
            $context.graph.entity.user.title = "Temp" nocase or
            $context.graph.entity.user.title = "Vendor" nocase, 40) +
        if ( $context.graph.entity.user.title = "Legal" nocase, 10)
    )

  condition:
    $auth and $context
}

Contoh peluncuran proses yang mencurigakan

Contoh berikut mengevaluasi data proses peristiwa UDM terhadap data konteks IOC yang disimpan sebagai konteks entitas.

rule ProcessLaunch {
  meta:
  events:
    $ioc.graph.metadata.vendor_name = "ACME"
    $ioc.graph.metadata.product_name = "IOCs"
    $ioc.graph.metadata.entity_type = "FILE"
    $ioc.graph.entity.file.sha256 = $hash

    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.principal.hostname = $hostname
    (
        not $process.target.process.file.sha256 = "" and
        $process.target.process.file.sha256 = $hash
    )

  match:
    $hash over 15m

  condition:
    $ioc and $process
}

Penentu tambahan untuk konteks entity

Untuk membuat variabel peristiwa yang menggunakan konteks entity, Anda harus memberikan <source> setelah nama peristiwa. <source> harus graph.

Pola berikut mengacu pada konteks entity:

• $e.graph.entity.hostname

Perhatikan bahwa ada dua metode yang setara untuk merujuk ke peristiwa UDM:

• $u.udm.principal.asset_id
• $u.principal.asset_id

Anda dapat mencampur dan mencocokkan semua penentu ini dalam teks aturan. Anda juga dapat menggunakan penentu yang berbeda untuk acara yang sama.

Bagian hasil

Mesin deteksi mendukung bagian outcome yang memungkinkan Anda memperoleh lebih banyak informasi dari aturan. Logika yang ditentukan di bagian outcome dievaluasi terhadap setiap deteksi. Jika aturan menghasilkan deteksi N, setiap deteksi N dapat menghasilkan kumpulan hasil yang berbeda.

Anda dapat menemukan contoh aturan yang menggunakan bagian outcome di sini.

Detail penggunaan dan sintaksis bagian outcome dapat ditemukan di bagian ini.

Bagian hasil dan penghapusan duplikat / pengelompokan deteksi

Untuk aturan dengan bagian pencocokan, ingat bahwa deteksi "dikelompokkan berdasarkan" variabel pencocokan. Hal ini menyebabkan duplikat deteksi dihapus, sehingga satu baris ditampilkan untuk setiap kumpulan unik variabel pencocokan dan jangka waktu.

Variabel hasil akan diabaikan saat melakukan penghapusan duplikat ini. Jadi, jika ada dua deteksi berbeda dengan nilai yang sama untuk variabel pencocokan dan jangka waktu, tetapi dengan nilai yang berbeda untuk variabel hasil, duplikat ini akan dihapus dan Anda hanya akan melihat satu deteksi. Hal ini dapat terjadi saat deteksi dibuat karena keterlambatan data yang diterima, misalnya. Berikut adalah contoh yang menggambarkan kasus ini.

rule ExampleOutcomeRule {
  ...
  match:
    $hostname over <some window>
  outcome:
    $risk_score = <some logic here>
  ...
}

Aturan ini menghasilkan kecocokan berikut:

Deteksi 1: nama host: jangka waktu host tes: [t1, t2] risk_score: 10

Deteksi 2: nama host: jangka waktu host tes: [t1, t2] risk_score: 73

Karena variabel pencocokan dan jangka waktu untuk Deteksi 1 dan Deteksi 2 sama, duplikat ini dihapus dan Anda hanya akan melihat satu deteksi, meskipun variabel hasil, risk_score, berbeda.

Langkah selanjutnya

Untuk mengetahui informasi tentang cara Chronicle menyerap data kontekstual dan memperkaya entity, lihat Cara Chronicle memperkaya data peristiwa dan entity