Get best of the week

Keamanan Informasi Platform respons insiden otomatis

Bayangkan sebuah pusat situasi khas untuk keamanan informasi di sebuah perusahaan besar. Di dunia yang ideal, perangkat lunak mendeteksi aktivitas mencurigakan, dan tim "peretas putih" mulai mengetuk tangan mereka pada keyboard. Dan ini terjadi sebulan sekali.

Di dunia nyata, ini adalah ratusan positif palsu dan staf pendukung yang lelah. Mereka terpaksa berurusan dengan setiap kejadian ketika pengguna lupa kata sandi, tidak dapat mengunduh game dari torrent, film porno lain dalam format * .exe, menonton kegagalan jaringan dan umumnya menyelidiki banyak situasi.

Sistem SIEM membantu mengatur dan menghubungkan peristiwa dari sumber. Dan mereka menghasilkan hal-hal positif, yang masing-masing perlu ditangani. Dari "semua orang" ini, mayoritas adalah palsu. Anda dapat mendekati masalah di sisi lain, memiliki skrip untuk pemrosesan alarm. Setiap kali sesuatu bekerja, alangkah baiknya tidak hanya memiliki penyebab alarm, dan kemudian naik ke empat hingga lima sistem untuk data yang berbeda, dan segera secara otomatis mengumpulkan seluruh diagnosis.



Kami membuat add-on seperti itu, dan itu sangat membantu mengurangi beban operator. Karena skrip untuk mengumpulkan informasi segera diluncurkan, dan jika ada tindakan tipikal, mereka segera diambil. Artinya, jika Anda memulai sistem "dalam situasi seperti itu, kami melakukan ini dan itu", maka kartu akan terbuka untuk operator dengan situasi yang sudah berjalan.

Apa yang salah dengan sistem SIEM?


Daftar offset dipenuhi dengan data mentah. Kartu insiden khusus untuk pengisian ditransfer ke platform kami.

Kasus-kasus umum memiliki diagram alir sampel reaksi.

Di sini, misalnya, laporan analisis data tentang kesalahan otentikasi pengguna:



Ada kriteria untuk false positive: misalnya, saya mencobanya dua kali - saya masuk dari yang ketiga. Pengguna baru saja menerima surat yang mengatakan bahwa kata sandi harus diketik dengan hati-hati, tiket ditutup. Jika dia mencoba lima atau enam kali, maka informasi terperinci sudah mulai dikumpulkan: apa yang terjadi selanjutnya, apa yang terjadi sebelumnya, dan seterusnya. Jika dia masuk 10 kali, dan kemudian pergi ke basis pengetahuan dan mulai mengunduh 10 file, maka mungkin ada pengaturan untuk "memblokir akses ke basis pengetahuan sampai akhir proses dan memberi tahu operator". Kemungkinan besar, jika pengguna tidak jahat, dalam hal ini departemen TI akan secara otomatis menerima email berisi perincian. Mungkin mereka akan mengajarkan pengguna untuk memasukkan kata sandi dengan benar atau membantu mengubahnya.

Jika aktivitas lebih berbahaya, level "membuka file yang dapat dieksekusi dalam surat, dan kemudian sesuatu mulai merayap di Web", maka seluruh segmen atau subnet dapat secara otomatis diblokir. Ya, SIEM dapat melakukan ini sendiri, tetapi tanpa penyesuaian, mungkin, tindakan seperti itu adalah batas otomatisasi.

Sekali lagi, di dunia yang ideal, operator memiliki akses ke semua sistem dan segera tahu apa yang harus dilakukan. Di dunia nyata, ia sering perlu menemukan seseorang yang bertanggung jawab untuk mengklarifikasi sesuatu. Dan dia juga sedang liburan atau di pertemuan. Oleh karena itu, bagian penting lainnya - dalam diagram alir reaksi harus segera bertanggung jawab untuk bagian sistem dan departemen tertentu. Artinya, Anda tidak perlu mencari ponsel karyawan, nama bosnya dan ponselnya, tetapi untuk segera melihatnya di kartu terbuka.

Apa yang telah kita lakukan


  1. , (), - .
  2. , ( ), , .
  3. , -. : , , .
  4. , .
  5. .
  6. ( , , ).
  7. .
  8. GUI -.

