VAPT

VAPT of OT and ICS Environments

Operational technology inverts the usual priorities. A controller that reboots because it received an unexpected packet is not an interesting finding, it is a stopped production line or a safety event. Assessment is therefore passive by default, active only where the client explicitly authorises it and usually only during a planned outage. The objective is to establish what an attacker could reach and what it would do, without becoming the incident.

Methodology

01
Documentation and architecture review
Network diagrams, asset registers, protocol inventory and the intended Purdue level assignment reviewed before anything touches the network.
02
Passive network monitoring
A span or tap port captures traffic for an agreed period. Asset discovery, protocol identification and communication mapping are derived from observation rather than probing.
03
Zone and conduit assessment
Actual traffic compared against the documented segmentation. Every flow crossing a Purdue boundary is identified and justified or reported.
04
IT/OT boundary testing
Active testing concentrated where it is safe — the corporate side of the boundary, jump hosts, historians, remote access paths and vendor connections.
05
Safe active assessment
Where authorised and scheduled, careful enumeration of Level 2 and above using OT-aware tooling with rate limiting, never on safety instrumented systems.
06
Vulnerability correlation
Discovered assets and firmware versions correlated against ICS-CERT advisories and vendor bulletins, without sending anything to the device.
07
Attack path modelling
How an attacker moves from corporate IT to process control, modelled against the observed architecture and mapped to MITRE ATT&CK for ICS.
08
Reporting and retest
Technical report and executive summary together, with remediation sequenced around maintenance windows rather than assuming it can happen immediately.

Approach to testing

Passive by default. Active scanning of Level 0 to Level 2 requires written authorisation, a scheduled window, and engineering staff present who can stop the process if needed.
Safety instrumented systems are never actively tested. Their assessment is documentation, configuration review and observation only.
The assessment assumes the IT network is already compromised, because that is how OT incidents begin. The question is what the boundary stops.
Legacy is a given, not a finding. Recommending that a fifteen-year-old PLC be patched is not useful; compensating controls around what cannot change are.
Remediation is sequenced against maintenance windows and change freeze periods. A report that assumes a plant can be stopped next Tuesday will be ignored.

Types of assessment

Passive assessment (default)

Traffic capture and documentation review only. Nothing is sent to any device. Safe to run on a live plant during production.

IT/OT boundary test

Active testing restricted to the corporate side of the boundary and the systems bridging it. The highest-value active testing available without production risk.

Authorised active assessment

Careful enumeration above Level 2, during a scheduled outage, with engineering present. Requires separate written authorisation.

Architecture and design review

Document-led assessment against IEC 62443 zones and conduits. Appropriate for greenfield projects or before a plant expansion.

Frameworks and standards

IEC 62443: The primary standard — zones and conduits, security levels, and the foundational requirements the environment is assessed against.
Purdue Enterprise Reference Architecture: The layering model used to assess segmentation and boundary control.
NIST SP 800-82: Guide to OT security, and the reference for testing practices that are safe in a control environment.
MITRE ATT&CK for ICS: Technique mapping for attack path modelling and detection coverage.
ISA/IEC 62443-3-3: System security requirements, used where the client is pursuing a certified security level.
CISA ICS advisories: Vulnerability correlation source for identified device firmware.

Tools used

Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.

Wireshark with ICS dissectors

Passive protocol analysis for Modbus, DNP3, S7comm, EtherNet/IP and Profinet.

Zeek

Long-duration passive capture, asset discovery and communication mapping.

GRASSMARLIN

Passive network mapping and topology derivation for control networks.

Nmap with OT-safe timing

Active enumeration only where authorised, with rate limits and no aggressive scripts.

Claroty / Nozomi (where deployed)

Reading the client's existing OT monitoring rather than duplicating it.

Vendor configuration tools

Reading controller and HMI configuration directly, with engineering support.

Checklist approach

The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.

Segmentation and boundary

Every flow crossing a Purdue boundary, against the documented design
Firewall rule review between IT and OT zones
Dual-homed hosts bridging zones
Wireless access within the control network
Direct internet reachability of any OT asset

Remote access

Vendor remote access paths, authentication and session recording
Jump host hardening and account management
Persistent versus on-demand access
MFA on every path into the control network
Third-party connections and their contractual controls

Asset and firmware

