SOC ABC OT. Mengapa SOC klasik tidak akan melindungi sistem kontrol proses

Bukan rahasia lagi bagi siapa pun bahwa pengalaman dan keahlian utama dalam subjek SOC di Rusia (dan, pada prinsipnya, di dunia) terutama difokuskan pada masalah kontrol dan keamanan jaringan perusahaan. Ini bisa dilihat dari rilis, laporan di konferensi, meja bundar dan sebagainya. Tetapi ketika ancaman berkembang (kami tidak akan mengingat penderitaan yang ditetapkan Stuxnet, namun, bagaimanapun, kami tidak akan melewati Black / Grey Energy, Industroyer dan Triton) dan persyaratan peraturan hukum "Tentang keamanan infrastruktur informasi kritis Federasi Rusia) pertanyaan tentang perlunya mencakup Perhatian SOC dan maha kudus semua perusahaan industri adalah segmen ICS. Kami melakukan pendekatan hati-hati pertama pada cangkang ini sekitar satu setengah tahun yang lalu ( 1 , 2). Sejak itu, ada lebih banyak pengalaman dan penelitian, dan kami merasakan kekuatan untuk meluncurkan siklus penuh materi yang ditujukan untuk masalah SOC OT. Mari kita mulai dengan bagaimana teknologi dan proses SOC perusahaan, yang telah lama kita kenal, berbeda dari SOC industri (segala sesuatunya akan datang secara alami ke masalah personalia). Jika Anda tidak acuh tak acuh dengan topik, silakan, di bawah kucing.







Agar analisis menjadi substantif, pertama-tama kami perbaiki bahwa kami membandingkan SOC OT dengan struktur pusat pemantauan, yang diterapkan di Solar JSOC kami.







Antara lain akan memungkinkan kita untuk membahas perbedaan tersebut dalam konteks tugas pusat GosSOPKA yang juga bertanggung jawab pada segmen industri.



Detail tentang setiap level model dapat ditemukan di artikel sebelumnya tentang inventaris infrastruktur , pemantauan , Threat Intelligence ( 1 , 2 ), kontrol keamanan , personel , dan proses.... Dalam artikel saat ini, kami akan fokus pada blok pusat Pemantauan Keamanan (fitur proses respons dan investigasi di ICS akan dijelaskan di artikel selanjutnya).



Teater dimulai dengan gantungan, dan SOC dimulai dengan pemantauan



Tampaknya di bidang pemantauan peristiwa, korelasi dan deteksi insiden, semuanya sudah ditentukan dan diketahui. Dan bahkan menjembatani celah udara untuk mengumpulkan peristiwa keamanan adalah topik yang patut dicoba dan benar . Namun, bagaimanapun, ada beberapa nuansa yang patut diperhatikan.



Arsitektur SOC umum... Meskipun solusi yang tampaknya sederhana dengan celah udara, situasi untuk perusahaan federal besar dengan fasilitas terdistribusi (ini terutama berlaku untuk industri listrik) agak rumit. Jumlah objek diukur dalam ribuan, seringkali bahkan tidak mungkin untuk menempatkan server kumpulan acara di atasnya, masing-masing objek cukup kompak, tetapi dapat menghasilkan peristiwa keamanan informasi yang signifikan. Bahkan di atas situasi yang dijelaskan, masalah saluran komunikasi sering dilapiskan, begitu sempit sehingga setidaknya beberapa beban yang signifikan pada transmisi acara ke "pusat" mulai mengganggu pengoperasian aplikasi utama.



Oleh karena itu, bagaimana cara menguraikan komponen SIEM dengan benar berdasarkan situs adalah pertanyaan yang sangat serius. Kami akan kembali ke sana di salah satu materi kami selanjutnya, sejakbidang buku harian ini terlalu kecil untuk memuatnya karena satu artikel informasi akan menjadi terlalu banyak.



