CrossCheck: Evidence-Based Compliance Verification for OT Network Segmentation

1. Introduction

Segmentation between information technology (IT) and operational technology (OT), and within OT itself, gets recommended constantly and verified rarely. The 2017 TRITON/TRISIS incident shows what that gap costs: attackers were inside a Saudi Arabian petrochemical plant's OT network for roughly six months before they reached the safety instrumented systems that existed specifically to stop this kind of failure, and what actually stopped them was a bug in their own malware. The network's defenses never intervened [9]. A typical audit today runs three phases, passive monitoring for an asset inventory, a manual comparison of that traffic against documented firewall rules, and a gap report; industry accounts put this at four to six weeks per facility [8].

Two things are broken in how this gets done today. Compliance tooling is built around whichever collection method its vendor uses, so the compliance answer tracks which sensor happened to be watching more than it tracks the traffic and the policy themselves. And checking a network against a specific standard is still a person reading clauses by hand. We built CrossCheck to answer only what address and flow level evidence can answer with confidence: three of the Cybersecurity and Infrastructure Security Agency's (CISA's) Cross-Sector Cybersecurity Performance Goal (CPG) 3.I's four segmentation elements, from evidence a utility already has, against policy in whichever of its two real forms applies, an inline appliance's rule groups or a documented access list. When the fourth element needs judgment the evidence alone cannot settle, the tool says so and stops there. For a compliance answer someone is going to act on, that matters more than trying to do everything at once.

2. Related Work

Compliance verification tooling. A mature market already does OT asset visibility, device classification, and behavioral baselining, both passively and inline, with cloud-native options also entering that space [10,11,12,13]. What it does not offer, as far as we have found, is a standard-mapped compliance verdict built from address and flow level evidence alone, independent of whichever visibility platform an organization runs, if it runs one at all. That is the gap here. A utility without dedicated visibility tooling still has the address and flow data this needs, because firewalls and switches log it by default whether or not anyone is watching.

LLM based policy automation. The closest academic work is Fernández Saura, Jayaram, et al. [6], a short paper on a two-stage retrieval-augmented LLM pipeline that turns written security policy into discrete, executable tasks, tested on six Windows attack-mitigation policies with a small hand-built labeled set. Adding retrieval augmentation improved F1 by 22 to 37 points over a plain baseline. That is a useful proof that LLM based policy interpretation works at small scale. It does not touch network segmentation, OT environments, or mapping to a compliance framework, which is where this paper picks up.

Finer-grained segmentation standards. CPG 3.I is not the strictest framework in this space. The National Institute of Standards and Technology's (NIST's) zero trust architecture [5] and CISA's own microsegmentation guidance [7] both describe finer-grained, often per-host isolation, a stronger posture than segmenting by broadcast domain. That is a real goal, and a harder one in OT specifically: legacy field devices that cannot run agents or certificates, safety certification requirements on anything added to a control loop, and the cost of re-architecting a running plant all push host-level isolation toward something utilities build up to rather than switch on. CPG 3.I's own recommended action sets a different, coarser-grained bar: routers placed between networks to create boundaries and increase the number of broadcast domains [1]. VLANs and routers, not individual devices, and no mention of intra-VLAN traffic. This tool checks against the bar specified in CPG 3.I. Passing it means meeting CPG 3.I. It does not mean an organization has also achieved zero-trust-style isolation, and we are not claiming that it does.

Sector-specific obligations. The America's Water Infrastructure Act of 2018 (AWIA), Safe Drinking Water Act Section 1433, requires community water systems serving more than 3,300 people to certify a Risk and Resilience Assessment covering cyber threats on a recurring cycle [2]. WaterISAC calls network segmentation one of the most effective protections available to the sector, and separately reports that CISA's own assessments keep finding inadequate boundary protection as the most common weakness [3,4].

3. Materials and Methods

3.1. Scope

The tool supports two deployment types, since that is what actually determines where the evidence comes from. Inline, a next-generation firewall (NGFW) or zero trust device sits in the traffic path itself, enforcing and observing at the same point. Passive/SPAN, a tap or switched port analyzer (SPAN) port captures traffic elsewhere on the network, while the actual access control lives separately, spread across the switches and routers rather than centralized in one appliance.

Whichever deployment type applies, the tool needs the same two inputs, just sourced differently. First, flow evidence: source IP address, destination IP address, the virtual LAN (VLAN) or subnet of source and destination, protocol, port, and flow count, which a firewall should log by default for most commercial firewall platforms. Under inline, this information comes from the device's own logs; under passive/SPAN, it comes from the tap. Second, policy: under inline, the device's own rule groups; under passive/SPAN, the switch and router access control lists (ACLs) governing that segment.

