Bagaimana cara menormalkan acara dengan benar? Bagaimana cara menormalkan peristiwa serupa dari sumber yang berbeda tanpa melupakan atau membingungkan apa pun? Tetapi bagaimana jika dua ahli melakukan ini secara independen? Pada artikel ini, kami akan membagikan metodologi normalisasi umum yang dapat membantu menyelesaikan masalah ini.


Gambar: Martinoflynn.com

Paling sering, aturan korelasi didasarkan pada peristiwa yang dinormalisasi. Dengan demikian, normalisasi peristiwa dan seberapa benar itu dilakukan secara langsung mempengaruhi keakuratan aturan korelasi.

Masalah yang timbul dari normalisasi peristiwa dirumuskan dalam artikel pertama (di sini ), dan cara untuk menyelesaikannya diusulkan dalam artikel berikutnya (di sini dan di sini ). Sekarang kami meringkas yang dijelaskan sebelumnya dan membentuk pendekatan umum untuk menormalkan peristiwa.

Untuk memulainya, kita ingat alat tingkat normalisasi mana yang telah kita kembangkan:

1. Diperlukan skema bidang umum untuk menyimpan data yang diambil dari acara. Fitur-fiturnya:
   
   
   • Ini memperhitungkan keberadaan entitas dalam acara: Subjek, Obyek, Sumber dan Pemancar acara, serta Sumber Daya.
   • Memberikan normalisasi yang benar dalam kasus ketika acara tersebut mengandung entitas tingkat jaringan dan aplikasi , dan ketika memiliki lebih dari satu Subjek dan / atau Objek.
   • Memungkinkan Anda secara eksplisit mengidentifikasi dan mempertahankan struktur proses interaksi antara Subjek dan Objek
2. Sistem kategorisasi acara mampu mencerminkan semantik acara TI atau IB.

Metodologi Normalisasi Peristiwa

Seluruh metodologi untuk menormalkan peristiwa terdiri dari tiga langkah:

1. Penilaian pakar atas acara tersebut.
2. Definisi skema interaksi.
3. Definisi kategori acara.

Untuk membuatnya lebih mudah untuk memahami cara kerja alat ini, kami akan memilih acara dan mempertimbangkan secara rinci semua langkah normalisasi sesuai dengan metodologi kami.

Misalkan kita memiliki sumber - DBMS Oracle Database dengan pengalamatan jaringan berikut:

• IP : 10.0.0.1;
• Hostname : myoracle;
• FQDN : myoracle.local.

Dari sumber ini, agen SIEM membongkar acara berikut:

Langkah 1. Evaluasi ahli acara

Pada awal proses normalisasi suatu peristiwa, penting untuk memahami tentang apa peristiwa ini. Cukup mengatakan esensi kepada diri sendiri. Jika seorang ahli, dari peristiwa awal, belum dinormalisasi, tidak mengerti proses apa yang terjadi pada sumbernya, kita berbicara tentang, dengan probabilitas tinggi dia akan salah menormalkannya. Lalu operasi seperti apa yang benar dari aturan korelasi yang bisa kita bicarakan?

Masalah dengan seberapa baik ahli menginterpretasikan acara dengan benar adalah nyata. Misalnya, dapatkah seorang ahli memahami apa arti acara selanjutnya?



Jika dalam contoh asli esensi dapat ditangkap dari teks acara itu sendiri, maka dalam hal ini Anda perlu memahami dengan baik sumber apa yang sedang Anda kerjakan dan dalam kasus apa ia menghasilkan peristiwa serupa. Kadang-kadang Anda bahkan harus mengerahkan dudukan terpisah dengan sumber agar dapat sepenuhnya mereproduksi situasi di mana ia mengirimkan acara yang kompleks dan sulit ditafsirkan ke SIEM.

Mari kita kembali ke contoh asli dengan acara dari Oracle Database. Pada tahap ini, pakar harus berpikir seperti ini:

" Sebagai seorang ahli, saya percaya bahwa acara awal menggambarkan proses pencabutan peran oleh satu pengguna dari yang lain dalam Oracle Database ."

Langkah 2. Menentukan skema interaksi

Langkah sebelumnya memungkinkan kami untuk memastikan bahwa kami dapat memahami setidaknya arti umum dari acara tersebut. Sekarang kita akan menganalisis secara rinci bagaimana membedakan entitas dan menentukan skema interaksi mereka.

Menurut metodologi ini, untuk setiap skema interaksi, perlu untuk menggambarkan aturan untuk distribusi pengidentifikasi entitas kunci di bidang peristiwa yang dinormalisasi. Pada saat yang sama, aturan didefinisikan untuk:

1. Entitas tingkat jaringan
2. Entitas tingkat aplikasi.

