Sertifikasi

Risk Assessment Keamanan Informasi — Cara Memetakan Risiko Sebelum Menjadi Insiden

Risk Assessment Keamanan Informasi — Cara Memetakan Risiko Sebelum Menjadi Insiden

Risk Assessment Keamanan Informasi — Cara Memetakan Risiko Sebelum Menjadi Insiden

Ketika membangun atau merawat sistem kecil, aku sering tergoda langsung mencari alat: memasang firewall baru, menyalakan scanner, atau menambah aturan akses. Semua itu berguna, tetapi ada satu pertanyaan yang seharusnya datang lebih dahulu: bagian mana yang paling perlu dilindungi? Tanpa jawaban itu, keamanan mudah berubah menjadi koleksi fitur yang ramai, tetapi tidak selalu relevan.

Di sinilah risk assessment keamanan informasi berguna. Proses ini bukan dokumen tebal yang hanya cocok untuk perusahaan besar atau bahan auditor. Untuk freelancer, tim kecil, pengelola website, sampai pemilik home server, ia adalah cara sederhana untuk melihat kemungkinan masalah sebelum masalah tersebut benar-benar meminta perhatian di jam yang tidak menyenangkan.

Memahami risiko, bukan sekadar celah

Celah keamanan dan risiko sering dipakai bergantian, padahal keduanya tidak sama. Celah adalah kelemahan, misalnya password admin yang dipakai ulang atau aplikasi yang belum diperbarui. Risiko adalah kemungkinan kelemahan itu dimanfaatkan dan dampaknya terhadap hal yang kita pedulikan.

Bayangkan rumah dengan jendela yang tidak terkunci. Jendela itu adalah celah. Risikonya akan berbeda antara gudang kosong dan ruang tempat menyimpan dokumen penting. Letak rumah, siapa yang bisa mengakses area tersebut, serta nilai barang di dalamnya ikut menentukan prioritas. Dalam sistem digital, cara berpikirnya serupa.

Secara praktis, risiko dapat dicatat dengan rumus sederhana berikut:

Risiko = kemungkinan kejadian x dampak kejadian

Angka pada rumus itu tidak harus sangat presisi. Skala rendah, sedang, dan tinggi sudah cukup sebagai awal. Tujuannya bukan meramal masa depan dengan sempurna, melainkan membuat keputusan keamanan lebih masuk akal dan dapat dijelaskan.

Mulai dari aset yang benar-benar penting

Kesalahan awal yang umum adalah langsung membuat daftar serangan. Lebih baik mulai dari aset, yaitu sesuatu yang nilainya ingin kita jaga. Aset tidak selalu berupa server. Data pelanggan, akun email, domain, repository kode, konfigurasi backup, perangkat laptop, hingga reputasi layanan juga termasuk aset.

Aku biasanya membaginya memakai tiga pertanyaan yang dekat dengan prinsip CIA: apakah data harus tetap rahasia (confidentiality), tetap akurat (integrity), dan tetap tersedia saat dibutuhkan (availability)? Sebuah database kontak pelanggan mungkin tinggi pada kerahasiaan. Halaman profil statis mungkin tidak terlalu rahasia, tetapi ketersediaannya tetap penting jika menjadi pintu masuk bisnis.

Buat inventaris singkat dan jangan mencoba mencatat semua hal sekaligus. Contohnya, sebuah website kecil dapat memulai dari lima aset berikut:

  • Database website dan data pengguna.
  • Akun registrar domain serta DNS.
  • Akun administrator CMS dan hosting.
  • Backup yang dapat dipulihkan.
  • Repository kode dan file konfigurasi.

Inventaris ini sering membuka mata. Banyak orang sangat fokus melindungi server, tetapi lupa bahwa pengambilalihan akun registrar bisa mengalihkan domain ke tempat lain tanpa menyentuh server sama sekali.

Hubungkan aset dengan ancaman dan kelemahan

Setelah tahu apa yang bernilai, tanyakan apa yang dapat terjadi dan mengapa hal itu mungkin terjadi. Ancaman adalah sumber kejadian, misalnya phishing, ransomware, kesalahan konfigurasi, atau perangkat rusak. Kerentanan adalah kondisi yang memungkinkan ancaman berhasil, seperti tidak adanya MFA, backup yang tidak pernah diuji, atau port administrasi terbuka ke internet.

Jangan berhenti pada ancaman dari luar. Kegagalan disk, salah menghapus file, token API yang tidak sengaja masuk repository publik, dan pembaruan yang merusak konfigurasi juga layak dicatat. Risiko keamanan informasi bukan hanya kisah penyerang bertopeng; sering kali ia datang dari proses sehari-hari yang belum diberi pagar.

Format tabel sederhana membuat hubungan ini mudah dibaca:

AsetAncaman / kelemahanDampakNilai risiko
Akun registrarPassword dipakai ulang, tanpa MFADomain dialihkanTinggi
DatabaseBackup hanya tersimpan di server yang samaData hilang saat disk rusakTinggi
CMSPlugin tidak diperbaruiDefacement atau malwareSedang

Menilai kemungkinan dan dampak tanpa terjebak angka

Untuk setiap skenario, beri nilai kemungkinan dan dampak dari 1 sampai 3. Kemungkinan rendah berarti butuh kondisi khusus atau kontrol yang ada sudah kuat. Kemungkinan tinggi berarti mudah terjadi atau sudah pernah terjadi. Dampak rendah mungkin hanya mengganggu pekerjaan sebentar; dampak tinggi dapat menyebabkan kehilangan data, biaya pemulihan, pelanggaran privasi, atau hilangnya kepercayaan pengguna.

Kalikan kedua nilai tersebut. Skor 6 sampai 9 dapat menjadi prioritas pertama, 3 sampai 4 masuk antrean perbaikan, sedangkan 1 sampai 2 cukup dipantau. Metode ini memang sederhana, tetapi kesederhanaannya justru membuatnya dapat dipakai secara konsisten. Spreadsheet kecil lebih berguna daripada framework yang sangat lengkap tetapi tidak pernah selesai diisi.

Yang penting, tulis alasan di balik nilai tersebut. Dua orang bisa memberi skor berbeda, dan diskusi atas alasannya jauh lebih berharga daripada memperdebatkan apakah nilainya harus 6 atau 8. Dalam konteks audit atau sertifikasi, catatan alasan ini juga menunjukkan bahwa keputusan dibuat berdasarkan konteks, bukan tebakan.

Memilih perlakuan untuk setiap risiko

Risiko tinggi tidak selalu berarti harus membeli solusi mahal. Ada empat pilihan dasar: mengurangi, menghindari, memindahkan, atau menerima risiko. Mengurangi berarti menambahkan kontrol, seperti MFA, update rutin, enkripsi, atau backup off-site. Menghindari berarti menghentikan aktivitas yang terlalu berisiko, misalnya tidak lagi mengekspos panel admin ke internet.

Memindahkan risiko dapat dilakukan melalui layanan pihak ketiga, kontrak, atau asuransi, walau tanggung jawab atas data tetap tidak hilang begitu saja. Menerima risiko adalah pilihan yang sah apabila dampaknya kecil dan biaya mitigasinya tidak sebanding. Namun penerimaan itu harus sadar dan dicatat, bukan terjadi karena kita lupa memeriksa.

Untuk contoh akun registrar tadi, tindakan paling berdampak biasanya sederhana:

1. Gunakan password unik dari password manager.
2. Aktifkan MFA dengan authenticator atau security key.
3. Simpan recovery code di tempat aman.
4. Aktifkan notifikasi perubahan DNS dan kontak akun.

Empat langkah ini tidak menjadikan risiko nol, tetapi menurunkan kemungkinan pengambilalihan secara drastis. Itulah sasaran kontrol yang baik: proporsional dengan nilai aset dan mudah dipelihara.

Jadikan risk assessment sebagai kebiasaan

Risk assessment bukan tugas sekali jadi. Sistem berubah ketika kita menambah aplikasi, membuat akun baru, memindahkan hosting, atau menerima data baru. Jadwalkan peninjauan singkat setiap tiga atau enam bulan, lalu lakukan juga setelah perubahan besar atau insiden kecil. Insiden kecil sering merupakan alarm yang murah sebelum muncul masalah yang mahal.

Simpan daftar risiko di tempat yang dapat diakses orang yang bertanggung jawab, lengkap dengan pemilik tindakan dan tanggal tinjau. Tidak perlu menunggu format formal seperti ISO 27001 untuk memulai. Justru kebiasaan mencatat aset, alasan prioritas, dan bukti perbaikan adalah fondasi yang akan memudahkan bila suatu hari kebutuhan kepatuhan menjadi lebih serius.

Penutup

Keamanan informasi bukan soal menutup semua kemungkinan, karena itu tidak realistis. Ia lebih mirip menyiapkan rumah sebelum musim hujan: kita memeriksa atap, membersihkan saluran, dan menyimpan barang penting di tempat aman karena tahu bagian mana yang paling rentan. Risk assessment membantu kita melakukan hal yang sama pada sistem digital.

Mulailah dari aset paling penting, buat tiga sampai lima skenario risiko, lalu selesaikan satu tindakan dengan dampak terbesar minggu ini. Setelah itu, ulangi secara berkala. Jika kamu punya cara sederhana untuk memetakan risiko pada proyek atau home server, bagikan di kolom komentar agar kita bisa saling belajar.