Salah satu pelanggan utama kami adalah SIEM QRadar. Sistem deteksi ancaman yang baik, ada tindakan dan langkah untuk setiap insiden, tetapi Anda tidak dapat memberikan daftar pekerjaan untuk operator manusia. Ketika datang ke superclass profesional, ini tidak perlu. Ketika datang ke operator dari baris pertama, sangat penting untuk memberinya instruksi tentang apa dan bagaimana melakukannya, dan ia akan dapat mencakup sebagian besar insiden khas di tingkat spesialis keren.

Artinya, kami mengeluarkan semua peristiwa yang jelas membosankan di baris pertama dan menambahkan kriteria ke skrip yang memisahkan membosankan dari yang membosankan. Semuanya atipikal, seperti sebelumnya, jatuh pada pro.

Kasing untuk perusahaan dari beberapa puluh ribu tempat kerja dan dengan kapasitas server mereka di beberapa pusat data telah diselesaikan dan diresepkan sebagai hasilnya selama sekitar satu tahun (ada hubungan yang sulit antara departemen, yang membuat integrasi ke dalam sistem yang berbeda menjadi sulit). Tetapi sekarang setiap sub-tugas dalam kartu memiliki penanggung jawab tertentu, dan selalu relevan.

Kesederhanaan bagi operator dapat dinilai dari fakta bahwa setelah implementasi, sistem pertama kali diluncurkan ke daerah, dan kemudian, setelah beberapa minggu, dokumentasi resmi mulai dikirim. Jadi selama ini, orang sudah mulai menutup insiden dengan percaya diri.

Bagaimana awalnya?


Ada SIEM, tetapi tidak jelas apa yang terus-menerus terjadi. Lebih tepatnya, QRadar menghasilkan banyak peristiwa, mereka jatuh ke departemen keamanan informasi, dan tidak ada tangan untuk membongkar semuanya dengan benar dan detail. Akibatnya, laporan hanya dilihat secara dangkal. Manfaat dari SIEM dengan pendekatan ini tidak terlalu tinggi.

Ada sistem manajemen aset.

Ada server untuk memindai jaringan, dikonfigurasi dengan sangat baik.

Laporan itu akan sangat bagus, tetapi mereka menatapnya dengan lelah dan menunda.

Pelanggan menginginkan apa yang mereka beli untuk mulai menghasilkan hasil.

Kami menempatkan meja layanan untuk penjaga keamanan di atas (sebenarnya sistem tiket, seperti dalam dukungan normal), memvisualisasikan analisis data, dan menulis platform otomasi yang dijelaskan atas dasar IBM Resilient + menambahkan reaksi khas. Tangguh datang telanjang, itu hanya kerangka kerja. Kami mengambil aturan korelasi dari QRadar sebagai dasar dan menyelesaikan rencana respons untuk kasus pengguna.



Selama beberapa bulan mereka melakukan Russification dari semuanya dan menggantung bundel yang benar oleh API. Segera setelah kami selesai, vendor mengeluarkan Russification, dan kami sedikit sedih.

Sekitar sebulan mereka berlatih dan berkenalan dengan dokumentasi (khususnya, cara menggambar diagram alur baru untuk kartu). Semakin jauh mereka belajar, kasus-kasus yang lebih sederhana menjadi: pada awalnya skrip tindakan besar ditulis, dan kemudian ternyata mereka menjadi semacam perpustakaan dari kasus-kasus tipikal. Dan orang dapat merujuk mereka dalam hampir semua reaksi.

Perbandingan reaksi


Insiden "Infeksi virus berulang dengan malware yang sama dalam waktu singkat." Artinya, virus terdeteksi di workstation, tetapi personel diperlukan untuk memahami dari mana ia berasal. Sumber infeksi aktif.

Klasik:

  1. Ada infeksi virus berulang dari host 192.168.10.5 dengan malware yang sama untuk waktu yang singkat, peristiwa dikirim ke SIEM, dan aturan yang sesuai berhasil.
  2. .
  3. .
  4. .
  5. .
  6. /CMDB-.
  7. .
  8. - , .
  9. / .
  10. Service Desk .
  11. Mengisi aplikasi dalam sistem Desk Service berdasarkan hasil investigasi untuk menghilangkan kerentanan yang disebabkan oleh host ini terinfeksi.
  12. Dia menunggu aplikasi layanan Meja ditutup, dan kemudian memeriksa eksekusi mereka.
  13. Mengisi kartu insiden dan menutup insiden itu.
  14. Melaporkan kepada manajemen tentang hasil pekerjaannya.
  15. Analis mengumpulkan statistik insiden untuk menganalisis efektivitas proses respons.

