SOP Penanganan Insiden Siber (Cyber Incident Response Plan) RS
Sobat IT RS pasti pernah dikejar-kejar kabar: “Server down, data SIMRS nggak bisa diakses!” atau “Ada email mencurigakan masuk, jangan-jangan kena ransomware!”. Bikin keringet dingin, apalagi kalau jam-jam genting. Udah gitu, atasan nanyain, “Mana laporan resmi ke BSSN? Udah lapor ke Kemenkes belum?”
Penanganan insiden siber di rumah sakit itu nggak cuma soal benerin server atau restore backup. Ada SOP, pelaporan resmi, sampai eskalasi tim. Kalau ngawur, siap-siap kena audit atau malah BPJS nahan klaim karena data nggak valid. Yuk, bongkar bareng langkah demi langkah biar Sobat IT RS nggak kelabakan pas insiden beneran kejadian!
Definisi & Tipe Insiden Siber di Rumah Sakit
Gampangnya, insiden siber itu apa aja yang mengancam data, sistem, atau layanan digital rumah sakit. Enggak harus hacker kelas wahid, kadang staf salah kirim data pasien juga udah masuk insiden.
- Malware/Ransomware: File terenkripsi, SIMRS stuck, data nggak bisa diakses.
- Data Breach: Ada yang ngopi database pasien tanpa izin, atau data bocor ke luar RS.
- Phishing/Social Engineering: Staf IT/medis dikibulin klik link palsu, masuk credential maling.
- DoS/DDoS: Server SIMRS dibombardir request sampai nggak bisa diakses, biasanya pas jam-jam klaim BPJS.
- Insider Threat: Pegawai sendiri iseng hapus data, atau curi data pasien buat dijual.
- Salah Konfigurasi: Firewall/DB kelupaan dikunci, data bisa diakses dari luar.
Alur Umum SOP: Dari Deteksi Sampai Pemulihan
Jangan sampai Sobat IT RS kayak pemadam kebakaran dadakan. Semua ada urutannya. Berikut langkah utama SOP Penanganan Insiden Siber untuk fasilitas kesehatan:
- Deteksi & Identifikasi Insiden
- Eskalasi ke Tim Tanggap Darurat Siber
- Pemutusan/Pembatasan Akses Sementara
- Analisis Dampak & Kronologi
- Pelaporan ke Pihak Eksternal Wajib (BSSN, Kemenkes)
- Remediasi & Pemulihan Data/Sistem
- Dokumentasi & Evaluasi
Langkah 1: Deteksi & Identifikasi Insiden
Penanda Insiden
- Login gagal terus-menerus di SIMRS, padahal username & password benar.
- File tiba-tiba di-encrypt, extension berubah aneh (contoh: .locked, .xcrypt).
- Penggunaan CPU/server melonjak, koneksi jaringan padat tanpa alasan jelas.
- Email masuk minta kirim credential/klik link aneh, subject nggak biasa.
Tools Deteksi
- Syslog/Log Server: Cari anomali di /var/log/syslog, SQL Server ErrorLog, Event Viewer.
- Network Monitoring: Pakai ntopng, Wireshark, atau NetFlow.
- EDR/Antivirus: Lihat alert, karantina file mencurigakan.
Contoh Query Deteksi Akses Ganjil di SQL Server
SELECT
login_name,
COUNT(*) AS failed_attempt
FROM sys.fn_logins_failed()
WHERE login_time >= DATEADD(hour, -1, GETDATE())
GROUP BY login_name
HAVING COUNT(*) > 10;
Query di atas deteksi user yang gagal login 10x dalam 1 jam terakhir. Biasanya tanda brute-force.
Langkah 2: Eskalasi ke Tim Tanggap Darurat Siber (CSIRT RS)
Struktur Tim CSIRT RS
- Ketua: IT Manager/Kepala Instalasi IT
- Anggota: Sysadmin, Programmer, Network Engineer, Wakil Manajemen
- PIC Pelaporan: Sekretaris/QA
Begitu indikasi kuat insiden, langsung aktifkan CSIRT. Eskalasi bertahap:
- Insiden kecil (laptop satu user): tangani lokal, log ke CSIRT, monitor.
- Insiden sistemik (server SIMRS, DB pusat, ransomware): ketua CSIRT aktif, segera lockdown, siapkan pelaporan eksternal.
Checklist Eskalasi
- Catat kronologi awal – siapa, kapan, sistem apa, gejala apa.
- Segera putus akses user terkait (disable user AD, cabut kabel network jika perlu).
- Aktifkan grup WhatsApp/Telegram Emergency IT RS, jangan lewat email/internet biasa.
- Kumpulkan log, screenshot, file sample (jangan hapus evidence!).
- Wajib rahasiakan insiden sebelum laporan resmi keluar.
Langkah 3: Pembatasan/Pemutusan Akses Sementara
Teknik Isolasi
- Unplug server terinfeksi dari LAN (cabut kabel fisik, matikan WiFi, shutdown VM infected).
- Disable account dicurigai terlibat (Active Directory, account DB, email internal).
- Blok IP sumber serangan di firewall/gateway, contoh iptables:
# Blokir IP penyerang di Linux
iptables -A INPUT -s 192.168.1.123 -j DROP
- Putuskan akses SIMRS dari luar (VPN, remote desktop, API ke BPJS/INHEALTH) sampai clear.
- Ganti password admin utama semua layanan kritis.
Catatan Penting
- Jangan buru-buru restore data sebelum analisa tuntas, biar bukti forensik aman buat audit.
- Pastikan user tetap bisa akses sistem esensial (IGD, ICU, rekam medis darurat) dengan mode manual/backup.
Langkah 4: Analisis Dampak & Kronologi
Poin Analisis Wajib
- Identifikasi sistem terdampak: server mana, aplikasi apa, data tabel mana.
- Estimasi data hilang/terkorupsi: ukuran file, jumlah record, tanggal backup terakhir.
- Cari tahu titik masuk serangan: via email, VPN, port terbuka, credential bocor.
- Mapping user/usergroup terdampak.
Contoh Struktur Tabel Kronologi Insiden
CREATE TABLE kronologi_insiden (
id INT PRIMARY KEY,
tgl_waktu DATETIME,
aktivitas VARCHAR(255),
user_terkait VARCHAR(100),
sistem_terdampak VARCHAR(100),
catatan TEXT
);
Entry contoh:
1 | 2024-05-20 07:35 | Login gagal berulang | user_bpjs | SIMRS | 15x gagal login, IP 10.10.10.13
2 | 2024-05-20 07:42 | File encrypted | sysadmin | DB Server | extension .locked muncul
Langkah 5: Pelaporan ke BSSN & Kemenkes
Syarat Pelaporan
- Insiden berdampak pada layanan publik (SIMRS down, data pasien bocor, ganggu pelayanan).
- Insiden terkait data pribadi pasien atau data critical RS (akses unauthorized, data leak, ransomware).
Format Laporan Insiden ke BSSN (Badan Siber dan Sandi Negara)
- Judul insiden (jenis, lokasi, waktu)
- Deskripsi singkat: kronologi, sistem terdampak, dampak pada pelayanan
- Langkah penanganan awal
- Data kontak PIC RS (nama, jabatan, kontak darurat)
- Bukti pendukung: log, screenshot, file sample (jangan lampirkan data pasien riil tanpa redaksi)
Lapor ke: incident@bssn.go.id (atau kanal CSIRT Sektor Kesehatan).
Format file: PDF, max 10MB, lampirkan dokumen pendukung zip bila perlu.
Format Laporan Insiden ke Kemenkes
- Template resmi dari Dirjen Yankes/PIK Kemenkes, biasanya via email/fax/portal pelaporan insiden TI kesehatan.
- Isi: kronologi, dampak, tindakan, status pemulihan, estimasi waktu normalisasi.
- Pelaporan wajib maksimal 3x24 jam sejak insiden terdeteksi. Keterlambatan dapat kena teguran.
Langkah 6: Remediasi & Pemulihan Data/Sistem
Langkah Remediasi
- Scan full malware/virus di semua endpoint (server, PC, storage) dengan EDR/antivirus yang update.
- Pastikan patch keamanan & OS aplikasi sudah update ke versi terbaru.
- Audit permission user, revoke akses yang tidak perlu/minimum privilege.
- Review konfigurasi firewall, tutup port non-standar/terbuka tanpa alasan.
- Restore data dari backup terakhir yang aman (pastikan file backup tidak ikut terinfeksi).
Contoh Prosedur Restore Database PostgreSQL
# Hentikan layanan aplikasi
systemctl stop simrs.service
# Restore DB dari backup .dump
pg_restore -U postgres -d simrs_db /backup/simrs_20240519.dump
# Start ulang layanan aplikasi
systemctl start simrs.service
Notes: Verifikasi integritas data setelah restore. Sampling 5-10 transaksi pasien terakhir, pastikan tidak ada mismatch/kehilangan data vital.
Dokumentasi & Rilis Internal/Eksternal
- Tulis laporan lengkap perjalanan insiden, dari awal deteksi sampai recovery.
- Rekomendasi pencegahan: training user, update SOP, simulasi insiden rutin tiap 6 bulan.
- Untuk internal, rilis ke semua unit: “Layanan SIMRS sudah normal, data per [tanggal] sudah diverifikasi.”
- Untuk eksternal (BSSN/Kemenkes): kirim update status pemulihan, lampirkan evaluasi, tindakan preventif ke depan.
Contoh Studi Kasus Insiden Siber RS
Studi Kasus: Ransomware Menyerang Server SIMRS
- 07:30 WIB: User IGD lapor tidak bisa akses hasil lab, SIMRS hang.
- 07:35 WIB: Sysadmin temukan database SIMRS file extension berubah jadi .locked, prompt ransom note muncul di desktop server.
- 07:40 WIB: Tim IT isolasi server, cabut kabel LAN, matikan VM.
- 07:45 WIB: Aktifkan CSIRT, lapor ke manajemen RS, mulai pengumpulan log & evidence.
- 08:00 WIB: Lapor awal via email ke incident@bssn.go.id dan PIK Kemenkes, format laporan singkat terlampir.
- 08:30 WIB: Analisa backup, temukan backup harian terakhir tanggal 06:00 WIB tidak terinfeksi.
- 09:00 WIB: Restore database dari backup, start ulang layanan, sampling data transaksi lab & IGD.
- 09:30 WIB: SIMRS up normal, rilis status ke seluruh unit, update laporan pemulihan ke Kemenkes/BSSN.
Snippet Kronologi Real
2024-05-20 07:30: User IGD lapor error akses lab
2024-05-20 07:35: Sysadmin deteksi file .locked, ransom note
2024-05-20 07:40: Server diisolasi fisik (cabut LAN)
2024-05-20 07:45: CSIRT aktif, evidence dikumpulkan
2024-05-20 08:00: Lapor awal ke BSSN, Kemenkes
2024-05-20 09:00: Restore DB dari backup, sampling validasi
2024-05-20 09:30: SIMRS normal, update unit & regulator
Checklist Pencegahan dan Penguatan SOP
- Backup otomatis, simpan offline/offsite, minimal 1x/hari.
- Pakai EDR/antivirus enterprise, update patch OS, matikan port/services tidak wajib.
- Audit user privilege, jangan pakai admin default di aplikasi/DB/OS.
- Simulasi insiden minimal 6 bulan sekali – latihan restore, pelaporan, lockdown access.
- Sosialisasi SOP insiden ke seluruh unit, tempelkan info kontak CSIRT di ruang kerja.
- Pastikan seluruh staff tau: “lapor insiden IT ke siapa, lewat apa, dan jangan panik hapus bukti”.
Download Template SOP Insiden Siber RS
- Format DOCX/PDF: SOP Penanganan Insiden Siber, form kronologi, form pelaporan BSSN/Kemenkes (akses di intranet RS atau hubungi IT Manager).
Penutup: Satu Insiden, Banyak Kepala
Insiden siber itu urusan semua lini, bukan cuma urusan IT RS. SOP jelas, pelaporan resmi, dan latihan bareng itu investasi biar Sobat IT RS nggak jadi kambing hitam pas audit. Pokok e, jangan nunggu kejadian baru cari template SOP. Siapin sekarang, tidur lebih nyenyak besok pagi.
PETIRS