From those two inputs alone the tool checks three of CPG 3.I's four elements: distinct segments behind a boundary device, inter-segment traffic tight enough to contain a breach, and physical isolation for any OT enclave the standard requires it for. A fourth element, CPG 3.I's “where safe and technically feasible” exception, and a related capability, asset classification, are left for later versions rather than half-built into this one; Section 5 covers why each is a next step and not a gap.

3.2. Tool Design

Whichever form the policy takes, and whichever source the flow evidence comes from, both get normalized into one common representation before any check runs. A flow record is source, destination, VLAN or subnet, protocol, port, frequency, first seen. A policy record is a statement between two named groups: source group, destination group, action. A group here is a VLAN or subnet, a network-based construct, on purpose. Vendors often provide richer options like tags or labels based on asset identity or type, but at the actual data path those still get evaluated as network-based constructs once the rule runs, the same way a Linux system enforces iptables rules against IP addresses and ports no matter how the rule was originally written. Network-based constructs are also what is actually prevalent across OT environments today, so staying at that layer is not giving anything up. That is the tool's own internal schema; it is not anyone's real syntax. Table 1 shows a short excerpt of what it looks like populated, with group names standing in for whatever VLANs a given deployment actually uses.

Under an inline deployment, the appliance enforcing this policy is also the source of the flow evidence, since it sees what it passes and what it blocks. Under passive or SPAN, the tap supplies the flow side, and a separately exported switch or router access list, translated into the same group schema, supplies the policy side. These stay two separate sources for a practical reason: a router or Layer 2/3 switch enforcing that ACL is often not giving a full flow record log on its own, even though it is the device doing the enforcing, so the flow side still has to come from somewhere else. Same network, two vantage points.

The three checks run against that shared representation. The boundary check flags any observed flow between two groups with no policy record covering it at all; that is the signature of a path the documented policy never accounted for. The containment check looks, for group pairs traffic was actually observed between, at whether the governing rule is scoped tight enough that the observed reachability matches it and is not broader than a breach-containing rule should be. The physical enclave check is the simplest of the three: for a segment the standard requires physically isolated, it looks at which direction traffic actually flowed, since a real one-way hardware boundary makes the reverse direction physically impossible no matter what any policy document says.

Worked example. Take the Intake Group to Filtration Group pair from Table 1, governed there by a DENY rule, the same inter-area pair Figure 1 marks as the undocumented flow to watch. With that DENY rule in place and no traffic observed crossing it, the containment check reads compliant: a scoped policy record covers the pair and nothing contradicts it. Table 2's scenario 3 changes one thing: the DENY rule gets widened to an ANY/ANY permit, and flow evidence shows traffic now reaching across that same pair. The check reads the policy record, sees it is a wildcard rule, and returns a containment violation without needing to look at the traffic itself first, a rule that broad cannot contain a breach regardless of what happens to be crossing it today. One documented policy change is the entire distance between the two verdicts, caught by reading the rule's scope against the evidence rather than by pattern-matching the traffic.

4. Results

Figure 1 shows the reference OT topology these scenarios are built against: a water treatment facility spanning Purdue Levels 4 through 0, with a demilitarized zone (DMZ) firewall separating IT from OT, four OT areas (SCADA, Intake, Filtration, and Distribution), each on its own VLAN, and a diode-isolated safety instrumented system enclave.

Figure 1. Reference OT topology used to construct the evaluation scenarios, annotated with the three checks from Section 3.2.

Figure 1. Reference OT topology used to construct the evaluation scenarios, annotated with the three checks from Section 3.2.

A small, hand-built set of six scenarios, numbered 1 to 6 below, was run at roughly the scale used in the closest academic precedent [6], each checked once under an inline deployment and once under a passive/SPAN deployment against an equivalent switch access list, to see whether the same underlying activity gets the same verdict either way. Two checkers ran against every scenario. Baseline Check is a basic keyword and static-rule matcher standing in for current manual practice: it reads the policy text for a default-deny statement and scans for an unrestricted rule between groups, never checking traffic against policy, and has no way to say it lacks enough evidence. CrossCheck is the tool itself, cross-referencing that same policy against the actual observed flows to produce the audit verdict.

Table 2. Results across the six scenarios (inline deployment; CrossCheck produced identical verdicts under the passive/SPAN counterparts in every case, Baseline Check differed on one).

