Teknologi Operasional di IoT Industri Tidak Dapat Menoleransi Penambalan Gaya TI. “Analisis Ancaman” adalah Solusi yang Aman dan Kuat

Berbicara tentang Industrial Internet of Things – (IIoT). Teknologi operasional di industri internet of things (IoT) tidak dapat mentolerir patch gaya TI. Menggunakan "Analisis Ancaman" adalah Solusi yang Aman dan Kuat. Di dalam perusahaan dan di seluruh dunia, ekosistem IIoT – adalah penggabungan TI dan OT yang terjalin secara rumit dan dinegosiasikan. Sistem PL tidak hanya kritis terhadap bisnis, tetapi juga kritis terhadap bangsa, atau kritis terhadap hidup dan mati.

Setiap pelanggan industrial internet of things (IIoT) yang saya ajak bicara menginginkan keamanan yang sekuat mungkin. Bukan internet hal – internet industri (IIoT).

Siapa di dalam organisasi pelanggan yang akan menjalankan dan memiliki proses ini? Dalam pertemuan demi pertemuan dengan pelanggan yang membangun kemampuan IIoT, saya menghadapi ketidakpastian yang wajar namun terkadang menegangkan antara profesional TI dan OT/LOB dalam hal keamanan IIoT.

Ketidakpastian modal ini – itu sendiri – kerentanan keamanan karena menunda penerapan keamanan yang penting.

Survei Forrester baru-baru ini terhadap para pemimpin TI dan OT/LOB menunjukkan bahwa manajer TI dan OT terbagi rata dalam hal apakah TI atau OT bertanggung jawab atas keamanan, menurut DARKReading dari InformationWeek. Sebagai akibat yang mengkhawatirkan dari kebuntuan ini, Forrester melaporkan, sejumlah besar perusahaan – 59 persen – bersedia “menoleransi risiko menengah hingga tinggi terkait dengan keamanan IoT”.

Saya yakin ini tidak benar dan salah bagi perusahaan untuk membiarkan pengabaian ini berlanjut — serta berbahaya bagi seluruh operasi mereka.

Pertimbangkan perbedaan antara TI perusahaan dan OT:

• Ketersediaan :
  IT menganggap 99 persen uptime dapat diterima, sedangkan OT membutuhkan 99,999 persen up-time – perbedaan antara 8,76 jam dan 5,25 menit downtime tahunan.
  • System life :
  Sistem TI diperbarui, rata-rata, setiap tiga hingga lima tahun. Sistem PL, sebaliknya, bertahan selama 10 hingga 15 tahun.
  • Menambal :
  Penambalan/pembaruan TI dapat dilakukan kapan pun pembaruan tersedia, tetapi penambalan/pembaruan OT berisiko mengganggu operasi industri strategis yang menghasilkan pendapatan.

Ada banyak perbedaan TI/PL lainnya – seperti berbagai pendekatan ke cloud.

Namun, semua perbedaan dicakup oleh kebutuhan universal akan keamanan IIoT paling tangguh yang tersedia.

Pendekatan yang saya sukai adalah membantu perusahaan industri menggunakan pelajaran TI yang diperoleh dengan susah payah dan perjuangan panjang untuk melompat ke tingkat keamanan IIoT yang lebih maju. IIoT dirancang dan digunakan secara ahli untuk memenuhi persyaratan OT yang berbeda. Beberapa orang percaya bahwa sistem OT adalah bentuk lain dari pusat data, inti TI perusahaan yang sangat dilindungi.

Ada beberapa ide menjanjikan yang dapat diadaptasi dari pengalaman TI selama puluhan tahun. Menggunakan ide-ide ini dan kemudian menambahkannya untuk memberikan tingkat keamanan IIoT baru, sambil menghormati kebutuhan spesifik OT. Di antara adaptasi ini adalah pemisahan jaringan titik akhir, segmentasi mikro, dan analisis perilaku pengguna (UBA). Saya akan membahasnya di bagian mendatang.

