Mike Anderson

Posted on Jul 14

ICS Cybersecurity A–Z (Part 1): Architecting, Hardening, and Monitoring SCADA Safely

#cybersecurity #security #ics #iot

Walk into a water treatment plant control room and the first thing you notice is how calm everything looks.

The pumps are running. The HMI screens show tank levels, valve states, and chemical dosing. The operators know the process. The environment feels stable.

Then you look closer.

An engineering workstation has a shared password taped under the keyboard. A PLC web interface is reachable from the plant VLAN. A vendor VPN lands too close to the control network. The historian talks to business systems through a firewall rule nobody has reviewed in years.

That is the real world of Industrial Control Systems (ICS) security.

In enterprise IT, a bad security decision may create downtime, data loss, or account compromise. In OT, the same decision can affect water pressure, power distribution, chemical dosing, worker safety, environmental impact, and public trust.

This two-part series is written for security engineers, SOC analysts, cloud and infrastructure teams, and IT leaders who need to work with OT teams without breaking the plant.

Part 1 covers the foundation:

SCADA network placement
Purdue-level segmentation
Remote access and vendor access
HMI, server, PLC, and RTU hardening
OT monitoring and detection
Safe vulnerability assessment
Common configuration failures

Part 2 covers operations, incident response, large-scale attack preparation, threat modeling, and leadership metrics.

Assumption: the environment is a production ICS/SCADA network supporting critical infrastructure such as water, power, manufacturing, utilities, or similar process-control operations. Adjust the details for your sector, vendor stack, safety case, and regulatory obligations.

The OT security rule that matters most

In OT, the first question is not:

"Can we secure this?"

The first question is:

"Can we secure this without creating unsafe process behavior?"

That changes the order of operations.

For normal IT, you may patch aggressively, scan broadly, isolate hosts quickly, or force password resets at scale.

For ICS, those actions can break HMI-to-PLC communication, trigger a failsafe, overload a fragile controller, lock out an operator, or interrupt a process that must remain stable.

So the decision rule is:

Preserve safety and control first. Reduce cyber risk through planned, tested, reversible controls.

That does not mean OT should remain insecure. It means the controls must be engineered, not blindly applied.

1. Start with the architecture: where SCADA should live

Before you harden a device or deploy a monitoring tool, you need a network model that defines trust boundaries.

The common reference model is the Purdue Enterprise Reference Architecture. It is not perfect for every modern environment, especially where cloud historians, remote operations, and IIoT platforms are involved, but it remains useful because it separates business IT from control functions.

A practical Purdue-style model looks like this:

Level 5  Enterprise services
         Email, ERP, internet, business applications

Level 4  Business IT
         User workstations, identity, reporting, corporate applications

Level 3.5 OT DMZ
         Historian replication, patch staging, remote access broker,
         file transfer gateway, jump access mediation

Level 3  Site operations
         SCADA servers, engineering workstations, local historians,
         domain services for OT where used

Level 2  Supervisory control
         HMIs, operator stations, local control rooms

Level 1  Basic control
         PLCs, RTUs, IEDs, controllers, intelligent actuators

Level 0  Physical process
         Sensors, pumps, valves, breakers, motors, field equipment

The architecture should enforce three principles.

Principle 1: Enterprise IT must not directly reach controllers

Nothing from Level 4 or Level 5 should directly communicate with PLCs, RTUs, IEDs, or safety controllers.

A ransomware infection on a finance laptop should not be able to discover Modbus, DNP3, EtherNet/IP, S7, or IEC 61850 devices.

Principle 2: Shared services belong in the OT DMZ

The OT DMZ is the controlled exchange zone.

Use it for:

Historian replication
Patch staging
Antivirus or EDR update staging
Secure file transfer
Remote access brokering
Jump host mediation
Log forwarding
Time synchronization relay where appropriate

Do not use it as a flat bridge between IT and OT.

Principle 3: Control commands should only come from authorized control paths

Telemetry can move upward when required. Control commands must be restricted downward to approved systems, approved users, approved ports, and approved operating procedures.

A good design does not only say "firewall between IT and OT." It defines exactly which asset can talk to which asset, on which protocol, for what business reason, with which owner and evidence.

2. Segmentation that actually reduces risk

Segmentation fails when it exists on a diagram but not in enforcement.

The minimum practical design is:

Minimum segmentation design

Enterprise to OT DMZ

