OT and ICS Security Assessment

What Passive Capture Shows, and What It Does Not

A capture is a record of what happened on the wire while it was running. Anything that did not speak during the window does not appear. A controller polled once a shift, a pump station that runs seasonally, an engineering laptop that only shows up when a vendor visits: any of these can be entirely absent from an otherwise complete capture. Configuration review closes part of that gap, since a device can sit in a switch table or a firewall rule without ever generating traffic, but the two sources are complementary and neither is a full inventory on its own.

The second limit is about certainty. Observation establishes that a path exists and that a service is reachable from where the capture was taken. It does not establish that the path can be exploited, because confirming that would mean sending something, which is the one thing the method excludes. Findings are written as exposure and reachability, not as proof of compromise. That distinction matters most when the report reaches someone who wanted a demonstration.

• Cleartext protocols give up nearly everything: function codes, register values, account names, and sometimes the credentials themselves.
• Encrypted or tunneled traffic still reveals endpoints, timing, volume and direction, which is often enough to identify an undocumented remote access path even when the contents stay closed.
• Firmware and version detail appears only when a device announces it or when the configuration export contains it. There is no active query to fill that in afterward.
• Traffic that never crosses the capture point is invisible no matter how long the capture runs, which makes placement the decision that matters more than duration.

Where the Capture Actually Comes From

The usual capture point is a mirror or SPAN session on a managed switch that already carries the traffic of interest. That is a switch configuration change, and it is made by your network staff under your own change process. It is also why the first conversation is about your topology rather than about tooling: a mirror configured on the wrong switch produces a very clean capture of traffic you already understand.

A network TAP is a separate question. Installing one means breaking the link it will monitor, briefly but really, and that is a planned interruption that belongs to your maintenance scheduling. It is not part of this assessment. If your staff have already placed TAPs, or choose to place one during an outage that you schedule and perform, the capture can be taken from it. Either way, physical work on the control network stays with the people who own the network.

Many OT segments are wired through unmanaged switches, which have no mirror capability at all. When that is the case the capture point moves upstream to the OT and IT boundary, at the firewall or the router. That shows every conversation crossing the boundary and none of the device to device traffic inside the segment. It is a real answer for segmentation and remote access questions and a weak one for asset discovery, and it is better to know which you are getting before the capture starts than to work it out during analysis.

Duration is chosen around your operational cycles rather than by the clock. A building with night setback, a plant with shift changes, a site whose integrator connects on a weekly rhythm: each argues for a window that contains at least one full cycle of whatever you care about. We ask what those cycles are because they cannot be inferred from traffic that has not been captured yet. Capture files also grow quickly, so where they are written and how much space is available is worth settling before the session is turned on.

What the Engagement Depends On From You

A passive method moves work onto the customer that an active scan would have done for itself. None of it is unusual, and none of it can be substituted.

The other dependency is a decision rather than an artifact: where the capture data lives, how it is transferred, and how long it is kept. Captures from a control segment can contain cleartext credentials and detailed process data, so they deserve to be handled at the sensitivity of the systems they describe. Settle that before capture rather than after, because a requirement that data never leaves your environment constrains where analysis can run and has to be arranged in advance.

• A named person with the authority to configure the mirror session and to approve the change window it needs.
• Whatever network documentation exists, including the parts known to be out of date. The gap between the diagram and the capture is itself a finding, so an inaccurate diagram is far more useful than none.
• Configuration exports: switch and firewall configurations, device backups, user and permission exports from the management layer, and VPN or remote access configuration.
• An explicit do not touch list, specific rather than general: named devices, named ports, hours that are off limits, and any equipment whose vendor agreement restricts what may be attached to it.
• The remote access inventory as your organization believes it to be. Comparing the documented list against the paths that appear in traffic produces a large share of the useful findings, and that comparison needs the documented list to exist.

When an Assessment Is Not the Right Next Step

There are situations where this engagement produces an accurate document and no change. They are worth recognizing before scoping rather than after delivery.

• You are dealing with an active incident. An assessment answers what the environment looks like normally. It is not built to answer what happened during an event, which is incident response and digital forensics work and starts from different questions.
• You already know the OT and IT networks are flat and that vendors connect through paths nobody controls. An assessment will confirm it in detail. Design work changes the network; an assessment only describes it. If the decision to remediate is already made, segmentation and remote access design is the work that moves it.
• You already hold captures and configuration exports from your own tooling. In that case the scope narrows to interpretation of data you already have, rather than collection plus interpretation, and it should be scoped that way from the start.
• The system is not yet commissioned. A greenfield network has no operational traffic to capture and no accumulated drift to find. Reviewing the design, the addressing plan and the intended remote access model is the useful work at that stage.
• You need proof that a specific device can be exploited. Passive work will not produce it. Say so early, because that requirement points to lab testing against identical hardware rather than to anything done on a production network.