Dengan penambalan , IT dan PL berbicara dalam bahasa yang berbeda. Masukkan “analisis ancaman”.

Kami memahami proses patching bertujuan untuk memperbarui, memperbaiki, atau meningkatkan program perangkat lunak. Biasanya perbaikan cepat – dan seringkali serampangan, pada saat itu. Dalam hal patching, bagaimanapun, port langsung dari praktik TI sehari-hari ke PL tidak selalu layak.

Dalam hal menambal, IT dan PL berbicara dalam bahasa yang berbeda.

Sangat penting bahwa industri IIoT – TI dan OT bersatu untuk kepentingan perusahaan mereka. Ini akan membutuhkan pemikiran yang lebih dalam dan dengan imajinasi yang lebih besar untuk mengembangkan teknik keamanan siber yang kuat. Karena kebutuhan, operasi ini harus lebih gesit dan efektif daripada patching refleksif.

Tambalan dapat membuat masalah untuk OT. Seperti yang kita lihat dengan tambalan untuk kerentanan CPU Meltdown dan Spectre, terkadang tambalan dapat memperburuk keadaan. Patch awal untuk Meltdown dan Spectre memengaruhi kinerja seluruh sistem.

Kebenaran yang sulit adalah bahwa perut lunak ekonomi industri modern sebagian besar adalah mesin PL tua. Dalam dunia IT, jika ada yang terinfeksi, insting pertama adalah mematikannya dengan cepat, dan menambalnya (atau menggantinya). Namun dalam PL, seringkali yang terjadi adalah kebalikannya:tetap berjalan dan berjalan.

Beberapa sistem PL penting telah berada di lantai pabrik selama 15 hingga 25 tahun atau lebih. Bayi-bayi ini tidak dapat dengan mudah diturunkan dan ditambal. Meskipun patch yang sesuai tersedia — sistem tersebut umumnya tidak memiliki cukup memori atau bandwidth CPU untuk menerima patch.

Terakhir, ada masalah kompleksitas dan kerapuhan relatif sistem OT dibandingkan dengan sistem TI.

Sistem TI dapat diturunkan, ditambal, dan dimulai kembali untuk memberikan layanan yang identik. TI dapat menjalankan rak yang dimuat dengan server yang identik, dan jika salah satu mati atau terbakar, yang berikutnya dalam antrean mengambil alih tanpa hambatan. Tetapi sistem PL sering kali merupakan kombinasi perangkat lunak dan perangkat keras yang sangat diatur yang memiliki "kepribadian".

Bahkan ketika perusahaan dapat menurunkan mesin untuk ditambal – ketika mesin tersebut kembali dipasang – hasilnya tidak dapat diprediksi. Ini bukan sistem yang sama karena patch telah memperkenalkan wild card yang dapat berkembang biak melalui elemen sistem lainnya.

Dalam PL, ketidakpastian tidak dapat diterima.

Intinya: pasti ada cara yang lebih baik untuk melindungi sistem IIoT daripada menambal secara refleks ATAU mengabaikan ancaman keamanan karena penambalan saja tidak layak – untuk semua alasan yang baru saja saya uraikan.

CARA YANG LEBIH BAIK:“ANALISIS ANCAMAN”

Pendekatan yang lebih baik dalam PL adalah memeriksa tantangan keamanan dengan cara yang jauh lebih terperinci daripada saat ini. Saya mengusulkan agar kami menggunakan pendekatan analisis ancaman kuno untuk menambal.

Langkah pertama dalam analisis ancaman:

Menunda mengambil tindakan segera. Itu berarti menunda penambalan, bukan penambalan, apa pun. Tunggu sebentar hingga kami memvalidasi apakah kerentanan sistem benar-benar ada – dan jika memang ada – bagaimana cara mengeksploitasinya?

Ada beberapa faktor yang perlu dipertimbangkan.

