Metodologi penanganan insiden siber pada sistem ICS: dari deteksi awal, containment yang aman, eradikasi, hingga pemulihan. Ditambah teknik forensik digital khusus OT — pengumpulan bukti dari PLC, HMI, dan jaringan tanpa mengganggu proses industri yang berjalan.
Incident Response pada ICS berbeda secara mendasar dari IT karena memiliki dimensi fisik dan keselamatan. Respon yang salah — misalnya mematikan sistem secara tiba-tiba — bisa lebih berbahaya dari insiden itu sendiri.
| ASPEK | INSIDEN IT BIASA | INSIDEN ICS/SCADA |
|---|---|---|
| Dampak utama | Data loss, reputasi, finansial | Kecelakaan fisik, cedera/kematian, kerusakan permanen |
| Shutdown sistem | Aman dilakukan untuk isolasi | BERBAHAYA — bisa picu kondisi tak aman di proses fisik |
| Preserve vs Contain | Isolasi cepat = prioritas | Keselamatan proses = prioritas > isolasi |
| Waktu respons | Jam hingga hari masih tolerabel | Menit — proses terus berjalan, attacker aktif |
| Komunikasi | IT team saja | IT + OT Engineer + Safety Officer + Plant Manager + Regulator |
| Evidence collection | Bisa shutdown untuk forensik | Forensik LIVE — sistem tidak boleh dimatikan |
Insiden ICS diklasifikasikan berdasarkan dampak terhadap proses fisik, bukan hanya dampak data:
NIST SP 800-61 mendefinisikan 4 fase IR. Untuk ICS, setiap fase memiliki pertimbangan tambahan yang tidak ada di IT biasa — terutama keselamatan proses dan kontinuitas operasi.
PREPARATION (SEBELUM INSIDEN): ▸ IRP terdokumentasi dan diuji setahun sekali (tabletop exercise) ▸ Tim IR OT terlatih: OT Engineer, IT Security, Safety Officer, Plant Mgr ▸ Kontak vendor PLC/SCADA tersedia 24/7 (hotline Siemens, Schneider, dll) ▸ Backup konfigurasi PLC/RTU terbaru tersedia offline ▸ Network baseline tersedia (normal traffic profile dari Nozomi/Claroty) ▸ Jumper/bypass plan: cara isolasi sistem tanpa hentikan proses fisik ▸ Koordinasi: BSSN (National), ID-SIRTII/CC (sektoral), vendor SCADA DETECTION INDICATORS (OT-SPECIFIC): 🔴 PLC behavior anomaly: register berubah tanpa perintah dari HMI 🔴 Firmware PLC berbeda dari baseline (hash mismatch) 🔴 Traffic OT ke IP/domain yang tidak dikenal 🔴 Engineering workstation menghubungi C2 server 🟡 Login ke SCADA di luar jam kerja atau dari IP tidak biasa 🟡 Setpoint diubah di luar prosedur normal 🟡 Alarm rate spike tidak terkait perubahan proses 🟡 Antivirus/AWL alert di HMI workstation
Triage adalah proses menentukan tingkat keparahan insiden secepat mungkin agar respons yang tepat dapat diambil. Untuk ICS, triage harus segera menjawab: "Apakah proses fisik dalam bahaya sekarang?"
PERTANYAAN TRIAGE (dalam urutan prioritas): Q1: Apakah proses fisik dalam kondisi tidak aman SEKARANG? ├── YA → EMERGENCY SHUTDOWN prosedural + hubungi Safety Officer SEGERA └── TIDAK → Lanjut Q2 Q2: Apakah attacker masih aktif di sistem (live intrusion)? ├── YA → Containment HATI-HATI: isolasi lateral, jangan matikan PLC └── TIDAK → Lanjut Q3 (forensik) Q3: Apakah integritas PLC/RTU/firmware masih terjaga? ├── TIDAK (firmware modified) → KRITIS: restore dari backup tervalidasi └── YA → Lanjut Q4 Q4: Apakah scope insiden meluas ke OT atau terbatas di IT? ├── OT → Aktifkan full ICS-IR team + vendor + regulator └── IT → Tangani dengan IR prosedur IT standar SEVERITY CLASSIFICATION (ICS-CERT Model): EMERGENCY : Safety risk AKTIF / attacker kontrol proses sekarang CRITICAL : Sistem kontrol kritis terkompromis / proses terpengaruh HIGH : Akses tidak sah ke OT tapi proses belum terpengaruh MEDIUM : Insiden di IT dengan potensi pivot ke OT LOW : Anomali / suspicious event, belum konfirmasi insiden
Di IT, respons standar adalah "isolasi dulu, tanya kemudian." Di ICS, ini bisa fatal. Sebelum isolasi jaringan OT: (1) Pastikan semua proses dalam kondisi aman atau sudah di-hold; (2) Koordinasi dengan operator dan Safety Officer; (3) Siapkan mode manual backup. Memutus komunikasi HMI-PLC tiba-tiba saat proses berjalan dapat menyebabkan kondisi tak terkendali.
Containment bertujuan membatasi penyebaran insiden tanpa menyebabkan kerusakan lebih lanjut. Untuk ICS, "containment" tidak sama dengan "shutdown" — ada serangkaian teknik berlapis yang lebih aman.
LEVEL 1 — NETWORK CONTAINMENT (risiko rendah ke proses): ✓ Blokir IP attacker di firewall OT (jika diketahui) — TANPA putus komunikasi HMI-PLC ✓ Isolasi segmen jaringan yang terinfeksi di IT — cegah lateral ke OT ✓ Revoke VPN credential yang dikompromis — putus remote access attacker ✓ Aktifkan monitoring intensif di semua boundary IT/OT ✓ Block DNS/C2 outbound di firewall (jika ada koneksi ke C2) LEVEL 2 — CREDENTIAL RESET (setelah konfirmasi scope): ✓ Ganti password semua akun SCADA yang mungkin dikompromis ✓ Revoke sertifikat yang mungkin dicuri ✓ Reset MFA token semua user yang terdampak ✓ Disable akun engineering yang tidak sedang digunakan LEVEL 3 — DEVICE ISOLATION (hanya jika proses aman untuk di-hold): ✓ Switch proses ke mode manual/local di PLC (bypass SCADA) ✓ Isolasi HMI yang terinfeksi dari jaringan OT ✓ Pastikan backup operator control tersedia (panel lokal, manual valve) YANG TIDAK BOLEH DILAKUKAN SAAT CONTAINMENT ICS: ✗ Matikan PLC tiba-tiba saat proses sedang berjalan ✗ Putus koneksi HMI-PLC tanpa koordinasi operator ✗ Jalankan antivirus scan agresif di HMI saat proses aktif ✗ Reboot engineering workstation yang sedang download PLC program
Forensik ICS hampir selalu live forensics — mengumpulkan bukti dari sistem yang masih berjalan tanpa mematikannya. Ini berbeda dari forensik IT di mana mesin sering dimatikan sebelum imaging.
LANGKAH 1: DOKUMENTASI STATUS AWAL ▸ Screenshot/foto semua layar HMI sebelum disentuh ▸ Catat: timestamp server, versi firmware PLC, status alarm ▸ Foto kondisi fisik ruang server/control room LANGKAH 2: VOLATILE DATA COLLECTION (LIVE — PLC TETAP JALAN) # Export konfigurasi dan program PLC (via engineering software) $ simatic_s7_backup --plc 192.168.10.51 --output plc-a-$(date +%Y%m%d).s7d $ md5sum plc-a-*.s7d # Hash untuk chain of custody # Bandingkan dengan baseline yang tersimpan $ diff plc-a-baseline.s7d plc-a-20240315.s7d # Jika berbeda → kemungkinan program PLC telah dimodifikasi! # Network capture (pasif — SPAN port) $ tcpdump -i eth1 -w ot-capture-$(date +%Y%m%d%H%M).pcap $ sha256sum ot-capture-*.pcap # Hash setiap capture file LANGKAH 3: HMI FORENSIK (LIVE) # Export event log dari WinCC / iFIX / Ignition # Export Windows Event Log PS> wevtutil epl Security C:\forensics\security-$(Get-Date -f yyyyMMdd).evtx PS> wevtutil epl System C:\forensics\system-$(Get-Date -f yyyyMMdd).evtx # RAM capture (jika tools tersedia) PS> winpmem_mini.exe C:\forensics\ram-dump.dmp PS> Get-FileHash C:\forensics\*.* -Algorithm SHA256 # Hash semua LANGKAH 4: NETWORK FORENSIK # Export log dari OT IDS (Nozomi/Claroty) ▸ Download alert events dalam rentang waktu insiden ▸ Export full PCAP untuk periode T-24jam hingga T+1jam insiden ▸ Export asset change log (jika ada device baru/firmware berubah)
Forensik ICS membutuhkan pengumpulan bukti dari berbagai layer — dari log sistem operasi HMI hingga data process historian yang merekam setiap perubahan nilai sensor.
Tim NOC PLTU 350 MW menerima alert dari SIEM pada pukul 22:47 — login ke SCADA server dari IP 192.168.20.99 (IP tidak dikenal) gagal 7 kali, lalu berhasil pada percobaan ke-8. Berikut respons yang dilakukan.