Bab 4: Manajemen Risiko TI

Track: Praktisi (P); untuk IT practitioner, auditor, dan pelaksana teknis.

Tiga Hal yang Wajib Dibawa Pulang

• Risiko TI yang tidak terdaftar bukan berarti tidak ada; ia hanya tidak terkelola. Risk register sederhana yang diperbarui rutin lebih berharga dari dokumen risiko setebal 100 halaman yang jarang dibuka.
• Setiap risiko harus punya satu pemilik, bukan hanya sebuah tim. Risiko yang dimiliki terlalu banyak pihak tanpa akuntabilitas tunggal biasanya bergerak lambat saat harus ditangani.
• Pemantauan bukan formalitas; ia instrumen navigasi. Organisasi yang hanya membuat risk register sekali setahun mengambil keputusan dengan informasi yang cepat usang.

Peta Konsep Bab Ini

Diagram 4.1 menunjukkan alur Bab 4: mulai dari insiden sistem pengolahan air, masuk ke identifikasi risiko, penilaian dan mitigasi, lalu berakhir pada daftar risiko TI yang hidup dan rencana 90 hari.

Insiden: Satu Kursor di Sistem Pengolahan Air

Pada 5 Februari 2021, menurut advisory keamanan siber bersama (joint cybersecurity advisory) FBI, CISA, EPA, dan MS-ISAC, aktor siber tidak dikenal memperoleh akses tidak sah ke sistem SCADA di sebuah instalasi pengolahan air minum di Amerika Serikat. Advisory itu menyebut pelaku menggunakan perangkat lunak SCADA untuk menaikkan kadar natrium hidroksida (sodium hydroxide), bahan kimia yang dipakai dalam proses pengolahan air. Operator melihat perubahan itu dan mengembalikan setelan ke angka normal sebelum berdampak ke publik.

Insiden ini sering diceritakan sebagai cerita keamanan siber. Tetapi untuk Direksi perusahaan utilitas air, pelajarannya lebih luas: risiko TI bukan lagi risiko komputer. Risiko TI bisa menyentuh kualitas produk, keselamatan publik, kepatuhan, reputasi, dan legitimasi organisasi. Satu akses jarak jauh yang tidak terkendali dapat berubah menjadi keputusan operasional palsu di sistem yang seharusnya hanya dikendalikan oleh operator resmi.

Kisah pembuka ini merujuk pada advisory publik yang diterbitkan otoritas keamanan Amerika Serikat. Perlu dicatat, laporan lanjutan pada 2023 menyebut FBI tidak dapat mengonfirmasi bahwa insiden Oldsmar tersebut merupakan intrusi siber yang ditargetkan. Justru di situlah pelajaran tata kelolanya: ketika sistem kritis berubah status, organisasi harus memiliki bukti, log, jalur eskalasi, dan pemilik keputusan yang jelas. Bab ini tidak memakai kasus tersebut untuk menakut-nakuti. Tujuannya lebih sederhana: menunjukkan bahwa manajemen risiko TI harus menghubungkan tiga dunia yang sering dipisahkan, yaitu teknologi informasi, teknologi operasional, dan keputusan pimpinan.

Kalau Anda jajaran Direksi yang membaca ini, pertanyaan utamanya bukan “apakah sistem kami pernah diserang?”. Pertanyaan yang lebih berguna: “Risiko seperti apa yang sudah kami tulis, siapa pemiliknya, batas toleransinya berapa, dan kapan terakhir kali mitigasinya diuji?”

Bab ini memberi peta kerja untuk mengenali jenis risiko TI yang relevan bagi perusahaan utilitas air, menilai prioritasnya, menetapkan risk appetite, menyusun daftar risiko TI (IT risk register), dan memulai program manajemen risiko dalam 90 hari tanpa menunggu organisasi sempurna.

4.1 Insiden SCADA: Analisis dan Pelajaran

Sebelum masuk ke kerangka kerja manajemen risiko, kasus pembuka perlu dibaca sebagai kegagalan lapisan kontrol, bukan sekadar kejadian teknis. Risiko tidak muncul mendadak pada hari insiden. Ia tumbuh pelan melalui akses yang terlalu longgar, pemantauan yang kurang, sistem yang usang, dan keputusan pimpinan yang belum pernah menetapkan ambang risiko secara eksplisit.

4.1.1 Kronologi Singkat Insiden

Kronologi yang relevan untuk pembelajaran manajemen risiko dapat diringkas sebagai berikut.

Pertama, advisory menyatakan pelaku memperoleh akses jarak jauh ke komputer yang terhubung dengan sistem SCADA. Advisory bersama FBI, CISA, EPA, dan MS-ISAC menyoroti eksploitasi perangkat lunak berbagi desktop serta penggunaan sistem operasi yang sudah end-of-life sebagai pola risiko yang perlu diperhatikan oleh organisasi sejenis.

Kedua, pelaku mencoba mengubah parameter proses pengolahan air. Perubahan ini terlihat oleh operator dan segera dikoreksi. Di sini tampak lapisan perlindungan manusia masih bekerja, tetapi organisasi tidak boleh menggantungkan keselamatan pada keberuntungan bahwa operator sedang melihat layar pada detik yang tepat.

Ketiga, otoritas keamanan menerbitkan rekomendasi: batasi penggunaan akses jarak jauh, aktifkan autentikasi multifaktor (multi-factor authentication, MFA), perbarui sistem operasi, kuatkan pemantauan, dan pastikan jaringan kritis tidak terbuka sembarangan. Semua rekomendasi itu sebenarnya bukan teknologi eksotis. Ia adalah disiplin dasar yang sering kalah oleh kebiasaan operasional.

4.1.2 Akar Risiko

Ada empat akar risiko yang perlu dibaca oleh perusahaan utilitas air.