Enforcement point: firewall, proxy, or remote access broker.
Allowed flow: corporate analyst reads replicated historian data.
Block: direct RDP, SMB, SSH, database, or PLC protocol access into OT.

OT DMZ to Level 3

Enforcement point: firewall with explicit allow rules.
Allowed flow: patch server pulls approved updates from DMZ staging.
Block: any inbound enterprise-initiated session to SCADA servers.

Level 3 to Level 2

Enforcement point: internal OT firewall or ACL.
Allowed flow: SCADA server communicates with HMIs and local services.
Block: direct workstation-to-HMI access from unrelated zones.

Level 2 to Level 1

Enforcement point: cell/area firewall or industrial switch ACL.
Allowed flow: HMI or SCADA server polls assigned PLCs.
Block: cross-cell traffic, unauthorized engineering access, and broad broadcast exposure.

Vendor access to OT

Enforcement point: VPN, MFA, jump host, and approval workflow.
Allowed flow: vendor connects to one approved engineering workstation during a change window.
Block: direct VPN landing inside Level 2 or Level 1.

A firewall rule should read like an operational decision, not a convenience setting.

Example:

Source:      SCADA-SRV-01
Destination: PLC-WTP-CLARIFIER-01
Protocol:    Modbus TCP/502
Direction:   SCADA to PLC only
Purpose:     Poll clarifier process values
Owner:       OT Operations
Review:      Quarterly
Logging:     Session metadata enabled

Bad rule:

Source:      Any
Destination: OT network
Protocol:    Any
Purpose:     Vendor support

That second rule is not a firewall exception. It is an attack path.

3. Remote access and vendor access

Remote access is one of the highest-risk paths into OT because it combines identity risk, unmanaged endpoints, third-party dependencies, and time pressure during outages.

For production ICS, vendor access should follow this model:

Vendor user
  -> MFA-authenticated remote access portal
  -> Approved time-bound session
  -> Recorded jump host
  -> Named target asset only
  -> OT engineer supervision for high-risk changes

Minimum controls:

MFA for all remote access.
No shared vendor accounts.
Time-bound access approved through a ticket.
Session recording for privileged remote access.
Vendor source restrictions where feasible.
No split tunneling for privileged OT access.
No direct VPN route to PLC, RTU, or HMI networks.
Disable access when the support contract ends.
Review vendor accounts at least monthly.
Keep emergency break-glass access documented and tested.

The key risk is not only that a vendor account may be compromised. The bigger risk is that the vendor access path may bypass the segmentation you carefully designed.

4. Harden systems without treating OT like office IT

Hardening should reduce attack surface without breaking vendor support or process stability.

That requires three things:

A tested baseline.
A rollback plan.
OT owner approval.

Windows HMIs and engineering workstations

Most SCADA front ends and engineering tools still run on Windows. They should not be managed like standard office laptops.

Practical controls:

Use application allowlisting where possible. AppLocker, Windows Defender Application Control, or a vendor-supported allowlisting tool is better than relying only on antivirus.
Remove unnecessary local admin access. Operators should not run daily sessions as administrators.
Use unique local administrator passwords. Microsoft LAPS or a controlled equivalent is preferred where domain-joined management is available.
Disable unnecessary services after vendor validation. Common review candidates include Print Spooler, Remote Registry, unused file sharing, unused web services, and unmanaged PowerShell remoting.
Restrict RDP to jump hosts only. Block direct RDP from enterprise networks.
Control USB usage. Block mass storage by default, allow approved devices only through documented procedure.
Enable Windows Firewall with explicit inbound rules.
Forward security logs to a central collector or SIEM.
Keep golden images for HMI and engineering workstation recovery.

Useful Windows event sources include:

Logon/logoff events: detect unusual operator, engineer, or vendor access.
Account management events: detect new users, group changes, and privilege changes.
Service creation events: detect persistence and unauthorized tooling.
PowerShell logs, where enabled safely: detect script-based administration or abuse.
RDP session logs: validate jump host and remote access policy.
Application installation logs: detect unauthorized software on HMIs.

Linux SCADA, historian, or middleware servers

For Linux-based systems:

Remove unused packages and services.
Disable password SSH and root SSH where operationally feasible.
Restrict SSH to the jump host or management subnet.
Use host firewall rules to allow only required service ports.
Mount temporary paths with safer options where compatible with the application.
Forward authentication and system logs to the central collector.
Monitor service restarts and unexpected listening ports.
Keep system backups and configuration exports.