#	Scenario	Ground truth	Baseline Check	CrossCheck
1	Compliant network, no violations	Compliant	Compliant (correct)	Compliant (correct)
2	Undocumented path into a segment	Boundary violation	Compliant (wrong)	Boundary violation (correct)
3	Overly broad rule between two segments	Containment violation	Containment violation (correct)	Containment violation (correct)
4	No policy on record for a segment pair	Insufficient evidence	Compliant (wrong)	Insufficient evidence (correct)
5	Reverse direction traffic on an isolated enclave	Physical isolation violation	Physical isolation violation (correct)	Physical isolation violation (correct)
6	Genuine one-way traffic on that same enclave	Compliant	Compliant (correct)	Compliant (correct)

Table 2. Results across the six scenarios (inline deployment; CrossCheck produced identical verdicts under the passive/SPAN counterparts in every case, Baseline Check differed on one).

#	Scenario	Ground truth	Baseline Check	CrossCheck
1	Compliant network, no violations	Compliant	Compliant (correct)	Compliant (correct)
2	Undocumented path into a segment	Boundary violation	Compliant (wrong)	Boundary violation (correct)
3	Overly broad rule between two segments	Containment violation	Containment violation (correct)	Containment violation (correct)
4	No policy on record for a segment pair	Insufficient evidence	Compliant (wrong)	Insufficient evidence (correct)
5	Reverse direction traffic on an isolated enclave	Physical isolation violation	Physical isolation violation (correct)	Physical isolation violation (correct)
6	Genuine one-way traffic on that same enclave	Compliant	Compliant (correct)	Compliant (correct)

Baseline Check got two of the six wrong. On scenario 2 it called the undocumented path compliant, since it only ever reads the policy text and never checks the actual traffic. On scenario 4 it guessed compliant without admitting it did not have enough to go on, because it has no separate category for insufficient evidence. CrossCheck got all six right, including scenario 4, where it said plainly that it could not judge the case. That puts Baseline Check at 0.73 F1 identifying real violations across these scenarios and their SPAN counterparts, against 1.00 for CrossCheck. The gap, about 27 points, falls within the 22 to 37 point range reported for the closest precedent [6], a first signal that cross-checking policy against actual traffic, not reading policy alone, is what closes it. This is a hand-built evaluation, short of a field test, so the obvious next step is running the same design against real exported configs and real captured traffic from a live deployment; that is a question of scale, and the design itself would not need to change.

5. Discussion

The two things scoped out of this version are the natural next steps, already named in Section 3.1. Asset classification and this compliance check serve different purposes: an organization already running visibility tooling loses nothing by also running this for a compliance answer, and one that is not still gets that answer without needing to buy one first. CrossCheck already clears the three evidence-based elements on its own, narrowing a reviewer's judgment time to exactly the cases that claim CPG 3.I's exception, the one place the standard asks for human judgment anyway. That exception clause is the natural next addition to the tool, since “where safe and technically feasible” is a call we built the rest of CrossCheck specifically not to make alone.

To be explicit about it: meeting the three elements this tool checks means meeting CPG 3.I. That is a narrower claim than meeting the host-level isolation that zero-trust architectures and standards like NIST 800-207 describe, and this paper is precise about which of the two it demonstrates. The evaluation itself is a limitation worth stating plainly: six hand-built scenarios and their SPAN counterparts, against a simple keyword baseline, show the architecture's logic is internally consistent, not that it generalizes to the diversity of real deployments. Real exported configurations and captured traffic in place of the synthetic dataset, and a stronger baseline than keyword matching, are what would actually move that confidence.

6. Conclusions

This paper is about CrossCheck, a tool that takes evidence in whichever of two forms an operator's deployment actually produces it. Passive or SPAN, that is tap traffic paired with switch and router ACLs, whether those were configured by hand or written onto the switches by a deeper visibility platform. Inline, that is a branch gateway device or NGFW's own logs and rule groups. Either way, it turns that evidence into a direct answer against a standard: given address and VLAN-level flow data and policy in whatever real form it takes, it checks three of CPG 3.I's four segmentation elements correctly, and states plainly when it does not have enough to judge the fourth. Nothing about that design is specific to water and wastewater; the same checks apply the same way in manufacturing or any other OT sector organized around VLANs and a boundary device. Water and wastewater is simply where this paper validates it first, against a statutory deadline that makes the sector's need immediate. Extending the tool to the fourth clause, and to more evidence sources validated against real deployment data, is the next work, building on a design that already holds up on the parts it covers.