Menakar Risiko: Seberapa Sering dan Seberapa Berat

Setiap utilitas perlu menyusun prioritasnya sendiri, karena sistem, anggaran, dan kondisinya berbeda. Tabel 2.4 memberi titik awal yang disusun dari catatan insiden di bab ini. Kolom "seberapa sering" adalah penilaian penulis dari catatan publik dan tidak dihitung dari data. Dukungan datanya paling tipis pada baris ransomware di sisi TI. Kolom dampak dipisahkan antara layanan air dan data, sesuai dua jenis kerugian di Bab 1.

Tabel 2.4 Peta risiko awal dari catatan insiden, tanpa skor angka. Kolom terakhir memuat kontrol pertama untuk tiap skenario, umumnya murah dan saling menguatkan.

Skenario Seberapa sering Dampak ke layanan air Dampak ke data dan hukum Kontrol pertama
Ransomware di sisi TI Tinggi (penilaian penulis) Tidak langsung: penagihan dan layanan pelanggan terhenti Berat: data terenkripsi atau dicuri; bila data pribadi terdampak, pemberitahuan 3x24 jam menurut UU PDP Pasal 46 ayat (1) (Bab 5) Cadangan terpisah yang diuji pulih
PLC atau HMI terbuka ke internet dibobol Berulang, dalam gelombang Langsung: tampilan dan kendali hilang, operasi manual Ringan untuk data pribadi. Kewajiban lapor gangguan serius (PP 71/2019 Pasal 24 ayat (3)) bergantung pada apakah sistem kendali tercakup, soal yang masih terbuka (Bab 5) Cabut dari internet, ganti kata sandi bawaan
Akses jarak jauh dibajak Berulang Bisa langsung, bila aksesnya ke komputer operator Sedang VPN dengan MFA, log sesi
Ransomware sampai ke SCADA Kadang Langsung, tetapi bisa diredam dengan operasi manual Sedang Pemisahan IT/OT, latihan manual
Orang dalam atau mantan pegawai Jarang tercatat Bisa berat Bisa berat Cabut akses saat keluar, akun pribadi
Pihak ketiga atau vendor Jarang, tetapi luas Tergantung akses vendor Tergantung data yang dipegang vendor Akses vendor terkendali, kontrak

Tabel ini sengaja tidak memberi skor angka. Skor seperti "kemungkinan 4 kali dampak 5" memberi kesan presisi yang tidak didukung data, dan sering membuat rapat sibuk memperdebatkan angka alih-alih memutuskan tindakan. Yang lebih berguna adalah kolom terakhir: kontrol pertama yang paling banyak mengurangi risiko untuk setiap skenario.

Urutan Mitigasi

Dari catatan insiden dan peta risiko di atas, urutan mitigasi yang masuk akal hampir terlihat dengan sendirinya. Bab 8 merincinya menjadi jadwal terpadu. Bagian ini cukup menjelaskan logikanya.

Tiga bulan pertama dipakai untuk menutup jalan masuk yang paling sering dipakai dan paling murah ditutup: memeriksa dan mencabut perangkat OT yang terpapar internet, termasuk modem seluler (Ilustrasi 2.2), mengganti kata sandi bawaan di PLC dan HMI, mematikan atau mengamankan akses jarak jauh dengan VPN dan MFA, mulai membuat cadangan yang terpisah dari jaringan untuk sistem terpenting, dan memberi pengarahan singkat kepada seluruh staf tentang cara mengenali surel tipuan dan ke mana melapor. Di bulan-bulan berikutnya, cadangan itu diuji pulih untuk pertama kalinya, lalu diulang secara berkala. Pemisahan dasar jaringan TI dan OT menyusul, disertai tim tanggap insiden dan kebijakan tertulis. Menjelang akhir tahun pertama, pengarahan singkat berkembang menjadi program pelatihan berkala, log mulai dikumpulkan, dan daftar kerentanan disusun: di sisi TI lewat pemindaian, di sisi OT dari inventaris aset dan versi firmware, karena pemindaian aktif bisa membuat PLC atau HMI lawas macet.

