Kami menyimpulkan serangkaian artikel yang ditujukan untuk aturan korelasi yang bekerja di luar kotak. Kami menetapkan tujuan untuk merumuskan pendekatan yang akan memungkinkan kami untuk membuat aturan korelasi yang dapat bekerja "di luar kotak" dengan minimum positif palsu.


Gambar: Pemasaran Perangkat Lunak

Semua poin utama dari artikel ini tersedia dalam kesimpulan , di tempat yang sama metodologi ini disajikan dalam bentuk diagram grafik.

Secara singkat tentang apa yang terjadi pada artikel sebelumnya: mereka mendeskripsikan seperti apa bentuk bidang kejadian yang dinormalisasi - diagram ; sistem kategorisasi acara mana yang digunakan; bagaimana, menggunakan sistem kategorisasi dan skema, untuk menyatukan proses normalisasi peristiwa. Kami juga memeriksa konteks penerapan aturan korelasi dan memeriksa apa yang harus diketahui SIEM tentang Sistem Otomatis (AS) yang dipantau, dan mengapa.

Semua pendekatan dan penalaran di atas adalah blok dari mana metodologi untuk mengembangkan aturan korelasi dibangun. Sudah waktunya untuk menyatukan mereka dan melihat seluruh gambar.

Seluruh metodologi untuk mengembangkan aturan korelasi terdiri dari empat blok:

• persiapan sumber dan lingkungan;
• normalisasi acara dan pengayaannya;
• adaptasi aturan korelasi dengan konteks AS;
• pembentukan kesepakatan tentang hal-hal positif.

Mempersiapkan sumber dan lingkungan

Aturan korelasi beroperasi pada peristiwa yang menghasilkan sumber. Dalam hal ini, sangat penting bahwa sumber-sumber yang diperlukan untuk aturan korelasi hadir dalam speaker dan dikonfigurasikan dengan benar.


Mempersiapkan sumber dan lingkungan

Langkah 1 : Pikirkan logika umum aturan dan pahami sumber acara apa yang dibutuhkan. Jika Anda mengembangkan dari awal atau mengambil aturan korelasi-Korelasi yang sudah jadi, Anda perlu memahami berdasarkan peristiwa dari mana sumber itu akan bekerja.

Langkah 2 : Pastikan semua sumber yang diperlukan ada di perusahaan dan mereka dapat dikumpulkan. Situasi mungkin terjadi ketika aturan beroperasi pada rantai peristiwa dari beberapa sumber formulir (peristiwa A dari sumber 1) - (peristiwa B dari sumber 2) - (peristiwa C dari sumber 3) selama 5 menit. Jika perusahaan Anda tidak memiliki setidaknya satu sumber, aturan seperti itu menjadi tidak berguna, karena tidak akan pernah berhasil. Anda perlu memahami apakah, pada prinsipnya, adalah mungkin untuk mengumpulkan acara dari sumber yang diperlukan dan apakah SIEM Anda dapat menyediakannya. Misalnya, sumber menulis acara ke file, tetapi file dienkripsi, atau database non-standar digunakan pada sumber untuk penyimpanan, akses yang tidak dapat dipastikan melalui driver ODBC / JDBC standar.

Langkah 3 : Hubungkan sumber ke SIEM. Tidak peduli seberapa basi itu terdengar, tetapi pada langkah ini perlu untuk menerapkan pengumpulan acara. Sering ada banyak masalah. Misalnya, masalah organisasi, ketika manajemen TI secara tegas melarang menghubungkan ke sistem kritis misi. Atau teknis, ketika tanpa pengaturan tambahan, agen SIEM (SmartConnector, Universal Forwarder), ketika mengumpulkan acara, cukup “membunuh” sumbernya, yang mengarah pada penolakan layanan. Ini sering dapat diamati ketika menghubungkan DBMS yang sangat dimuat ke SIEM.

Langkah 4 : Pastikan audit pada sumber dikonfigurasi dengan benar, peristiwa yang diperlukan untuk korelasi diterima dalam SIEM. Aturan korelasi mengharapkan jenis peristiwa tertentu. Mereka harus dihasilkan oleh sumber. Sering terjadi bahwa untuk menghasilkan peristiwa yang diperlukan untuk aturan, sumber harus dikonfigurasi tambahan: audit lanjutan diaktifkan dan log output dalam format tertentu dikonfigurasi.

