Bab 4: Manajemen Risiko TI

🎯 Track: Keduanya (K) untuk Direksi/Manajer maupun Praktisi TI.

Hook Naratif: Insiden Ransomware di Unit A

Hari Selasa yang tampak biasa berubah menjadi krisis ketika Kepala Unit A menerima telepon panik dari tim TI. Sistem billing yang berisi data ratusan ribu pelanggan telah terkunci oleh ransomware. Pesan di layar menuntut pembayaran dalam cryptocurrency yang jumlahnya fantastis jika mereka ingin data kembali.

Sementara tim TI bekerja siang dan malam untuk memahami tingkat kerusakan, operasi bisnis terhenti total. Pelanggan tidak dapat melakukan pembayaran, tagihan tidak dapat diterbitkan, dan call center dibanjiri keluhan. Tiga hari kemudian, setelah kerja sama dengan security vendor dan pihak berwenang, sistem berhasil dipulihkan dari backup. Namun, kerugian finansial dan kerusakan reputasi sudah terjadi.

Investigasi pasca-insiden menemukan bahwa serangan masuk melalui phishing email yang dikirim ke staf administrasi. Setelah masuk, attacker bergerak lateral di jaringan sampai menemukan akses ke server billing. Yang lebih mengkhawatirkan: backup terakhir adalah tiga minggu sebelumnya, dan tidak ada prosedur incident response yang terdokumentasi.

Kisah ini bukan kasus isolated. Serangan siber terhadap infrastruktur kritis meningkat secara global, dan perusahaan utilitas adalah target yang menarik karena dampak operasionalnya yang signifikan. Bab ini akan membahas bagaimana organisasi dapat memitigasi risiko seperti ini melalui pendekatan terstruktur dalam manajemen risiko TI.

Tujuan Pembelajaran:

• Memahami jenis-jenis risiko TI yang dihadapi perusahaan utilitas
• Mampu melakukan identifikasi dan penilaian risiko TI
• Memahami pendekatan mitigasi risiko yang efektif
• Menyusun IT Risk Register yang komprehensif
• Memahami standar keamanan siber yang relevan (IEC 62443)

4.1 Insiden Ransomware di Unit A: Analisis dan Pelajaran

Sebelum masuk ke kerangka kerja manajemen risiko, mari kita pelajari lebih dalam dari kasus pembuka. Analisis insiden yang terperinci memberikan wawasan praktis tentang bagaimana risiko nyata dapat memanifestasikan diri dalam organisasi.

4.1.1 Kronologi Insiden

Berikut adalah rekonstruksi kronologi insiden berdasarkan investigasi pasca-kejadian:

H-30 (Satu Bulan Sebelum Insiden):

• Attacker melakukan reconnaissance terhadap organisasi, mengumpulkan informasi dari website, media sosial, dan publikasi lain
• Email phishing pertama dikirim ke beberapa alamat email staf, tetapi tidak ada yang berhasil

H-14 (Dua Minggu Sebelum Insiden):

• Attacker menyempurnakan teknik phishing, menggunakan email yang terlihat lebih legitimate
• Salah satu staf administrasi mengklik tautan dan memasukkan kredensial
• Attacker memperoleh akses awal ke jaringan

H-7 (Satu Minggu Sebelum Insiden):

• Attacker bergerak lateral di jaringan, mengeksploitasi konfigurasi yang lemah
• Mereka menemukan server billing yang memiliki kerentanan keamanan
• Backdoor diinstal untuk akses persisten

H-0 (Hari Insiden):

• Attacker menjalankan ransomware, mengenkripsi data di server billing
• Pesan tebusan ditampilkan di layar administrator
• Operasi bisnis terhenti total

H+1 (Satu Hari Setelah Insiden):

• Tim TI menyadari insiden tetapi tidak tahu harus berbuat apa
• Tidak ada prosedur incident response yang dapat diikuti
• Keputusan dibuat untuk tidak membayar tebusan

H+2 (Dua Hari Setelah Insiden):