Complete asset inventory against the client's register
Firmware versions correlated with ICS-CERT advisories
End-of-life and unsupported devices
Default credentials on controllers, HMIs and switches
Engineering workstation patch and protection status

Protocol and authentication

Unauthenticated control protocols in use
Cleartext credentials on the control network
Protocol conversion points and their trust assumptions
Historian and OPC server access control

Resilience and recovery

Controller configuration backups and their protection
Recovery time for a compromised engineering workstation
Offline backup of project files and logic
Documented manual operation procedures

Monitoring

Logging coverage within the control network
Detection of unauthorised device connection
Alerting on controller logic changes
Who receives OT alerts, and whether they are staffed outside business hours

How findings are scored

Every finding is scored on CVSS 3.1 and placed in one of five levels. The executive summary adds a sixth band — Compliant — so components that passed appear on the same chart as those that did not.

Critical: Immediate measures must be taken. These vulnerabilities can allow an attacker to take complete control of the application or server — stealing user data, tricking users into supplying sensitive information, or defacing the site.
High: Maximum risk associated with a specific vulnerability instance. May enable an attacker to compromise the application and its data, partially or completely, or to modify application behaviour beyond its intended purpose. To be handled with utmost priority.
Medium: Considerable risk. May enable an attacker to exploit the application to a particular level, gaining low-level information that can be used to craft more specific attacks.
Low: Lowest risk. May allow an attacker to gain some information about the application that was not intended to be known, without an exploitation technique currently available at that instance.
Informational: A functionality or component is missing best-practice implementation. Not a risk today, but may become one as the application changes or as exploitation techniques, policy or legal requirements evolve.

Scan types selected

Safe Checks
Standard / OWASP Top 10
Destructive
SANS Top 25
Business Logic Vulnerability Testing

Standard toolset by stage

OSINT: Datasploit, Google Dorks, Shodan
Enumeration & Scanning: Nmap, Wfuzz, Unicornscan
Domain Enumeration: Nikto, DnsRecon, Knock
Crawling & Fuzzing: Burp Suite, Acunetix, Netsparker
Vulnerability Analysis: OpenSSL, sqlmap, CVE-Details
Exploitation: Metasploit, Netcat, Exploit-DB

Free toolkit

Penetration Testing Checklists

Sixteen assessment checklists covering the targets we test: web applications, Android, iOS, APIs, networks, Active Directory, thick clients, WiFi, SCADA and ATMs — plus red team test cases, firewall audit, malware analysis and vendor security assessment.

16 checklists · ZIP · 775 KB

Download the toolkit

Deliverables

Technical assessment report (PDF)
Executive summary (PDF, one page)
Derived asset inventory (spreadsheet) with register deltas
Zone and conduit diagram from observed traffic
Attack path model mapped to MITRE ATT&CK for ICS
Remediation plan sequenced to maintenance windows
Retest report evidencing closure

Frequency

One-time: A first assessment, a new plant or line, or an insurance or regulatory requirement.
Annually: The default for most operators. OT changes slowly and the assessment tracks drift and new advisories.
Biannually: Operators with frequent integration work, active digitalisation programmes or many vendor connections.
After any plant change: Triggered — a new line, a vendor connection, a control system upgrade, or an IT/OT integration project.

Resource deployment

OT assessment is substantially on-site work and cannot be done well remotely. Capture points must be physically placed, control rooms and cabinets inspected, and engineering staff interviewed about what the system actually does rather than what the drawing says. A typical engagement places one or two assessors on site for four to seven days per location, with traffic analysis and reporting completed afterwards. Where a client operates several plants, CSS assesses a representative sample on site and reviews the remainder from documentation and capture.

How CSS tests

A unified swarm of agents, for blind spot detection

AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.

Passive capture over days produces far more traffic than a human can review. Agents classify flows and surface the ones that cross a boundary or use an unexpected protocol, which is where the findings are.
Asset inventories in OT are almost always incomplete. Deriving the real inventory from observed traffic, then diffing it against the register, reliably finds devices nobody knew were connected.
Firmware-to-advisory correlation across hundreds of devices and thousands of advisories is lookup work, and doing it by hand means sampling.
Attack path modelling from IT to process control is graph analysis over the observed topology rather than the documented one.

In OT the swarm is strictly read-only. It analyses captured traffic and documentation; it never touches a device. Every finding is validated by a human assessor with control systems experience, and nothing is sent to any controller by any automated process.

Why this differs

What CSS does that most vendors do not

