Fondasi: Tahun 1

1. Kredensial dan Pengelola Kata Sandi

Mengganti kata sandi bawaan pabrik di setiap PLC, HMI, modem, dan perangkat jaringan adalah kontrol paling dasar di Lapis Perangkat Bab 4, dan kasus Aliquippa di Bab 3 menunjukkan akibatnya bila langkah itu terlewat. Masalah berikutnya muncul sesudah kata sandi diganti: di mana kata sandi baru disimpan? Kertas di laci panel, berkas di komputer operator, dan grup pesan singkat adalah tempat yang biasa dipakai, dan semuanya lemah.

Pengelola kata sandi menyimpan kredensial unik untuk setiap sistem dalam brankas terenkripsi, mengatur siapa boleh melihat kredensial mana, dan mencatat kapan kredensial dibuka. Alat ini mengurangi masalah itu dengan dua syarat: brankasnya sendiri ikut masuk cadangan offline yang dibahas di bab ini, dan ada salinan darurat tersegel untuk kredensial OT kritis yang bisa dibuka ketika server brankas tidak terjangkau, misalnya saat terjadi serangan ransomware atau jaringan padam. Untuk tim kecil, mulailah dari brankas berbasis berkas terenkripsi tanpa server, misalnya KeePassXC, ditambah salinan darurat tersegel untuk kredensial OT kritis. Brankas berbasis server, misalnya Bitwarden yang dipasang di server sendiri, baru dipasang sesudah ada orang yang ditugasi merawatnya, karena server itu menjadi sistem paling berharga yang harus diamankan, ditambal, dicadangkan, dan dicatat di daftar aset. Kebijakannya lebih penting daripada alatnya. NIST SP 800-63B-4 (2025) menyatakan bahwa sistem tidak boleh mewajibkan penggantian kata sandi secara berkala, tetapi wajib memaksa penggantian bila ada bukti kata sandi sudah bocor (NIST, 2025). Kata sandi yang panjang, unik per sistem, dan diganti ketika ada tanda bocor atau ketika pemegangnya keluar dari organisasi lebih berguna daripada kata sandi pendek yang diganti tiap tiga bulan.

Akun bersama perlu diberi perhatian khusus. Peringatan penegakan hukum (enforcement alert) EPA Mei 2024 yang dibahas di Bab 2 menyoroti akun yang hanya dilindungi kata sandi tanpa verifikasi tambahan. Bentuk paling rapuhnya, menurut penulis, adalah satu login yang dipakai semua operator. Akun bersama membuat log tidak bisa menjawab siapa melakukan apa. Di HMI yang memang harus dipakai bergantian, kredensialnya tetap disimpan di brankas dan setiap penggunaannya dicatat.

2. VPN dengan MFA

Akses jarak jauh tidak bisa dihindari. Vendor perlu merawat sistem dari jauh, dan staf kadang perlu memeriksa instalasi di luar jam kerja. Bab 3 sudah menjelaskan prinsipnya: semua akses jarak jauh lewat satu pintu, yaitu VPN dengan verifikasi kedua (MFA), dan tidak ada perangkat lunak berbagi layar yang terpasang langsung di komputer operator. VPN sumber terbuka seperti OpenVPN, yang mendukung verifikasi kedua lewat plugin dan aplikasi autentikator di ponsel, sudah cukup untuk memulai. WireGuard lebih ringan, tetapi hanya mengenal kunci per perangkat, sehingga verifikasi kedua harus ditambahkan lewat lapisan lain, misalnya portal autentikasi di depannya. Apa pun pilihannya, buktikan verifikasi keduanya bekerja lewat log masuk sebelum vendor diberi akses. Tiga syarat lain ikut menentukan. Gateway VPN sendiri adalah perangkat tepi, jenis perangkat yang di Tabel 2.1 menjadi pintu masuk aktor negara, sehingga ia masuk daftar aset dan menjadi prioritas patch dengan acuan katalog Known Exploited Vulnerabilities (KEV) dari CISA. Sejak Bulan 0-3, sebelum IDMZ lengkap dibangun, sesi VPN harus berakhir di satu host perantara atau segmen terbatas, tidak langsung di jaringan OT. Di jaringan yang masih datar, ini dicapai dengan aturan akses di gateway VPN yang hanya mengizinkan satu host perantara pada port tertentu, atau jump host yang dipasang pada port atau VLAN tersendiri di belakang gateway itu; ini langkah sementara sampai firewall segmentasi terpasang di Bulan 3-6. Portal pengelolaan VPN tidak boleh terbuka ke internet.