• Security vendor dibawa untuk membantu investigasi dan pemulihan
• Ditemukan bahwa backup terakhir adalah tiga minggu sebelumnya
• Proses restore dimulai

H+3 (Tiga Hari Setelah Insiden):

• Sistem berhasil dipulihkan dari backup
• Validasi integritas data dilakukan
• Sistem kembali online

H+7 (Satu Minggu Setelah Insiden):

• Investigasi penuh selesai, root cause diidentifikasi
• Rekomendasi perbaikan dibuat
• Pelaporan ke pihak berwenang dilakukan

4.1.2 Root Cause Analysis

Investigasi menemukan beberapa root cause utama yang memungkinkan insiden ini terjadi:

Pertama, kurangnya Security Awareness. Staf administrasi yang menjadi korban phishing tidak pernah menerima pelatihan security awareness. Mereka tidak tahu bagaimana mengenali tanda-tanda phishing: alamat pengirim yang mencurigakan, kesalahan tata bahasa, permintaan yang mendesak, atau tautan yang mencurigakan.

Kedua, kontrol akses yang lemah. Server billing dapat diakses dari jaringan tanpa segmentasi yang memadai. Tidak ada multi-factor authentication untuk akses remote, dan privilege administrator diberikan terlalu luas.

Ketiga, patch management yang buruk. Server billing menjalankan versi operating system yang sudah usang dengan patch keamanan yang belum diinstal. Kerentanan yang dieksploitasi attacker sebenarnya telah memiliki patch yang tersedia bulan sebelumnya.

Keempat, backup yang tidak memadai. Backup terakhir adalah tiga minggu sebelumnya, sehingga tiga minggu data transaksi hilang. Tidak ada prosedur backup yang terdokumentasi, dan tidak ada pengujian restore yang rutin.

Kelima, tidak ada prosedur incident response. Ketika insiden ditemukan, tim TI tidak tahu apa yang harus dilakukan. Tidak ada contact list, tidak ada escalation matrix, dan tidak ada prosedur komunikasi dengan stakeholder.

Keenam, kurangnya monitoring. Aktivitas attacker selama seminggu sebelum insiden tidak terdeteksi. Tidak ada sistem intrusion detection, dan log tidak ditinjau secara berkala.

4.1.3 Pelajaran dan Rekomendasi

Dari insiden ini, beberapa pelajaran penting dapat diambil:

Pelajaran 1: Investasi dalam Security Awareness sangat penting. Biaya pelatihan security awareness untuk seluruh karyawan jauh lebih rendah daripada biaya insiden keamanan. Pelatihan harus dilakukan minimal setahun sekali. Materinya mencakup: cara mengenali phishing, kebijakan password, dan prosedur pelaporan insiden.

Pelajaran 2: Segmentasi jaringan mengurangi blast radius. Jika jaringan telah disegmentasi dengan baik, attacker tidak akan dapat bergerak dengan mudah dari workstation administrasi ke server billing. Segmentasi jaringan harus memisahkan tiga zona: zona user, zona server, dan zona sistem kritis.

Pelajaran 3: Patch Management adalah fondasi keamanan. Kerentanan yang dieksploitasi telah memiliki patch yang tersedia. Prosedur patch management yang rutin dan terdokumentasi adalah salah satu kontrol paling efektif untuk mencegah insiden.

Pelajaran 4: Backup dan Recovery harus diuji. Memiliki backup tidak cukup jika proses restore tidak pernah diuji. Organisasi harus menguji proses restore secara berkala untuk memastikan bahwa backup dapat digunakan ketika dibutuhkan.

Pelajaran 5: Prosedur Incident Response sangat penting. Ketika insiden terjadi, setiap menit berharga. Prosedur incident response yang terdokumentasi memungkinkan respons yang cepat dan terkoordinasi, mengurangi downtime dan kerusakan.

4.1.4 Dampak Finansial dan Reputasi

Insiden ini memiliki dampak finansial langsung dan tidak langsung yang signifikan.

Dampak Langsung:

• Biaya security vendor untuk investigasi dan pemulihan
• Biaya overtime tim TI
• Hilangnya pendapatan selama tiga hari operasi terhenti
• Biaya komunikasi dengan pelanggan dan media