Beberapa sistem yang beroperasi jauh di dalam perusahaan mungkin memang memiliki kerentanan. Karena sistem sangat terisolasi di dalam perusahaan, risiko keamanan sebenarnya kurang daripada risiko mematikan sistem untuk patch – dengan asumsi patch bahkan ada.

Perubahan kalkulus saat mengevaluasi sistem yang terpapar ke Cloud atau Internet – adalah risiko keamanan yang jelas jauh lebih besar.

Analisis ancaman:

Analisis ancaman: kemudian akan dengan cepat mengidentifikasi sistem mana yang mungkin dapat terus beroperasi tanpa patch, dan sistem mana yang perlu dihentikan untuk patch.

Analisis ancaman: juga akan memvalidasi kerentanan. Penting untuk mengajukan pertanyaan lain:jika kerentanan ini dapat dieksploitasi oleh ancaman tertentu, apakah ada cara untuk menghentikan penambalan singkat ini ?

Misalnya, pakar keamanan dapat membuat serangkaian skrip yang telah ditentukan sebelumnya di dalam jaringan, atau di perangkat titik akhir itu sendiri. Itu akan membantu mengidentifikasi respons yang tepat terhadap sejumlah ancaman yang berbeda. Skrip ini akan berfungsi sebagai template “jika/maka” untuk memformalkan, mengotomatisasi, dan mempercepat respons terhadap ancaman. Intinya adalah berpikir dengan lebih canggih daripada keputusan tambalan biner/jangan tambal.

Perusahaan perangkat lunak harus mendukung pengembangan analisis ancaman dengan memberi tahu pelanggan lebih banyak tentang patch yang mereka rilis. Informasi penting yang ingin kami lihat adalah bagaimana kerentanan dapat dieksploitasi dan kemungkinan cara untuk melindunginya.

Transparansi ekstra ini akan memberi pelanggan lebih banyak informasi untuk membuat keputusan tentang langkah keamanan yang tepat untuk sistem yang terpengaruh. Pakar keamanan harus yakin bahwa patch setidaknya akan mempertahankan tingkat risiko yang sama seperti sebelum kerentanan ditemukan.

Analisis ancaman: harus sangat terperinci. Jika suatu perusahaan menjalankan 100 perangkat, masing-masing perangkat memerlukan analisis ancamannya sendiri, yang akan mencakup perbandingan kerentanan vs. manfaat patch, serta "menu" opsi keamanan yang dihasilkan.

Tujuan utamanya, tentu saja, adalah untuk meningkatkan keamanan sekaligus memaksimalkan waktu aktif OT.

Analisis ancaman: lebih bernuansa dan multi-dimensi daripada keputusan patching go/no-go.

Namun ada tantangan yang harus dipecahkan oleh industri untuk mencapai dari tempat kita berada sekarang ke tempat yang seharusnya:saat ini, mengikuti proses yang dijelaskan di atas membutuhkan waktu, biaya uang, membutuhkan profesional yang sangat terampil – dan bahkan kemudian, itu tidak mudah dilakukan.

Komunitas vendor harus mulai bertindak berdasarkan seperangkat standar yang disepakati. Kami membutuhkan standar, dan mungkin undang-undang tentang bagaimana laporan dan mengatasi kerentanan akan ditangani. Artinya – tidak ditutup-tutupi. Seluruh proses ini dapat diotomatisasi.

Apa yang berhasil dengan baik di TI tidak cocok dengan PL.

Sudah waktunya untuk inovasi industri di luar pilihan antara patch, patch, patch – atau membiarkan sistem yang tidak di-patch menjadi rentan.

Tujuan kami harus membangun proses yang kuat dan efektif, lalu mengotomatisasi mereka untuk menempatkan pendekatan baru ini. Semua ini dapat dijangkau oleh perusahaan industri dan negara secara global.

Hanya karena kita bisa melihat masa depan yang lebih baik ini dengan jelas bukan berarti sudah dekat.

Tapi mari kita mulai sekarang, bersama-sama.