Pada jam-jam pertama insiden keamanan, Anda tidak dapat menyelesaikan gambaran teknis tentang apa yang terjadi. Tim Anda mungkin masih berusaha memahami akun mana yang dikompromikan, data apa yang diakses, sejauh mana penyerang berhasil, atau apakah insiden masih aktif.
Di samping penyelidikan Anda, tekanan untuk bertindak dimulai segera. Karyawan mendengar serpihan informasi dan perlu tahu apa yang harus dilakukan. Sementara itu, pelanggan mungkin menyadari gangguan layanan, aktivitas mencurigakan, atau permintaan atur ulang kata sandi yang tidak biasa. Mitra bisnis mungkin bertanya apakah sistem atau data mereka terlibat, dan pimpinan perlu memutuskan siapa yang berbicara, apa yang dapat dikonfirmasi, dan kapan diam menjadi risiko tersendiri.
Komunikasi insiden keamanan sulit karena bisnis harus transparan sebelum memiliki semua jawaban, tetapi cukup terinformasi untuk tidak menebak. Komunikasi yang dikirim terlalu dini dapat menimbulkan kebingungan, tetapi jika dikirim terlalu terlambat dapat merusak kepercayaan, memperlambat tindakan perlindungan, dan menimbulkan pertanyaan regulasi.
Kecil kemungkinan bahwa bisnis kecil dan menengah telah membuat atau melatih rencana respons insiden mereka, dan ini dapat menyebabkan kekacauan tambahan. Bahkan untuk bisnis yang lebih besar dengan rencana, langkah teknis mungkin didokumentasikan: mengendalikan insiden, atur ulang akses, pertahankan bukti, pulihkan sistem. Komunikasi mungkin ditinggalkan untuk nanti, sampai tiba-tiba insiden meningkat atau berubah.
Bagian dari persiapan menghadapi insiden adalah mengetahui siapa yang perlu mendengar dari Anda, apa yang perlu mereka ketahui, siapa yang menyetujui pesan, dan bagaimana mengomunikasikan fakta dengan jelas saat penyelidikan masih berjalan.
Perencanaan komunikasi termasuk dalam respons insiden
Struktur dua jalur untuk respons Anda
Mulai dari audiens, bukan pengumuman
Apa yang perlu dikomunikasikan secara internal
Cara memberi tahu pelanggan tentang pembobolan
Kapan memberi tahu lembaga regulator
Siapkan pesan sebelum Anda membutuhkannya
Bagaimana Proton Pass for Business dapat membantu
Perencanaan komunikasi termasuk dalam respons insiden
Respons insiden sering digambarkan sebagai proses teknis, tetapi insiden nyata dengan cepat menjadi lintas fungsi. Tim TI mungkin mengendalikan ancaman, tetapi pimpinan, hukum, dukungan pelanggan, SDM, komunikasi, dan operasi semuanya perlu tahu apa yang terjadi dan apa yang boleh mereka katakan.
Panduan NCSC tentang komunikasi yang efektif dalam insiden siber(jendela baru), praktik terbaik umum yang berlaku jauh melampaui Inggris, menekankan hal ini dengan jelas: organisasi sering memprioritaskan respons teknis dan mengesampingkan komunikasi, padahal komunikasi membentuk bagaimana staf, pelanggan, pemangku kepentingan, dan media memandang organisasi selama krisis.
Tidak setiap insiden memerlukan pernyataan publik. Namun, bisnis harus tahu sebelumnya siapa yang memutuskan apa yang dikomunikasikan, siapa yang menyetujui pesan eksternal, siapa yang berbicara kepada pelanggan, dan siapa yang menangani pelaporan regulator.
Rencana respons pembobolan data yang kuat perlu mencakup lapisan komunikasi. Ini harus mencakup rincian praktis:
- Daftar kontak
- Draf templat
- Jalur persetujuan
- Tinjauan hukum
- Poin pembicaraan dukungan pelanggan
- Tanggung jawab notifikasi regulator
- Catatan tentang apa yang dikirim, kapan, dan kepada siapa
Struktur dua jalur untuk respons Anda
Respons insiden memerlukan dua jalur: respons teknis dan respons komunikasi. Keduanya berjalan paralel satu sama lain dan pemimpin insiden/pemilik respons menghubungkan keduanya.
| Jalur kiri: respons teknis | Jalur kanan: respons komunikasi |
| Mengendalikan insiden | Perbarui tim internal |
| Amankan akun yang terpengaruh | Beri tahu pelanggan atau mitra yang terpengaruh |
| Pertahankan bukti | Nilai notifikasi regulator |
| Pulihkan sistem | Jaga konsistensi pesan saat fakta berubah |
Ini memungkinkan Anda menyusun respons dan memastikan kolaborasi terus berjalan saat anggota tim mengambil tugas yang berbeda.
Mulai dari audiens, bukan pengumuman
Komunikasi insiden keamanan gagal ketika satu pesan mencoba melayani semua orang. Karyawan, pelanggan, mitra, dan regulator memerlukan tingkat rincian yang berbeda karena keputusan yang harus mereka buat berbeda.
Tim internal Anda memerlukan kejelasan terlebih dahulu
Mereka tidak memerlukan setiap rincian, terutama saat penyelidikan masih berlangsung, tetapi mereka memerlukan kejelasan tentang apa yang dikonfirmasi, apa yang harus dilakukan sekarang, dan siapa yang memimpin respons. Artinya, mengetahui sistem atau akun mana yang harus dihindari, tindakan apa yang harus segera diambil, dan pertanyaan mana yang masih terbuka.
Karyawan juga perlu tahu apa yang tidak boleh dilakukan. Misalnya:
- Jangan membahas insiden secara publik
- Jangan mengatur ulang kredensial di luar proses yang disetujui
- Jangan menghubungi pelanggan dengan penjelasan improvisasi
- Jangan meneruskan pesan mencurigakan tanpa panduan.
Pelanggan dan mitra perlu tahu bagaimana mereka terpengaruh
Mereka ingin tahu apakah data, akses, pembayaran, layanan, atau operasi mereka terpengaruh. Notifikasi pelanggan yang baik harus menjelaskan:
- Apa yang diketahui
- Jenis data apa yang mungkin terlibat
- Apa yang dilakukan bisnis
- Apa yang harus dilakukan pelanggan sekarang, jika ada
- Di mana mereka bisa mendapatkan pembaruan.
Nada bahasanya harus sederhana dan langsung. Pelanggan juga tidak memerlukan detail forensik, mereka hanya perlu informasi yang cukup untuk melindungi diri mereka sendiri.
Regulator memerlukan catatan faktual
Notifikasi pembobolan GDPR kepada otoritas pengawas yang relevan (ICO(jendela baru) di Inggris, otoritas perlindungan data nasional di setiap negara anggota UE) bukanlah pesan pemasaran atau catatan penenangan pelanggan. Sebaliknya, ini harus menjadi catatan faktual tentang apa yang terjadi, siapa yang terdampak, dan apa yang Anda lakukan tentang hal itu. Kami membahas secara tepat apa yang harus disertakan di bagian tentang memberi tahu regulator di bawah ini.
Apa yang harus dikomunikasikan secara internal
Karyawan Anda adalah bagian dari respons, bahkan ketika mereka tidak berada di tim insiden. Tim yang bingung dapat secara tidak sengaja menciptakan lebih banyak kebisingan, membagikan informasi yang tidak akurat, atau memperlambat penanganan. Di sisi lain, tim yang mendapat informasi yang baik dapat membantu melindungi akun, mengarahkan pelanggan ke kanal yang tepat, dan menghindari tumbuhnya spekulasi.
Pengumuman insiden keamanan internal harus mencakup:
- Ringkasan jelas tentang apa yang telah dikonfirmasi sejauh ini, dalam bahasa yang sederhana
- Sistem, akun, tim, atau data mana yang berpotensi terdampak
- Apa yang sedang dilakukan bisnis sekarang
- Apa yang harus segera dilakukan karyawan
- Siapa yang diizinkan berkomunikasi secara eksternal
- Di mana pembaruan akan diposting
- Bagaimana melaporkan aktivitas mencurigakan terkait
Ada aspek yang tidak boleh disertakan: vektor serangan, analisis akar masalah, dan kerentanan spesifik umumnya tidak dibagikan secara internal saat insiden masih berlangsung, dan seringkali juga tidak setelahnya, karena rincian tersebut dapat membantu penyerang lain, menciptakan eksposur hukum, atau mengungkap celah yang belum ditutup.
Pesan internal pertama tidak perlu menjawab setiap pertanyaan, tetapi perlu menciptakan ketertiban. Misalnya, karyawan mungkin perlu mengatur ulang kata sandi hanya melalui proses yang disetujui, menghindari penggunaan sistem tertentu, menyimpan email mencurigakan, atau berhenti menggunakan kredensial bersama sampai tim respons menyelesaikan peninjauan.
Menilai kontrol akses yang ada terhadap praktik terbaik untuk pengelolaan kata sandi juga penting. Selama insiden, berbagi kredensial yang sudah usang atau informal dapat mempersulit pemahaman tentang apa yang terekspos.
Panduan Proton untuk perlindungan pembobolan data dan pencegahan pembobolan data untuk bisnis menjelaskan bagaimana kontrol berlapis mengurangi eksposur sebelum pembobolan terjadi. Pengelolaan kredensial yang aman adalah salah satu lapisan tersebut karena membantu bisnis mengetahui akun mana yang ada, siapa yang dapat mengaksesnya, dan apa yang perlu diubah dengan cepat.
Cara memberi tahu pelanggan tentang pembobolan
Notifikasi pembobolan data kepada pelanggan lebih sulit karena membawa bobot reputasi dan hukum. Orang mungkin khawatir tentang pencurian identitas, pengambilalihan akun, penipuan finansial, atau paparan informasi pribadi. Mereka juga mungkin frustrasi karena perusahaan tidak mencegah insiden tersebut.
Pesan pelanggan yang baik harus jujur tanpa membuat panik. Pesan tersebut harus menghindari jargon teknis, tetapi tetap jelas. Pelanggan perlu memahami data apa yang terlibat, risiko apa yang ditimbulkan, dan apa yang harus mereka lakukan selanjutnya.
Struktur yang berguna adalah:
- Apa yang terjadi, pada tingkat rincian yang sesuai untuk pelanggan
- Kapan bisnis menyadarinya
- Informasi atau layanan apa yang mungkin terdampak
- Langkah apa yang telah diambil bisnis
- Apa yang harus dilakukan pelanggan sekarang
- Bagaimana bisnis akan memberikan pembaruan
- Siapa yang dapat dihubungi pelanggan jika ada pertanyaan
Jika investigasi masih berlangsung, hal ini harus diungkapkan. Akurasi dan transparansi membantu memulihkan kepercayaan. Bersikap terbuka tentang dampak tidak memerlukan pengungkapan detail teknis yang dapat membantu seseorang mengulangi serangan.
Untuk insiden serius, pelanggan mungkin memerlukan instruksi praktis: ubah kata sandi, aktifkan MFA, waspadai email phishing, hubungi bank mereka, dan abaikan pesan yang mengaku dari perusahaan kecuali jika melalui kanal resmi. Notifikasi harus membuat langkah-langkah tersebut mudah dipahami.
Kapan dan bagaimana memberi tahu lembaga regulator
Tidak setiap insiden keamanan perlu dilaporkan ke otoritas pengawas. Pembobolan yang wajib dilaporkan berdasarkan GDPR Inggris dan UE bergantung pada apakah pembobolan data pribadi kemungkinan mengakibatkan risiko terhadap hak dan kebebasan orang.
Panduan pembobolan data pribadi(jendela baru) dari ICO mencerminkan persyaratan yang umum untuk GDPR Inggris dan UE: organisasi harus melaporkan pembobolan yang wajib dilaporkan tanpa penundaan yang tidak semestinya dan selambat-lambatnya 72 jam setelah menyadarinya. Laporan yang terlambat memerlukan alasan atas keterlambatan tersebut.
Jendela 72 jam itu dapat menciptakan tekanan, terutama ketika investigasi masih belum selesai. GDPR mengakui bahwa organisasi mungkin tidak memiliki setiap rincian dalam 72 jam pertama, sehingga informasi dapat diberikan secara bertahap, asalkan pembaruan lebih lanjut diberikan tanpa penundaan yang tidak semestinya.
Notifikasi kepada otoritas pengawas yang relevan (ICO di Inggris, atau otoritas perlindungan data nasional di UE) biasanya harus mencakup:
- Sifat pembobolan data pribadi
- Kategori dan perkiraan jumlah individu yang terdampak
- Kategori dan perkiraan jumlah catatan data pribadi yang terdampak
- Nama dan rincian kontak DPO atau titik kontak lainnya
- Konsekuensi yang mungkin timbul dari pembobolan
- Langkah-langkah yang diambil atau diusulkan untuk mengatasinya
ICO juga menyediakan halaman pusat untuk melaporkan pembobolan(jendela baru) dan mengarahkan organisasi ke proses pelaporan yang sesuai.
Bagi individu yang terdampak, ambang batasnya berbeda. Jika pembobolan data pribadi kemungkinan mengakibatkan risiko tinggi terhadap hak dan kebebasan orang, mereka harus diberi tahu tanpa penundaan yang tidak semestinya. Ini adalah situasi di mana tim hukum, privasi, dan kepemimpinan harus dilibatkan sejak awal, bahkan di bisnis kecil.
Siapkan pesan sebelum Anda membutuhkannya
Waktu terburuk untuk merancang proses komunikasi adalah selama insiden. Tidak membantu untuk mengeluarkan pernyataan atau panduan yang perlu diperbarui dan diubah.
Itulah sebabnya penting untuk menyiapkan struktur pesan Anda sebelum Anda membutuhkannya. Bukan kata-kata akhirnya, karena setiap insiden akan berbeda, tetapi strukturnya: siapa yang perlu menyetujui pesan, rincian apa yang harus disertakan, di mana pembaruan akan dicatat, dan siapa yang bertanggung jawab untuk setiap audiens.
Kit komunikasi sederhana sudah cukup untuk membuat jam pertama lebih terkendali. Kit ini dapat mencakup:
- Template pengumuman insiden internal
- Template notifikasi pelanggan
- Template pembaruan mitra atau vendor
- Poin pembicaraan dukungan pelanggan
- Daftar periksa notifikasi otoritas pengawas
- Daftar juru bicara yang disetujui
- Kontak eskalasi untuk hukum, TI, privasi, kepemimpinan, dan komunikasi
- Tempat untuk mencatat semua pembaruan dan keputusan
Persiapan memberi tim titik awal yang aman ketika kecepatan dan akurasi sama-sama penting. Template yang telah disiapkan menyisakan lebih banyak perhatian untuk fakta-fakta insiden: apa yang terjadi, siapa yang terdampak, apa yang sudah dilakukan, dan apa yang perlu dilakukan selanjutnya.
Bagaimana Proton Pass for Business dapat membantu
Komunikasi insiden keamanan bergantung pada fakta. Semakin jelas bisnis mengelola akses sebelum insiden, semakin mudah menjelaskan apa yang terjadi, apa yang mungkin terdampak, dan apa yang telah diubah.
Pengelola kata sandi bisnis seperti Proton Pass for Business membantu tim mengurangi eksposur terkait kredensial. Karyawan dapat membuat kata sandi yang kuat, menyimpannya di brankas kata sandi terenkripsi, menggunakan isi otomatis, membagikan kredensial dengan aman, mengelola kunci sandi, dan menggunakan autentikasi dua faktor bawaan. Admin dapat menerapkan kebijakan kata sandi, meninjau log aktivitas, mengelola akses dengan kontrol berbasis peran, dan mendukung penyediaan melalui integrasi SCIM dan SSO.
Selama insiden, fitur-fitur ini dapat membantu bisnis bertindak lebih percaya diri. Jika akun karyawan dikompromikan, admin dapat meninjau akses, mengidentifikasi kredensial yang dibagikan yang mungkin perlu rotasi, menegakkan autentikasi yang lebih kuat, dan mengurangi ketergantungan pada kata sandi yang disalin melalui obrolan atau spreadsheet.
Bersiaplah untuk merespons sebelum pembobolan terjadi dengan pengelola kata sandi bisnis.