Langkah yang lebih mahal menunggu fondasinya siap. Uji penetrasi oleh profesional yang berpengalaman di lingkungan OT baru bernilai sesudah kontrol dasar berjalan, dan Bab 8 menjadwalkannya di tahun ketiga, bisa dimajukan ke akhir tahun kedua. Audit eksternal juga termasuk langkah lanjutan di tahun ketiga.

Asuransi siber layak dipertimbangkan sebagai pengalih sebagian risiko keuangan, tetapi cakupan polis asuransi siber berbeda-beda antarpenanggung, sehingga polisnya perlu dibaca bersama bagian hukum, terutama pengecualiannya: apakah insiden pada sistem operasional ditanggung, bagaimana dengan serangan yang dikaitkan dengan aktor negara, dan apa syarat pelaporannya. Penanggung lazimnya menanyakan kontrol dasar seperti MFA dan cadangan sebelum menerbitkan polis, jadi asuransi tidak bisa menggantikan kontrol itu. Asuransi juga hanya membayar sebagian kerugian keuangan dan tidak memulihkan layanan air atau kepercayaan pelanggan. Buku ini tidak menilai apakah polis semacam itu tersedia bagi utilitas air di Indonesia atau berapa preminya; itu perlu ditanyakan langsung kepada pialang atau penanggung. Bila polis yang cocok tidak ada atau tidak terjangkau, cadangan yang terbukti bisa dipulihkan (Bab 7) tetap menjadi pengaman keuangan yang paling bisa diandalkan, karena cadangan seperti itu memperpendek waktu henti.

Modem seluler abu-abu dengan dua antena, semua lampunya padam. Kabel dayanya terlepas dan kepala steker tergeletak di samping. Selotip di badan modem bertulisan spidol merah: terpapar internet. Di kaki gambar tertulis soal menutup jalan masuk yang paling murah ditutup.

Ilustrasi 2.2 Cabut dulu yang paling mudah dicabut. Kabel daya modem seluler yang terlepas adalah contohnya.

Ringkasan Bab

Kronologi PDNS 2024 menunjukkan bahwa pengaman dapat dilumpuhkan sebelum aktivitas berbahaya merusak sistem. Empat kelompok pelaku mengincar utilitas air dengan tujuan berbeda. Pada insiden yang jalur masuknya tercatat, beberapa pintu masuk mencakup kredensial yang tidak dicabut, akses jarak jauh, perangkat yang terbuka ke internet, dan kata sandi bawaan. Soal pemulihan, advisori AA21-287A mencatat bahwa sistem SCADA dan sistem cadangan korban ikut terkena ransomware. Data Indonesia tentang insiden di sektor air belum tersedia, sehingga utilitas perlu memeriksa sendiri, di antara pintu masuk yang terbukti dipakai di tempat lain, mana yang masih terbuka, lalu menutupnya mulai dari yang paling murah.

Langkah Pertama Minggu Ini

Untuk Pengambil Keputusan

  1. Tanyakan kapan terakhir kali data dipulihkan dari cadangan. Bila jawabannya "belum pernah", jadwalkan uji pulih pertama.
  2. Tetapkan jalur laporan insiden. Tentukan siapa yang dihubungi operator atau staf TI bila melihat tanda-tanda di Tabel 2.3, termasuk di luar jam kerja.

Untuk Manajer TI

  1. Pastikan penonaktifan perangkat lunak keamanan memicu peringatan yang dilihat seseorang. Peringatan yang berhenti di catatan log tidak membuat siapa pun bertindak.
  2. Periksa akun orang yang sudah keluar, termasuk akun VPN, surel, dan akun di sistem vendor, lalu cabut yang masih aktif.
  3. Pastikan log akses jarak jauh disimpan cukup lama untuk bisa ditelusuri kembali, di tempat yang tidak bisa dihapus oleh akun yang sama.

