Perancangan dan implementasi rencana keberlangsungan bisnis (BCP) dan pemulihan bencana (DRP) khusus untuk sistem industri. Meliputi Business Impact Analysis (BIA), penetapan RTO/RPO, strategi backup konfigurasi PLC, dan prosedur failover yang aman untuk infrastruktur kritis.
BCP (Business Continuity Plan) dan DRP (Disaster Recovery Plan) adalah dua dokumen berbeda namun saling melengkapi. Keduanya wajib dimiliki oleh operator infrastruktur kritis sesuai regulasi Indonesia (PP 82/2012 dan Perpres 82/2022).
| ASPEK | BCP — BUSINESS CONTINUITY PLAN | DRP — DISASTER RECOVERY PLAN |
|---|---|---|
| Fokus | Keberlangsungan operasi bisnis/layanan selama gangguan | Pemulihan sistem teknis (IT/OT) setelah bencana |
| Scope | Seluruh organisasi: proses, orang, fasilitas, komunikasi | Sistem teknologi: server, jaringan, SCADA, database |
| Pertanyaan utama | "Bagaimana layanan tetap berjalan saat sistem down?" | "Bagaimana sistem dipulihkan ke kondisi normal?" |
| Contoh aksi ICS | Jalankan proses manual (operator valve fisik), pengurangan kapasitas, komunikasi ke pelanggan | Restore SCADA dari backup, rebuild HMI, restore konfigurasi PLC |
| Waktu berlaku | Aktif saat insiden terjadi hingga sistem pulih | Aktif setelah keputusan disaster declaration hingga full restore |
| Owner | Plant Manager / COO / Business Continuity Manager | IT/OT Manager / Technical Recovery Team |
BIA adalah proses mengidentifikasi fungsi bisnis kritis dan menentukan dampak kuantitatif dari gangguan pada masing-masing fungsi. Hasil BIA menjadi dasar penetapan prioritas pemulihan dan investasi continuity.
Untuk ICS, BIA harus memasukkan dimensi yang tidak ada di IT biasa: dampak keselamatan, lingkungan, dan layanan publik — bukan hanya finansial.
MTPD = Maximum Tolerable Period of Disruption | RTO = Recovery Time Objective | RPO = Recovery Point Objective
RTO (Recovery Time Objective) adalah waktu maksimum yang dapat ditoleransi dari saat gangguan hingga sistem kembali beroperasi. RPO (Recovery Point Objective) adalah toleransi kehilangan data — berapa lama data yang boleh hilang.
Sistem SCADA infrastruktur kritis memiliki RTO yang sangat pendek karena proses fisik terus berjalan. Turbin PLTU tidak bisa "pause" menunggu sistem SCADA dipulihkan — operator harus beralih ke kontrol manual dalam menit, bukan jam. Ini berarti strategi recovery harus benar-benar dipersiapkan dan diuji, bukan hanya terdokumentasi.
| TIPE SISTEM OT | RTO TIPIKAL | RPO TIPIKAL | JUSTIFIKASI |
|---|---|---|---|
| Sistem kontrol safety (SIS/ESD) | ≤ 1 menit | 0 (no data loss) | Kegagalan SIS saat proses tidak aman = bencana |
| Kontrol proses utama (PLC/DCS) | ≤ 10 menit | ≤ 1 menit | Proses berlanjut di manual, tapi terbatas kapasitas |
| SCADA / HMI operator | ≤ 2 jam | ≤ 15 menit | Operator bisa kerja manual sementara |
| Historian / reporting | ≤ 8 jam | ≤ 1 jam | Dampak terbatas pada compliance dan analisis |
| Sistem bisnis (ERP, billing) | ≤ 24 jam | ≤ 4 jam | Tidak ada dampak operasional langsung |
Backup konfigurasi OT adalah fondasi DRP. Tanpa backup yang valid dan teruji, recovery tidak mungkin dilakukan dalam RTO yang ditetapkan. Backup OT mencakup lebih dari sekadar data — juga program PLC, konfigurasi HMI, dan parameter proses.
APA YANG HARUS DI-BACKUP (OT-SPECIFIC): PLC / RTU / IED: ✓ Program ladder logic / function block / structured text ✓ Data blocks (konfigurasi parameter, setpoint default) ✓ Hardware configuration (GSD, rack, module layout) ✓ Firmware version + hash (untuk deteksi modifikasi) ✓ IP address, node ID, Profibus address HMI / SCADA Server: ✓ Project file SCADA (WinCC, iFIX, Ignition, Wonderware) ✓ Tag database dan alarm configuration ✓ Graphic screens / faceplates ✓ User accounts dan RBAC configuration ✓ OS image (system state backup) — untuk rapid restore Jaringan OT: ✓ Konfigurasi firewall (rules, policies, objects) ✓ Switch configuration (VLAN, ACL, port config) ✓ Router / managed switch config ✓ Network diagram terkini (as-built) ATURAN BACKUP 3-2-1 (ADAPTASI UNTUK OT): 3 salinan backup (1 aktif + 2 backup) 2 media berbeda (HDD + USB terenkripsi / tape) 1 salinan offsite/offline — tidak terhubung ke jaringan OT +1 salinan immutable — tidak bisa diubah/dihapus (WORM media) JADWAL BACKUP YANG DIREKOMENDASIKAN: PLC program : Setiap kali ada perubahan program + bulanan otomatis SCADA project : Setiap kali ada perubahan + mingguan otomatis OS image HMI : Bulanan atau setelah patch/update mayor Konfigurasi jaringan: Setiap kali ada perubahan + mingguan Historian database : Harian (incremental) + bulanan (full) VERIFIKASI BACKUP (KRITIS!): ✓ Test restore ke environment lab setiap kuartal ✓ Hash verification setiap backup selesai ✓ Enkripsi backup (AES-256) — backup plaintext = risiko exfiltration ✓ Catat versi yang di-backup — jangan restore versi yang salah
Pemilihan strategi recovery site ditentukan oleh RTO yang ditetapkan dalam BIA. Semakin pendek RTO, semakin mahal biaya infrastruktur yang dibutuhkan.
Untuk sistem kontrol proses yang memerlukan RTO <15 menit, hot standby biasanya diimplementasikan dengan redundant PLC controller (misalnya Siemens S7-400H atau Schneider Quantum Hot Standby) yang berjalan dalam mode sinkron. Saat primary controller gagal, secondary mengambil alih dalam <1 scan cycle (~10ms) tanpa gangguan proses. Ini berbeda dari hot standby site-level yang membutuhkan failover menit-an.
Failover pada ICS harus dieksekusi dengan hati-hati. Berbeda dari IT, perpindahan traffic ke server backup bisa dilakukan transparan — di ICS, perpindahan kendali proses dari primary ke backup harus dikoordinasikan dengan operator dan divalidasi sebelum dan sesudah.
KONDISI: SCADA Primary Server gagal / dikompromis TARGET: Aktifkan Warm Standby dalam RTO 2 jam PRE-FAILOVER CHECKLIST: □ Konfirmasi Primary Server memang gagal (bukan false alarm) □ Notifikasi Plant Manager dan Safety Officer □ Pastikan semua operator tahu akan ada transisi HMI □ Pastikan proses dalam kondisi stabil sebelum switch □ Verifikasi backup terbaru tersedia di Warm Standby Server LANGKAH FAILOVER (harus dilakukan berurutan): T+0 — ISOLASI PRIMARY 1. Putus Primary Server dari jaringan OT (jika dikompromis) 2. Dokumentasikan waktu failover dimulai T+10 — RESTORE BACKUP KE WARM STANDBY 3. Restore SCADA project dari backup terakhir yang verified clean 4. Verifikasi hash backup sebelum restore 5. Restore user database dan RBAC config 6. Verifikasi koneksi ke PLC/RTU dari Warm Standby Server T+60 — VALIDASI SEBELUM GO-LIVE 7. Engineer OT verifikasi semua tag terhubung dan nilai benar 8. Uji alarm: trigger test alarm, pastikan muncul di HMI baru 9. Uji kontrol: kirim perintah test ke I/O non-kritis, verifikasi respons 10. Sign-off dari Plant Manager sebelum operator mulai gunakan T+90 — OPERASI DARI WARM STANDBY 11. Operator shift beralih ke HMI baru 12. Monitoring intensif 4 jam pertama 13. Catat semua anomali untuk investigasi YANG HARUS DIHINDARI: ✗ Restore backup tanpa verifikasi integritas (bisa restore malware) ✗ Go-live tanpa sign-off operator dan engineering ✗ Failover saat proses dalam kondisi tidak stabil
BCP/DRP yang tidak pernah diuji sama dengan tidak punya BCP/DRP. Dokumen yang bagus tidak berguna jika tim tidak pernah mempraktikkannya. Setidaknya satu kali setahun harus dilakukan exercise untuk setiap level kritis.
| TIPE EXERCISE | DESKRIPSI | PESERTA | FREKUENSI |
|---|---|---|---|
| Tabletop Exercise | Diskusi skenario di ruang rapat. Tim mendiskusikan respons terhadap skenario insiden tanpa aksi nyata. Murah dan efektif untuk mengidentifikasi gap prosedur. | Semua tim (IT, OT, Safety, Manajemen) | 2x per tahun |
| Walk-through Drill | Tim walkthrough setiap langkah prosedur secara verbal dan fisik — tanpa benar-benar mengeksekusi. Verifikasi bahwa prosedur masuk akal secara teknis. | Tim teknis OT + IT | 1x per tahun |
| Functional Exercise | Simulasi penuh di lab/test environment. Benar-benar eksekusi failover ke sistem backup di environment non-produksi untuk validasi teknis. | Tim IT + OT teknis | 1x per tahun |
| Full-scale Drill | Simulasi nyata di produksi — planned maintenance window. Benar-benar failover ke warm/cold standby, ukur RTO aktual vs target. | Semua tim + manajemen | 1x per 2 tahun |
SKENARIO: "OPERATION DARK GRID" Inject 1 (T=0): NOC menerima laporan: beberapa RTU substation tidak merespons. SIEM alert: multiple failed login ke SCADA server dari IP asing. → Pertanyaan: Langkah pertama? Siapa yang dihubungi? Triage severity? Inject 2 (T+20 menit): Konfirmasi: SCADA server terinfeksi ransomware. File SCADA di-encrypt. 2 unit pembangkit tidak bisa dikontrol dari SCADA. → Pertanyaan: Apakah BCP diaktifkan? Bagaimana komunikasi ke operator manual? Inject 3 (T+45 menit): Media memberitakan "sistem listrik Kota X terganggu." Pelanggan industri menelpon menanyakan kapan normal. → Pertanyaan: Siapa yang bicara ke media? Apa yang boleh diungkap? Inject 4 (T+2 jam): Tim berhasil restore SCADA dari backup ke warm standby server. Tapi backup berumur 6 jam — data setpoint terbaru hilang. → Pertanyaan: Bagaimana validasi setpoint sebelum kembali online? Siapa yang sign-off? PERTANYAAN EVALUASI AKHIR: 1. Berapa RTO aktual vs target? 2. Gap prosedur apa yang ditemukan? 3. Komunikasi mana yang tidak berjalan baik? 4. Apa yang perlu diperbaiki dalam BCP/DRP?