Dampak Tidak Langsung:

• Kerusakan reputasi yang memengaruhi kepercayaan pelanggan
• Potensi kehilangan pelanggan ke kompetitor
• Peningkatan insurance premium untuk cyber insurance
• Waktu manajemen yang dihabiskan untuk menangani krisis

Insiden ini juga menarik perhatian regulator. Mereka meminta penjelasan tentang langkah-langkah yang diambil organisasi untuk mencegah insiden serupa di masa depan.

4.2 Identifikasi Risiko TI di Utilitas

Manajemen risiko yang efektif dimulai dari identifikasi risiko yang komprehensif. Bagian ini akan 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 remediation 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 tidak umum di sektor lain:

Pertama, konvergensi IT dan OT. Sistem Operational Technology seperti SCADA, PLC, dan telemetry awalnya dirancang untuk lingkungan yang terisolasi, tanpa mempertimbangkan ancaman siber. Ketika sistem ini terhubung ke jaringan TI untuk integrasi data, mereka menjadi rentan. Risiko khusus mencakup:

• Manipulasi parameter proses produksi
• Gangguan distribusi produk
• Sabotase peralatan fisik melalui akses siber

Insiden di salah satu kota di Florida, Amerika Serikat (2021) di mana attacker berusaha meningkatkan kadar bahan kimia dalam suplai air menunjukkan betapa seriusnya risiko ini.

Kedua, risiko keamanan fisik. Infrastruktur utilitas tersebar di multiple lokasi: production facilities, pumping stations, reservoirs, dan lain-lain. Setiap lokasi adalah potensi titik kerentanan. Risiko mencakup:

• Pencurian peralatan
• Vandalisme terhadap fasilitas
• Akses tidak resmi ke control room

Ketiga, risiko terhadap keselamatan publik. Gangguan pada sistem utilitas dapat memiliki dampak langsung pada keselamatan publik. Risiko ini melampaui kerugian finansial dan mencakup:

• Kontaminasi produk
• Tekanan distribusi yang tidak aman
• Kegagalan sistem darurat

Keempat, risiko geografis. Infrastruktur utilitas tersebar di wilayah yang luas, seringkali di area yang sulit dijangkau. Risiko mencakup:

• Kerusakan infrastruktur karena bencana alam
• Kesulitan maintenance di lokasi terpencil
• Keterbatasan komunikasi di area terpencil

4.2.3 Teknik Identifikasi Risiko

Beberapa teknik dapat digunakan untuk mengidentifikasi risiko TI secara sistematis:

Pertama, 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.

Kedua, Interview dengan Key Stakeholders. Lakukan interview satu-satu dengan pemangku kepentingan kunci. Keuntungan: mendapatkan perspektif mendalam. Keterbatasan: memakan waktu.

Ketiga, Review Insiden Masa Lalu. Pelajari insiden yang terjadi di organisasi atau organisasi serupa. Keuntungan: berdasarkan realita. Keterbatasan: mungkin tidak menangkap risiko baru.

Keempat, Risk Assessment Workshop. Selenggarakan workshop terstruktur dengan fasilitator untuk mengidentifikasi dan menilai risiko. Keuntungan: terstruktur dan kolaboratif. Keterbatasan: memerlukan persiapan yang baik.

Kelima, Checklist dan Framework. Gunakan checklist 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 adalah daftar sumber risiko TI umum dalam perusahaan utilitas:

Sumber Teknis:

• Kegagalan hardware (server, storage, jaringan)
• Kegagalan software (bug, compatibility issues)
• Kerentanan keamanan (unpatched systems)
• Ketergantungan pada teknologi usang (legacy systems)

Sumber Manusia:

• Kesalahan operasional (human error)
• Insider threat (karyawan yang tidak puas)
• Kurangnya kompetensi teknis
• Kurangnya security awareness

Sumber Proses:

• Prosedur yang tidak adekuat
• Kurangnya dokumentasi
• Change management yang buruk
• Vendor management yang tidak efektif