Untuk Teknisi dan Operator

  1. Kenali tanda-tanda di sisi proses. Waspadai setpoint yang berubah sendiri, HMI yang kehilangan data, atau program PLC yang berbeda dari salinannya. Laporkan juga sebagai kemungkinan insiden keamanan, selain sebagai gangguan teknis.
  2. Jangan colokkan flashdisk yang tidak jelas asal-usulnya ke komputer di ruang kendali, termasuk flashdisk dari vendor yang tidak diperiksa lebih dulu.

Pertanyaan untuk Direnungkan

  1. Bila perangkat lunak keamanan di server Anda dimatikan malam ini, kapan dan oleh siapa hal itu akan diketahui?
  2. Dari enam jalan masuk di Diagram 2.1, mana yang paling terbuka di utilitas Anda, dan mana yang paling mudah ditutup?
  3. Bila utilitas Anda mengalami kejadian seperti Oldsmar, apakah ada log yang bisa memastikan apa yang terjadi?
  4. Pihak ketiga mana saja yang punya akses ke sistem Anda hari ini, dan apakah konfigurasi serta kata sandi mereka sama untuk semua pelanggannya?

Jembatan ke Tetralogi Ketahanan Air

Oldsmar juga diceritakan di Amanah yang Bocor, Bab 12 "Sistem Kendali Digital dan SCADA", subbab 12.4.1 "Anatomi Oldsmar: Tiga Pintu yang Tidak Dikunci", dan kedua buku sampai pada pembacaan yang sama. Subbab itu mencatat bahwa atribusi serangannya runtuh, lalu memusatkan pelajaran pada tiga kelemahan yang dipotret laporan pasca-insiden: perangkat akses jarak jauh yang kata sandinya dipakai bersama, komputer kendali dengan sistem operasi yang sudah habis masa dukungannya, dan jalur dari internet ke komputer proses yang nyaris tanpa lapis pemisah.

Bab ini menyusun peta risiko dari banyak kejadian, sedangkan Amanah yang Bocor memakai satu kejadian untuk menunjukkan kepada pengelola kehilangan air bahwa penangkalnya terjangkau. Bagi pembaca yang harus meyakinkan pimpinan, subbab itu berguna sebagai bacaan pendamping. Isinya menunjukkan bahwa pelajaran Oldsmar tetap berlaku entah penyebabnya penyusup atau operator yang keliru menekan tombol, sebab sistem yang sehat menahan keduanya.

Bab ini menunjukkan dari mana serangan datang. Bab 3 membahas medan yang diserang, dan itu perlu dipahami sebelum membangun pertahanan.

Sebagian jalan masuk di Diagram 2.1 melewati sisi TI sebelum mencapai sisi OT, sedangkan jalan 2 dan 5 (akses jarak jauh dan vendor) sering langsung menembus komputer OT. Karena itu, cara memisahkan dan menyambungkan kedua sisi menentukan seberapa jauh penyusup bisa berjalan. Sistem kendali juga punya aturan yang berbeda dari sistem kantor: sistem kendali tidak bisa sembarangan di-restart, diperbarui, atau dipindai, dan perlakuan yang benar di kantor bisa membahayakan di ruang kendali. Selain itu, banyak kelemahan di bab ini lahir di perbatasan antara TI, OT, dan vendor, tempat tanggung jawab sering kabur.

Bab 3 menjelaskan lingkungan IT dan OT di utilitas air, Model Purdue untuk menata jaringannya, dan tantangan nyata yang dihadapi utilitas yang ingin memisahkannya.

Lanjutkan ke Bab 3: Memahami Lingkungan IT/OT Utilitas Air.

Rujukan Bab

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. Penerapan pada sistem yang sedang beroperasi tetap memerlukan verifikasi dan penyesuaian oleh pihak yang berwenang di organisasi masing-masing.