Beberapa waktu lalu saya terlibat dalam engagement OT security di salah satu fasilitas manufaktur. Tim internal mereka baru saja menyelesaikan pentest menggunakan pendekatan standar IT: Nmap aggressive scan untuk inventarisasi aset, Nessus untuk vulnerability scanning, lalu Metasploit untuk validasi temuan. Hasilnya: tiga PLC di lini produksi masuk ke fault state dan harus di-reset secara manual oleh engineer di lantai pabrik. Produksi berhenti empat jam.
Bukan karena ada eksploitasi berhasil. Hanya karena scanner mengirimkan probe TCP yang tidak diharapkan.
Pengalaman itu menggambarkan masalah mendasar yang masih sering saya temui: banyak tim keamanan menganggap OT (Operational Technology) hanya sebagai varian IT dengan hardware yang berbeda. Asumsi itu berbahaya.
Mengapa OT berbeda
Di dunia IT, kita terbiasa dengan prioritas CIA: Confidentiality, Integrity, Availability. Di OT, urutannya terbalik: Safety dulu, lalu Availability, baru Integrity dan Confidentiality. Downtime di server email adalah insiden. Downtime di sistem kontrol pabrik bisa berarti kerusakan peralatan, tumpahan bahan kimia, atau cedera pekerja.
Protokol yang menjalankan OT dirancang jauh sebelum keamanan jaringan menjadi prioritas. Modbus dikembangkan Modicon pada 1979 untuk jaringan serial yang terisolasi. Tidak ada autentikasi, tidak ada enkripsi, tidak ada session management. Setiap perangkat di jaringan yang sama bisa mengirimkan perintah.
DNP3 memiliki opsi autentikasi dasar di versi Secure Authentication-nya, tapi mayoritas implementasi yang saya temui di lapangan tidak mengaktifkannya. OPC-UA sebagai protokol yang lebih baru memiliki enkripsi dan sertifikat bawaan, tapi di banyak fasilitas masih ada OPC-Classic yang berjalan tanpa security apa pun.
Usia perangkat memperburuk semuanya. Siklus hidup perangkat OT adalah 15 sampai 25 tahun. PLC yang dipasang 2005 mungkin memiliki engineering workstation yang masih menjalankan Windows XP, dengan firmware yang belum diperbarui sejak instalasi awal. Patch di OT bukan keputusan IT, melainkan proses yang memerlukan kualifikasi vendor dan maintenance window yang direncanakan jauh-jauh hari.
Apa yang terjadi ketika tool IT standar masuk ke OT
Nmap dengan opsi aggressive scan, Nessus vulnerability scanner, Metasploit: semua ini mengirimkan active network probe dalam jumlah besar. Di jaringan IT, perangkat yang menerima probe ini merespons atau mengabaikannya. Di OT, banyak PLC tidak dirancang untuk menangani koneksi TCP yang tidak terduga dengan baik.
Seorang PLC Modbus yang menerima koneksi TCP di luar pola komunikasi normalnya bisa halt atau masuk fault state. Reset-nya memerlukan engineer yang hadir secara fisik di lokasi. Ini bukan skenario hipotetis. Kurikulum SANS ICS secara eksplisit mencantumkan aggressive scanning sebagai bahaya yang diketahui di lingkungan ICS.
Masalah lain yang sering diabaikan: waktu. Sistem OT real-time berkomunikasi dalam milidetik. Ketika scanner menghabiskan bandwidth atau memperkenalkan latency yang tidak terduga ke segmen jaringan yang sama dengan PLC, kontroler bisa kehilangan sinkronisasi dengan sensor atau aktuator.
Celah arsitektur yang paling sering saya temui
Model referensi Purdue (ISA-95) mendefinisikan hierarki Level 0 sampai 4. Di antara Level 3 dan Level 4 seharusnya ada DMZ, Level 3.5 dalam terminologi Purdue. DMZ ini berfungsi sebagai zona penyangga: data bisa mengalir dari OT ke IT melalui mekanisme yang terkontrol, tapi akses langsung tidak ada.
Dari sebagian besar fasilitas industri Indonesia yang pernah saya asesmen, mayoritas tidak memiliki DMZ ini. Historian OT terhubung langsung ke jaringan korporat. Kadang engineer di kantor pusat Jakarta bisa mengakses sistem SCADA pabrik di Jawa Tengah tanpa melewati satu pun kontrol jaringan yang berarti.
Remote access adalah vektor serangan OT yang paling sering saya temui di lapangan. Vendor memasang modem seluler di PLC untuk keperluan maintenance remote. Tim keamanan tidak mengetahuinya karena pengadaannya dilakukan oleh tim operasional atau engineering, bukan IT. Modem itu tetap aktif setelah commissioning selesai, kadang selama bertahun-tahun, tanpa monitoring dan tanpa kontrol akses yang layak.
Referensi insiden yang perlu dipahami
Dua serangan yang paling sering saya jadikan referensi dalam diskusi dengan klien OT adalah Stuxnet dan Triton.
Stuxnet (2010) menargetkan PLC Siemens S7 di fasilitas pengayaan uranium Iran. Ia menggunakan empat zero-day vulnerability untuk mengubah pemrograman PLC sementara melaporkan kondisi normal kepada operator. Centrifuge berputar di luar parameter aman sementara HMI menunjukkan semuanya berjalan baik. Analisis teknis terlengkap dipublikasikan oleh Langner Communications, tim yang pertama kali mendekonstruksi cara kerja Stuxnet.
Triton/TRISIS (2017) menargetkan Safety Instrumented System (SIS) Schneider Electric Triconex di fasilitas petrokimia Timur Tengah. SIS adalah lapisan terakhir yang mencegah kegagalan proses berbahaya. Triton dirancang untuk menonaktifkan lapisan keselamatan ini. Pabrik akhirnya shutdown ketika malware secara tidak sengaja memicu fail-safe. Ini adalah pertama kalinya malware secara khusus menyerang sistem keselamatan industri.
Implikasi untuk asesmen OT: sistem SIS harus dievaluasi secara terpisah dari sistem kontrol reguler.
Temuan paling umum dalam asesmen OT
Survei tahunan dari Claroty dan Dragos secara konsisten menemukan bahwa lebih dari 80% perangkat OT tidak pernah melalui security review. Angka itu konsisten dengan apa yang saya temui di engagement. Bukan karena tidak ada kepedulian, tapi karena asumsi lama bahwa air-gap memberikan perlindungan yang cukup, sementara kenyataannya air-gap itu sudah tidak ada.
Yang perlu dipikirkan sebelum memulai OT assessment
Jika organisasi Anda sedang mempertimbangkan asesmen keamanan OT, beberapa pertanyaan yang perlu dijawab terlebih dahulu: apakah tim assessor memiliki pengalaman spesifik OT, bukan hanya IT? Apakah mereka memahami protokol Modbus, DNP3, dan IEC 61850? Apakah metode yang mereka usulkan mencakup passive monitoring, bukan hanya active scanning?
Panduan teknis yang bisa dijadikan acuan: NIST SP 800-82 Rev. 3 untuk keamanan sistem kontrol industri, dan seri IEC 62443 untuk konteks kepatuhan industri. Jika beroperasi di Indonesia, Perpres 82/2022 mengatur persyaratan keamanan infrastruktur informasi kritis nasional yang berlaku untuk sebelas sektor termasuk energi, manufaktur, dan transportasi.
Juga penting: libatkan tim operasional dari awal. Keputusan tentang apa yang boleh diuji dan kapan harus melibatkan engineer yang bertanggung jawab atas proses, bukan hanya tim IT atau CISO. Merekalah yang tahu konsekuensi nyata jika sesuatu terganggu.
OT security bukan bagian dari IT security. Pendekatannya berbeda, toolnya berbeda, dan risikonya ketika melakukan kesalahan jauh lebih nyata.