Spesialisasi dan Pembuatan Profil Kasus Penggunaan . Bahkan tanpa menyentuh topik skenario yang sepenuhnya terspesialisasi yang hanya relevan untuk segmen ICS, perlu dicatat bahwa bahkan insiden standar di ICS memiliki arti dan kekritisan yang sama sekali berbeda. Kita semua sudah terbiasa menggunakan Alat Admin Jarak Jauh di jaringan perusahaan untuk waktu yang lama. Tetapi jelas bahwa kekritisan insiden semacam itu, serta, pada prinsipnya, komunikasi yang berhasil dengan Internet dalam jaringan teknologi tertutup, sangatlah besar. Hal yang sama berlaku untuk penginstalan layanan sistem baru di workstation teknologi, fakta pendeteksian malware, yang memerlukan investigasi wajib, dll.



Pembatasan signifikan pada operasi Use-Case juga diperkenalkan oleh pembatasan pada implementasi sistem keamanan informasi (biasanya segmen teknologi tidak terlalu kaya di dalamnya), dan penggunaan sistem operasi versi lama (dan ahli teknologi melihat instalasi Sysmon dengan ketidakpercayaan).



Namun demikian, volume kasus penggunaan lingkungan korporat yang sangat besar dapat berhasil diterapkan ke segmen ICS dan memberikan tingkat kontrol infrastruktur keseluruhan yang cukup tinggi.



Nah, sulit untuk melewati maha suci - sistem SCADA... Jika pada tingkat sistem keamanan informasi, sistem operasi dan aliran jaringan, semua segmen setidaknya sedikit, tetapi serupa, maka ketika bergerak lebih dalam, perbedaan utama muncul. Dalam hal jaringan dan segmen perusahaan, setiap orang memimpikan pemantauan bisnis dan konektivitas aplikasi bisnis. Dan proses ini, meskipun rumit (log bermutasi dan tidak ingin berpura-pura menjadi CEF, informasi normal hanya dapat diperoleh dari database, tetapi administrator bersumpah dan mengeluh tentang perlambatan), tetapi umumnya diterapkan. Di segmen teknologi, ketika menghubungkan sistem tingkat atas dan menengah, masalah ini diangkat ke titik absolut sehubungan dengan kekritisan ruang dari waktu henti teknologi. Untuk mengambil langkah pertama untuk menghubungkan sumber, Anda perlu:



  1. Pasang dudukan dan periksa keberhasilan menerima acara
  2. Gambarlah solusi arsitektur umum dengan semua detail teknis
  3. Setuju dengan vendor dalam beberapa bulan
  4. Periksa lagi di stand pelanggan dengan emulasi beban tempur
  5. Sangat hati-hati (seperti dalam lelucon tentang landak) untuk menerapkan solusi ke dalam produksi


Kesedihan, kerinduan, proses bisnis. Dan ini terlepas dari kenyataan bahwa, sebagai suatu peraturan, peralatan APCS dicirikan oleh logging yang cukup luas, lengkap, dapat dimengerti, dan berkualitas tinggi.



Tapi, untungnya (atau secara kebetulan), biasanya pendekatan yang berbeda dapat diterapkan di segmen ICS. Sebagian besar protokol di dalamnya tidak menyiratkan enkripsi atau penyamaran informasi yang dikirimkan. Oleh karena itu, salah satu pendekatan yang paling umum untuk memantau dan mengurai perintah kontrol adalah penerapan sistem deteksi intrusi industri atau firewall industri yang memungkinkan Anda untuk bekerja dengan salinan atau lalu lintas jaringan aktual dan protokol parse serta perintah kontrol dengan logging berikutnya. Beberapa di antaranya, antara lain, memiliki mesin korelasi dasar bawaan di dalamnya (menyelamatkan kita dari kengerian normalisasi, kategorisasi, dan pembuatan profil peristiwa), tetapi pada saat yang sama mereka bukan pengganti penuh untuk sistem SIEM.



, ,