Mengaktifkan audit yang diperluas sering memengaruhi jumlah aliran peristiwa (EPS) yang diterima dalam SIEM dari sumbernya. Karena fakta bahwa sumber itu sendiri dan SIEM berada dalam bidang tanggung jawab departemen yang berbeda, selalu ada risiko bahwa audit yang diperluas dapat dinonaktifkan dan, sebagai akibatnya, jenis peristiwa yang diperlukan akan berhenti datang ke SIEM. Masalah ini dapat dideteksi sebagian dengan memantau aliran peristiwa untuk setiap sumber, atau lebih tepatnya, memantau perubahan dalam Acara per Detik (EPS).

Langkah 5 : Verifikasi bahwa acara sedang berlangsung dan konfigurasikan pemantauan sumber. Dalam infrastruktur apa pun, cepat atau lambat, kegagalan dalam jaringan atau sumber itu sendiri muncul. Pada titik ini, SIEM kehilangan kontak dengan sumber dan tidak dapat menerima acara. Jika sumber pasif dan menulis log ke file atau database, peristiwa tidak akan hilang jika terjadi kegagalan dan SIEM akan dapat menerimanya ketika komunikasi dipulihkan. Jika sumbernya aktif dan mengirimkan acara ke SIEM, misalnya, melalui syslog, tanpa menyimpannya di mana saja, maka setelah kegagalan acara akan hilang, dan aturan korelasimu tidak akan berfungsi, karena acara yang diinginkan tidak akan menunggu. Menggali lebih dalam, Anda dapat melihat bahwa, bahkan ketika bekerja dengan sumber pasif, ketika memulihkan komunikasi setelah kegagalan, tidak ada jaminan bahwa aturan korelasi akan berhasil, terutama yang beroperasi dengan jendela waktu. Perhatikan contoh aturan yang dijelaskan di atas: (peristiwa A dari sumber 1) - (peristiwa B dari sumber 2) - (peristiwa C dari sumber 3) selama 5 menit. Jika kegagalan terjadi setelah peristiwa B dan koneksi dipulihkan dalam satu jam, korelasinya tidak akan berfungsi, karena acara C tidak akan tiba dalam 5 menit yang diharapkan.

Dengan mengingat fitur-fitur ini, Anda harus mengonfigurasi pemantauan sumber dari mana peristiwa dikumpulkan. Pemantauan ini harus memantau ketersediaan sumber, ketepatan waktu kedatangan acara dari mereka, kekuatan aliran acara yang dikumpulkan (EPS).

Pemicu dari sistem pemantauan adalah bel pertama yang berbicara tentang munculnya faktor negatif yang mempengaruhi kinerja semua atau sebagian dari aturan korelasi.

Normalisasi acara dan pengayaannya

Mengumpulkan peristiwa-peristiwa yang diperlukan untuk korelasi tidak cukup. Acara yang tiba di SIEM harus dinormalisasi secara ketat sesuai dengan aturan yang berlaku. Kami menulis tentang masalah normalisasi dan pembentukan metodologi normalisasi dalam artikel terpisah. Secara umum, blok ini dapat dikarakteristikkan sebagai pertarungan melawan sampah masuk, sampah keluar ( GIGO ).


Normalisasi dan pengayaan acara

Langkah 6 dan Langkah 7 : Kategorisasi acara dan normalisasi acara sesuai dengan kategori, berdasarkan metodologi. Kami tidak akan membahasnya secara rinci, karena kami mempertimbangkan langkah-langkah ini secara rinci dalam artikel "Metodologi untuk menormalkan peristiwa" .

Langkah 8 : Pengayaan acara dengan informasi yang hilang dan tambahan, sesuai dengan kategori. Seringkali, peristiwa yang masuk tidak selalu berisi informasi sejauh yang diperlukan agar aturan korelasi berfungsi. Misalnya, suatu peristiwa hanya berisi alamat IP host, tetapi tidak ada informasi tentang FQDN atau Hostname-nya. Contoh lain: suatu acara berisi ID pengguna, tetapi tidak ada nama pengguna dalam acara tersebut. Dalam hal ini, informasi yang diperlukan harus diambil dari sumber eksternal - database, pengontrol domain atau direktori lain dan ditambahkan ke acara tersebut.

Penting untuk dicatat bahwa kategorisasi peristiwa terjadi di awal - sebelum normalisasi. Selain fakta bahwa kategori mendefinisikan aturan untuk menormalkan acara, itu juga menetapkan daftar data yang harus dicari di sumber eksternal jika mereka tidak ada di acara itu sendiri.

Menyesuaikan aturan korelasi dengan konteks AS

