Evolusi protokol komunikasi industrial menuju keamanan modern. Meliputi Modbus TCP over TLS, DNP3 Secure Authentication v5, OPC UA Security modes, standar IEC 62351, dan implementasi PKI (Public Key Infrastructure) untuk ekosistem ICS.
Protokol industri paling luas digunakan — Modbus, DNP3, IEC 60870-5 — dirancang era 1970–1990an untuk keandalan dan kecepatan, bukan keamanan. Hasilnya: tidak ada autentikasi, enkripsi, maupun otorisasi.
Lebih dari 70% instalasi SCADA sektor energi Indonesia masih menggunakan Modbus TCP atau DNP3 tanpa enkripsi. Alasan: biaya penggantian hardware, risiko downtime, dan kurangnya tenaga ahli ICS security. Pendekatan pragmatis: migrasi bertahap, prioritas sistem paling kritis.
TLS wrapper mengamankan transport layer Modbus TCP tanpa mengubah payload-nya. Payload Modbus tetap sama — TLS membungkusnya dengan enkripsi dan autentikasi. Didefinisikan dalam RFC 8455 pada port 802.
MODBUS TCP BIASA (Port 502): Client → Server: [Modbus Request FC03 — PLAINTEXT] Server → Client: [Modbus Response data — PLAINTEXT] // Siapapun di network: sniff data, inject perintah FC06 WRITE MODBUS TCP OVER TLS (Port 802, RFC 8455): // Fase 1: TLS 1.3 Mutual Handshake Client → Server: ClientHello + certificate Server → Client: ServerHello + certificate + Finished // Identitas kedua pihak terverifikasi via X.509 // Fase 2: Modbus dalam tunnel TLS terenkripsi Client → Server: [TLS Encrypted: Modbus FC03 Request] Server → Client: [TLS Encrypted: Modbus Response] MANFAAT: ✓ Enkripsi — traffic tidak bisa di-sniff ✓ Autentikasi — hanya client dengan cert valid yang bisa konek ✓ Integrity — paket yang dimodifikasi terdeteksi ✓ Tidak perlu ubah PLC firmware (bisa via gateway/proxy) KETERBATASAN: ✗ Overhead TLS handshake (+1-5ms latency) — perhatikan real-time req ✗ Masih tidak ada otorisasi level Function Code ✗ PLC lama tidak support TLS natively → butuh TLS proxy/gateway ARSITEKTUR TLS PROXY (untuk PLC lama): HMI ──(Modbus/TLS:802)──▶ TLS PROXY ──(Modbus TCP:502)──▶ PLC [terenkripsi] │ [plaintext — LAN lokal] [Decrypt, forward, re-encrypt response] Produk: Hirschmann EAGLE Tofino, Ewon Flexy, stunnel+iptables
DNP3 SAv5 menambah autentikasi kriptografis HMAC-SHA256 pada DNP3 tanpa mengubah payload atau mengganti hardware. Mekanisme challenge-response memastikan perintah hanya diterima dari master yang sah.
MASALAH DNP3 STANDAR: Master → RTU: "Control Output DO-05 = ON" — siapapun bisa kirim ini // MitM bisa inject perintah palsu, tidak ada cara RTU memverifikasi DNP3 SAv5 — UNTUK OPERASI KRITIS: Step 1: RTU mengeluarkan Challenge RTU → Master: Challenge (4-byte random nonce) Step 2: Master membuktikan identitas via HMAC Master → RTU: Challenge Reply = HMAC-SHA256( Key = Session Key (turunan dari Update Key), Data = {Challenge Nonce + Message Content} ) Step 3: RTU verifikasi — jika cocok, eksekusi perintah RTU → Master: Auth OK — Command Executed KEY HIERARCHY: Update Key : Jangka panjang — dikonfigurasi saat instalasi/maintenance Session Key : Sementara — diturunkan dari Update Key per sesi Key Wrap : AES-256 Key Wrap (RFC 3394) untuk distribusi session key aman OBJEK DNP3 BARU (Group 120-122): Group 120: Authentication (challenge, reply, aggressive mode) Group 121: Security Statistics Group 122: Security Events (audit log per event auth)
| FITUR | DNP3 STANDAR | DNP3 SAv5 |
|---|---|---|
| Autentikasi | ✗ Tidak ada | ✓ HMAC-SHA256/SHA3-256 |
| Enkripsi traffic | ✗ Plaintext | ✗ Masih plaintext |
| Integrity kriptografis | CRC dasar saja | ✓ HMAC per pesan |
| Replay attack prevention | ✗ Tidak ada | ✓ Challenge nonce |
| Backward compatible | N/A | ✓ Bisa dinonaktifkan per device |
| Standar referensi | IEEE 1815-2012 | IEEE 1815-2012 Clause 7&8 |
DNP3 SAv5 hanya menambah autentikasi — traffic masih plaintext. Untuk enkripsi penuh, kombinasikan dengan TLS tunnel per IEC 62351-5. Ini krusial untuk koneksi WAN antar substation yang melewati jaringan publik.
OPC UA (IEC 62541) dikembangkan dari nol dengan keamanan sebagai fondasi. Tiga Security Modes dapat dikonfigurasi sesuai kebutuhan dan posisi dalam arsitektur jaringan.
OPC UA SERVER (Kepware/Unified Automation): Security Policy : Basic256Sha256 (AES-256-CBC + SHA-256) Message Security Mode: SignAndEncrypt Authentication : Certificate (X.509 mutual TLS) Trusted Certs : [HMI-A.der, SCADA-SRV.der, ENG-WS.der] OPC UA CLIENT (HMI/SCADA Server): Server URL : opc.tcp://192.168.10.200:4840 Security Mode : SignAndEncrypt Client Cert : HMI-CLIENT.pem Private Key : HMI-CLIENT-KEY.pem (simpan di HSM jika tersedia) Server Cert : OPC-SERVER.der (certificate pinning) CIPHER SUITES YANG DIREKOMENDASIKAN (IEC 62541-6): ✓ Basic256Sha256 : RSA-2048/4096, AES-256-CBC, SHA-256 ✓ Aes128Sha256RsaOaep: RSA-2048, AES-128-CTR, SHA-256 ✗ Basic128Rsa15 : DEPRECATED — SHA-1 lemah ✗ Basic256 : DEPRECATED — SHA-1 untuk signing
IEC 62351 adalah seri standar internasional yang mendefinisikan keamanan untuk protokol komunikasi di sistem tenaga listrik — "menambal" keamanan pada protokol yang sudah ada tanpa harus mengganti semua hardware.
| BAGIAN | JUDUL | PROTOKOL YANG DIAMANKAN |
|---|---|---|
| IEC 62351-3 | TCP/IP Profiles | Semua protokol IEC berbasis TCP — menggunakan TLS 1.2/1.3 |
| IEC 62351-4 | MMS Profiles | MMS (IEC 61850 manufacturing message) |
| IEC 62351-5 | IEC 60870-5 & DNP3 | IEC 60870-5-101/104, DNP3 — challenge-response auth |
| IEC 62351-6 | IEC 61850 Profiles | GOOSE, Sampled Values (SV) di substation automation |
| IEC 62351-8 | Role-Based Access Control | RBAC model standar untuk semua protokol IEC |
| IEC 62351-9 | Key Management | Distribusi dan manajemen kunci kriptografi ICS |
IEC 62351-5 sangat relevan karena IEC 60870-5-104 dan DNP3 banyak digunakan di SCADA distribusi PLN. Standar ini mendefinisikan: challenge-response HMAC-SHA256 untuk autentikasi perintah kritis, TLS tunnel untuk enkripsi koneksi WAN, dan key management untuk update kunci secara aman. BSSN merekomendasikan infrastruktur ketenagalistrikan kritis untuk mulai mengadopsi IEC 62351.
PKI adalah fondasi kriptografi OPC UA dan protokol aman ICS lainnya. PKI menyediakan mekanisme untuk menerbitkan, mendistribusikan, dan memvalidasi sertifikat X.509 yang menjadi identitas digital setiap device.
# 1. Buat Root CA (OFFLINE, simpan di HSM) $ openssl genrsa -aes256 -out root-ca.key 4096 $ openssl req -x509 -new -key root-ca.key -sha256 -days 3650 \ -out root-ca.crt -subj "/CN=ICS-Root-CA/O=Perusahaan/C=ID" # 2. Buat Intermediate CA (untuk penerbitan cert sehari-hari) $ openssl genrsa -out intermediate-ca.key 4096 $ openssl req -new -key intermediate-ca.key -out int-ca.csr \ -subj "/CN=ICS-Intermediate-CA/O=Perusahaan" $ openssl x509 -req -in int-ca.csr -CA root-ca.crt -CAkey root-ca.key \ -CAcreateserial -out intermediate-ca.crt -days 1825 # 3. Terbitkan cert untuk OPC UA Server $ openssl genrsa -out opcua-server.key 2048 $ openssl req -new -key opcua-server.key -out server.csr \ -subj "/CN=SCADA-SERVER-01/O=Perusahaan" $ openssl x509 -req -in server.csr -CA intermediate-ca.crt \ -CAkey intermediate-ca.key -out opcua-server.crt -days 730 # 4. Verifikasi chain of trust $ openssl verify -CAfile root-ca.crt -untrusted intermediate-ca.crt opcua-server.crt opcua-server.crt: OK ← chain valid
Migrasi dari protokol legacy ke protokol aman harus dilakukan secara bertahap. Tidak ada "big bang" migration di ICS — setiap perubahan harus divalidasi di lab sebelum produksi.