Example host firewall intent:

Allow SSH only from OT-JUMP-01.
Allow application port only from approved SCADA/HMI systems.
Deny all other inbound traffic.
Log denied management attempts.

The exact command syntax depends on the distribution and change process. The control intent matters more than copying a command from the internet.

PLCs, RTUs, and controllers

Controllers are often the most sensitive assets. Treat changes carefully.

Minimum hardening actions:

Disable unused services such as HTTP, FTP, Telnet, SNMP, or vendor discovery services where not required.
Restrict programming access to approved engineering workstations.
Use controller access control lists where supported.
Change default passwords.
Use firmware supported by the vendor and validated in a lab or maintenance window.
Protect physical ports, cabinet access, and serial interfaces.
Keep offline backups of logic, configuration, and firmware versions.
Record checksums or vendor-equivalent integrity evidence for controller logic.
Document which controller owns which physical process.

The most important question for PLC hardening is:

"Who can change logic, from where, under what approval, and how would we know?"

If you cannot answer that, you do not have control of the control system.

5. Monitor what matters in OT

OT monitoring is not only about malware signatures. It is about understanding normal process communication and detecting changes that should not happen.

You need visibility across four areas.

Minimum visibility areas

Network traffic

Telemetry: NetFlow, PCAP, Zeek logs, and industrial protocol metadata.
Why it matters: detects new devices, unusual protocol use, and unauthorized writes.

Host activity

Telemetry: Windows/Linux logs, OT-safe EDR telemetry, and service changes.
Why it matters: detects compromised HMIs, engineering workstations, and servers.

Controller state

Telemetry: logic changes, firmware changes, diagnostic buffers, and mode changes.
Why it matters: detects unauthorized control-layer modification.

Identity and remote access

Telemetry: VPN logs, jump host logs, MFA events, and privileged sessions.
Why it matters: detects compromised accounts and vendor access misuse.

Network monitoring

Passive monitoring is usually the safest starting point.

Use a SPAN port, network TAP, or packet broker to send traffic to an OT-aware sensor. Tools may include Zeek, Security Onion, Suricata, Nozomi, Dragos, Claroty, Forescout, Microsoft Defender for IoT, or similar platforms.

The tool is less important than the use cases.

Good OT detections include:

New device in a control cell: unknown MAC/IP communicating on an OT VLAN. This may indicate a rogue laptop, vendor device, or attacker foothold.
Unauthorized PLC write: write function from a non-engineering source. This may indicate process manipulation.
PLC mode change: run, stop, or program mode change outside a change window. This may indicate unsafe or unauthorized activity.
New engineering workstation behavior: engineering protocol traffic from an unusual host. This may indicate a compromised IT asset or unauthorized tool.
Vendor login outside an approved window: remote session outside the ticketed time. This may indicate account abuse.
Protocol crossing the wrong boundary: Modbus, DNP3, S7, or similar protocol traffic from the DMZ or enterprise network. This indicates segmentation failure.
Firmware or logic change: controller reports updated logic or firmware. This is an integrity event requiring validation.

A useful detection statement looks like this:

Alert when any non-approved engineering workstation sends write-capable industrial protocol traffic to Level 1 devices outside an approved change window.

That is stronger than saying "monitor PLCs."

It defines the source, destination, behavior, and context.

Honeypots and deception

A low-risk deception control can work well in OT if it is carefully isolated.

For example, a Conpot-style ICS honeypot can sit in a monitored network segment where no legitimate device should communicate with it.

Rules:

Do not connect the honeypot to the live control path.
Do not emulate a real production controller name that could confuse operators.
Alert on any connection attempt.
Treat interaction as high-confidence reconnaissance or lateral movement.
Document the honeypot in the asset inventory so internal teams do not mistake it for a real controller.

6. Assess vulnerabilities without creating an outage

Vulnerability assessment in ICS must follow a safety ladder.

Do not start with aggressive scanning.

Step 1: Passive assessment

Start by collecting traffic and configuration data without sending packets to controllers.

Good sources:

SPAN/TAP packet captures
Firewall rules
Switch MAC address tables
Asset inventory
Engineering workstation project files
PLC configuration exports
Vendor firmware inventories
Remote access logs
Historian connection lists

Output:

Asset list
Protocol map
Known vendor/model inventory
Network flows
Exposed services
Unsupported firmware
Default credential candidates
Unknown devices

Step 2: Configuration review