Penting untuk diingat bahwa ada skema di mana Subjek sama dengan Objek dan sama dengan Sumber. Untuk skema semacam itu, perlu untuk secara jelas mendefinisikan aturan untuk mengisi bidang ketiga entitas. Jika ini tidak dilakukan, maka, pada tingkat aturan korelasi atau pencarian peristiwa, masalah akan dimulai dan logika tambahan akan muncul untuk interpretasi yang benar dari bidang kosong. Tentang ini - dalam artikel yang ditujukan untuk skema interaksi .

Mari kita lihat bagaimana langkah metodologi ini bekerja pada contoh awal:

• Skema interaksi tingkat jaringan : skema pengumpulan langsung lengkap, tanpa pemancar.
• Skema interaksi di tingkat aplikasi : interaksi melalui sumber daya.

Untuk skema ini, aturan normalisasi berikut dapat didefinisikan:

1. Entitas lapisan jaringan:
   
   • Subjek :
     
     • Bidang: src.ip = <empty>
     • Bidang: src.hostname = alex_host
     • Bidang: src.fqdn = <empty>
   • Obyek
     
     • Bidang: dst.ip = 10.0.0.1
     • Bidang: dst.hostname = myoracle
     • Bidang: dst.fqdn = myoracle.local
   • Sumber (cocok dengan Objek) :
     
     • Bidang: event_source.ip = 10.0.0.1
     • Bidang: event_source.hostname = myoracle
     • Bidang: event_source.fqdn = myoracle.local
   • Pemancar :
     
     • Bidang: forwarder.ip = <empty>
     • Bidang: forwarder.hostname = <empty>
     • Bidang: forwarder.fqdn = <empty>
   • Saluran interaksi :
     
     • Bidang: interaksi.id = 2342594
     
     
2. Entitas tingkat aplikasi (kumpulan elemen):
   
   • Subjek :
     
     • Bidang: subjek [1] .name = “Alex”
     • Bidang: subjek [1] .type = “akun”
   • Obyek
     
     • Bidang: objek [1] .name = “Bob”
     • Bidang: objek [1] .type = “akun”
   • Sumber :
     
     • Bidang: sumber daya [1] .name = “MYROLE”
     • Bidang: sumber daya [1] .type = “role”

Langkah 3. Menentukan kategori acara

Setelah semua entitas utama dari acara telah diidentifikasi, perlu untuk menjelaskan esensi dari proses yang tercermin dalam acara tersebut dan mentransfernya ke bahasa normalisasi. Untuk tujuan ini, sistem untuk mengkategorikan acara digunakan. Sistem kategorisasi acara dibahas secara rinci dalam artikel terpisah, sekarang mari kita lihat cara kerjanya dalam praktik.

Untuk menyatukan normalisasi, sistem kategorisasi menetapkan aturan berikut:

1. Untuk setiap kategori dari setiap level TI dan acara keamanan informasi, seorang ahli membentuk direktori dengan daftar informasi yang perlu ditemukan di acara awal dan dinormalisasi.
2. Jika suatu peristiwa diberikan kategori apa pun, pakar, sesuai dengan direktori, harus menemukan informasi yang diperlukan dan menormalkannya.
3. Setiap kategori mendefinisikan satu set bidang skema acara yang dinormalisasi yang perlu diisi.

Dengan demikian, kategori yang dipilih untuk acara tersebut membuat korespondensi langsung antara:

• semantik acara;
• informasi penting untuk diekstraksi dari acara tersebut, sesuai dengan kategori yang ditempelkan;
• seperangkat bidang skema acara dinormalisasi di mana informasi ini harus "dimasukkan".

Pendekatan ini memungkinkan Anda untuk memahami dengan jelas dari kategori suatu peristiwa apa data di bidang mana dari peristiwa yang dinormalisasi.

Jika, dengan dukungan sumber-sumber baru, ternyata beberapa informasi penting perlu diekstraksi secara tambahan dari peristiwa dalam kategori tertentu, lalu dimasukkan ke dalam direktori. Dalam hal ini, Anda perlu:

• menentukan aturan untuk mengisi bidang skema acara;
• melakukan audit normalisasi untuk peristiwa dalam kategori ini dari semua sumber yang didukung sebelumnya;
• Tambahkan informasi baru ke acara yang sebelumnya dinormalisasi.

Dengan cara ini, konsistensi dari perubahan yang dilakukan dipertahankan. Pertimbangkan contoh aslinya.

Menurut sistem kategorisasi, acara ini memiliki kategori berikut:

• Sistem Kategorisasi : Acara IT
• Kategori Tingkat Pertama (Tingkat 1) : Pengguna dan Hak
• Kategori Tingkat Kedua (Tingkat 2) : Pengguna
• Kategori Tingkat Ketiga (Level 3) : Manipulasi

Direktori untuk kategori ini terlihat seperti ini:

1. Saat menormalkan peristiwa dalam kategori Pengguna dan Hak , penting untuk dipahami:
   
   • Jika eskalasi hak istimewa digunakan, maka atas nama siapa proses diimplementasikan.
     
     • Bidang: subjek [i] .assign
   • Apakah tindakannya berhasil.
     
     • Bidang: result.status
   • Apa kode pengembaliannya?
     
     • Bidang: result.status.code
   
   
2. Saat menormalkan peristiwa dalam kategori Pengguna , penting untuk dipahami:
   
   • Apakah ada informasi tentang alamat ip, nama host atau fqdn dari mesin pengguna.
     
     • Bidang: src.ip, src.hostname, src.fqdn
     • Bidang: dst.ip, dst.hostname, dst.fqdn
   • Di bawah akun mana pengguna terhubung.
     
     • Bidang: subjek [i] .name, objek [i] .name
   • Apakah ada informasi tentang akunnya di OS.
     
     • Bidang: subjek [i] .osname, objek [i] .osname
   • Apakah ada informasi akun domain?
     
     • Bidang: subjek [i] .domain, objek [i] .domain
   • Apakah ada informasi tentang aplikasi pengguna.
     
     • Bidang: subjek [i] .aplikasi, objek [i] .aplikasi
   
   
3. Saat menormalkan peristiwa dalam kategori Manipulasi , penting untuk dipahami:
   
   • Jenis operasi.
     
     • Bidang: interaksi.type
   • Apa yang sudah berubah?
     
     • Bidang: objek [i] .name, objek [i] .type - saat mengganti akun
     • Bidang: sumber daya [i] .name, sumber daya [i] .type - saat mengubah sumber daya
   • Apa yang sudah berubah?
     
     • Bidang: objek [i] .modify
     • Bidang: sumber daya [i] .modify
   • Jika operasi itu pada sumber daya, siapa pemiliknya.
     
     • Field: resource [i] .owner

Kami telah memberikan panduan ini untuk menunjukkan prinsip pembentukannya, oleh karena itu ia tidak berpura-pura akurat dan lengkap.

Akibatnya, acara yang dinormalisasi dengan metodologi ini terlihat seperti ini:


Contoh acara yang dinormalisasi pada langkah ketiga metodologi.

Kesimpulan

Pengalaman menunjukkan bahwa sering terjadi kesalahan normalisasi dan tidak adanya aturan normalisasi seragam yang sering mengarah pada kesalahan positif dari aturan korelasi. Sekarang kita memiliki pendekatan yang memungkinkan, jika tidak dihilangkan, maka setidaknya meminimalkan dampak dari masalah tersebut.

Jadi, untuk meringkas - pendekatan tersebut mencakup tiga langkah:

• Langkah 1 Pakar mencoba memahami esensi umum dari fenomena yang dijelaskan dalam peristiwa awal.
• Langkah 2 Pakar mengidentifikasi entitas utama dari jaringan dan tingkat aplikasi dalam acara: Subjek, Obyek, Sumber, Pemancar, Sumber Daya, Saluran Interaksi. Ini mengisolasi mereka dalam acara tersebut dan menentukan pola interaksi entitas ini. Setiap skema menghasilkan aturan untuk menempatkan entitas ini di bidang acara yang dinormalisasi - skema. Ini dijelaskan secara rinci dalam sebuah artikel yang ditujukan untuk skema interaksi entitas.
• Langkah 3 Pakar menentukan kategori tingkat pertama, kedua dan ketiga. Untuk setiap kategori, itu menciptakan direktori yang mencakup deskripsi data yang penting untuk ditemukan dalam acara tersebut selama normalisasi, informasi tentang bidang mana dari peristiwa yang dinormalisasi yang perlu untuk "menempatkan" data yang ditemukan.

Sekarang, dari konstruksi aturan korelasi untuk "bekerja di luar kotak", kita hanya dipisahkan oleh masalah perubahan konstan dalam entitas itu sendiri - aset. Alamat mereka berubah, aset baru diperkenalkan, yang lama dinonaktifkan, cluster node beralih, dan mesin virtual berpindah dari satu pusat data ke yang lain dan, kadang-kadang, bahkan dengan perubahan dalam pengalamatan. Cara mengatasi masalah ini, kita akan berbicara di artikel siklus berikutnya.

---

Seri artikel:

Kedalaman SIEM: korelasi out-of-box. Bagian 1: Pemasaran murni atau masalah yang tidak dapat diselesaikan?

Kedalaman SIEM: korelasi out-of-box. Bagian 2. Skema data sebagai refleksi dari model "dunia"

Kedalaman SIEM: korelasi out-of-box. Bagian 3.1. Kategorisasi acara

Kedalaman SIEM: korelasi out-of-box. Bagian 3.2. Metodologi Normalisasi Peristiwa ( Artikel ini )

Kedalaman SIEM: korelasi out-of-box. Bagian 4. Model sistem sebagai konteks aturan korelasi

Kedalaman SIEM: korelasi out-of-box. Bagian 5. Metodologi untuk mengembangkan aturan korelasi