Sumber Eksternal:

• Cyber attack (ransomware, phishing, DDoS)
• Bencana alam (banjir, gempa, longsor)
• Kegagalan vendor atau partner
• Perubahan regulasi

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:

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

Risk Score = Probability × Impact

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 risk appetite (nafsu makan risiko) dan risk tolerance (toleransi risiko). Ini adalah keputusan strategis yang harus ditetapkan oleh dewan direksi.

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

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.

4.3.3 Opsi Penanganan Risiko

Setelah dinilai, risiko dapat ditangani dengan empat opsi utama:

Pertama, Accept (Terima). 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.

Kedua, Avoid (Hindari). 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.

Ketiga, Mitigate (Kurangi). 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

Keempat, Transfer (Alihkan). 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. Berikut adalah contoh matriks untuk perusahaan utilitas:

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

• Ransomware pada sistem billing
• 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
• 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

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 - Security for Industrial Automation and Control Systems

Standar ini dirancang khusus untuk lingkungan Operational Technology (OT) seperti SCADA. Konsep kunci:

Pertama, Segmentasi Jaringan. Zona OT harus dipisahkan dari zona TI. Zone-to-zone communication harus dikontrol dan dimonitor.

Segmentasi dapat diimplementasikan dengan:

• Firewall industri antara zona TI dan OT
• Demilitarized zone (DMZ) untuk sistem yang memerlukan akses dari kedua zona
• Data diode untuk komunikasi satu arah dari OT ke TI

Kedua, Defense in Depth. Berlapis pertahanan untuk mengurangi risiko kegagalan satu kontrol. Lapisan pertahanan meliputi:

• Fisik: akses terkontrol ke fasilitas kritis
• Jaringan: segmentasi dan firewall
• Sistem: hardening sistem operasi
• Aplikasi: secure coding dan testing
• Data: enkripsi dan access control

Ketiga, 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.

Keempat, Security by Design. Keamanan harus dipertimbangkan sejak awal desain sistem, bukan ditambahkan kemudian. Ini mencakup: threat modeling, security requirements, dan testing keamanan.

ISO/IEC 27001 - Information Security Management

Standar ini adalah standar internasional untuk sistem manajemen keamanan informasi. Untuk perusahaan utilitas, controls 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 IT Risk Register: Template dan Implementasi

IT Risk Register adalah dokumen pusat untuk manajemen risiko TI. Bagian ini menyediakan template dan panduan implementasi.

4.4.1 Template IT Risk Register

Berikut adalah template Risk Register yang dapat digunakan perusahaan utilitas:

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

Risk Score: Probabilitas × Dampak (skor 1-25)

Penanganan: Pilihan penanganan (Accept, Avoid, Mitigate, Transfer)

Owner: Individu yang bertanggung jawab untuk penanganan risiko

Target: Target penyelesaian penanganan

Status: Status saat ini (Open, In Progress, Closed, On Hold)

4.4.3 Siklus Manajemen Risiko

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

1. Identifikasi (Per Triwulan)

• Workshop identifikasi risiko
• Review insiden masa lalu
• Scan 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. Monitoring (Bulanan)

• Review status penanganan
• Identifikasi hambatan
• Penyesuaian rencana

5. Pelaporan (Per Triwulan)

• Pelaporan ke steering committee
• Eskalasi risiko kritis
• Rekomendasi keputusan

4.4.4 Studi Kasus: Implementasi Risk Management di Organisasi X

Organisasi WaterX, sebuah perusahaan utilitas air menengah dengan 300.000 pelanggan, memulai perjalanan manajemen risiko TI dari level 2 ke level 3 dalam rentang 18 bulan. Berikut adalah perjalanan tersebut:

Posisi Awal (Bulan 0):

Tidak ada IT Risk Register formal. Risiko diidentifikasi secara ad-hoc ketika masalah muncul. Insiden ditangani secara reaktif tanpa prosedur jelas. Steering committee ada tetapi jarang membahas risiko.

Bulan 1-3: Identifikasi dan Dokumentasi