Review device and network configurations offline.

Look for:

Default credentials
Shared accounts
Insecure SNMP communities
PLC web interfaces enabled without need
Open RDP/VNC/SSH
Broad firewall rules
Any-to-any vendor access
Unused services
Lack of time synchronization
Missing backup evidence
No logic-change approval trail

Step 3: Controlled active testing

Active testing requires written OT approval.

Minimum conditions:

Approved maintenance window or lab environment.
Named target IPs only.
Low-rate scanning profile.
OT engineer present or on bridge.
Backup and rollback confirmed.
Safety impact reviewed.
Stop conditions agreed in advance.
Test evidence retained.

A cautious discovery command for a single approved test asset might look like this:

# Example only: use only for an approved test target and approved window.
nmap -sT -Pn -n --scan-delay 1s --max-retries 1 -p 22,80,443,502,102,44818 <approved-test-ip>

Do not run broad default IT vulnerability scans against live PLCs or controllers.

Step 4: Penetration testing

ICS penetration testing should start in a lab that mirrors the production configuration.

For production testing:

Scope must be narrow.
Exploit testing must be explicitly approved.
Denial-of-service testing should remain in the lab unless there is an exceptional, formally accepted reason.
Safety and operations must own the stop/go decision.
Engineering backups must be verified before testing.
Testers must understand the process impact, not only the protocol.

The point of ICS testing is not to "prove we can break it." It is to validate whether a realistic attack path can affect operations and whether the organization can detect, contain, and recover safely.

7. Common configuration failures

Here are the issues I see most often in real OT environments.

Common failures and required fixes

Flat IT/OT network

Real risk: malware or attacker movement from enterprise into control systems.
Required fix: segment by Purdue level and process cell; enforce firewall rules.

Dual-homed engineering workstation

Real risk: bypasses the IT/OT boundary.
Required fix: remove dual-homing or place a controlled firewall/proxy path between networks.

Direct vendor VPN into OT

Real risk: third-party compromise becomes OT compromise.
Required fix: use MFA, jump host, time-bound approval, recording, and named destinations.

PLC web interface left enabled

Real risk: reconnaissance, credential attack, or controller instability.
Required fix: disable unless operationally required; restrict source IPs.

Default or shared credentials

Real risk: trivial unauthorized access and no accountability.
Required fix: use unique accounts, password vaulting, and MFA where supported.

Unauthenticated write-capable protocols

Real risk: unauthorized process change.
Required fix: restrict sources, segment, monitor writes, and upgrade to secure variants where possible.

No controller logic backup

Real risk: slow or impossible recovery after compromise.
Required fix: maintain offline, tested backups and version records.

No time synchronization

Real risk: logs cannot support investigation.
Required fix: use a local OT time source and validate clock drift.

No internal segmentation

Real risk: one compromised HMI exposes the whole plant.
Required fix: segment by cell/area and apply least-traffic rules.

No evidence of change approval

Real risk: cannot prove integrity or accountability.
Required fix: use formal OT change records and retain exports/checksums.

8. Evidence pack for audit and operations

Good OT security leaves evidence.

For Part 1 controls, keep:

Current network diagrams with trust boundaries.
Firewall rule exports with owners and business justification.
Asset inventory with owner, location, role, firmware, and criticality.
Remote access policy and access logs.
Vendor access approvals and session records.
HMI/server hardening baseline.
PLC/RTU configuration and logic backup evidence.
SIEM or monitoring ingestion proof.
Detection catalog mapped to OT use cases.
Vulnerability assessment scope, approval, results, and remediation plan.
Exception register with expiry dates and compensating controls.

If you cannot produce evidence, the control may exist technically but it is not operationally mature.

9. What good looks like

A defensible ICS environment does not need to be perfect. It needs to be controlled.

Good looks like this:

You know every critical asset and what process it supports.
Enterprise users cannot directly reach controllers.
Vendor access is time-bound, monitored, and approved.
Engineering workstations are controlled and logged.
PLC logic changes require approval and leave evidence.
OT traffic is passively monitored.
Unauthorized write behavior is detectable.
Backups are offline and tested.
Active scanning is controlled and approved.
Exceptions are visible, owned, and temporary.

That is a strong foundation.

In Part 2, we move from architecture to operations: how to run the program, respond to incidents without causing harm, prepare for large-scale campaigns, use MITRE ATT&CK for ICS, and report risk to leadership.

DEV Community