Every one of these is checkable. Ask any vendor for the same and compare the answers.

Passive first, and we mean it

Many vendors run an IT methodology on an OT network and cause an outage. CSS assesses from captured traffic and documentation, and treats active testing as a separate, scheduled, separately authorised activity.

Remediation sequenced to reality

Recommendations are ordered around maintenance windows, change freezes and what a vendor will actually support, because a plant cannot be patched on a Tuesday afternoon.

Both reports, always

Technical report and executive summary together, plus a zone and conduit diagram derived from observed traffic rather than from the drawing.

Compensating controls where patching is impossible

Legacy devices are a permanent condition, not a finding to be closed. The report addresses what can be built around them.

Reporting

Two documents, two audiences

Both are produced for every engagement. They are not the same document at two lengths — they answer different questions and are written separately. The structure below is the one CSS actually issues.

Technical assessment report

For the engineers who will fix it

Disclaimer, and Limitations on Disclosure and Use
Risk Level & Description — the five levels above, scored on CVSS 3.1
Scan Type — which of the five assessment types were selected
Assessment Scope — the control areas covered
Assessment Date — the exact testing window
Objective of the Assessment — objectives listed against completion status
Tools Utilization — manual and automated tooling by stage
Summary of the Assessment
Overall Recommendations, split into Must Have and Should Have
Vulnerability Overall Classifications as per Organization
Security Issues Highlighted
The Key Findings — each with evidence and detailed recommendation
Summary of Findings & Conclusion

For this assessment specifically

Scope, capture locations, capture duration and any active testing performed
Derived asset inventory, with deltas against the client's own register
Observed zone and conduit diagram, compared with the documented architecture
Findings with IEC 62443 requirement references and severity in availability terms
Firmware correlation against ICS-CERT advisories, with exploitability assessed in context
Attack path model from corporate IT to process control, mapped to ATT&CK for ICS
Remediation sequenced by maintenance window feasibility
Retest results appended against each original finding

Executive summary

For the people who will fund the fix

Objectives, each against a completion status
Overall Finding of the Assessment — total threats identified, broken down by component and severity
Summary of the Assessment
Artefacts of the Assessment — the key findings as a numbered register with severity
Observation of the Assessment — the major attacks the organisation should be prepared for, given what was found
Overall Recommendation, including a Business Enabling Recommendation sequence
Must Have and Should Have actions

For this assessment specifically

What an attacker who compromised the corporate network could reach in the plant
Safety and availability consequences in operational terms, not CVSS scores
The three changes that most reduce exposure, with the outage cost of each
Regulatory and insurance position where applicable
Remediation sequence against the maintenance calendar
One page

Case studies

What this finds in practice

Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.

A chemical processing plant, roughly 400 control devices across three production areas.

Finding: Passive capture showed the historian at Level 3 holding an open connection to a corporate reporting server, and the same historian polling controllers directly at Level 1. It was effectively a bridge from the office network to the process network, and it was absent from every architecture diagram.
Recommendation: Break the direct path: replicate historian data to a separate corporate-side instance and remove Level 1 polling from the Level 3 host. Add flow monitoring so a new bridge is detected rather than discovered at the next assessment.
Outcome: Replication implemented at the next maintenance window. Flow monitoring has since flagged two unauthorised connections within days of being made.

A water utility with twelve remote pumping stations on cellular links.

Finding: Remote stations used a shared VPN credential with no MFA, and the same credential was held by two maintenance contractors. Once inside, the station networks were flat and reached the SCADA master directly.
Recommendation: Per-station credentials with MFA, contractor access issued on demand and revoked after each visit, and a firewall between station and master permitting only the required protocol.
Outcome: Credentials and MFA rolled out across all twelve sites in six weeks. Firewalls followed over a longer programme as each site's maintenance window came up.

An automotive assembly line, engineering workstations and PLCs on a single flat network.

Finding: The derived asset inventory contained 63 devices absent from the client's register, including an unmanaged switch and two contractor laptops that had remained connected since a commissioning project eighteen months earlier.
Recommendation: Reconcile the register, remove unmanaged devices, and add port-level control so an unknown device cannot obtain a connection silently.
Outcome: Contractor laptops removed immediately. Port security is being rolled out area by area; the register is now reconciled against a passive capture quarterly rather than maintained by hand.

Scope this assessment

Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.

Start a conversation All VAPT capabilities