Log, pemantauan, dan respons insiden: siapa bertindak?

Log apa yang berguna untuk keamanan?

Pilih catatan yang membantu menjelaskan kejadian dan menentukan tindakan. Contohnya kegagalan login, perubahan hak admin, pengambilan data penting, dan perubahan konfigurasi. Sesuaikan dengan risiko layanan, bukan sekadar merekam sebanyak mungkin.

Catat waktu beserta zona waktunya, sistem, identitas akun yang relevan, tindakan, hasil, dan penanda untuk menghubungkan kejadian. Hindari kata sandi, token, kunci, atau salinan data pribadi yang tidak diperlukan. Batasi akses log dan lindungi dari perubahan atau penghapusan tanpa izin.

Uji juga apakah pencatatan bekerja saat terjadi kegagalan. Log yang hilang ketika dibutuhkan tidak dapat digantikan oleh tampilan dasbor yang rapi.

Apa beda SIEM, SOC, dan MDR?

Security information and event management (SIEM) membantu mengumpulkan dan menghubungkan catatan keamanan. Security operations center (SOC) adalah fungsi atau tim yang menjalankan pemantauan dan penanganan keamanan. Managed detection and response (MDR) adalah layanan deteksi dan respons yang dikelola pihak lain.

Nama layanan belum menjelaskan cakupan kerjanya. Dalam pengadaan, minta jawaban tentang sumber log, jam pemantauan, waktu eskalasi, tindakan yang diizinkan, lokasi data, dan pekerjaan yang tetap menjadi tanggung jawab tim sendiri. Jangan menyimpulkan semua layanan otomatis memantau setiap sistem selama 24 jam.

Siapkan alur dari peringatan ke tindakan

Tentukan penerima pertama, pengganti saat ia tidak tersedia, penanggung jawab insiden, pemilik layanan, dan pihak yang menyetujui pembatasan layanan. Pisahkan fakta yang sudah diperiksa dari dugaan.

Contoh fiktif berikut menunjukkan bentuk catatan, bukan hasil insiden nyata atau target waktu penanganan.

Waktu contoh	Catatan	Penanggung jawab dan tindak lanjut
09.10 WIB	Peringatan pengunduhan besar oleh akun admin	Petugas memeriksa sumber peringatan dan konteks pekerjaan
09.18 WIB	Pemilik akun menyatakan tidak melakukan kegiatan itu	Koordinator menilai pembatasan akses dan dampak layanan
09.25 WIB	Akses akun dibatasi oleh petugas berwenang	Catat persetujuan, waktu, dan tindakan; pertahankan bukti
Belum diketahui	Apakah data telah keluar dari sistem	Tetapkan pemeriksa dan bukti yang masih diperlukan

Jangan mengganti “belum diketahui” dengan kesimpulan pasti demi melengkapi laporan. Tulis perubahan kesimpulan beserta alasannya.

Bagaimana menjaga bukti dan kerahasiaan?

Catat sumber bukti, waktu pengambilan, petugas, lokasi penyimpanan, dan siapa yang mengaksesnya. Pertahankan keutuhan catatan sesuai prosedur serta kebutuhan penyelidikan. Jangan membagikan dump database atau log berisi data pribadi ke grup luas.

Pemeriksaan forensik memerlukan metode dan petugas yang sesuai. Halaman ini membantu kesiapan organisasi; bukan prosedur pengambilan bukti forensik atau jaminan bukti diterima dalam proses hukum. Lama penyimpanan ditentukan dari kebutuhan, risiko, kontrak, dan aturan yang berlaku, bukan satu angka universal.

Bagaimana melakukan simulasi sederhana?

Lakukan latihan diskusi atau tabletop: sampaikan bahwa admin menerima peringatan saat kontak utama tidak tersedia. Minta peserta menunjukkan siapa dihubungi, siapa dapat membatasi akses, bukti apa dijaga, dan siapa memberi informasi ke pengguna. Gunakan data fiktif dan jangan mematikan layanan produksi untuk latihan ini.

Catat keputusan yang belum memiliki pemilik, kontak yang tidak bisa dipakai, dan informasi yang sulit ditemukan. Beri setiap perbaikan penanggung jawab dan tenggat yang disepakati.

Jika ada kemungkinan insiden melibatkan data pribadi, lakukan penilaian kewajiban pemberitahuan melalui panduan insiden data pribadi. Pemantauan teknis tidak menggantikan penilaian tersebut.

Catat insiden dengan satu urutan kejadian

Gunakan lembar catatan insiden sejak laporan awal. Koordinator menentukan prioritas dan pihak yang perlu dihubungi; petugas teknis mencatat tindakan serta hasilnya; pencatat menjaga urutan waktu dan keputusan. Satu orang dapat memegang beberapa tugas pada tim kecil, tetapi tanggung jawabnya perlu jelas.

Pisahkan fakta dari dugaan. Misalnya, “tautan berstatus publik pukul 09.10 WIB” tidak sama dengan “semua orang sudah mengunduh dokumen”. Cantumkan lokasi bukti dengan akses terbatas, bukan menempelkan isinya ke percakapan umum. Pertahankan asal, waktu pengambilan, dan petugas yang menangani bukti.

Saat ada dugaan kegagalan pelindungan data pribadi, minta pihak yang bertanggung jawab segera menilai kewajiban pemberitahuan. Catatan insiden membantu penilaian itu, tetapi tidak menggantikan pemberitahuan atau menetapkan satu tenggat bagi semua kejadian.

Pilih langkah sesuai kejadian

• Website diretas: pembatasan, pemeriksaan perubahan, dan pembukaan kembali.
• Akun admin diambil alih: pemulihan akun dan pemeriksaan kewenangannya.
• API key bocor: pencabutan, penggantian, dan pemeriksaan penggunaan.
• Ekspor data mencurigakan: bedakan permintaan, berkas yang dibuat, dan akses hasil.

Catat hasil pemeriksaan sebelum membuka layanan dalam lembar pemulihan setelah insiden.

Pahami risiko di balik pemeriksaan

Baca Security Logging and Alerting Failures untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.

Langkah penerapan berikutnya

Pilih perilaku yang relevan dengan MITRE ATT&CK, lalu susun dan uji aturan deteksi. Gunakan panduan triase untuk menentukan status dan pemilik tindak lanjut. Uji pembagian keputusan melalui latihan tabletop.