Pertama, akses jarak jauh yang tidak dikendalikan. Akses jarak jauh memang membantu operasi, terutama ketika tim terbatas dan lokasi tersebar. Tetapi tanpa kontrol kuat, akses jarak jauh menjadi pintu yang terlalu lebar. Direksi perlu tahu sistem mana yang bisa diakses dari luar, siapa yang punya akses, bagaimana akses itu disetujui, dan bagaimana jejaknya diaudit.

Kedua, pemisahan TI dan OT yang lemah. Sistem TI seperti email, komputer kantor, dan aplikasi administrasi tidak boleh menjadi jalan langsung menuju sistem OT seperti SCADA, PLC, atau telemetry. Segmentasi bukan detail teknis kecil. Ia adalah pagar keselamatan.

Ketiga, sistem usang yang dianggap masih cukup. Banyak organisasi mempertahankan sistem lama karena “masih jalan”. Dalam manajemen risiko, frasa itu berbahaya. Sistem yang masih jalan tetapi tidak lagi mendapat pembaruan keamanan adalah aset yang secara operasional hidup, tetapi secara risiko membusuk.

Keempat, risiko yang tidak pernah dibahas di tingkat pimpinan. Tim teknis mungkin tahu banyak titik lemah. Tetapi jika titik lemah itu tidak masuk risk register, tidak punya owner, dan tidak pernah muncul di agenda Direksi atau steering committee, maka organisasi belum benar-benar mengelolanya.

4.1.3 Pelajaran untuk Direksi

Pelajaran pertama: risiko TI harus diterjemahkan ke dampak layanan. “Akses jarak jauh tanpa MFA” terdengar teknis. “Orang luar bisa mengubah parameter sistem pengolahan air” terdengar seperti risiko Direksi. Bahasa kedua yang harus dipakai dalam rapat pimpinan.

Pelajaran kedua: kontrol dasar harus diuji, bukan hanya ditulis. Segmentasi jaringan, backup, patch management, access control, dan prosedur incident response tidak cukup ada di dokumen. Semua harus diuji dengan skenario: siapa yang tahu, siapa yang memutuskan, berapa lama organisasi mendeteksi, dan bagaimana organisasi memulihkan layanan.

Pelajaran ketiga: risiko lintas TI dan OT tidak bisa dimiliki satu divisi saja. Kepala TI bisa memimpin kontrol teknis. Kepala Operasi memahami dampak proses. Direksi menetapkan batas risiko dan memastikan dua fungsi itu tidak bekerja sendiri-sendiri.

4.1.4 Dampak Finansial, Operasional, dan Reputasi

Insiden siber pada perusahaan utilitas air membawa tiga lapis dampak.

Dampak operasional muncul ketika sistem kritis tidak dapat dipercaya, operator harus beralih ke prosedur manual, dan pengambilan keputusan bergantung pada komunikasi darurat.

Dampak finansial muncul melalui biaya investigasi, pemulihan, lembur, pengadaan darurat, potensi klaim, dan investasi korektif yang biasanya jauh lebih mahal daripada pencegahan bertahap.

Dampak reputasi muncul ketika publik melihat organisasi tidak siap menjaga layanan dasar. Dalam sektor air, kepercayaan rusak bukan hanya karena layanan terhenti, tetapi karena masyarakat ragu apakah organisasi memahami risiko yang sedang dihadapi.

4.2 Identifikasi Risiko TI di Utilitas

Pola yang berulang di organisasi layanan air: risk register dibuat setahun sekali untuk memenuhi checklist audit, lalu jarang dibuka lagi sampai audit berikutnya. Risk register yang hidup adalah dokumen yang dibahas di rapat bulanan, yang pemiliknya dapat ditagih progresnya, dan yang skornya berubah seiring waktu. Jika risk register statis selama 12 bulan, organisasi belum benar-benar memiliki manajemen risiko aktif. Bagian ini membahas kategori risiko TI yang dihadapi perusahaan utilitas dan cara mengidentifikasinya.

4.2.1 Kategori Risiko TI

Risiko TI dapat dikategorikan menjadi beberapa jenis utama. Memahami kategori ini membantu organisasi mengidentifikasi risiko secara sistematis.

Risiko Operasional adalah risiko yang berkaitan dengan gangguan operasi bisnis karena kegagalan sistem atau proses TI. Contoh:

• System downtime karena hardware failure
• Software bug yang menyebabkan kesalahan perhitungan
• Human error dalam operasional sistem
• Vendor dependency jika vendor gagal menyampaikan layanan

Risiko Keamanan adalah risiko yang berkaitan dengan ancaman siber yang dapat mengganggu operasi, mencuri data, atau merusak aset. Contoh:

• Malware dan ransomware
• Phishing dan social engineering
• Unauthorized access ke sistem atau data
• Denial of service terhadap sistem kritis

Risiko Finansial adalah risiko yang berkaitan dengan kerugian finansial langsung atau tidak langsung dari insiden TI. Contoh:

• Kehilangan pendapatan karena downtime
• Biaya pemulihan insiden
• Revenue leakage karena kesalahan sistem
• Cost overrun proyek TI

Risiko Regulasi adalah risiko terkait ketidakpatuhan terhadap regulasi yang berlaku. Contoh:

• Sanksi dari regulator karena ketidakpatuhan
• Gugatan hukum dari pelanggan
• Kehilangan izin operasi
• Kewajiban perbaikan yang mahal

Risiko Reputasi adalah risiko kerusakan reputasi organisasi karena insiden TI. Contoh:

• Persepsi negatif dari pelanggan
• Liputan media negatif
• Kepercayaan pemegang saham menurun
• Kesulitan merekrut talenta terbaik

4.2.2 Risiko Khusus Utilitas

Perusahaan utilitas menghadapi beberapa risiko khusus yang jarang muncul di organisasi layanan biasa.

