WindlassConsulting

What an ICS security assessment covers, and what it leaves alone

  • OT security
  • ICS
  • NIST 800-82r3
  • IEC 62443
  • Assessment methodology

An ICS security assessment answers one question: is the control environment defended the way the organization believes it is? The answer usually differs from the network diagram, the asset register, and the last audit’s findings, because control networks change through vendor visits, outages, and one-off exceptions that never make it back into the documentation. A useful assessment measures the network as it runs today.

It also has a constraint an IT audit doesn’t. The equipment being assessed is running a physical process, and some of it can’t tolerate the testing an IT assessment takes for granted. So the scope has two halves: what the assessment examines, and what it deliberately leaves alone.

What’s in scope

The assessment covers everything that can affect the control system, which reaches well past the controllers themselves:

  • PLCs, RTUs, and other controllers, identified by model and firmware version wherever the evidence shows it.
  • HMIs, engineering workstations, historians, and the servers that run the SCADA or DCS platform. Engineering workstations deserve particular attention, since they hold the software and credentials that can reprogram a controller.
  • The IT/OT boundary: firewall rules, the DMZ if there is one, and every path between the corporate network and the control network, documented or not.
  • Remote access for vendors and integrators: jump hosts, VPNs, and always-on connections, including how each one is approved and when it’s removed.
  • Procedures for patching, backups, account management, and incident response, as they apply to the control environment rather than as the corporate policy describes them.

How the evidence gets gathered

Most of the work happens without sending a single packet to a controller.

Document review comes first: network diagrams, asset registers, firewall configurations, and policies. These show what the organization believes is true, which gives the rest of the assessment something to check against.

Passive capture comes next. A tap or SPAN port on the network records the traffic already flowing, and that traffic identifies devices, protocols, and often firmware versions. NIST SP 800-82r3 (Appendix E.2.2) notes passive methods can identify “manufacturers, part numbers, and firmware versions” for devices actively communicating on a monitored segment. The capture also shows which hosts talk to which, and that’s usually where the undocumented connections turn up.

Configuration audit fills in what capture misses. Device configs, firmware manifests, and firewall rule sets supply version data for devices that were quiet during the capture window, and they show what the boundary is configured to allow, which the traffic alone can’t prove.

A site walkdown ties it together: control rooms, network cabinets, and the physical paths that never appear on a diagram, like a cellular modem in a remote cabinet or a laptop left connected to a maintenance port.

With versions in hand, vulnerabilities come from matching them against published advisories. That gives a vulnerability list without probing anything.

What it leaves alone

A well-run ICS assessment doesn’t port-scan or penetration-test live controllers. NIST SP 800-82r3 (Appendix E.2.3) warns that active scans “may cause device instability or interfere with the device process state, potentially impacting safety and integrity,” and its incident records include a ping sweep that hung a system at a chip fabrication plant and destroyed $50,000 worth of wafers.

Active testing still has a place in OT. Factory acceptance testing, a test bed or replica, and a planned outage are all settings where a probe can’t take down a running process. Active vs. passive vulnerability scanning in OT covers where each method fits and what passive methods miss. The point for scoping is that confirming a vulnerability on a live controller is rarely worth risking the outage the vulnerability could cause.

The frameworks findings map to

Four references come up in almost every ICS assessment:

  • NIST SP 800-82r3, the federal guide to OT security, which covers architecture, controls, and assessment methods for control environments.
  • ISA/IEC 62443, whose Part 3-2 builds risk assessment around zones and conduits, and whose Part 3-3 sets system requirements, including a control system component inventory.
  • NIST CSF 2.0, which gives leadership a program-level view that lines up with how the rest of the enterprise reports cyber risk.
  • MITRE ATT&CK for ICS, a knowledge base of adversary techniques against industrial control systems. Mapping findings to it shows which attack paths a gap opens.

Mapping findings to these frameworks keeps the results comparable from one year to the next, and lets an auditor, an insurer, or a board member read them without a translation layer.

What a useful report looks like

The report should rank findings by operational risk rather than list everything at equal weight. It should separate configuration changes a team can make next week from work that needs a project, a budget, and an outage window. It should include the asset inventory and a current-state network diagram, since those are often worth as much as the findings.

It should also say plainly what each method covered. Passive capture only sees what talks during the capture window, so a report that states where confidence is high and where it’s limited is more honest, and more useful, than one that implies uniform coverage.

For what that looks like as an engagement, see the ICS and OT security assessment service.

Source: NIST SP 800-82r3, Guide to Operational Technology (OT) Security, September 2023: Appendix C.3.4, Appendix E.2.2 and E.2.3. IEC 62443 references are to Parts 3-2 and 3-3; the standard is available from ISA. MITRE ATT&CK for ICS.

All posts