7.1Firewall untuk Lingkungan OT — Karakteristik dan Jenis
Firewall OT memiliki persyaratan yang berbeda dari firewall IT. Selain filtering paket standar, firewall OT harus memahami protokol industrial seperti Modbus, DNP3, EtherNet/IP, dan IEC 61850 untuk dapat memfilter di level konten pesan.
⚠ MENGAPA FIREWALL IT BIASA TIDAK CUKUP UNTUK OT
- Firewall IT biasa hanya mengerti IP/TCP/UDP — tidak bisa memfilter Function Code Modbus (tidak bisa membedakan "baca data" vs "tulis perintah berbahaya")
- Firewall IT biasa tidak mengerti koneksi EtherNet/IP Implicit yang digunakan PLC
- Firewall IT biasa tidak bisa mendeteksi anomali pada traffic OT yang terlihat normal secara IP
- High-availability requirement OT: firewall tidak boleh menambah latency signifikan
Evolusi Firewall untuk OT
| GENERASI | KEMAMPUAN | COCOK UNTUK OT | CONTOH PRODUK |
|---|---|---|---|
| Packet Filter (Generasi 1) |
Filter berdasarkan IP, port, protokol (TCP/UDP). Stateless. | ❌ Terbatas | iptables, ACL pada router |
| Stateful Firewall (Generasi 2) |
Melacak state koneksi TCP. Memahami sesi. | ⚠ Minimal | Cisco ASA, Fortigate dasar |
| Next-Gen Firewall (NGFW) (Generasi 3) |
Deep Packet Inspection, App-ID, User-ID, Threat Intel integration | ✓ Baik | Palo Alto, Fortigate, Check Point |
| Industrial NGFW (OT-Specific) |
DPI untuk Modbus, DNP3, EtherNet/IP, IEC 61850. OT anomaly detection. Rugged hardware. | ✓✓ Terbaik | Fortinet FortiGate Rugged, Cisco IR1101, Tofino Xenon |
Deep Packet Inspection (DPI) untuk Protokol OT
DPI MODBUS — FUNCTION CODE FILTERING
// Firewall OT dengan DPI dapat memfilter hingga level Function Code Modbus // Ini adalah kemampuan yang TIDAK dimiliki firewall IT biasa RULE SET — MODBUS TCP FILTERING (Fortinet FortiGate Industrial): RULE 10: PERMIT Src:HMI(192.168.20.10) Dst:PLC-A(192.168.10.51) Port:502 Modbus FC:01,02,03,04 # Izinkan READ saja dari HMI Action: ALLOW + LOG RULE 20: PERMIT Src:EngWS(192.168.20.20) Dst:PLC-A(192.168.10.51) Port:502 Modbus FC:01-16 # Engineering WS boleh READ dan WRITE Schedule: Mon-Fri 08:00-17:00 # Hanya jam kerja! Action: ALLOW + LOG + ALERT RULE 30: DENY Src:ANY Dst:PLC-A(192.168.10.51) Port:502 Modbus FC:05,06,15,16 # BLOKIR semua WRITE dari source lain Action: DENY + ALERT + LOG RULE 99: DENY Src:ANY Dst:ANY Port:502 Action: DENY + LOG # Default deny Modbus // Tanpa DPI: firewall hanya bisa permit/deny port 502 secara keseluruhan // Dengan DPI: bisa membedakan FC03 (baca aman) vs FC06 (tulis berbahaya)
7.2Aturan Firewall Praktis — OT Firewall Rule Design
Desain rule firewall OT harus mengikuti prinsip whitelist (default-deny): semua traffic diblokir kecuali yang secara eksplisit diizinkan. Ini berkebalikan dengan pendekatan blacklist yang hanya memblokir yang diketahui buruk.
📌 PRINSIP WHITELIST vs BLACKLIST DALAM FIREWALL OT
Blacklist (Default-Allow): Izinkan semua kecuali yang diketahui berbahaya. Masalah: kita tidak bisa tahu semua hal berbahaya. Attacker dengan teknik baru akan lolos.
Whitelist (Default-Deny): Blokir semua kecuali yang secara eksplisit diizinkan. Lebih aman karena hanya komunikasi yang dikenal yang diizinkan. Cocok untuk OT di mana komunikasi sangat terstruktur dan dapat diprediksi.
Contoh rule set lengkap untuk firewall antara DMZ dan OT Zone pada sistem SCADA pembangkit listrik:
#SOURCEDESTINATIONPORT/PROTOACTIONLOG
001
JumpSrv(DMZ)
HMI-WS
TCP:3389 RDP
PERMIT
YES+ALERT
002
SCADA-SRV
Historian(DMZ)
TCP:5450 PI
PERMIT
YES
003
PatchSrv(DMZ)
HMI-WS
TCP:8530 WSUS
PERMIT
YES
010
HMI-WS
PLC-A,B,C
TCP:502 Modbus
PERMIT
YES
011
SCADA-SRV
PLC-A,B,C
TCP:502 Modbus
PERMIT
YES
020
EngWS
PLC-A,B,C
TCP:44818 EIP
PERMIT
YES+ALERT
090
IT Network
OT Network
ANY
DENY
YES+ALERT
099
ANY
ANY
ANY
DENY
YES
⚠ KESALAHAN UMUM DALAM FIREWALL RULES OT
- "ANY ANY PERMIT" — Rule terlalu permisif yang sering dibuat saat troubleshooting tapi tidak pernah dihapus
- Tidak ada log/alert — DENY tanpa log tidak memberikan visibilitas insiden
- Rule berlebihan yang tumpang tindih — Firewall diprogram puluhan tahun oleh berbagai orang, menghasilkan rule yang berkonflik
- Tidak ada review berkala — Rule yang sudah tidak relevan dibiarkan, memperluas attack surface
7.3IDS/IPS di Jaringan OT — Deteksi Intrusi yang Aman
IDS/IPS di lingkungan OT memiliki pertimbangan khusus: IPS inline yang agresif dapat menyebabkan packet loss dan mengganggu kontrol real-time. Pendekatan yang direkomendasikan adalah dimulai dengan passive IDS (monitoring saja, tanpa block).
| ASPEK | IDS PASIF (RECOMMENDED OT) | IPS INLINE |
|---|---|---|
| Posisi | TAP atau SPAN port — tidak dalam jalur traffic | Inline — semua traffic melewatinya |
| Dampak ke Proses | Nol — kegagalan IDS tidak mempengaruhi OT | Signifikan — jika IPS crash, traffic bisa terputus |
| Aksi saat Deteksi | Alert dan log saja | Alert, log, dan block/drop packet |
| False Positive Risk | Rendah — hanya alert, tidak memblokir | Tinggi — false positive = memblokir traffic sah = gangguan proses |
| Rekomendasi OT | ✓ Mulai dengan ini selalu | Hanya setelah tuning dan validasi panjang di OT |
Metode Deteksi pada OT IDS
METODE DETEKSI IDS OT
1. SIGNATURE-BASED DETECTION: Mencocokkan traffic dengan pola serangan yang diketahui (CVE database). Kelebihan: Akurat untuk serangan diketahui, false positive rendah Kelemahan: Tidak bisa deteksi zero-day atau serangan baru Contoh signature: Modbus FC=16 ke address yang tidak biasa diakses 2. ANOMALY/BEHAVIORAL DETECTION: Membangun baseline traffic normal OT, deteksi penyimpangan. Kelebihan: Bisa deteksi serangan baru yang belum ada signature-nya Kelemahan: False positive lebih tinggi (perlu tuning) Contoh anomali: - Komunikasi dari device yang tidak pernah ada sebelumnya - HMI mengirim Modbus WRITE (biasanya hanya baca) - Volume traffic OT spike 10x dari baseline - PLC-A berkomunikasi dengan PLC-B (tidak pernah terjadi sebelumnya) 3. PROTOCOL VIOLATION DETECTION: Mendeteksi paket yang melanggar spesifikasi protokol resmi. Contoh: Modbus dengan Function Code yang tidak didukung PLC target DNP3 dengan Application Layer Confirmation yang tidak semestinya 4. ASSET DISCOVERY & PROFILING: Bukan "deteksi" tapi "inventarisasi" — membangun peta semua device OT. Manfaat: Mendeteksi device baru yang tidak dikenal (rogue device)
7.4Platform Monitoring dan Deteksi OT Terkemuka
Sejumlah vendor menyediakan platform khusus untuk monitoring dan deteksi ancaman pada jaringan OT/ICS yang memahami protokol industrial secara native.
ASSET VISIBILITY & THREAT DETECTION
Claroty Platform
Platform komprehensif: asset discovery, vulnerability management, network monitoring, threat detection untuk OT/ICS/IoT. Deployment pasif via SPAN port.
OT NATIVE
OT THREAT INTELLIGENCE
Dragos Platform
Fokus pada threat intelligence khusus ICS. Memiliki database kelompok APT yang menarget ICS (ELECTRUM, KAMACITE, dll). Termasuk incident response OT.
OT NATIVE
CONTINUOUS MONITORING
Nozomi Networks
Real-time monitoring OT/IoT. Deteksi anomali berbasis AI. Integrasi dengan SIEM dan SOAR. Tersedia varian cloud dan on-premise.
OT NATIVE
PASSIVE MONITORING
Tenable OT Security
Vulnerability management untuk OT. Aktif dan pasif scanning. Plugin khusus untuk PLC, RTU, IED dari berbagai vendor.
IT + OT
OPEN SOURCE IDS
Zeek (Bro) + OT Plugins
Framework analisis jaringan open-source dengan plugin Modbus, DNP3, EtherNet/IP. Cocok untuk organisasi dengan budget terbatas.
OPEN SOURCE
SIEM OT INTEGRATION
Splunk + OT Add-ons
SIEM terkemuka dengan add-on khusus OT. Korelasi event IT dan OT dalam satu platform. Dashboards untuk SOC yang monitor keduanya.
IT + OT
ℹ️ PASSIVE MONITORING — CARA DEPLOYMENT TANPA RISIKO
Semua platform monitoring OT di atas mendukung passive deployment via SPAN port atau TAP. Traffic dimonitor tanpa menyentuh jalur komunikasi aktif:
- SPAN Port (Switch Port Analyzer): Switch mengkopi semua traffic dari port tertentu ke port monitoring. Tidak membutuhkan hardware tambahan tapi mengonsumsi resource switch.
- Network TAP (Test Access Point): Perangkat hardware yang disisipkan pada kabel jaringan, mengkopi traffic secara pasif. Lebih andal dari SPAN, tidak mengonsumsi resource switch.
- Sensor IDS ditempatkan di posisi strategis: di antara OT firewall dan core switch OT, mendapat visibilitas penuh tanpa risiko gangguan
7.5VPN dan Remote Access Aman untuk Sistem SCADA
Remote access ke sistem SCADA untuk maintenance vendor atau monitoring jarak jauh harus diimplementasikan dengan sangat hati-hati. Setiap akses remote adalah potensi vektor serangan jika tidak diamankan dengan benar.
SITE-TO-SITE VPN
IPSec Tunnel antar Site
Menghubungkan dua site (main site dan DR site, atau dua pabrik) secara permanen via tunnel terenkripsi. Semua traffic antara dua site mengalir melalui tunnel. Cocok untuk: Koneksi tetap antar lokasi yang saling terpercaya.
CLIENT VPN (REMOTE ACCESS)
SSL/TLS VPN + MFA
Vendor atau engineer terhubung dari luar ke Jump Server di DMZ via VPN. Wajib gunakan MFA. Session dibatasi waktu. Semua aktivitas direkam. Cocok untuk: Vendor maintenance jarak jauh yang tidak rutin.
CELLULAR OT VPN
4G/5G Private APN
RTU/PLC di lokasi terpencil terhubung via SIM card industrial dengan APN privat. Traffic langsung ke OT network tanpa melewati internet publik. Cocok untuk: RTU pada PLTA terpencil, pompa pipeline di gunung.
SATELLITE BACKUP
VSAT / Starlink OT
Koneksi backup saat link utama putus. Latency tinggi (600ms+) untuk VSAT, rendah untuk Starlink (~20ms). Cocok untuk: Backup komunikasi untuk RTU sangat terpencil, DRP connectivity.
Checklist Remote Access OT yang Aman
SECURE REMOTE ACCESS — BEST PRACTICE CHECKLIST
AUTENTIKASI: [✓] Multi-Factor Authentication (MFA) wajib untuk semua user remote [✓] Password policy: minimal 12 karakter, complexity, rotate 90 hari [✓] Tidak ada shared account — setiap user punya credential unik [✓] Certificate-based auth untuk site-to-site VPN AKSES KONTROL: [✓] Jump Server / Bastion Host — WAJIB sebagai intermediate step [✓] Role-based: vendor A hanya bisa akses PLC-A, bukan seluruh OT [✓] Waktu akses dibatasi (time-based access control) [✓] Session recording — semua aktivitas remote direkam (screen + keylog) [✓] Session timeout otomatis setelah idle 15 menit MONITORING: [✓] Alert real-time saat ada koneksi VPN baru dari luar [✓] Notifikasi ke admin saat vendor login [✓] Log semua perintah yang dikirim ke PLC/HMI dari sesi remote [✓] Review log sesi remote secara periodik ENDPOINT VENDOR: [✓] Device vendor harus memenuhi minimum security posture [✓] Scan antimalware sebelum koneksi (NAC — Network Access Control) [✗] Vendor menggunakan PC pribadi tanpa enkripsi disk — RISIKO TINGGI [✗] Koneksi TeamViewer/AnyDesk langsung ke HMI tanpa jump server
7.6Application Whitelisting — Pertahanan Endpoint Terkuat
Application Whitelisting (AWL) adalah pendekatan keamanan endpoint di mana hanya software yang ada dalam daftar putih (whitelist) yang boleh dieksekusi. Semua software lain — termasuk malware baru — langsung diblokir secara default.
📌 MENGAPA AWL SANGAT COCOK UNTUK HMI/SCADA WORKSTATION
HMI dan Engineering Workstation pada sistem SCADA memiliki karakteristik yang ideal untuk AWL:
- Software set statis — Set aplikasi yang berjalan di HMI sangat kecil dan tidak berubah: SCADA client, OS, driver. Mudah di-whitelist.
- Tidak untuk browsing internet — Berbeda dari PC kantor yang perlu banyak software dinamis
- Legacy OS umum — Windows XP/7 yang tidak bisa di-patch masih bisa dilindungi AWL meskipun tidak bisa antivirus update
- Rekomendasi NIST SP 800-82 dan IEC 62443 — Keduanya merekomendasikan AWL sebagai kontrol kunci untuk HMI
◈ CONTOH APPLICATION WHITELIST — HMI WORKSTATION SCADA ◈
WinCC_HMI.exe
SHA256: a3f8c2...d91e
ALLOWED
FactoryTalk_View.exe
SHA256: 7b2d44...cc03
ALLOWED
explorer.exe (Windows Shell)
SHA256: 9e10f3...ab77
ALLOWED
svchost.exe (Windows Service)
SHA256: verified Microsoft
ALLOWED
mimikatz.exe
SHA256: 4d9e11...f200
BLOCKED + ALERT
chrome.exe (tidak diizinkan di HMI)
SHA256: valid Google binary
BLOCKED
scada_update_v2.exe (tidak dikenal)
SHA256: tidak ada di whitelist
BLOCKED + ALERT
| PRODUK AWL | FITUR UTAMA | COCOK UNTUK |
|---|---|---|
| Carbon Black App Control | Hash-based dan path-based whitelisting, memory protection, legacy OS support | HMI Windows XP/7/10, Engineering WS |
| Trend Micro Safe Lock | Ringan, dirancang khusus untuk SCADA/kiosk, tidak butuh update definisi rutin | HMI industrial yang resource-constrained |
| McAfee Application Control | Integrasi dengan ePO, centralized management, change control workflow | Enterprise deployment multi-site |
| Windows Defender Application Control (WDAC) | Built-in Windows 10/11, gratis, policy berbasis publisher certificate | HMI Windows modern, hemat biaya |
7.7Studi Kasus: Implementasi Keamanan Jaringan OT di PDAM
📋 SKENARIO: PEDAM TIRTA KOTA — UPGRADE KEAMANAN JARINGAN OT
PDAM Tirta Kota dengan 3 WTP dan jaringan distribusi yang dikendalikan SCADA memutuskan untuk melakukan upgrade keamanan jaringan OT setelah audit menemukan banyak kerentanan.
KONDISI SEBELUM vs SESUDAH IMPLEMENTASI
KONDISI SEBELUM (BASELINE — BURUK): ✗ Tidak ada pemisahan IT/OT — satu flat network ✗ TeamViewer diinstal di setiap HMI untuk akses vendor ✗ Semua HMI memakai password sama: "admin123" ✗ USB port terbuka — karyawan charge HP di PC HMI ✗ Tidak ada log dan monitoring apapun ✗ Windows XP masih berjalan di 3 dari 5 HMI ✗ Tidak ada antivirus karena "bisa crash SCADA" IMPLEMENTASI BERTAHAP (6 BULAN): BULAN 1–2: ✓ Pasang firewall IT/OT (Fortinet FortiGate 60F) ✓ Pisahkan jaringan menjadi: IT VLAN, DMZ VLAN, OT VLAN ✓ Ganti semua password default — unik per device ✓ Disable USB port pada semua PC HMI (BIOS lock + Group Policy) ✓ Uninstall TeamViewer, ganti dengan Jump Server di DMZ BULAN 3–4: ✓ Deploy Nozomi Networks passive sensor (SPAN port di OT switch core) ✓ Pasang VPN SSL dengan MFA (Fortinet FortiClient + FortiToken) ✓ Implementasi Application Whitelisting (Trend Micro Safe Lock) di semua HMI ✓ Setup log aggregation ke SIEM (Splunk Light) BULAN 5–6: ✓ Training security awareness untuk semua operator ✓ Prosedur Incident Response OT didokumentasikan ✓ Vulnerability assessment — temukan 12 kerentanan, 8 sudah ditangani ✓ Simulasi insiden pertama berhasil dideteksi sistem KONDISI SESUDAH — HASIL TERUKUR: Attack Surface: Turun 85% (dari flat network ke segmented) Visibility : 100% asset OT teridentifikasi (sebelumnya 0%) MTTR Insiden: 4 jam → 45 menit (dengan runbook baru) Compliance : Memenuhi 70% kontrol NIST SP 800-82
✓Latihan Soal — Sesi 7
■ PERTANYAAN 1 / 5
1. Mengapa Industrial Next-Generation Firewall lebih cocok untuk OT dibandingkan firewall IT biasa dalam konteks keamanan Modbus TCP?
A Industrial NGFW lebih murah dan lebih cepat dari firewall IT biasa
B Industrial NGFW dapat melakukan Deep Packet Inspection pada protokol OT, seperti memfilter Modbus Function Code tertentu (misal: izinkan baca FC03 tapi blokir tulis FC06)
C Industrial NGFW dapat mengenkripsi Modbus TCP otomatis
D Firewall IT biasa tidak bisa bekerja pada jaringan OT sama sekali
✓ Benar! Deep Packet Inspection (DPI) pada Industrial NGFW memungkinkan pemfilteran sampai ke level konten pesan OT. Untuk Modbus: bisa izinkan FC01-04 (read) dari HMI tapi blokir FC05,06,15,16 (write) dari source yang tidak berwenang. Firewall IT biasa hanya bisa permit/deny berdasarkan port TCP:502, tidak bisa membedakan jenis perintah Modbus.
■ PERTANYAAN 2 / 5
2. Mengapa IDS Pasif (via SPAN/TAP) lebih direkomendasikan daripada IPS Inline sebagai langkah pertama keamanan jaringan OT?
A IDS Pasif lebih murah dari IPS Inline
B IDS Pasif tidak berada di jalur traffic — kegagalan atau false positive IDS tidak akan mengganggu komunikasi OT yang kritis, berbeda dengan IPS Inline yang jika bermasalah bisa memutus kontrol proses
C IDS Pasif dapat memblokir serangan lebih efektif dari IPS Inline
D IPS Inline tidak kompatibel dengan jaringan industrial
✓ Benar! Di lingkungan OT, memblokir traffic yang salah terdeteksi (false positive) bisa menyebabkan PLC kehilangan perintah, sensor data terputus, atau proses industri berhenti tiba-tiba. IDS Pasif via SPAN/TAP hanya memonitor tanpa menyentuh traffic aktif — jika IDS crash, OT tetap berjalan normal. Ini adalah pendekatan "do no harm" untuk lingkungan safety-critical.
■ PERTANYAAN 3 / 5
3. Standar minimum keamanan yang WAJIB ada saat mengizinkan vendor maintenance melakukan remote access ke sistem SCADA adalah...
A Cukup dengan username dan password yang kuat
B Multi-Factor Authentication (MFA) + Jump Server/Bastion Host + session recording + time-limited access
C VPN saja sudah cukup tanpa MFA jika password-nya panjang
D Tidak perlu keamanan khusus jika vendor sudah terpercaya dan berpengalaman
✓ Benar! Insiden Oldsmar (2021) terjadi karena remote access hanya dilindungi TeamViewer tanpa MFA. Standar minimum remote access OT: (1) MFA wajib — bahkan jika credential dicuri, attacker butuh faktor kedua; (2) Jump Server di DMZ — vendor tidak langsung masuk ke OT; (3) Session recording — audit trail; (4) Time-limited — akses berakhir otomatis setelah sesi maintenance selesai.
■ PERTANYAAN 4 / 5
4. Application Whitelisting pada HMI SCADA bekerja dengan prinsip...
A Memblokir software yang sudah diketahui berbahaya berdasarkan signature database
B Hanya mengizinkan software yang ada dalam daftar putih (whitelist) untuk dieksekusi — semua yang tidak ada dalam daftar, termasuk malware baru, diblokir secara default
C Memantau perilaku aplikasi dan menghentikan yang mencurigakan
D Mengenkripsi semua aplikasi SCADA agar tidak bisa dimodifikasi
✓ Benar! AWL menggunakan pendekatan "default-deny" untuk eksekusi aplikasi. Berbeda dengan antivirus yang hanya memblokir yang diketahui buruk (blacklist), AWL memblokir SEMUA kecuali yang ada di whitelist — bahkan malware zero-day yang belum ada signature-nya. Sangat cocok untuk HMI yang software-set-nya statis dan tidak berubah-ubah.
■ PERTANYAAN 5 / 5
5. Dalam desain firewall rule untuk OT, prinsip "default-deny" berarti...
A Secara default, semua traffic dari IT ke OT diizinkan kecuali ada rule yang memblokir
B Secara default, semua traffic diblokir kecuali yang secara eksplisit tercantum dalam rule PERMIT
C Password default semua device harus diubah menjadi deny
D Firewall menolak koneksi yang timeout secara default
✓ Benar! Default-deny (atau whitelist approach pada firewall) berarti rule terakhir selalu "DENY ALL" — semua traffic yang tidak cocok dengan rule PERMIT di atasnya akan diblokir. Ini adalah prinsip paling aman karena attacker harus menemukan "lubang" dalam rule permit yang ada, bukan hanya menghindari rule deny yang ada. Berlawanan dengan default-allow yang hanya memblokir yang diketahui jahat.