By Alex Teague
If you’ve spent any time in industrial cybersecurity, you know that assessing an ICS or OT environment is a fundamentally different discipline from reviewing a typical enterprise network. The stakes are higher, the technology is older and the customer is above all, concerned with protecting the process.
Over the years, I’ve led numerous security architecture reviews across industrial environments, manufacturing, energy, and beyond. Along the way, I’ve developed a methodology not just for assessing these networks, but for developing the people who assess them. Because the reality of this field is that experienced ICS security professionals are rare, and the only way to grow the talent pool is to bring less experienced team members into real engagements and give them meaningful work.
Here’s how I think about structuring these reviews and building a capable team in the process.
Preparing the Team Before We Start
Before we get into the structure of the review itself, it’s worth talking about what happens before anyone touches any data. I don’t send a team member into an ICS/OT review cold. Prior to their first review, I run training sessions covering the types of devices and protocols the team is likely to encounter.
For many analysts coming from an IT security background, this will be their first exposure to PLCs, RTUs, HMIs, historians, and safety instrumented systems. These often-unfamiliar acronyms behave differently to what they may have seen before, and misunderstanding their role and the context can lead to poor analysis and poor recommendations. The team needs to understand what these devices do, what the risks are, why they exist, and why they matter to the people who operate them.
The same goes for protocols. If you’ve never seen Modbus, DNP3, PROFINET etc, you’re going to struggle to distinguish normal traffic from something that warrants flagging. A brief grounding in what these protocols look like, and what their known weaknesses are gives the less experienced team members the context they need to do meaningful work during the review rather than simply cataloguing what they don’t recognise.
This upfront investment in preparation pays for itself many times over.
What Makes ICS/OT Architecture Reviews Different
A security architecture review of an OT environment to me is like a pen and paper pen test. You’re trying to understand the design how the network is segmented, how data flows between zones, where trust boundaries exist (or don’t), and whether the architecture aligns with established frameworks. Without the active and oftentimes risky interaction of scanning.
These networks often contain equipment that has been running continuously for a decade or more. PLCs, RTUs, HMIs, and historians don’t respond well to aggressive interrogation (more on why these devices are so fragile in an upcoming blog). Many of them run proprietary protocols that enterprise security tools simply don’t understand.
This means the review process must be overwhelmingly passive. You observe. You collect. You analyse. You map. And then you compare what you found against what the design documentation says should be there. The gap between those two pictures is where the risk lives.
Structuring the Team: Passive Tasks as Training Ground
When I bring less experienced analysts onto an ICS/OT engagement, I assign them to what I call the “foundational layer” of the review. These are passive, observation-based tasks that produce deliverables without introducing risk to the environment.
PCAP Review
I’ll have less experienced team members work through packet captures collected from key networks.
What I’m asking them to look for goes well beyond port and protocol identification. They should be, identifying broadcast traffic patterns, flagging any protocols that shouldn’t be present and noting unencrypted credential exchanges. As well as noting unexpected IT protocols mixed in with industrial traffic.
This task teaches them to read the actual behaviour of a network. It also develops an intuition for what “normal” looks like in industrial environments.
Network Diagram Construction and Validation
When we conduct SARS one of the things we ask for are network diagrams. These were often drawn during commissioning and never updated, or they reflect the intended design rather than the current reality. We’ve even had some that were hand drawn back of a napkin style.
I task less experience team members with building a ground-truth diagram from collected evidence noting any discrepancies from the provided documentation: PCAP data, switch and router configurations, firewall rule sets, and interviews with operations staff. They map out what’s actually on the network, where traffic actually flows, and how segments are actually separated.
This is painstaking work, but it’s invaluable. It forces them to reconcile multiple data sources, ask the right questions, and develop a mental model of how OT networks are architected.
Asset Inventory Review
You can’t secure what you don’t know about. It is vitally important that the testers are conscientious here. Segregating the asset inventory list properly ready to be compared and contrasted with the other documentation.
Configuration Reviews
Reviewing the configurations of firewalls, managed switches, routers, and where possible controllers is another task well suited to developing analysts. I’ll provide them with a review checklist aligned to the engagement’s reference framework (and manufacturers configuration best practice if applicable) and have them work through each device methodically.
They’re looking for overly permissive firewall rules (especially any-any rules between zones), insecure management protocols, default credentials, unnecessary services, and misconfigurations that undermine the intended segmentation.
What makes this task especially educational is that it connects technical findings to architectural risk. A single misconfigured firewall rule or switch can collapse an entire zone boundary, effectively merging two segments that the architecture was designed to keep separate.
Why This Approach Works?
There’s a deliberate philosophy behind assigning these tasks to less experienced team members. Each one is low-risk to the target environment but high-value for both the engagement and the analyst’s development.
These tasks produce the raw evidence that the entire review depends on. Senior team members can then focus on the higher-order analytical work evaluating the architecture against threats specific to the industry sector, assessing the effectiveness of compensating controls, identifying systemic weaknesses in the security programme, and developing actionable recommendations that operations teams will adopt.
Meanwhile, the less experience analysts are learning how to think about OT security from the ground up. They’re seeing real industrial protocols, understanding why segmentation matters, and building the observational skills that produce a capable OT security professional.
Building the Next Generation
The ICS and OT security field needs more practitioners, and they won’t appear fully formed. Every experienced professional in this space was once an inexperienced analyst learning the difference between OT and IT for the first time. The way we structure our engagements giving less experienced team members real, meaningful work on real assessments is how we grow the field.
Security architecture reviews are the ideal vehicle for this. They demand rigour, reward curiosity, and provide a structured environment where developing analysts can build genuine expertise without putting critical infrastructure at risk.
If you lead assessment teams, think carefully about how you assign work. The passive tasks aren’t just grunt work to keep less experienced testers busy. They’re the foundation of both the engagement and the careers you’re helping to build.