Organisasi memulai dengan menyusun IT Risk Register awal:

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

Risiko prioritas yang diidentifikasi:

• Ransomware pada sistem billing ( skor 20)
• Downtime SCADA karena hardware failure ( skor 20)
• Unauthorized access ke data pelanggan ( skor 10)
• Vendor dependency untuk sistem core ( skor 12)
• Kurangnya kompetensi tim TI ( skor 12)

Bulan 4-9: Implementasi Kontrol Mitigasi

Untuk setiap risiko prioritas, action plan disusun:

R01 - Ransomware pada sistem billing:

• Implementasi endpoint protection di seluruh workstation
• Pelatihan security awareness untuk seluruh karyawan
• Segmentasi jaringan antara zona TI dan zona OT
• Implementasi backup harian dengan offsite storage

R02 - Downtime SCADA karena hardware failure:

• Implementasi redundancy untuk server kritis
• Kontrak maintenance dengan vendor SLA terjamin
• Prosedur disaster recovery terdokumentasi
• Backup perangkat spare untuk komponen kritis

R03 - Unauthorized access ke data pelanggan:

• Implementasi multi-factor authentication untuk akses remote
• Role-based access control di seluruh aplikasi
• Audit trail untuk akses data sensitif
• Enkripsi data pelanggan saat diam dan transmisi

Hasil setelah 6 bulan: seluruh risiko prioritas memiliki rencana mitigasi yang jelas dengan owner dan target. Beberapa kontrol sudah diimplementasi dan mulai menunjukkan hasil.

Bulan 10-15: Monitoring dan Penyesuaian

Setelah kontrol diimplementasi, organisasi memonitor efektivitasnya:

1. Insiden phishing turun 70% setelah pelatihan awareness
2. Downtime SCADA turun dari 8 jam/bulan menjadi 3 jam/bulan setelah implementasi redundancy
3. Waktu deteksi unauthorized access meningkat berkat sistem monitoring

Namun, beberapa kontrol memerlukan penyesuaian:

• SLA vendor perlu ditingkatkan karena response time masih belum memadai
• Beberapa karyawan masih membuka phishing email, memerlukan pelatihan tambahan

Bulan 16-18: Evaluasi dan Perluasan

Pada akhir periode 18 bulan, organisasi melakukan evaluasi komprehensif:

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

Hasil akhir:

• 8 dari 10 risiko prioritas awal berhasil dimitigasi
• Risk appetite organisasi jelas dan didokumentasikan
• IT Risk Register menjadi bagian rutin dari agenda steering committee
• Budaya manajemen risiko mulai terbentuk

Pelajaran Kunci:

1. Keterlibatan pimpinan sangat krusial. Area yang didukung direksi berkembang lebih cepat
2. Konsistensi lebih penting daripada intensitas. Review 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: Assessment dan Perencanaan

Tujuan: Memahami posisi saat ini dan merencanakan perbaikan

Kegiatan:

1. Risk Assessment Workshop (Hari 1-5)

   • Undang perwakilan dari TI, operasi, keuangan, hukum
   • Lakukan brainstorming risiko TI
   • Kategorisasi risiko (keamanan, operasional, finansial, regulasi, reputasi)
   • Susun daftar awal 20-30 risiko

2. Risk Scoring (Hari 6-10)

   • Tentukan skala probabilitas (1-5)
   • Tentukan skala dampak (1-5)
   • Hitung risk score untuk setiap risiko
   • Prioritaskan berdasarkan skor

3. Gap Analysis (Hari 11-20)

   • Identifikasi kontrol yang sudah ada
   • Bandingkan dengan risiko yang diidentifikasi
   • Temukan area yang belum memiliki kontrol memadai
   • Susun daftar gap

4. Roadmap 90 Hari (Hari 21-30)

   • Pilih 10 risiko prioritas
   • Susun rencana mitigasi untuk masing-masing
   • Tetapkan owner dan target
   • 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 Quick Wins (Hari 31-45)

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

2. Implementasi Kontrol Menengah (Hari 46-60)

   • Patch management rutin
   • Antivirus di seluruh workstation
   • Firewall antara jaringan TI dan OT
   • Incident response procedure dasar