Di platform kami:

  1. Ada infeksi virus berulang pada host 192.168.10.5 dengan malware yang sama dalam waktu singkat, peristiwa dikirim ke SIEM, dan aturan yang sesuai berhasil.
  2. Operator melihat kartu kejadian, di mana informasi tentang host ini, status alat perlindungan anti-virus dan log-nya, kerentanan pada host, insiden terkait dan orang yang bertanggung jawab untuk host ini telah diunduh.
  3. , : , , Service Desk , - .
  4. Service Desk , .
  5. .
  6. .




Itu menjadi sedikit lebih cepat. Tetapi yang utama bukanlah ini, tetapi adalah mungkin untuk memilah tugas menjadi “operator lini pertama yang akan menangani” dan “kebutuhan khusus”. Artinya, rata-rata, solusi untuk setiap tiket menjadi jauh lebih murah, dan sistemnya lebih terukur.



Selain banyak positif palsu, ada banyak duplikat yang ternyata mudah dideteksi oleh sistem.



Kartu tidak terlihat seperti kumpulan data tidak jelas dari laporan, tetapi seperti “Vasya melakukan ini dan itu pada host. Ini buruk. Tuan rumah bertanggung jawab untuk Petya. Itulah tepatnya yang terjadi. Kita perlu pergi ke Petya dan mengatakan bahwa komputer Vasya dari area kerja tidak dapat digunakan untuk menampilkan presentasi di konferensi. "

Hal penting lainnya dalam semua ini adalah bahwa berdasarkan pada pengumpulan data primer, dimungkinkan untuk memprioritaskan tiket. Artinya, potensi ancaman utama muncul dan membutuhkan perhatian segera, dan tidak dalam antrian langsung.

Otomatisasi pada antarmuka dengan tiket TI memungkinkan tidak hanya untuk mengumpulkan semua informasi tentang insiden tersebut, tetapi juga untuk segera memasukkan tiket ke departemen TI. Jika Anda perlu mengubah beberapa pengaturan pada router, maka sekarang tiket dari IT dihasilkan secara otomatis, misalnya. Anehnya, kasus mulai muncul "lupa mengubah akun di layanan, dan ia mencoba terhubung selama sebulan." TI tidak melihat situasi seperti itu atau mengabaikan infrastruktur. Dan di sini IS mengatakan - layanan tidak dapat masuk. Dan mereka menaruh tiket.

Berkat pengetikan kartu reaksi, insiden mulai diselesaikan dengan metode standar. Sebelumnya, masing-masing diputuskan secara kreatif: orang yang berbeda melakukan tindakan yang berbeda.

Hasilnya adalah alur kerja yang baik seperti dalam CRM modern. Insiden melewati corong. Masalah lain diselesaikan pada tahap terakhir: orang-orang yang sebelumnya kadang-kadang menutup tiket hanya karena lelah. Artinya, hasilnya tidak ditentukan dengan benar. Dan sekarang Anda perlu membuktikan kepada sistem bahwa ini adalah false positive. Artinya, Anda bisa menutupnya, seperti sebelumnya, tetapi jelas bahwa, siapa dan dalam kondisi apa melakukannya, dan jauh lebih mudah untuk membuka kusen. Bukan hanya "pengguna tidak dapat menjalankan file", tetapi "membawa game di USB flash drive, ingin menginstalnya - mereka menjelaskan aturan hidup sekali lagi". Dan sudah jelas apa yang terjadi.

Keserbagunaan


Sekarang ada beberapa integrasi dalam produksi (satu sangat besar dengan QRadar dan sistem manajemen aset, yang lain lebih kecil). Dimungkinkan untuk menautkan dengan SIEM apa pun menggunakan API standar, tetapi, tentu saja, integrasi memerlukan waktu untuk konektor, penyempurnaan file, dan menuliskan aturan reaksi untuk orang-orang. Namun demikian, sangat membantu untuk benar-benar menanggapi insiden keamanan dan melakukannya dengan relatif cepat dan relatif murah. Sangat mungkin bahwa dalam 10 tahun sistem SIEM sendiri akan dapat melakukan ini, tetapi sejauh ini add-on kami telah menunjukkan diri dengan baik.

Jika Anda ingin merasakannya bersama kami atau membahas bagaimana penampilannya dengan Anda, berikut adalah surat saya AAMatveev@technoserv.com.

More articles:


All Articles