Setelah Anda menyiapkan data input (peristiwa) dan melanjutkan ke pengembangan aturan korelasi, perlu untuk mempertimbangkan secara spesifik peristiwa yang masuk, AS itu sendiri dan variabilitasnya. Lebih lanjut tentang ini ada di artikel "Model Sistem sebagai Konteks Aturan Korelasi" .


Menyesuaikan aturan korelasi dengan konteks AS

Langkah 9 : Memahami frekuensi peristiwa dari masing-masing sumber, tentukan jendela waktu untuk korelasi. Cukup sering, aturan korelasi menggunakan jendela waktu ketika perlu untuk mengharapkan kedatangan suatu peristiwa tertentu dalam interval waktu tertentu. Saat mengembangkan aturan seperti itu, penting untuk mempertimbangkan keterlambatan dalam menerima acara. Mereka biasanya disebabkan oleh dua faktor.

Pertama , sumber itu sendiri mungkin tidak langsung menulis acara ke database, ke file, atau mengirimnya melalui syslog. Waktu keterlambatan ini harus diperkirakan dan diperhitungkan dalam aturan.

Kedua , ada keterlambatan pengiriman acara ke SIEM. Misalnya, kumpulan acara dari basis data dikonfigurasikan sehingga permintaan acara dilakukan sekali setiap 10 menit, tentu saja, bahwa jendela korelasi 5 menit bukanlah solusi terbaik dalam situasi ini.

Masalahnya diperparah ketika perlu untuk mengembangkan aturan korelasi yang bekerja dengan peristiwa dari beberapa sumber sekaligus. Dalam hal ini, penting untuk dipahami bahwa mereka mungkin memiliki waktu pengiriman yang berbeda. Dalam kasus terburuk, peristiwa akan terjadi secara acak dengan pelanggaran kronologi. Dalam situasi seperti itu, pengembang aturan korelasi perlu memahami dengan jelas kapan SIEM menyadari korelasi tersebut (pada waktu kejadian atau ketika acara tiba di SIEM). Saya perhatikan bahwa korelasi pada saat kedatangan acara adalah opsi yang paling sederhana dan paling umum secara teknis untuk memproses acara dalam mode pseudo-real-time. Namun, opsi ini hanya memperburuk masalah di atas, dan tidak menyelesaikannya.

Jika SIEM Anda memberikan korelasi pada waktu acara, maka kemungkinan besar ada mekanisme untuk memesan ulang acara yang dapat mengembalikan kronologi peristiwa yang sebenarnya.

Jika Anda memahami bahwa jendela waktu terlalu besar untuk melakukan korelasi pada streaming, Anda harus menggunakan mekanisme korelasi retro, di mana peristiwa yang sudah disimpan dipilih dari database SIEM sesuai dengan jadwal dan menjalankan melalui aturan korelasi.

Langkah 10 : Membangun Mekanisme Pengecualian. Di dunia nyata, akan selalu ada objek dengan perilaku khusus yang tidak boleh ditangani oleh aturan korelasi tertentu, karena ini mengarah ke false positive. Oleh karena itu, pada tahap pengembangan aturan, mekanisme harus dilakukan untuk menambahkan objek tersebut ke pengecualian. Misalnya, jika aturan Anda berfungsi dengan alamat IP mesin, Anda memerlukan daftar tabel tempat Anda dapat menambahkan alamat yang aturannya tidak akan berfungsi. Demikian pula, jika aturan bekerja dengan login pengguna atau nama proses, perlu terlebih dahulu bekerja dengan daftar pengecualian tabel dalam logika aturan.

Pendekatan ini akan memungkinkan Anda untuk secara otomatis atau menambahkan objek ke pengecualian tanpa harus menulis ulang isi aturan.

Langkah 11 : Tentukan batas fisik dan logis penerapan aturan korelasi. Ketika mengembangkan aturan korelasi, penting untuk memahami batas-batas penerapan (ruang lingkup) aturan tersebut, dan apakah aturan itu ada atau tidak. Saat mengerjakan logika dan men-debug aturan, perlu untuk fokus pada spesifik area ini. Jika aturan mulai bekerja dengan data yang melampaui ruang lingkup bidang ini, kemungkinan positif palsu meningkat.

Dua jenis ruang lingkup dapat dibedakan: fisik dan logis. Lingkup fisik adalah jaringan perusahaan dan yang berdekatan, dan area logis adalah bagian dari AS, aplikasi bisnis, atau proses bisnis. Contoh area fisik: segmen DMZ, subnet internal dan eksternal, jaringan akses jarak jauh. Contoh lingkup logis dari aturan: kontrol proses, akuntansi, segmen PCI DSS, segmen PD, atau hanya peran peralatan tertentu - pengontrol domain, sakelar akses, router inti.