Output:

• Minimal 5 kontrol baru diimplementasi
• Prosedur dasar terdokumentasi
• Pelatihan pertama selesai

4.5.3 Hari 61-90: Monitoring dan Perbaikan

Tujuan: Memantau efektivitas kontrol dan menyempurnakan proses

Kegiatan:

1. Monitoring Efektivitas Kontrol (Hari 61-75)

   • Review insiden yang terjadi
   • Evaluasi efektivitas kontrol yang baru
   • Identifikasi area perbaikan

2. Risk Register Review (Hari 76-85)

   • Tinjau ulang penilaian risiko
   • Perbarui status mitigasi
   • Tambahkan risiko baru yang ditemukan
   • Hapus risiko yang tidak relevan

3. Perencanaan Berikutnya (Hari 86-90)

   • Evaluasi pencapaian 90 hari
   • Susun rencana 90 hari berikutnya
   • Tetapkan target baru
   • Dokumentasikan pelajaran

Output:

• Risk Register terperbarui
• Evaluasi kontrol
• Rencana fase berikutnya

4.5.4 Checklist Implementasi

Berikut adalah checklist untuk memastikan implementasi berjalan dengan baik:

Persiapan:

• Sponsor dari manajemen puncak didapat
• Tim manajemen risiko dibentuk
• Risk assessment workshop dijadwalkan
• Template risk register disiapkan

Identifikasi Risiko:

• Brainstorming risiko dilakukan
• Risiko dikategorisasi dengan jelas
• Skor probabilitas dan dampak ditentukan
• Prioritas risiko ditetapkan

Mitigasi Risiko:

• Rencana mitigasi disusun untuk risiko prioritas
• Owner risiko ditugaskan
• Target penyelesaian ditetapkan
• Kontrol diimplementasi sesuai rencana

Monitoring:

• 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 why (alasan) secara jelas
• Libatkan karyawan dalam proses
• Tunjukkan hasil cepat (quick wins)
• Jadikan proses se-sederhana 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
• 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:

• Pelatihan untuk tim yang ada
• Rekrut ahli jika anggaran memungkinkan
• Konsultasi dengan external auditor
• Belajar dari 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
• Perhaliki penilaian seiring waktu

Lanjut ke Mana?

Setelah memahami isi bab ini, lanjutkan ke Bab 5 (Struktur Organisasi TI) untuk pendalaman berikutnya. Untuk konteks tambahan, lihat juga Bab 7 untuk audit risiko.

Referensi & Bacaan Lanjutan

1. IEC 62443-3-3:2017 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 Information Security Management

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

3. NIST Cybersecurity Framework

   • NIST (2018). Framework keamanan siber yang komprehensif, banyak digunakan di sektor kritikal.
   • 🔗 NIST.gov

4. COBIT 2019: Governance and Management Objectives

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

5. Water Treatment Plant Cyber Attack Analysis

   • FBI Advisory (2021). Analisis insiden serangan siber terhadap fasilitas air di Florida.
   • 🔗 FBI Advisory

6. Guidelines for Cybersecurity in the Water Sector

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

7. Panduan Pengelolaan Risiko Keamanan Informasi

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

8. UU No. 27 Tahun 2022 tentang Perlindungan Data Pribadi

   • Pemerintah Indonesia (2022). Regulasi perlindungan data pribadi dengan implikasi risiko keamanan.
   • 🔗 JDIH Kominfo

Catatan akses: 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.

Disclaimer: Tulisan ini adalah pandangan pribadi penulis berdasarkan pengalaman praktis dan studi independen. Manajemen risiko harus disesuaikan dengan konteks spesifik organisasi dan memerlukan pertimbangan matang mengenai risk appetite dan ketersediaan sumber daya. Standar yang disebutkan (IEC 62443, ISO 27001, dll) adalah referensi dan organisasi harus mengecek versi terbaru sebelum implementasi. Insiden yang disebutkan dalam hook adalah ilustrasi komposit untuk tujuan pembelajaran.