1. Konvergensi TI dan OT. Sistem Teknologi Operasional (operational technology, OT) seperti SCADA, PLC, dan telemetry awalnya dirancang untuk lingkungan yang terisolasi, tanpa mempertimbangkan ancaman siber modern. Ketika sistem ini terhubung ke jaringan TI untuk integrasi data, risikonya berubah: parameter proses dapat dimanipulasi, distribusi produk dapat terganggu, dan peralatan fisik dapat terkena dampak dari akses siber.

   Advisory tentang instalasi pengolahan air di Florida, Amerika Serikat (2021), menunjukkan bahwa perubahan parameter bahan kimia harus dibaca sebagai risiko layanan dan keselamatan, bukan sekadar risiko komputer.

2. Risiko keamanan fisik. Infrastruktur utilitas tersebar di banyak lokasi: fasilitas produksi, rumah pompa, reservoir, kantor layanan, dan titik telemetri. Setiap lokasi adalah potensi titik kerentanan, mulai dari pencurian peralatan, vandalisme, sampai akses tidak resmi ke control room.

3. Risiko terhadap keselamatan publik. Gangguan pada sistem utilitas dapat melampaui kerugian finansial. Kontaminasi produk, tekanan distribusi yang tidak aman, dan kegagalan sistem darurat adalah contoh risiko yang langsung menyentuh keselamatan masyarakat.

4. Risiko geografis. Infrastruktur utilitas tersebar di wilayah luas, sering kali di area yang sulit dijangkau. Kerusakan karena bencana alam, keterbatasan komunikasi, dan sulitnya maintenance di lokasi terpencil membuat risiko TI tidak bisa dilepaskan dari risiko lapangan.

4.2.3 Teknik Identifikasi Risiko

Beberapa teknik dapat digunakan untuk mengidentifikasi risiko TI secara sistematis:

1. Sesi curah pendapat (brainstorming session). Kumpulkan tim dari berbagai fungsi (TI, operasi, keuangan, hukum) untuk mendiskusikan risiko potensial. Keuntungan: memanfaatkan pengetahuan kolektif. Keterbatasan: dapat didominasi oleh suara yang paling keras.
2. Wawancara dengan pemangku kepentingan. Lakukan wawancara satu-satu dengan pemangku kepentingan kunci. Keuntungan: mendapatkan perspektif mendalam. Keterbatasan: memakan waktu.
3. Tinjauan insiden masa lalu. Pelajari insiden yang terjadi di organisasi atau organisasi serupa. Keuntungan: berdasarkan realita. Keterbatasan: mungkin tidak menangkap risiko baru.
4. Lokakarya asesmen risiko (risk assessment workshop). Selenggarakan lokakarya terstruktur dengan fasilitator untuk mengidentifikasi dan menilai risiko. Keuntungan: terstruktur dan kolaboratif. Keterbatasan: memerlukan persiapan yang baik.
5. Daftar periksa dan kerangka kerja. Gunakan daftar periksa dari framework seperti COBIT, NIST, atau ISO 27001. Keuntungan: komprehensif dan terstruktur. Keterbatasan: mungkin tidak sepenuhnya relevan dengan konteks organisasi.

4.2.4 Sumber Risiko TI

Untuk memandu identifikasi risiko, berikut daftar sumber risiko TI umum dalam perusahaan utilitas.

Sumber Teknis: kegagalan hardware (server, storage, jaringan), kegagalan software (bug, compatibility issues), kerentanan keamanan (unpatched systems), dan ketergantungan pada teknologi usang (legacy systems).

Sumber Manusia: kesalahan operasional (human error), insider threat, kurangnya kompetensi teknis, dan rendahnya security awareness.

Sumber Proses: prosedur yang tidak memadai, dokumentasi yang kurang, change management yang buruk, dan vendor management yang tidak efektif.

Sumber Eksternal: serangan siber (cyber attack) seperti ransomware, phishing, dan DDoS; bencana alam; kegagalan vendor atau mitra; dan perubahan regulasi.

4.2.5 Risiko Vendor Lock-in dan Ketergantungan Sistem Kritis

Dari daftar sumber risiko di atas, satu risiko yang sering terlambat naik ke meja Direksi adalah ketergantungan berlebihan pada vendor sistem kritis (vendor lock-in). Risikonya bukan bahwa vendor selalu buruk. Risikonya muncul ketika organisasi tidak memiliki kendali memadai atas data, dokumentasi teknis, hak integrasi, dan rencana keluar (exit plan).

Banyak aplikasi penting perusahaan utilitas air, seperti sistem billing dan ERP, dibangun bertahun-tahun oleh pihak ketiga dengan kontrak yang belum selalu mengatur hak akses, dokumentasi, integrasi, dan keberlanjutan layanan secara rinci. Dampaknya bisa berat: akses ke source code tidak jelas, struktur database hanya dipahami vendor, biaya integrasi sulit diprediksi, dan organisasi kehilangan daya tawar ketika kualitas layanan menurun atau vendor tidak lagi mampu mendukung sistem.

Mitigasi di tingkat Direksi perlu dimulai sejak fase pengadaan dan pembaruan kontrak.

1. Kendali data dan akses administratif. Organisasi perlu memastikan hak akses ke data operasional, struktur database, dan prosedur pemulihan terdokumentasi. Akses administratif harus dikendalikan, diaudit, dan tidak bergantung pada satu pihak tanpa mekanisme pengawasan.
2. Klausul keberlanjutan kode sumber (source code escrow). Untuk software custom yang kritis, kontrak sebaiknya mengatur penyerahan source code atau penyimpanan melalui pihak ketiga (escrow agreement) dengan kondisi pelepasan yang jelas jika vendor gagal memenuhi SLA, berhenti beroperasi, atau kontrak berakhir.
3. Antarmuka integrasi terbuka (open API). Kontrak perlu mengatur API terdokumentasi agar organisasi dapat mengintegrasikan layanan baru tanpa tergantung pada satu vendor lama untuk setiap perubahan.
4. Rencana keluar (exit plan). Setiap kontrak sistem kritis perlu memiliki rencana transisi, termasuk ekspor data, dokumentasi konfigurasi, dan dukungan migrasi.

4.3 Penilaian dan Mitigasi Risiko

