SCADA and ICS Security Assessment Best Practices for Safe Continuous Monitoring
A security assessment in an industrial control system cannot behave like an enterprise IT scan. A plant network is tied to pumps, breakers, turbines, conveyors, furnaces, dosing systems, and safety interlocks. A noisy test that is routine in an office network can interrupt a controller, overload a fragile HMI, or trigger alarms that operators have to treat as real.
That is why SCADA and ICS security assessment work must start with one principle: protect the process first. The aim is to understand exposure, weaknesses, and risk without putting production, safety, quality, or availability at stake.
For SCADA, DCS, PLC, and HMI environments, the safest assessments are planned, passive by default, and closely coordinated with operations. They combine engineering knowledge with cyber security methods, then turn findings into practical risk reduction rather than long lists of technical flaws.
Start with the operating context
Before assessing devices, understand what the system does. This includes the physical process, safety constraints, production schedules, maintenance windows, and operator procedures.
A useful assessment starts with questions such as:
Which processes are critical to safety, environment, or production?
Which PLCs, RTUs, DCS controllers, and HMIs support those processes?
Which systems can tolerate passive monitoring only?
Which links cross zones, plants, vendor networks, or remote sites?
Which alarms or events would force an operator response?
Which assets are old, unsupported, or difficult to replace?
This context helps classify risk correctly. A vulnerable Windows service on an engineering workstation matters, but a misconfigured remote access path to a safety-adjacent system may matter more. A missing patch on a non-critical historian may be lower priority than an unknown device on a controller network.
Use recognised guidance as a reference point, not as a rigid checklist. IEC 62443 gives a strong model for zones, conduits, security levels, and system lifecycle controls. NIST SP 800-82 is widely used for ICS security guidance. The MITRE ATT&CK for ICS framework helps teams map tactics and techniques seen against industrial environments.
The best assessment scope separates systems into clear groups:
Asset group | Typical assessment focus | Safe method |
SCADA servers | User access, hardening, patch status, logging, remote access | Credential review, configuration review, passive monitoring |
DCS controllers | Network exposure, engineering access, change control | Vendor-supported review, offline configuration checks |
PLCs and RTUs | Logic integrity, firmware, protocol exposure, backups | Passive discovery, backup comparison, controlled vendor checks |
HMIs | Operating system security, shared accounts, malware exposure | Local review, EDR status checks, patch review |
Historians | Data flow, trust relationships, domain connections | Network path review, log analysis |
Engineering workstations | Project files, programming tools, privileges, removable media | Endpoint review, access audit, malware controls |
Build an accurate asset inventory without disrupting operations
Many ICS risks remain hidden because the asset inventory is incomplete. Unknown PLCs, unmanaged switches, forgotten remote access devices, legacy HMIs, and temporary engineering laptops can create real exposure.
In industrial networks, passive asset discovery is usually the safest starting point. Instead of probing devices directly, passive monitoring observes traffic from a network tap, mirror port, or packet broker. It can identify IP addresses, MAC addresses, protocols, firmware hints, device roles, communication pairs, and normal traffic patterns.
Common ICS protocols such as Modbus TCP, DNP3, IEC 60870-5-104, EtherNet/IP, PROFINET, OPC UA, and vendor-specific protocols can reveal useful information when monitored carefully. Even when the tool cannot interpret every protocol, it can show which systems communicate and how often.
Good inventory records include:
Asset name and process function
Device type and vendor
Firmware or operating system where known
Network address and zone
Communication partners
Criticality rating
Owner and support vendor
Backup status
Patch and lifecycle status
Remote access dependency
Last verified date
Avoid treating the first inventory as final. Industrial sites often have seasonal equipment, standby systems, temporary skids, and vendor-managed devices. Keep the inventory alive through change management and continuous monitoring.
Use passive techniques before active testing
Active scanning has a place, but it must be controlled. Some older PLCs, HMIs, embedded devices, serial gateways, and protocol converters react badly to unexpected packets. A scan that checks thousands of ports may cause latency, dropped communications, or device faults.
A safer assessment sequence is:
Review architecture and documents
Start with network diagrams, asset lists, firewall rules, remote access records, backup procedures, and prior incident reports.
Observe traffic passively
Build baselines for normal communications. Identify protocols, talking pairs, broadcast traffic, external connections, and unusual devices.
Review configurations offline
Examine firewall rules, switch configurations, PLC project backups, HMI project files, historian settings, and Windows local policies outside the live process path where possible.
Validate findings with operations
Ask engineering and operations teams to confirm whether observed traffic and devices are expected.
Plan any active checks
If active checks are needed, test them in a lab first, seek vendor guidance for sensitive assets, and run them during an approved window.
Monitor during the test
Watch process alarms, network latency, device CPU where available, controller communication status, and operator feedback.
Tools for passive and low-impact assessment include packet capture and protocol analysis tools such as Wireshark, Zeek, and Suricata, along with ICS-focused monitoring platforms from vendors such as Dragos, Nozomi Networks, Claroty, and Tenable.ot. These tools can support asset discovery, protocol analysis, vulnerability mapping, and anomaly detection.
Active tools such as Nmap or vulnerability scanners should be used with care. If they are used at all, restrict target ranges, ports, timing, and scripts. Disable aggressive checks. Do not scan controller networks casually. Test scanning profiles on comparable equipment before using them near production.
The rule is simple: if a test could change state, increase load, or trigger an unsafe response, it needs formal approval and a safe window.
Assess network segmentation and trust paths
Segmentation is one of the main controls that protect ICS environments. A well-segmented network limits how far an attacker, malware outbreak, or misconfigured system can move.
Start by mapping zones and conduits. Typical zones include enterprise IT, demilitarised zones, operations management, SCADA servers, DCS control networks, PLC networks, safety system zones, vendor access zones, and wireless or remote telemetry segments.
Assess these areas:
Firewall rules between IT and OT
Access from enterprise domain controllers to OT systems
Remote desktop and jump server paths
Engineering workstation access to PLCs and controllers
Vendor VPN accounts and access approvals
Historian connections across security zones
Wireless bridges, cellular routers, and radio networks
Flat Layer 2 networks with wide broadcast domains
Default routes from controllers or HMIs
Unused switch ports and unmanaged network devices
A common risk pattern is a flat OT network where HMIs, engineering workstations, controllers, historians, and vendor laptops all share broad access. Another is a historian or file transfer server that quietly acts as a bridge between corporate and control networks.
Segmentation assessment should produce a clear trust map. Show who can talk to what, using which protocol, and for what business reason. Then remove unnecessary paths or apply tighter controls.
Useful improvements include:
Dedicated jump hosts for OT administration
Multi-factor authentication for remote access
Allow-list firewall rules between zones
Separate engineering workstations for high-criticality systems
Deny-by-default vendor access
Strict logging for privileged sessions
Controlled file transfer mechanisms between IT and OT
Review identity, remote access, and engineering change control
Many ICS incidents involve weak access control rather than advanced techniques. Shared HMI accounts, local administrator reuse, old vendor credentials, and unmanaged remote access create high-impact exposure.
Assess account practices across SCADA servers, HMIs, engineering workstations, historians, domain services, vendor portals, and network devices. Review whether staff use named accounts, whether privileged access is limited, and whether inactive accounts are disabled.
Pay close attention to engineering access. If an attacker can modify PLC logic, download a DCS configuration, or change HMI graphics, cyber risk becomes process risk.
Key checks include:
Who can edit PLC or DCS logic
Whether controller program changes are logged
Whether project files are backed up and access controlled
Whether online edits require approval
Whether vendor access is time-bound and recorded
Whether removable media is controlled before use on engineering stations
Whether emergency accounts are sealed, monitored, and reviewed
For PLC and DCS logic, comparison against known-good backups is a safe and valuable technique. It can identify unexpected changes without touching the running controller. If online validation is required, use vendor-supported tools and involve control engineers who understand the process impact.
Identify vulnerabilities with context, not just CVSS scores
Vulnerability management in ICS needs context. A high CVSS issue on an isolated asset may pose less practical risk than a medium-rated weakness on a system reachable from a vendor VPN. Availability, safety, exploitability, and compensating controls all matter.
Use several techniques together:
Technique | What it finds | Why it is safe |
Passive vulnerability matching | Known device and software weaknesses based on observed versions | No direct probing required |
Configuration review | Weak services, default settings, poor firewall rules | Uses backups or read-only access |
Patch and lifecycle review | Unsupported operating systems, firmware, and applications | Based on records and safe checks |
Log analysis | Failed access, unusual services, remote sessions | Uses existing records |
Backup comparison | Unexpected PLC or HMI project changes | Can be performed offline |
Architecture review | Excessive trust, weak segmentation, unsafe remote access | No production traffic impact |
Physical inspection | Unauthorised devices, open ports, uncontrolled cabinets | No network impact |
Do not focus only on missing patches. Many industrial systems cannot be patched quickly because of vendor certification, uptime needs, or process validation requirements. In those cases, risk treatment may include isolation, firewall restrictions, application control, monitoring, backup improvement, or removal of unnecessary services.
Vulnerability findings should state:
Affected asset and process function
Business and safety impact
Evidence
Likely attack path
Existing controls
Recommended treatment
Operational impact of remediation
Owner and target date
This makes the output useful for both engineering and security teams.
Protect availability during the assessment
Safe assessment work depends on planning and control. Treat testing like a change to the industrial environment, even when no change is expected.
Use these practices before any technical activity:
Define the scope and out-of-scope systems
Classify systems by safety and production criticality
Agree stop conditions with operations
Confirm maintenance windows where needed
Notify control room staff before monitoring or testing
Prepare a rollback plan for any configuration change
Keep vendor support contacts available for sensitive systems
Record exact timing of tests for alarm correlation
Use read-only credentials where possible
Avoid testing during start-up, shutdown, batch transition, or peak load
During the assessment, keep a live communication path open with operations. If alarms appear, traffic changes unexpectedly, or device performance degrades, pause immediately.
A mature assessment team also maintains a test register. It records the tool, target, method, approval, start time, end time, observer, and outcome. This helps distinguish assessment activity from real incidents and gives the site a reliable audit trail.
Add continuous monitoring after the assessment
A point-in-time assessment is useful, but ICS risk changes over time. New vendor access, firmware updates, temporary connections, replacement HMIs, and emergency changes can all alter the security posture.
Continuous monitoring helps detect change early. It should cover:
New or missing assets
New communication paths
Unauthorised remote access
Protocol changes
Controller program changes
HMI server changes
Failed logins and privilege use
Malware alerts on Windows-based systems
Firewall rule changes
Backup failures
Time synchronisation issues
Network latency or abnormal traffic volume
Monitoring should fit the plant. Too many alerts will be ignored. Start with high-value detections, then tune them with operations input. For example, a vendor connection during an approved maintenance window may be normal. The same connection at night from an unknown source should raise concern.
Continuous monitoring also supports incident response. When a site has a baseline of normal control traffic, it can separate routine engineering actions from suspicious changes much faster.
Turn assessment findings into risk management
An assessment has limited value unless it changes decisions. The final report should not be a raw export from a scanner. It should explain risk in operational terms.
A strong risk register groups findings by process impact and treatment path. Some issues need immediate action. Others need planning, budget, vendor coordination, or shutdown time.
Common risk treatment options include:
Remove unnecessary connectivity
Restrict access through firewalls and jump hosts
Replace shared accounts with named accounts
Add multi-factor authentication for remote access
Improve backups and recovery testing
Apply security patches during planned outages
Disable unused services
Improve logging and time synchronisation
Isolate unsupported systems
Add application control on HMIs and engineering stations
Improve removable media controls
Review vendor contracts for security requirements
Use risk acceptance carefully. If a legacy controller cannot be patched, document why, define compensating controls, and set a review date. Do not let accepted risk become forgotten risk.
What a safe assessment should deliver
A well-run SCADA and ICS security assessment produces more than a list of vulnerabilities. It gives the organisation a practical view of exposure, process risk, and next steps.
The deliverables should include:
Verified asset inventory
Network and trust path diagrams
Critical communication flows
Remote access review
Segmentation findings
Vulnerability and configuration findings
PLC, DCS, SCADA, and HMI risk observations
Monitoring gaps
Prioritised remediation roadmap
Quick wins and longer-term actions
Evidence and assumptions
Operational safety notes
The best reports separate urgent risk from hygiene issues. They also state when further vendor review, engineering testing, or planned outage work is needed.
Final takeaway
Industrial security assessment is most effective when it respects the plant. Passive discovery, careful planning, engineering involvement, and controlled testing help identify weaknesses without interrupting operations.
SCADA, DCS, PLC, and HMI systems need continuous attention because the risk does not stay still. Networks change, vendors connect, equipment ages, and attackers keep looking for simple paths into critical operations.
Start with visibility. Validate what is connected. Understand who can access it. Monitor for change. Then manage risk in a way that protects both cyber security and the physical process.
Comments