Tidak semua MFA sama kuatnya. Lembar fakta CISA tentang MFA tahan-phishing (Oktober 2022) mencatat bahwa kode yang dikirim lewat SMS atau panggilan suara bisa dicuri melalui celah di jaringan telepon atau pengambilalihan kartu SIM, dan bahwa notifikasi persetujuan di ponsel bisa diserang dengan membanjiri pengguna dengan permintaan sampai ia menekan "setuju". Bentuk yang oleh CISA disebut paling kuat adalah autentikasi FIDO/WebAuthn dan autentikasi berbasis infrastruktur kunci publik (PKI). CISA juga mendesak administrator sistem dan sasaran bernilai tinggi lainnya untuk menerapkan atau merencanakan peralihan ke MFA tahan-phishing (CISA, 2022). Bagi utilitas kecil, langkah yang masuk akal adalah memulai dengan aplikasi autentikator untuk semua pengguna VPN, lalu memberikan kunci keamanan fisik kepada administrator dan akun vendor yang bisa menjangkau jaringan OT. Satu catatan sebelum membeli kunci: OpenVPN dan WireGuard pada umumnya tidak mendukung FIDO/WebAuthn secara bawaan, sehingga MFA tahan-phishing biasanya membutuhkan portal autentikasi atau penyedia identitas yang mendukung WebAuthn di depan VPN atau di jump host. Pastikan kompatibilitasnya dulu, dan masukkan komponen itu ke baris lisensi atau perangkat di Tabel 8.6. Untuk vendor, kunci itu perlu dicatat atas nama teknisi tertentu, bukan atas nama perusahaan, dan ditarik atau dinonaktifkan ketika teknisinya berganti atau kontraknya berakhir. Bila vendor sering mengganti teknisi atau bekerja dari kota lain sehingga kunci fisik sulit dikelola, aplikasi autentikator tetap jauh lebih baik daripada kata sandi saja, asal setiap teknisi punya akun sendiri.

Verifikasi kedua juga perlu dipasang di luar VPN. Surel kantor dan akun administrator layanan awan (cloud) yang dipakai utilitas, misalnya untuk surel, penyimpanan berkas, atau cadangan, bisa dibuka dari mana saja, sehingga satu kata sandi yang bocor sudah cukup untuk masuk. Akun administrator layanan awan diberi MFA lebih dulu, lalu surel semua pegawai. Kotak surel dipakai untuk mengatur ulang kata sandi layanan lain, dan dari sana surel tipuan bisa dikirim ke rekan kerja.

Akses vendor sebaiknya dibuka hanya ketika dibutuhkan, dengan akun terpisah per orang, dan ditutup lagi sesudah pekerjaan selesai. Sesi vendor dicatat. Kasus Oldsmar di Bab 2 menunjukkan mengapa catatan sesi jarak jauh itu bernilai: tanpa catatan, dua tahun kemudian tidak ada yang bisa memastikan apa yang terjadi.

3. Backup Offline dan Uji Pulih

Bab 2 dan Bab 6 sudah menunjukkan mengapa cadangan menentukan hasil sebuah serangan ransomware. Panduan #StopRansomware menganjurkan cadangan data penting yang offline dan terenkripsi, serta pengujian ketersediaan dan keutuhannya secara berkala dalam skenario pemulihan bencana. Alasannya, banyak varian ransomware sengaja mencari cadangan yang bisa dijangkau lalu menghapus atau mengenkripsinya (CISA dkk., #StopRansomware Guide). Panduan yang sama menganjurkan citra baku (golden image) sistem penting, yaitu salinan sistem operasi dan aplikasi yang sudah terkonfigurasi dan bisa dipasang ulang dengan cepat.

Teknologinya tidak harus mahal. Untuk utilitas kecil, cakram eksternal yang diisi secara terjadwal lalu dilepas dan disimpan di tempat lain sudah memenuhi syarat offline. Untuk utilitas yang lebih besar, sistem cadangan terkelola dengan salinan yang tidak bisa diubah memberi kenyamanan lebih. Yang menentukan adalah dua kebiasaan. Pertama, cadangan mencakup hal-hal yang sulit dibuat ulang di OT: program PLC, konfigurasi HMI dan SCADA, serta dokumentasi jaringan, seperti dianjurkan Bab 3. Kedua, pemulihan benar-benar diuji. Uji pulih pertama masuk jadwal Bulan 3-6 di Bab 8, lalu diulang sedikitnya setiap tiga bulan, dan hasilnya dicatat, termasuk berapa jam yang dibutuhkan. Uji pulih TI dilakukan ke server uji. Untuk program PLC, bedakan verifikasi cadangan dari uji pulih. Verifikasi cukup membuka berkas proyek di perangkat lunak rekayasa dan membandingkannya dengan program yang berjalan; uji pulih mengunduhnya ke PLC cadangan di gudang (Bab 3), bukan ke PLC produksi. Bila tidak ada PLC cadangan, pakai emulator atau simulator dari vendor bila tersedia, atau pinjam PLC sejenis dari vendor atau utilitas tetangga saat jendela pemeliharaan; bila tidak ada satu pun, catat uji pulih PLC sebagai risiko terbuka dan jangan mengujinya di PLC produksi. Membangun ulang server SCADA atau HMI, dari sistem operasi, lisensi, driver, sampai konfigurasi tag, memakan waktu paling lama; uji pulihnya dijalankan berkala ke mesin cadangan atau mesin virtual di jendela pemeliharaan, dan durasinya dicatat terpisah dari uji pulih TI. Angka itu yang akan dipakai pimpinan ketika menjawab pertanyaan pertama di Tabel 6.3. Sebelum uji pertama, tanyakan ke vendor apakah lisensi runtime SCADA atau HMI, termasuk yang terikat dongle (Bab 4), boleh dijalankan di mesin cadangan atau mesin virtual, dan masukkan hak lisensi siaga ke kontrak pemeliharaan.