Setelah risiko diidentifikasi, langkah selanjutnya adalah menilai risiko dan merencanakan mitigasi. Bagian ini membahas metode penilaian dan pendekatan mitigasi.

4.3.1 Metode Penilaian Risiko

Penilaian risiko bertujuan untuk menentukan prioritas penanganan. Dua pendekatan umum digunakan:

Pendekatan Kualitatif menggunakan skala subjektif untuk menilai dampak dan probabilitas. Keuntungan: sederhana dan cepat. Keterbatasan: kurang presisi.

Skala umum yang digunakan ditunjukkan dalam Tabel 4.1 dan Tabel 4.2.

Tabel 4.1 Skala probabilitas risiko TI

Tabel 4.2 Skala dampak risiko TI

Pendekatan Kuantitatif menggunakan data numerik untuk menghitung nilai risiko. Biasanya menggunakan formula:

Skor risiko (risk score) = probabilitas × dampak

Contoh: jika probabilitas system downtime adalah 30% per tahun dan dampak finansial adalah Rp 5 miliar, maka expected loss adalah Rp 1,5 miliar per tahun. Pendekatan ini memerlukan data historis yang memadai dan seringkali sulit diterapkan untuk risiko yang jarang terjadi.

4.3.2 Risk Appetite dan Risk Tolerance

Sebelum merencanakan mitigasi, organisasi harus menentukan selera risiko (risk appetite) dan toleransi risiko (risk tolerance). Ini adalah keputusan strategis yang harus ditetapkan oleh Direksi, bukan oleh tim TI sendiri.

Selera risiko (risk appetite) adalah jumlah dan jenis risiko yang bersedia diambil organisasi untuk mencapai tujuannya. Contoh:

• Risiko yang dapat diterima: downtime sistem non-kritis hingga 4 jam per bulan
• Risiko yang tidak dapat diterima: downtime sistem kritis lebih dari 1 jam

Toleransi risiko (risk tolerance) adalah variasi yang dapat diterima terhadap parameter risiko. Contoh:

• Variasi ±10% dari anggaran TI dapat diterima
• Project delay hingga 1 bulan dapat ditoleransi

Penetapan risk appetite dan risk tolerance membantu organisasi mengambil keputusan yang konsisten tentang risiko. Tanpa penetapan yang jelas, keputusan akan bersifat ad-hoc.

Dalam pengalaman saya, kalimat “risiko masih bisa diterima” sering terdengar meyakinkan di rapat, tetapi rapuh ketika tidak disertai angka, batas waktu, dan pemilik mitigasi. Risiko yang diterima tanpa batas adalah risiko yang sebenarnya sedang diabaikan.

4.3.3 Opsi Penanganan Risiko

Setelah dinilai, risiko dapat ditangani dengan empat opsi utama:

1. Terima (accept). Risiko diterima sebagaimana adanya karena biaya mitigasi lebih besar daripada dampaknya. Contoh:

• Downtime sistem non-kritis dengan dampak finansial minimal
• Risiko yang memiliki kontrol yang sudah memadai

Ketika menerima risiko, organisasi harus: (a) mendokumentasikan keputusan, (b) memonitor risiko secara berkala, dan (c) meninjau keputusan jika kondisi berubah.

2. Hindari (avoid). Risiko dihindari dengan menghentikan aktivitas yang menyebabkan risiko. Contoh:

• Tidak menggunakan teknologi tertentu karena risikonya terlalu tinggi
• Menghentikan operasi di lokasi yang terlalu berisiko

Penghindaran risiko seringkali berarti mengorbankan peluang, sehingga harus dipertimbangkan secara hati-hati.

3. Kurangi (mitigate). Risiko dikurangi dengan menerapkan kontrol. Contoh:

• Mengimplementasikan firewall untuk mengurangi risiko unauthorized access
• Melakukan backup rutin untuk mengurangi risiko data loss

Mitigasi dapat berupa:

• Preventive controls yang mencegah insiden terjadi
• Detective controls yang mendeteksi insiden ketika terjadi
• Corrective controls yang memperbaiki dampak insiden

4. Alihkan (transfer). Risiko dialihkan ke pihak lain, biasanya melalui asuransi atau kontrak. Contoh:

• Cyber insurance untuk mengalihkan risiko finansial insiden siber
• Service level agreement dengan vendor untuk mengalihkan risiko kegagalan layanan

4.3.4 Matriks Risiko

Matriks risiko adalah alat visual untuk memprioritaskan penanganan risiko. Tabel 4.3 menyajikan contoh matriks untuk perusahaan utilitas.

Tabel 4.3 Matriks prioritas risiko TI

Rincian selengkapnya dapat dilihat pada daftar berikut:

Prioritas Kritis: Risiko ini harus ditangani segera dengan sumber daya yang memadai. Contoh:

• Ransomware pada sistem billing
• Akses tidak sah (unauthorized access) ke SCADA
• Kehilangan data pelanggan

Prioritas Tinggi: Risiko ini harus ditangani dalam roadmap jangka pendek (3-6 bulan). Contoh:

• System downtime sistem kritis
• Vendor dependency untuk sistem utama
• Kesenjangan kepatuhan (compliance gap) terhadap regulasi utama

Prioritas Sedang: Risiko ini dapat ditangani dalam roadmap jangka menengah (6-12 bulan). Contoh:

• Downtime sistem non-kritis
• Ketergantungan teknologi usang
• Skills gap tim TI

Terima/Pantau (accept/monitor): Risiko ini dapat diterima dengan pemantauan berkala. Contoh:

• Downtime sistem pendukung
• Risiko dengan kontrol yang sudah memadai
• Risiko biaya mitigasi jauh lebih besar dari dampak

4.3.5 Standar Keamanan Siber untuk Utilitas

Untuk perusahaan utilitas, standar keamanan siber berikut sangat relevan:

IEC 62443 - Keamanan Sistem Otomasi dan Kontrol Industri (Security for Industrial Automation and Control Systems)

Standar ini dirancang khusus untuk lingkungan Teknologi Operasional (operational technology, OT) seperti SCADA. Konsep kunci:

1. Segmentasi jaringan. Zona OT harus dipisahkan dari zona TI. Komunikasi antar-zona (zone-to-zone communication) harus dikontrol dan dipantau. Segmentasi dapat diimplementasikan dengan firewall industri antara zona TI dan OT, zona demiliterisasi (demilitarized zone, DMZ) untuk sistem yang memerlukan akses dari kedua zona, dan data diode untuk komunikasi satu arah dari OT ke TI.

2. Pertahanan berlapis (defense in depth). Pertahanan berlapis mengurangi risiko kegagalan satu kontrol. Lapisan pertahanan meliputi kontrol fisik untuk akses ke fasilitas kritis, segmentasi dan firewall pada jaringan, hardening sistem operasi, secure coding dan testing pada aplikasi, serta enkripsi dan access control pada data.

3. Tidak ada koneksi langsung ke internet. Perangkat OT kritis seperti PLC tidak boleh memiliki koneksi langsung ke internet. Akses harus melalui jump server atau bastion host dengan kontrol akses ketat.

4. Keamanan sejak desain (security by design). Keamanan harus dipertimbangkan sejak awal desain sistem, bukan ditambahkan kemudian. Ini mencakup threat modeling, persyaratan keamanan (security requirements), dan pengujian keamanan (security testing).

ISO/IEC 27001 - Sistem Manajemen Keamanan Informasi (Information Security Management)

Standar ini adalah standar internasional untuk sistem manajemen keamanan informasi. Untuk perusahaan utilitas air, kontrol yang paling relevan meliputi:

A.5 Kebijakan Keamanan Informasi: Kebijakan tertulis yang disetujui manajemen, dikomunikasikan, dan ditinjau berkala.

A.6 Organisasi Keamanan Informasi: Peran dan tanggung jawab yang jelas, termasuk steering committee dan incident response team.

A.7 Keamanan Sumber Daya Manusia: Screening kandidat, perjanjian kerahasiaan, dan pelatihan security awareness.

A.8 Manajemen Aset: Inventaris aset informasi dan klasifikasi berdasarkan sensitivitas.

A.9 Kontrol Akses: User access management, otentikasi, dan privileged access rights.

A.12 Keamanan Operasional: Prosedur operasi, patch management, dan backup.

A.13 Keamanan Komunikasi: Jaringan aman, enkripsi, dan transfer informasi.

A.16 Pengelolaan Insiden: Prosedur incident response, pelaporan, dan pembelajaran.

4.4 Daftar Risiko TI (IT risk register): Contoh dan Implementasi

Daftar risiko TI (IT risk register) adalah dokumen pusat untuk manajemen risiko TI. Bagian ini menyediakan contoh template dan panduan implementasi.

4.4.1 Contoh Daftar Risiko TI

Tabel 4.4 adalah contoh daftar risiko TI yang dapat digunakan perusahaan utilitas air sebagai titik awal.

Tabel 4.4 Contoh daftar risiko TI awal

4.4.2 Panduan Pengisian

Berikut adalah panduan untuk mengisi setiap kolom:

• ID: Pengenal unik untuk risiko (R01, R02, dst)
• Risiko: Deskripsi singkat tetapi jelas tentang risiko. Gunakan format “Kemungkinan terjadi [dampak] karena [penyebab]”
• Kategori: Klasifikasi risiko (Keamanan, Operasional, Finansial, Regulasi, Reputasi)
• Probabilitas: Skala 1-5 sesuai tabel di bagian 4.3.1
• Dampak: Skala 1-5 sesuai tabel di bagian 4.3.1
• Skor risiko (risk score): Probabilitas × Dampak (skor 1-25)
• Penanganan: Pilihan penanganan: terima (accept), hindari (avoid), kurangi (mitigate), atau alihkan (transfer)
• Pemilik (owner): Individu yang bertanggung jawab untuk penanganan risiko
• Target: Target penyelesaian penanganan
• Status: Status saat ini, misalnya terbuka, berjalan, selesai, atau ditahan

4.4.3 Siklus Manajemen Risiko

Manajemen risiko adalah proses berkelanjutan, bukan aktivitas satu kali. Siklusnya meliputi:

1. Identifikasi (Per Triwulan) Lokakarya identifikasi risiko. Tinjau insiden masa lalu. Pindai lingkungan untuk risiko baru.

2. Penilaian (Per Triwulan) Penilaian probabilitas dan dampak. Perhitungan risk score. Penentuan prioritas.

3. Penanganan (Per Triwulan) Penentuan opsi penanganan. Penugasan owner. Penetapan target.

4. Pemantauan (Bulanan)

• Tinjau status penanganan
• Identifikasi hambatan
• Penyesuaian rencana

5. Pelaporan (Per Triwulan) Pelaporan ke steering committee. Eskalasi risiko kritis. Rekomendasi keputusan.

4.4.4 Skenario Komposit: Implementasi Manajemen Risiko di Organisasi X

Organisasi X adalah skenario komposit yang merangkum pola implementasi manajemen risiko di perusahaan utilitas air menengah. Ia bukan satu organisasi tertentu, dan angka di bawah ini dipakai sebagai ilustrasi ritme kerja, bukan klaim hasil dari kasus nyata.

Posisi awal.

Belum ada daftar risiko TI formal. Risiko diidentifikasi secara ad hoc ketika masalah muncul. Insiden ditangani secara reaktif tanpa prosedur jelas. Steering committee ada, tetapi jarang membahas risiko teknologi sebagai risiko layanan.

Bulan 1-3: Identifikasi dan dokumentasi.

Organisasi memulai dengan menyusun daftar risiko TI awal:

1. Lokakarya asesmen risiko diadakan dengan peserta dari TI, operasi, keuangan, dan hukum
2. 25 risiko awal diidentifikasi dan diklasifikasikan
3. Setiap risiko diberi skor risiko (probabilitas × dampak)
4. 10 risiko prioritas dipilih untuk penanganan segera

