OT VAPT vs IT VAPT: mengapa lingkungan industri butuh metodologi berbeda

Ketika tim keamanan IT pertama kali diminta menguji jaringan OT, reaksi pertamanya sering kali adalah membuka Nessus dan menjalankan pemindaian seperti biasa. Hasilnya bisa berupa PLC yang berhenti, RTU yang tidak merespons, atau SCADA server yang masuk ke kondisi error, semuanya karena probe jaringan standar yang di lingkungan IT tidak menimbulkan masalah apa pun. OT VAPT bukan sekadar IT VAPT yang dijalankan di jaringan yang berbeda. Metodologinya berbeda dari dasarnya, dan alasannya perlu dipahami sebelum Anda memutuskan mana yang dibutuhkan.

Mengapa perkakas IT VAPT berbahaya di OT

Perkakas pengujian penetrasi standar, seperti Nessus, Metasploit, atau bahkan pemindai port sederhana, dirancang dengan asumsi bahwa target adalah sistem IT: server web, workstation, atau perangkat jaringan yang bisa merespons probe tanpa efek samping. Perangkat OT tidak bekerja dengan cara itu.

PLC (Programmable Logic Controller) yang mengendalikan katup atau conveyor tidak dirancang untuk menangani lalu lintas jaringan yang tiba-tiba tidak biasa. RTU (Remote Terminal Unit) yang mengumpulkan data dari lapangan bisa hang ketika menerima paket yang tidak dikenalnya. DCS (Distributed Control Systems) dan server SCADA bisa masuk ke kondisi error yang membutuhkan intervensi manual untuk dipulihkan.

Dalam lingkungan IT, efek seperti itu bisa diterima dalam konteks pengujian karena sistem bisa di-restart dan layanannya tidak bersifat real-time. Di OT, shutdown yang tidak terduga pada sebuah PLC bisa menghentikan lini produksi, memicu alarm keselamatan, atau dalam kasus terburuk menyebabkan kondisi berbahaya yang memerlukan respons fisik di lapangan.

Bagaimana metodologi OT VAPT bekerja

OT VAPT dimulai dengan passive network discovery. Tim memasang sensor atau network tap untuk menganalisis lalu lintas yang sudah mengalir di jaringan, tanpa mengirimkan satu pun probe ke perangkat. Dari sana, analis memetakan topologi jaringan, mengidentifikasi semua perangkat yang terhubung termasuk yang mungkin tidak terdokumentasi, dan mengamati protokol yang digunakan seperti Modbus, DNP3, OPC-UA, Profinet, atau EtherNet/IP.

Setelah peta jaringan terbentuk, pekerjaan berlanjut ke analisis konfigurasi dan arsitektur. Ini mencakup tinjauan terhadap Purdue Model yang diterapkan di lingkungan tersebut, apakah Level 0 hingga Level 4 tersegmentasi dengan benar, apakah ada zona DMZ di Level 3.5 yang memisahkan jaringan OT dari IT korporat, dan apakah ada koneksi langsung yang tidak seharusnya ada.

Pengujian aktif terbatas, dan hanya dilakukan dalam jendela pemeliharaan yang sudah direncanakan bersama tim operasi. Ini bisa berarti menguji perangkat yang sudah dimatikan untuk keperluan perawatan rutin, atau menjalankan skenario terbatas pada perangkat duplikat jika tersedia. Tidak ada exploit yang dikirim ke perangkat produksi yang sedang berjalan.

Area temuan yang paling sering ditemukan

Segmentasi jaringan IT/OT adalah area paling kritis. Jaringan datar yang menghubungkan IT korporat langsung ke jaringan OT tanpa firewall atau DMZ adalah temuan yang masih sangat umum, dan risikonya nyata: satu email phishing yang berhasil di sisi IT bisa memberi penyerang jalur langsung ke SCADA.

Akses remote vendor adalah kategori kedua yang sering mengejutkan klien. Modem seluler atau tunnel VPN yang dipasang oleh vendor peralatan untuk keperluan dukungan sering kali tidak tercatat dalam dokumentasi jaringan dan tidak dimonitor oleh tim operasi. Jalur ini adalah titik masuk yang nyata.

Protokol tanpa autentikasi juga menjadi temuan standar. Modbus dan DNP3, misalnya, tidak memiliki autentikasi bawaan. Perangkat yang berkomunikasi menggunakan protokol ini bisa diakses oleh siapa saja yang berada di segmen jaringan yang sama.

Perbedaannya secara ringkas

Mana yang Anda butuhkan

Apa yang dihasilkan OT VAPT

Laporan OT VAPT berbeda dari laporan IT VAPT dalam hal prioritas. Selain daftar temuan dan rekomendasi teknis, laporan ini mencakup peta segmentasi jaringan aktual versus yang seharusnya, inventaris perangkat termasuk yang tidak terdokumentasi, analisis jalur komunikasi antar level Purdue Model, dan rekomendasi kompensasi kontrol untuk perangkat yang tidak bisa di-patch.

Jika lingkungan Anda mencakup perangkat OT yang mengendalikan proses fisik, percakapan pertama yang perlu dilakukan adalah tentang metodologi, bukan cakupan.