Anda dapat mengatur cakupan untuk aturan korelasi melalui daftar tabel. Mereka dapat diisi secara manual atau otomatis. Jika Anda menemukan waktu di perusahaan Anda untuk manajemen aset (manajemen aset), maka semua data yang diperlukan mungkin sudah terkandung dalam model AS yang dibuat dalam SIEM. Pembuatan daftar tabular otomatis semacam itu memungkinkan Anda untuk secara dinamis memasukkan dalam ruang lingkup aset baru yang muncul di perusahaan. Misalnya, jika Anda memiliki aturan yang bekerja secara eksklusif dengan pengontrol domain, menambahkan pengontrol baru ke forest domain akan diperbaiki dalam model dan akan jatuh ke dalam cakupan aturan Anda.

Secara umum, daftar tabel yang digunakan untuk pengecualian dapat dianggap sebagai daftar hitam, dan daftar yang bertanggung jawab atas ruang lingkup aturan sebagai daftar putih.

Langkah 12 : Gunakan model speaker untuk mengklarifikasi konteksnya. Dalam proses mengembangkan aturan korelasi yang mengidentifikasi tindakan jahat, penting untuk memastikan bahwa tindakan itu benar-benar dapat diterapkan. Jika ini tidak diperhitungkan, pemicu aturan yang mengungkapkan potensi serangan akan berubah menjadi salah, karena jenis serangan ini mungkin tidak berlaku untuk infrastruktur Anda. Saya akan jelaskan dengan sebuah contoh:

1. Misalkan kita memiliki aturan korelasi yang mendeteksi koneksi RDP jarak jauh ke server.
2. Firewall menampilkan upaya untuk menyambung ke server myserver.local port TCP 3389.
3. Aturan menyala, dan Anda mulai mengurai potensi insiden dengan prioritas tinggi.

Selama penyelidikan, Anda dengan cepat mengetahui bahwa di myserver.local 3389 ditutup dan tidak pernah dibuka oleh layanan apa pun dan Linux ada di sana. Ini adalah hasil positif palsu yang perlu waktu untuk Anda selidiki.

Contoh lain: IPS mengirimkan peristiwa pemicu tanda tangan ketika upaya dilakukan untuk mengeksploitasi kerentanan CVE-2017-0144, tetapi selama penyelidikan ternyata patch yang sesuai dipasang pada mesin yang diserang dan tidak perlu menanggapi insiden seperti itu dengan prioritas tertinggi.
Menggunakan data dari model speaker akan membantu meratakan masalah ini.

Langkah 13 : Gunakan pengidentifikasi entitas, bukan kunci sumbernya. Seperti yang sudah dijelaskan dalam artikel "Model Sistem sebagai Konteks Aturan Korelasi", alamat IP, FQDN, dan bahkan MAC suatu aset dapat berubah. Jadi, jika Anda menggunakan pengidentifikasi sumber aset dalam aturan korelasi atau daftar tabel, maka setelah beberapa saat ada kemungkinan besar menerima positif palsu untuk alasan yang benar-benar dangkal, misalnya, server DHCP hanya mengeluarkan IP ini ke komputer lain.

Jika SIEM Anda memiliki mekanisme untuk mengidentifikasi aset, melacak perubahannya dan memungkinkan Anda untuk beroperasi dengan pengidentifikasi mereka, Anda harus menggunakan pengidentifikasi, bukan kunci sumber aset.

Terbentuknya kesepakatan positif

Mendekati blok terakhir pembuatan aturan korelasi, kami ingat bahwa hasil dari aturan tersebut adalah insiden yang muncul di SIEM. Para profesional yang bertanggung jawab harus menanggapi insiden semacam itu. Meskipun tujuan dari rangkaian artikel ini tidak termasuk pertimbangan proses respons insiden, harus dicatat bahwa sebagian informasi tentang insiden tersebut sudah dihasilkan pada tahap pembuatan aturan korelasi yang sesuai.

Berikutnya, kami mempertimbangkan poin-poin dasar yang harus diperhitungkan ketika mengkonfigurasi parameter untuk memicu aturan korelasi dan menghasilkan insiden.


Terbentuknya kesepakatan positif

Langkah 14 : Tentukan kondisi agregasi dan penutupan jika terjadi sejumlah besar kesalahan positif. Pada tahap debugging, dan dalam proses fungsinya, jika Anda tidak mematuhi teknik ini :), alarm palsu dari aturan dapat terjadi. Baik jika ada satu atau dua perjalanan per hari, tetapi bagaimana jika satu aturan memiliki ribuan atau puluhan ribu perjalanan? Tentu saja, ini menunjukkan bahwa aturan tersebut perlu dikembangkan lebih lanjut. Namun, perlu untuk memastikan bahwa dalam situasi seperti itu positif palsu besar:

1. Itu tidak mempengaruhi kinerja SIEM.
2. Di antara massa positif palsu, insiden yang sangat penting tidak hilang. Bahkan ada jenis serangan terpisah yang bertujuan menyembunyikan aktivitas jahat utama di balik banyak kegiatan palsu.

Masalah semacam ini dapat diselesaikan jika, ketika membuat aturan korelasi di tingkat keseluruhan sistem secara keseluruhan atau untuk masing-masing aturan secara terpisah, kondisi untuk agregasi insiden dan kondisi untuk penutupan darurat aturan ditetapkan.

Mekanisme agregasi insiden tidak akan memungkinkan untuk membuat jutaan insiden identik, tetapi untuk "merekatkan" insiden baru menjadi satu, asalkan mereka identik. Dalam kasus ekstrim, ketika agregasi insiden memberikan beban yang signifikan, disarankan untuk mengkonfigurasi penonaktifan otomatis aturan korelasi ketika melebihi jumlah operasi tertentu per satuan waktu (menit, jam, hari).

Langkah 15 : Tentukan aturan untuk menghasilkan nama insiden. Item ini sering diabaikan, terutama jika mereka tidak mengembangkan aturan untuk perusahaan mereka, misalnya, jika perusahaan pihak ketiga bertanggung jawab untuk menerapkan SIEM dan mengembangkan aturan. Nama aturan korelasi, serta insiden yang dihasilkannya, harus pendek dan jelas mencerminkan esensi aturan tertentu.

Jika lebih dari satu orang bekerja dengan insiden dan aturan korelasi di perusahaan Anda, disarankan agar Anda mengembangkan aturan penamaan. Mereka harus dipahami dan diterima oleh seluruh tim yang bekerja dengan SIEM.

Langkah 16 : Tetapkan aturan untuk membentuk pentingnya insiden. Sebagian besar solusi SIEM pada tahap terakhir menciptakan insiden memungkinkan Anda untuk menetapkan kepentingan dan signifikansinya. Beberapa keputusan bahkan menghitung kepentingan secara otomatis, berdasarkan konteks kejadian dan objek yang terlibat di dalamnya.

Jika SIEM Anda mengoperasikan penghitungan otomatis eksklusif tentang pentingnya insiden, ada baiknya mencari tahu berdasarkan apa dan dengan rumus apa ia dihitung. Misalnya, jika kepentingan dihitung berdasarkan pentingnya aset yang terlibat dalam kejadian tersebut, Anda harus menganggap serius masalah Manajemen Aset di perusahaan terlebih dahulu.

Jika Anda menetapkan pentingnya suatu insiden secara manual, Anda disarankan untuk mengembangkan formula perhitungan yang memperhitungkan setidaknya yang berikut ini:

1. Pentingnya ruang lingkup di mana aturan bekerja. Misalnya, insiden di zona kritis sistem Misi mungkin lebih kritis daripada jika insiden yang sama persis terjadi di zona sistem kritis Bisnis.
2. Pentingnya aset dan akun pengguna yang terlibat dalam insiden tersebut.
3. Perulangan kejadian ini di perusahaan.

Juga, seperti dalam menyebutkan insiden, penting bahwa semua pihak yang berkepentingan memahami dengan jelas dan sama aturan tentang pentingnya suatu insiden.

Kesimpulan

Merangkum hasil dari seri artikel kami, saya perhatikan bahwa adalah mungkin, menurut pendapat saya, untuk membuat aturan korelasi yang bekerja di luar kotak. Solusinya mungkin merupakan perpaduan dari pendekatan organisasi dan teknis. SIEM sendiri harus dapat melakukan sesuatu, tetapi spesialis yang mengoperasikannya harus melakukan dan mengetahui sesuatu.

Untuk meringkas:

1. Metode ini terdiri dari blok-blok berikut:
   
   • Mempersiapkan sumber dan lingkungan.
   • Normalisasi acara dan pengayaannya.
   • Adaptasi aturan korelasi dengan konteks AS.
   • Terbentuknya kesepakatan tentang hal-hal positif.
2. Setiap unit memiliki komponen organisasi dan teknis.
3. , SIEM, .
4. , , SIEM-.
5. . .

, « »

, , . — . .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «»

SIEM: « ». Bagian 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4.

SIEM: « ». 5. ( )