Risiko prioritas yang diidentifikasi meliputi ransomware pada sistem billing, downtime SCADA karena kegagalan perangkat keras, akses tidak sah (unauthorized access) ke data pelanggan, ketergantungan vendor untuk sistem kritis, dan kurangnya kompetensi tim TI.

Bulan 4-9: Implementasi kontrol mitigasi.

Untuk setiap risiko prioritas, rencana tindakan (action plan) disusun:

R01 - Ransomware pada sistem billing. Organisasi menerapkan endpoint protection di seluruh workstation, pelatihan security awareness untuk karyawan, segmentasi jaringan antara zona TI dan zona OT, serta backup harian dengan penyimpanan di lokasi terpisah (offsite storage).

R02 - Downtime SCADA karena kegagalan perangkat keras. Organisasi menerapkan redundansi (redundancy) untuk server kritis, kontrak pemeliharaan (maintenance) dengan SLA yang jelas, prosedur pemulihan bencana (disaster recovery) terdokumentasi, dan perangkat cadangan (spare) untuk komponen kritis.

R03 - Akses tidak sah ke data pelanggan. Organisasi menerapkan autentikasi multifaktor (multi-factor authentication, MFA) untuk akses jarak jauh, kontrol akses berbasis peran (role-based access control) di seluruh aplikasi, jejak audit (audit trail) untuk akses data sensitif, dan enkripsi data pelanggan saat tersimpan maupun saat transmisi.

Hasil awal yang dicari bukan angka sempurna, melainkan setiap risiko prioritas punya pemilik, target, kontrol, dan bukti tindak lanjut. Beberapa kontrol sudah berjalan, sebagian lain masih menunggu anggaran atau keputusan lintas fungsi.

Bulan 10-15: Pemantauan dan penyesuaian.

Setelah kontrol diimplementasi, organisasi memantau efektivitasnya melalui indikator yang sederhana tetapi konsisten:

1. Jumlah insiden phishing yang dilaporkan dan ditindaklanjuti
2. Durasi downtime SCADA dan penyebab utamanya
3. Waktu deteksi akses tidak sah
4. Kepatuhan SLA vendor terhadap target layanan

Angka dasar (baseline) dicatat terlebih dahulu. Setelah itu barulah organisasi bisa menilai apakah kontrol benar-benar memperbaiki risiko, atau hanya menambah dokumen.

Bulan 16-18: Evaluasi dan perluasan.

Pada akhir periode 18 bulan, organisasi melakukan evaluasi komprehensif:

1. Asesmen risiko ulang dilakukan
2. Risiko awal ditinjau statusnya
3. Risiko baru diidentifikasi
4. Proses manajemen risiko disempurnakan

Hasil akhirnya: selera risiko (risk appetite) terdokumentasi, daftar risiko TI masuk agenda rutin steering committee, dan manajemen risiko berubah dari respons insiden menjadi ritme keputusan.

Pelajaran Kunci:

1. Keterlibatan pimpinan sangat krusial. Area yang didukung direksi berkembang lebih cepat
2. Konsistensi lebih penting daripada intensitas. Tinjauan triwulan lebih baik daripada marathon tahunan
3. Dokumentasi adalah kunci. Tanpa dokumentasi, pembelajaran hilang dan risiko berulang
4. Risk register adalah alat hidup, bukan dokumen statis. Perlu ditinjau dan diperbarui secara berkala

4.5 Implementasi Praktis: Panduan 90 Hari

Bagian ini menyediakan panduan praktis untuk memulai atau memperbaiki manajemen risiko TI dalam 90 hari.

4.5.1 Hari 1-30: Asesmen dan Perencanaan

Tujuan: Memahami posisi saat ini dan merencanakan perbaikan

Kegiatan:

1. Lokakarya penilaian risiko (risk assessment workshop, Hari 1-5) Undang perwakilan dari TI, operasi, keuangan, dan hukum. Lakukan sesi curah pendapat (brainstorming) risiko TI, kategorikan risiko (keamanan, operasional, finansial, regulasi, reputasi), lalu susun daftar awal 20-30 risiko.

2. Penilaian risiko (risk scoring, Hari 6-10) Tentukan skala probabilitas (1-5), tentukan skala dampak (1-5), hitung risk score untuk setiap risiko, lalu prioritaskan berdasarkan skor.

3. Analisis kesenjangan (gap analysis, Hari 11-20) Identifikasi kontrol yang sudah ada, bandingkan dengan risiko yang diidentifikasi, temukan area yang belum memiliki kontrol memadai, lalu susun daftar gap.

4. Roadmap 90 hari (Hari 21-30) Pilih 10 risiko prioritas, susun rencana mitigasi untuk masing-masing, tetapkan owner dan target, lalu dapatkan persetujuan manajemen.

Output:

• Daftar risiko awal dengan skor
• Gap analysis kontrol
• roadmap 90 hari tertulis

4.5.2 Hari 31-60: Implementasi Kontrol

Tujuan: Mengimplementasikan kontrol untuk risiko prioritas

Kegiatan:

1. Implementasi kontrol kemenangan cepat (quick wins, Hari 31-45)

   • Kebijakan kata sandi dan password policy
   • Pelatihan security awareness pertama
   • Prosedur backup dan restore
   • Inventaris aset TI

2. Implementasi Kontrol Menengah (Hari 46-60) Terapkan patch management rutin, antivirus di seluruh workstation, firewall antara jaringan TI dan OT, serta prosedur incident response dasar.

Output: Minimal 5 kontrol baru diimplementasi. Prosedur dasar terdokumentasi. Pelatihan pertama selesai.

4.5.3 Hari 61-90: Pemantauan dan Perbaikan

Tujuan: Memantau efektivitas kontrol dan menyempurnakan proses

Kegiatan:

1. Pemantauan Efektivitas Kontrol (Hari 61-75) Tinjau insiden yang terjadi. Evaluasi efektivitas kontrol yang baru. Identifikasi area perbaikan.