4. Firewall Segmentasi IT/OT

Bab 3 sudah menguraikan Model Purdue dan zona perantara (IDMZ) di antara jaringan TI dan OT. Teknologinya adalah firewall yang ditempatkan di batas zona dan diatur dengan prinsip tolak-semua kecuali yang diizinkan. Untuk jaringan kecil, firewall sumber terbuka seperti pfSense atau OPNsense bisa menjadi titik awal. Untuk batas di dalam zona OT, misalnya antara server SCADA dan PLC, firewall industri yang memahami protokol OT seperti Modbus dan DNP3 memberi kendali lebih halus, misalnya hanya mengizinkan perintah tulis dari server SCADA atau komputer rekayasa yang ditentukan. Lalu lintas dari arah TI tetap berhenti di IDMZ, sesuai Tabel 3.4.

Kesalahan yang perlu dihindari adalah memasang firewall lalu membuka semua lalu lintas "sementara" supaya sistem tetap jalan, lalu tidak pernah menutupnya. Setiap aturan perlu dicatat bersama alasannya, pemiliknya, dan tanggal peninjauannya. Aturan yang tidak ada pemiliknya dihapus pada peninjauan berikutnya. Di peta jalan Bab 8, segmentasi dasar dikerjakan di Bulan 3-6, sedangkan IDMZ lengkap dengan replika historian dibangun di Tahun 2, sesudah tim terbiasa merawat aturan firewall.

5. Pengamanan Surel dan Latihan Phishing

Surel tipuan adalah salah satu pintu masuk utama yang dibahas di Bab 2, dan keamanan surel adalah satu dari lima kategori temuan EPA OIG di awal bab ini. Pengamanan surel punya dua sisi. Sisi pertama melindungi nama utilitas. Panduan #StopRansomware menganjurkan penerapan kebijakan DMARC, yang dibangun di atas SPF dan DKIM, untuk mengurangi peluang surel palsu yang mengatasnamakan domain yang sah. Panduan itu juga mencatat batasnya: DMARC melindungi domain Anda dari pemalsuan, tetapi tidak melindungi Anda dari surel masuk yang dipalsukan, kecuali domain pengirimnya juga menerapkan DMARC (CISA dkk., #StopRansomware Guide). Bagi utilitas air, sisi ini penting karena pelanggan menerima tagihan dan pemberitahuan dari domain utilitas. Penipu yang bisa mengirim "tagihan" atas nama utilitas akan merugikan pelanggan sekaligus merusak kepercayaan kepada utilitas. SPF dan DMARC berupa catatan di DNS, sedangkan DKIM memerlukan kunci dari penyedia surel. Urutannya bertahap: susun daftar semua pihak yang mengirim surel atas nama domain, termasuk vendor penagihan, pasang SPF dan DKIM untuk masing-masing, mulai DMARC dengan kebijakan pemantauan (p=none) dan baca laporannya beberapa minggu, baru naikkan ke karantina atau tolak. Kebijakan ketat yang dipasang langsung bisa membuat surel sah, seperti tagihan, ditolak penerimanya.

Sisi kedua melindungi staf dari surel yang masuk. Penyaring surel bawaan layanan surel perlu diaktifkan penuh, makro di berkas Office yang datang lewat surel dinonaktifkan seperti dianjurkan panduan yang sama, dan staf perlu dilatih mengenali tanda-tanda yang dibahas di Bab 2. Pelatihan lebih berguna bila berulang dan dekat dengan kenyataan. Simulasi phishing terkendali, yaitu surel tipuan buatan tim sendiri yang dikirim ke staf dengan sepengetahuan pimpinan, mengukur apakah pelatihan berhasil. Ukurannya perlu dipilih dengan cermat. Jumlah staf yang melaporkan surel mencurigakan lebih berguna daripada jumlah staf yang tertipu. Hitungan pelapor mendorong kebiasaan yang diinginkan, sedangkan hitungan korban mudah berubah menjadi alat mempermalukan.

Disclaimer: Tulisan ini adalah pandangan pribadi penulis dan tidak mewakili pandangan organisasi mana pun. Isi bab ini disajikan untuk tujuan edukasi, bukan nasihat keamanan siber, hukum, atau teknis resmi, dan bukan rekomendasi produk atau vendor tertentu. Penerapan pada sistem yang sedang beroperasi tetap memerlukan verifikasi dan penyesuaian oleh pihak yang berwenang di organisasi masing-masing.