Bagian tersulit dari insiden keamanan biasanya terjadi setelah insiden itu sendiri berakhir: saat bisnis harus menjelaskan apa yang terjadi, kapan insiden ditemukan, data apa yang terlibat, siapa yang terdampak, dan mengapa keputusan tertentu dibuat.
Bagi banyak UKM, catatan ini tidak ada dalam bentuk yang lengkap. Rincian mungkin tersebar di seluruh pesan chat, kotak masuk, tiket helpdesk, tangkapan layar, dan ingatan anggota tim. Bisnis tetap bertahan selama insiden dengan catatan tambal sulam ini, tetapi catatan tersebut menjadi isu ketika otoritas pengawas, perusahaan asuransi, pelanggan, atau anggota dewan meminta linimasa yang jelas.
Bisnis dari semua ukuran memerlukan log insiden keamanan yang menyeluruh. Log ini harus menjadi satu sumber kebenaran untuk mencatat apa yang terjadi, bagaimana insiden ditangani, dan bukti apa yang mendukung keputusan yang dibuat selama proses berlangsung.
Catatan ini tetap berharga bahkan ketika Anda tidak perlu melaporkan insiden. Kami akan menjelaskan mengapa log insiden keamanan bermanfaat bagi bisnis Anda dan cara membuat log Anda sendiri.
Mengapa log insiden keamanan penting
Log insiden vs rencana respons insiden
Apa saja yang harus ada dalam log insiden keamanan
Templat log insiden sederhana untuk UKM
Cara mencatat keputusan notifikasi
Apa yang diharapkan otoritas pengawas dari log insiden keamanan
Mengapa log insiden keamanan penting
Log insiden keamanan menciptakan akuntabilitas pada saat bisnis paling mungkin kehilangan jejak rincian. Selama insiden, tindakan terjadi dengan cepat: kata sandi diatur ulang, akun dinonaktifkan, penyedia TI dihubungi, data pelanggan diperiksa, dan pimpinan diberi penjelasan. Langkah-langkah tersebut mungkin tepat seperti yang dibutuhkan bisnis saat itu, tetapi akan jauh lebih sulit dijelaskan nanti jika tidak ada yang mencatat kapan setiap tindakan terjadi, siapa yang menyetujuinya, dan bukti apa yang mendukung keputusan tersebut.
Bagi bisnis yang berbasis di Eropa, ini bukan sekadar praktik yang baik. Berdasarkan General Data Protection Regulation (GDPR), baik di Inggris maupun UE, pembobolan data pribadi perlu dinilai, dan sebagian harus dilaporkan kepada otoritas pengawas yang bersangkutan.
Di Inggris, panduan laporkan pembobolan(jendela baru) dari ICO menjelaskan bahwa organisasi harus menilai kemungkinan risiko terhadap hak dan kebebasan orang serta memberi tahu ICO ketika risiko tersebut mungkin terjadi. Pasal 33 juga mewajibkan pengendali untuk mendokumentasikan pembobolan data pribadi, termasuk fakta pembobolan, dampaknya, dan tindakan perbaikan yang diambil. Persyaratan yang sama berlaku berdasarkan GDPR UE.
Misalnya, ICO tidak mengharapkan setiap UKM memiliki sistem kelas perusahaan, tetapi ICO mengharapkan catatan yang sesuai. Kerangka kerja respons dan pemantauan pembobolan miliknya menyatakan bahwa organisasi harus memiliki prosedur untuk memastikan insiden dan pembobolan data pribadi terdeteksi, dikelola, dan dicatat dengan tepat. Artinya, log insiden tidak boleh dibuat hanya ketika pembobolan serius sudah terjadi. Log tersebut harus menjadi bagian dari proses respons normal.
Catatan yang baik juga mendukung klaim asuransi. Perusahaan asuransi siber mungkin meminta bukti tentang kapan insiden ditemukan, langkah penanggulangan apa yang diambil, akun mana yang terdampak, dan apakah bisnis mengikuti proses respons insidennya. Log yang terawat baik dapat menunjukkan bahwa bisnis bertindak cepat dan konsisten.
Hal ini juga membantu perusahaan belajar. Ingatan dan catatan lisan tidak dapat diandalkan, tetapi catatan yang menunjukkan bahwa insiden dimulai dari kata sandi yang digunakan ulang, tidak adanya autentikasi multifaktor (MFA), akses vendor, atau offboarding yang tertunda memberi bisnis sesuatu yang konkret untuk diperbaiki dan arah yang lebih jelas untuk memperkuat keamanan dari waktu ke waktu.
Log insiden vs rencana respons insiden
Log insiden keamanan dan rencana respons insiden saling terhubung, tetapi keduanya bukan dokumen yang sama.
Rencana respons insiden menjelaskan apa yang harus dilakukan bisnis ketika terjadi masalah. Rencana ini menetapkan peran, jalur eskalasi, langkah penanggulangan, tanggung jawab komunikasi, dan prosedur pemulihan. Log insiden mencatat apa yang sebenarnya terjadi. Log tersebut merupakan linimasa, jejak bukti, catatan keputusan, dan file tindak lanjut untuk peristiwa tertentu.
Perbedaan tersebut penting karena bahkan rencana yang baik dapat gagal tanpa dokumentasi. Bisnis mungkin mengikuti langkah yang benar tetapi tetap kesulitan membuktikannya di kemudian hari. Log harus memungkinkan untuk menjawab pertanyaan praktis: kapan kami mengetahuinya, siapa yang bertindak, apa yang kami tanggulangi, data apa yang berisiko, apa yang kami putuskan, dan apa yang berubah setelahnya?
| Rencana respons insiden: Apa yang harus dilakukan bisnis Anda | Log insiden keamanan: Apa yang sebenarnya terjadi |
| Siapa yang memimpin respons Siapa yang menghubungi TI, legal, perusahaan asuransi, atau regulator Cara menanggulangi, memulihkan, dan berkomunikasi | Kapan insiden ditemukan Sistem dan data apa yang terdampak Tindakan apa yang diambil, oleh siapa, dan kapan |
Apa yang harus ada dalam log insiden keamanan
Log insiden yang berguna harus cukup konsisten agar bisnis dapat merekonstruksi peristiwa tersebut di kemudian hari dan menjelaskan keputusan yang dibuat selama respons.
Tanggal dan waktu penemuan
Catat kapan bisnis pertama kali menyadari insiden, siapa yang menyadarinya, dan bagaimana insiden ditemukan. Jika waktunya perkiraan, tandai sebagai perkiraan. Waktu penemuan penting karena tenggat pelaporan GDPR dan persyaratan asuransi sering bergantung pada kapan bisnis menyadari isu tersebut.
Sifat insiden
Jelaskan apa yang terjadi dengan bahasa yang sederhana. Hindari label samar seperti “isu keamanan” atau “kemungkinan pembobolan” tanpa konteks. Log harus menjelaskan sistem mana yang terdampak dan apakah insiden melibatkan kredensial, email, file, data pelanggan, sistem pembayaran, endpoint, atau akses pihak ketiga.
Data yang terlibat
Jika data pribadi mungkin terdampak, catat jenis data apa yang terlibat: nama, alamat email, nomor telepon, alamat, rincian akun, informasi keuangan, catatan karyawan, komunikasi pelanggan, kredensial masuk, atau kategori relevan lainnya. Perkirakan berapa banyak individu yang mungkin terdampak, dan perjelas apakah jumlahnya sudah dikonfirmasi atau masih dalam penyelidikan.
Kemungkinan penyebab
Catat penyebab yang diketahui atau diduga, meskipun penyelidikan masih berlangsung. Saat rincian baru muncul, log dapat diperbarui dari “penyebab tidak diketahui” menjadi “email phishing menyebabkan kompromi kredensial” atau “akun mantan kontraktor tetap aktif.” Log harus menunjukkan bagaimana pemahaman bisnis berubah seiring waktu.
Tindakan penanggulangan segera
Dokumentasikan apa yang dilakukan untuk membatasi kerusakan. Ini dapat mencakup pengaturan ulang kata sandi, pencabutan sesi, penerapan MFA, penangguhan akun, penghapusan aturan kotak surat, isolasi perangkat, penghapusan akses vendor, perubahan firewall, atau penghentian layanan sementara. Jika memungkinkan, sertakan penanggung jawab dan stempel waktu untuk setiap tindakan.
Keputusan notifikasi
Catat apakah bisnis memberi tahu otoritas pengawas yang relevan, seperti ICO di Inggris atau otoritas perlindungan data nasional di tempat lain di UE, serta individu yang terdampak, pelanggan, pemasok, perusahaan asuransi, penasihat hukum, atau penegak hukum. Jika keputusannya adalah tidak memberi tahu, dokumentasikan alasannya. Penjelasan tersebut sering kali sama pentingnya dengan notifikasi itu sendiri.
Langkah perbaikan dan linimasa
Penanggulangan menangani insiden langsung. Perbaikan mengurangi kemungkinan isu yang sama terjadi lagi. Catat tindakan lanjutan seperti menerapkan MFA, menghapus kredensial bersama, memperbarui kebijakan akses, memperbaiki proses offboarding, memperbaiki kesalahan konfigurasi, atau mengubah cara cadangan dilindungi.
Pelajaran yang dipetik
Akhiri dengan apa yang dipelajari bisnis dan apa yang akan berubah. Ini tidak boleh ditulis sebagai menyalahkan. Bagian ini harus mengidentifikasi kelemahan, perbaikan yang dibutuhkan, dan siapa yang bertanggung jawab atas tindak lanjutnya.
Templat log insiden sederhana untuk UKM
Perangkat lunak khusus tidak diperlukan untuk mendokumentasikan insiden. Spreadsheet, formulir internal yang aman, sistem tiket, atau daftar bersama dapat digunakan jika akses dikendalikan dan entri dijaga konsisten.
Log insiden yang efektif harus mencakup kolom-kolom berikut:
- ID insiden: Nomor referensi unik.
- Tanggal dan waktu ditemukan: Saat bisnis menyadari insiden.
- Dilaporkan oleh: karyawan, penyedia, pelanggan, vendor, peringatan monitoring, atau pihak eksternal.
- Jenis insiden: phishing, malware, kompromi kredensial, kehilangan data, akses tidak sah, ransomware, insiden pemasok, kehilangan perangkat, email salah kirim, atau lainnya.
- Ringkasan: apa yang terjadi, ditulis dengan bahasa sederhana.
- Sistem yang terdampak: aplikasi, akun, perangkat, basis data, kotak masuk, atau layanan pihak ketiga yang terlibat.
- Data yang terlibat: apakah data pribadi terdampak, jenis apa, dan berapa banyak orang yang mungkin terpengaruh.
- Kemungkinan penyebab: diketahui, diduga, atau sedang diselidiki.
- Tindakan pengendalian: apa yang dilakukan segera.
- Keputusan notifikasi: otoritas pengawas, individu, pelanggan, perusahaan asuransi, atau tidak ada notifikasi dengan alasan.
- Tautan bukti: tangkapan layar, tiket, log, email, catatan akses, file ekspor, atau laporan penyedia.
- Tindakan remediasi: langkah yang diambil setelah pengendalian.
- Pemilik: orang yang bertanggung jawab atas tindak lanjut.
- Status: terbuka, monitoring, terkendali, terselesaikan, ditutup.
- Pelajaran yang dipetik: apa yang harus diubah.
Cara mencatat keputusan notifikasi
Keputusan notifikasi perlu ruang tersendiri dalam log insiden keamanan karena sering ditinjau setelah insiden.
Di bawah GDPR Inggris dan UE, organisasi harus menilai kemungkinan risiko terhadap hak dan kebebasan orang ketika terjadi pembobolan data pribadi. Jika kemungkinan risiko ada, otoritas pengawas harus dinotifikasi sesegera mungkin dan, jika memungkinkan, dalam 72 jam, ICO(jendela baru) di Inggris, otoritas perlindungan data nasional di setiap negara anggota UE. Jika risikonya tinggi, individu yang terdampak juga harus dinotifikasi tanpa penundaan yang tidak semestinya. Ambang batas dan tenggatnya sama di kedua sisi; hanya otoritasnya yang berubah.
Log insiden yang baik harus menunjukkan bahwa bisnis melakukan penilaian ini. Log tersebut harus mencatat apakah data pribadi terlibat, jenis kerugian apa yang mungkin timbul, perlindungan apa yang diterapkan, dan mengapa bisnis memutuskan untuk melaporkan atau tidak melaporkan.
Misalnya, insiden yang melibatkan kata sandi admin yang terekspos mungkin tidak langsung mengungkap apakah data pribadi diakses. Log harus mencerminkan ketidakpastian tersebut. Log dapat mencatat kekhawatiran awal, langkah investigasi, tinjauan aktivitas akun, dan kesimpulan akhir setelah bukti tersedia.
Pada titik ini dalam proses, banyak bisnis fokus mengatur perbaikan teknis dan lupa mencatat alasan kepatuhan. Kata sandi diatur ulang, akun diamankan, dan operasional berlanjut. Beberapa minggu kemudian, bisnis tidak dapat menjelaskan mengapa mereka memutuskan insiden tersebut tidak perlu dilaporkan.
Apa yang diharapkan otoritas pengawas dari catatan
Otoritas pengawas tidak hanya melihat apakah pembobolan dilaporkan. Mereka juga mungkin bertanya bagaimana bisnis:
- Mengidentifikasi insiden
- Menilai risiko
- Memutuskan apakah notifikasi diperlukan
- Mendokumentasikan tindakan yang diambil
Catatan yang baik harus membuat cerita insiden jelas dari awal hingga akhir. Catatan tersebut harus menunjukkan apa yang terjadi, data pribadi apa yang terlibat, kerugian apa yang mungkin timbul, apa yang dilakukan bisnis untuk mengendalikan isu tersebut, dan mengapa mereka melaporkan atau tidak melaporkan pembobolan itu.
Tingkat rincian harus sesuai dengan keseriusan insiden. Email yang salah kirim tidak memerlukan catatan yang sama dengan serangan ransomware, tetapi tetap perlu didokumentasikan untuk menunjukkan bahwa bisnis menilainya dengan benar.
Catatan ini juga harus disimpan dengan aman. Log insiden dapat memuat rincian sensitif tentang individu yang terdampak, sistem yang terekspos, tindakan karyawan, tangkapan layar, log akses, atau langkah remediasi. Akses harus dibatasi hanya untuk orang yang membutuhkannya, dan retensi harus selaras dengan kebijakan retensi data perusahaan secara lebih luas.
Log akses kredensial
Banyak insiden melibatkan kredensial: insiden dapat dipicu oleh kata sandi yang digunakan ulang, akun bersama, kotak masuk yang dikompromikan, proses masuk admin yang terekspos, permintaan MFA yang mencurigakan, atau karyawan yang tidak diberhentikan aksesnya dengan benar.
Oleh karena itu, catatan akses kredensial dapat menjadi input langsung ke dalam dokumentasi insiden keamanan siber. Ketika insiden melibatkan proses masuk bersama atau akun sensitif, bisnis perlu mengetahui siapa yang memiliki akses, bagaimana akses dibagikan, apakah izin berubah, dan apakah kredensial dirotasi setelah insiden.
Sebuah pengelola kata sandi bisnis seperti Proton Pass for Business membantu tim mengelola kredensial di brankas terenkripsi, membuat kata sandi unik, menggunakan isi otomatis, membagikan kredensial dengan aman, mengelola kunci sandi, dan menggunakan autentikasi dua faktor bawaan. Untuk dokumentasi insiden, nilai terkuatnya adalah jejak akses seputar kredensial: siapa yang memiliki akses ke brankas/akun bersama, bagaimana akses dikelola dan siapa yang menggunakannya, serta apa yang berubah setelah insiden.
Sebuah pengelola kata sandi untuk tim IT menambahkan fitur admin seperti kebijakan, pelaporan, log, kontrol akses berbasis peran, penyediaan SCIM, dan integrasi SSO. Fitur-fitur ini dapat membantu bisnis menunjukkan bagaimana akses kredensial dikendalikan dan memberikan bukti saat insiden terkait kredensial diselidiki.
Pengelola kata sandi tidak dapat menggantikan log insiden, penilaian hukum, proses notifikasi regulasi, atau rencana respons insiden. Namun, pengelola kata sandi menyediakan bukti kredensial yang dapat menjadi masukan untuk proses tersebut.
Simpan jejak audit lengkap akses kredensial dengan pengelola kata sandi bisnis.