2. Tinjauan daftar risiko TI (Hari 76-85) Tinjau ulang penilaian risiko, perbarui status mitigasi, tambahkan risiko baru yang ditemukan, dan hapus risiko yang tidak relevan.

3. Perencanaan Berikutnya (Hari 86-90) Evaluasi pencapaian 90 hari, susun rencana 90 hari berikutnya, tetapkan target baru, dan dokumentasikan pelajaran.

Output:

• Daftar risiko TI terperbarui
• Evaluasi kontrol
• Rencana fase berikutnya

4.5.4 Daftar Periksa Implementasi

Berikut adalah daftar periksa (checklist) untuk memastikan implementasi berjalan dengan baik:

Persiapan:

• Sponsor dari manajemen puncak didapat
• Tim manajemen risiko dibentuk
• Lokakarya asesmen risiko dijadwalkan
• template daftar risiko disiapkan

Identifikasi Risiko:

• Sesi curah pendapat risiko dilakukan
• Risiko dikategorisasi dengan jelas
• Skor probabilitas dan dampak ditentukan
• Prioritas risiko ditetapkan

Mitigasi Risiko:

• Rencana mitigasi disusun untuk risiko prioritas
• Pemilik (owner) risiko ditugaskan
• Target penyelesaian ditetapkan
• Kontrol diimplementasi sesuai rencana

Pemantauan:

• Risk register ditinjau secara berkala
• Efektivitas kontrol dievaluasi
• Laporan risiko disampaikan ke manajemen
• Pelajaran ditangkap dan didokumentasi

4.5.5 Tantangan Umum dan Cara Mengatasinya

Tantangan 1: Resistensi terhadap Perubahan Karyawan mungkin merasa proses manajemen risiko sebagai beban tambahan. Cara mengatasi: komunikasikan alasan secara jelas, libatkan karyawan dalam proses, tunjukkan hasil cepat (quick wins), dan buat proses sesederhana mungkin.

Tantangan 2: Keterbatasan Sumber Daya Organisasi mungkin tidak memiliki cukup orang atau anggaran. Cara mengatasi:

• Prioritaskan risiko paling kritis dulu
• Gunakan solusi open source jika memungkinkan
• Alihdayakan (outsource) beberapa fungsi jika perlu
• Fokus pada kontrol dengan rasio cost-benefit terbaik

Tantangan 3: Kurangnya Kompetensi Tim TI mungkin tidak memiliki keahlian manajemen risiko. Cara mengatasi: latih tim yang ada, rekrut ahli jika anggaran memungkinkan, konsultasikan desain kontrol dengan auditor eksternal (external auditor), dan belajar dari praktik baik (best practice) industri.

Tantangan 4: Data yang Tidak Tersedia Penilaian risiko membutuhkan data historis yang mungkin tidak ada. Cara mengatasi: mulai dengan penilaian kualitatif, kumpulkan data secara bertahap, gunakan data industri sebagai referensi, dan perbaiki penilaian seiring waktu.

4.6 Penutup Bab

Manajemen risiko TI bukan dokumen yang selesai ketika tabelnya lengkap. Ia adalah disiplin keputusan. Risiko yang tidak punya pemilik akan berpindah-pindah meja; risiko yang tidak punya batas toleransi akan diperdebatkan terus saat insiden; risiko yang tidak pernah ditinjau akan menjadi sejarah yang berulang.

Untuk perusahaan utilitas air, risiko TI perlu diterjemahkan ke bahasa layanan. Bukan hanya “server gagal”, tetapi “tagihan tidak bisa diterbitkan”. Bukan hanya “akses SCADA terbuka”, tetapi “parameter operasi bisa diubah orang yang tidak berwenang”. Bukan hanya “data bocor”, tetapi “kepercayaan pengguna jasa menurun tajam”.

Pola ini berlaku lintas industri. BUMD listrik dan gas, koperasi simpan pinjam, puskesmas atau RSUD, sekolah penerima BOS, dan korporasi swasta menengah sama-sama membutuhkan daftar risiko hidup yang punya pemilik, batas toleransi, dan ritme tinjauan.

Ringkasan Bab

• Risiko TI yang tidak tercatat bukan berarti tidak ada; ia hanya tidak dikelola.
• Risiko pada perusahaan utilitas air harus dibaca lintas TI, OT, operasi, finansial, regulasi, dan reputasi.
• Selera risiko (risk appetite) dan toleransi risiko (risk tolerance) adalah keputusan Direksi, bukan keputusan teknis semata.
• Daftar risiko TI (IT risk register) harus menjadi alat kerja hidup, dibahas rutin, dan diperbarui saat kondisi berubah.
• Program 90 hari cukup untuk membuat fondasi: daftar risiko awal, skor prioritas, pemilik risiko, kontrol pertama, dan ritme pemantauan.

Lima Pertanyaan Refleksi untuk Direksi

1. Apakah organisasi memiliki daftar 10 risiko TI terbesar yang diperbarui minimal setiap triwulan?
2. Apakah setiap risiko prioritas punya satu nama pemilik, bukan hanya nama divisi?
3. Apakah Direksi sudah menetapkan risiko mana yang tidak boleh diterima, berapa pun biaya penghematannya?
4. Apakah risiko OT seperti SCADA, PLC, dan telemetry dibahas bersama risiko TI, bukan di ruang yang terpisah?
5. Apakah hasil mitigasi risiko pernah diuji melalui simulasi, atau hanya dinyatakan “sudah ada prosedur”?

Tiga Langkah yang Bisa Dimulai Minggu Ini

1. Buat risk register satu halaman. Tulis 10 risiko TI teratas, skor probabilitas, skor dampak, pemilik, kontrol yang ada, dan tindakan 30 hari.
2. Tetapkan satu risk owner per risiko prioritas. Jangan menulis “tim TI” atau “divisi”. Tulis nama jabatan yang bisa dimintai keputusan.
3. Masukkan risiko ke agenda rapat. Jadwalkan tinjauan risk register sebagai agenda tetap Komite Pengarah TI atau rapat Direksi yang relevan.