Bergerak. Tampaknya masalah inventaris di jaringan ICS adalah yang paling tidak menyakitkan. Jaringan cukup statis, peralatan diisolasi dari segmen umum, membuat perubahan arsitektur membutuhkan proyek kerja secara keseluruhan. Dongeng tentang jaringan perusahaan - "Perbaiki saja modelnya dan masukkan ke CMDB." Tapi, seperti biasa, ada nuansa: untuk segmen ICS, kemunculan peralatan baru adalah salah satu tanda yang sangat penting dari sebuah insiden atau serangan, dan harus diidentifikasi tanpa gagal. Dan dengan semua ini, metode klasik inventaris (mode operasi hemat pemindai kerentanan) menyebabkan alergi paling parah di antara para ahli teknologi, dan bahkan di antara personel keamanan sistem kontrol proses otomatis. Hal ini tidak biasa dalam jaringan perusahaan ketika Pemindaian Inventaris dalam mode yang tidak berhasil pada waktu yang tidak berhasil dapat "menempatkan" beberapa aplikasi tertentu.Biasanya, tidak ada yang siap mengambil risiko seperti itu dalam sistem kontrol proses otomatis.



Oleh karena itu, alat inventaris utama di APCS (selain kontrol manual) adalah sistem analisis lalu lintas jaringan dan sistem deteksi intrusi industri yang telah disebutkan sebelumnya. Setiap node baru, muncul di jaringan, mulai berkomunikasi dengan tetangganya. Baik metode dan protokol komunikasi, kekhususan paket dan bidang layanan memungkinkan tidak hanya untuk melihat "tetangga" baru dengan cepat, tetapi juga untuk mengidentifikasinya dengan jelas.



Sebaliknya, proses mengidentifikasi dan mengelola kerentanan lebih konservatif. Sebagai aturan, infrastruktur jarang diperbarui dan ditambal dan dengan cara yang sangat terkontrol; daftar perangkat lunak aplikasi dan peralatan teknologi diperbaiki. Oleh karena itu, untuk menentukan daftar dan status kerentanan saat ini di segmen ICS, biasanya cukup menentukan versi perangkat lunak utama dan memeriksa buletin produsen. Akibatnya, kami beralih dari mode pemindaian agresif dan verifikasi perangkat lunak ke metode audit versi manual dan teknis serta analitik dari seorang pakar dari industri.



Proses menganalisis atau mengidentifikasi ancaman dibangun dengan cara yang serupa. Sebagai aturan, model tetap satu kali dimodernisasi baik berdasarkan fakta pembangunan kembali infrastruktur yang kritis (menambahkan node baru, memperbarui versi firmware peralatan kritis, dll.), Atau setelah mengungkapkan kerentanan baru yang relevan dengan infrastruktur dan / atau vektor serangan baru. Namun, dengan mereka juga, semuanya tidak sesederhana itu.



OT Threat Intelligence atau apakah jaringan terisolasi memimpikan indikator kompromi



Mungkinkah informasi tentang ancaman baru dan vektor serangan tidak berguna? Saya ingin segera menjawab "tidak", tetapi bersama-sama mari kita coba memahami penerapan data TI klasik di segmen PL yang matang.



TI biasanya berupa umpan (aliran data) atau IoC (indikator gangguan untuk mengidentifikasi perangkat lunak perusak atau alat peretasan tertentu). Mereka mengandung karakteristik berikut:



  • (IP-, URL, ), upload ยซยป , . , , . , , ยซยป .
  • (MD5- , , / ..), / / . , . , , , , whitelisting, , . โ€“ ยซยป . TI .


Akibatnya, untuk serangan yang ditujukan pada ICS, informasi tentang TTP, taktik, dan pendekatan penyerang terhadap serangan, yang sangat jarang terjadi di pasar TI, memperoleh bobot yang jauh lebih besar, yang akan memungkinkan mekanisme dan pendekatan pertahanan yang tepat untuk memantau dan mengidentifikasi ancaman di segmen tersebut.



Hal ini dan banyak nuansa lainnya memaksa kami untuk mengambil pendekatan yang sangat serius dan bijaksana dalam proses membangun SOC semacam itu atau pemilihan kontraktor, serta secara serius memikirkan tentang strategi untuk membentuk SOC PL. Jika itu bersinggungan dengan SOC IT atau fungsinya terpisah darinya, mungkinkah semacam saling memperkaya dan sinergi dalam proses, tim, dan tugas untuk diselesaikan. Dalam artikel kami berikutnya, kami akan mencoba menyoroti pendekatan yang berbeda dari tim internasional untuk masalah ini. Aman di semua aspek infrastruktur dan kehidupan Anda.



All Articles