Daftar Periksa Rapat Risiko TI

1. Apakah risiko tertinggi berubah sejak rapat sebelumnya?
2. Apakah ada insiden kecil yang menunjukkan kontrol tidak efektif?
3. Apakah mitigasi punya pemilik dan tanggal selesai?
4. Apakah ada risiko yang perlu dinaikkan ke Direksi?
5. Apakah ada keputusan risiko yang perlu dicatat secara formal?

Daftar periksa ini sederhana, tetapi ia mengubah risiko dari daftar pasif menjadi ritme keputusan.

Satu Pertanyaan untuk Dibawa ke Rapat Direksi Berikutnya

Risiko TI mana yang semua orang tahu, tetapi tidak ada satu orang pun yang bisa ditanya sebagai pemiliknya?

Jawaban atas pertanyaan ini biasanya membuka peta pekerjaan yang paling penting. Risiko tanpa pemilik adalah risiko yang sedang menunggu tanggal kejadian.

Menuju Bab 5: Mengapa Struktur Organisasi Menentukan Risiko

Setelah risiko ditulis, pertanyaan berikutnya adalah siapa yang mengelolanya. Di sinilah banyak program manajemen risiko berhenti. Dokumen sudah ada, skor sudah ada, mitigasi sudah ditulis, tetapi struktur organisasi tidak mendukung tindak lanjut.

Ada tiga alasan Bab 5 membahas struktur organisasi setelah manajemen risiko.

Pertama, risiko butuh pemilik. Tanpa struktur peran yang jelas, risk owner hanya menjadi label di tabel. Saat terjadi insiden, semua orang merasa ikut bertanggung jawab, tetapi tidak ada yang benar-benar memutuskan.

Kedua, risiko lintas TI dan OT membutuhkan koordinasi lintas fungsi. Kepala TI, Kepala Operasi, Keuangan, Hukum, Audit, dan Direksi harus tahu di titik mana peran mereka bersinggungan. Struktur organisasi yang kabur membuat koordinasi bergantung pada hubungan personal.

Ketiga, manajemen risiko yang matang membutuhkan RACI dan forum keputusan. Siapa yang Responsible, siapa yang Accountable, siapa yang Consulted, dan siapa yang Informed harus terlihat sebelum insiden datang.

Bab 5 akan merancang struktur organisasi TI, peran kunci, dan mekanisme steering committee yang membuat risiko tidak berhenti sebagai dokumen.

Lanjutkan ke Bab 5: Struktur Organisasi TI & Peran.

Referensi & Bacaan Lanjutan

1. IEC 62443-3-3:2017 - Keamanan Sistem Otomasi dan Kontrol Industri (Security for Industrial Automation and Control Systems)

   • IEC (2017). Standar internasional keamanan siber untuk sistem OT seperti SCADA.
   • 🔗 IEC Webstore

2. ISO/IEC 27001:2022 - Sistem Manajemen Keamanan Informasi (Information Security Management)

   • ISO (2022). Standar internasional sistem manajemen keamanan informasi.
   • 🔗 ISO.org

3. Kerangka Keamanan Siber NIST (NIST Cybersecurity Framework) 2.0

   • NIST (2024). Kerangka manajemen risiko siber lintas sektor, dengan fungsi Govern sebagai penguatan tata kelola.
   • 🔗 NIST CSF 2.0

4. COBIT 2019: Governance and Management Objectives

   • ISACA (2019). Bagian EDM03 (Ensured Risk Optimization) untuk tata kelola risiko TI.
   • 🔗 COBIT 2019

5. Compromise of U.S. Water Treatment Facility

   • FBI, CISA, EPA, dan MS-ISAC (2021). Joint advisory tentang akses tidak sah ke sistem SCADA instalasi pengolahan air.
   • 🔗 CISA Advisory AA21-042A

6. FBI Vault: Attempted Hacking of Oldsmar Water Treatment Plant

   • FBI (2021). Arsip dokumen publik terkait insiden Oldsmar, digunakan sebagai rujukan trail verifikasi.
   • 🔗 FBI Vault

7. Laporan lanjutan investigasi Oldsmar

   • WUSF/Tampa Bay Times (2023). Laporan bahwa FBI tidak dapat mengonfirmasi insiden Oldsmar sebagai intrusi siber yang ditargetkan.
   • 🔗 WUSF

8. Guidelines for Cybersecurity in the Water Sector

   • AWWA (2021). Panduan keamanan siber sektor air dari American Water Works Association.
   • 🔗 AWWA.org

9. Panduan Pengelolaan Risiko Keamanan Informasi

   • BSSN (2021). Panduan nasional pengelolaan risiko keamanan siber.
   • 🔗 BSSN.go.id

10. Water and Wastewater Cybersecurity

• CISA dan EPA (berkala). Toolkit keamanan siber untuk sektor air dan air limbah.
• 🔗 CISA Water and Wastewater Cybersecurity

11. UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi

• Pemerintah Indonesia (2022). Regulasi pelindungan data pribadi dengan implikasi risiko keamanan.
• 🔗 BPK RI

Catatan akses sumber: Tautan di atas mengarah ke portal resmi pemerintah, lembaga standar, atau penerbit. Sebagian dokumen tersedia bebas; dokumen ISO/IEC dan jurnal akademik tertentu bersifat berbayar di situs resmi. Apabila tautan berubah karena pembaruan portal, gunakan judul resmi dan nomor regulasi sebagai dasar pencarian.

Penafian: Tulisan ini adalah pandangan pribadi penulis berdasarkan pengalaman praktis dan studi independen. Manajemen risiko harus disesuaikan dengan konteks spesifik organisasi, termasuk selera risiko (risk appetite) dan ketersediaan sumber daya. Standar yang disebutkan adalah referensi; organisasi perlu mengecek versi terbaru sebelum implementasi. Insiden pembuka merujuk pada advisory publik dan diceritakan ulang untuk tujuan pembelajaran.