LEARN. PRACTICE. GROW.Translate needs into a flow matrix
The office network needs reports, not direct contact with every controller. Describe each required communication by source, destination, direction, protocol, port, purpose, owner and window. Group assets by function, trust and consequences before selecting boundaries. A VLAN provides logical separation; enforced policy between zones determines which traffic crosses. An intermediary service can reduce direct access but still needs hardening, management and observation. In the lab, four containers share an internal bridge. Filtering acts on the synthetic server’s input; it implements neither a routed industrial network, a complete DMZ nor a Purdue architecture. This boundary lets the exercise study a concrete source-and-port decision without claiming an architecture that is absent.
Observe both denial and service availability
The synthetic service listens on three TCP ports. Before policy, office reaches telemetry and operator reaches maintenance. Afterwards, only operator can start telemetry connections on port 15020. Office fails, while a local check confirms the additional service remains listening. Diagnosis therefore does not depend on an isolated timeout: compare service health, permitted source, denied source and filter counters. These counters count packets, not users or unique attempts. Retransmissions can increase totals. Application logs show requests that reached the service; they do not automatically record every dropped packet. Preserve time, configuration and test context to distinguish deliberate denial from a routing or application failure.
Bound maintenance access
The window opens a permission for source vendor and port 15021. That vendor still cannot access telemetry or the third port; office still cannot access maintenance. In actual operation, an address rule neither identifies a person nor establishes contractual authorization. Complement architecture with individual identities, appropriate authentication, task-bounded approval, supervision and a way to remove access. Define start, end, destination and permitted actions while considering equipment compatibility. The exercise implements no MFA, bastion or supplier accounts. Its contribution is checking that the source-and-port combination does not inadvertently become broader permission. A scheduled window also needs closure evidence, including treatment of sessions that began before its end.
Separate new connections from established traffic
The fixture keeps a vendor session exchanging messages. Removing its temporary allow rule prevents new connections, but the session continues through the earlier rule accepting established state. Under this ruleset, ending permission to start is not ending all existing traffic. The exercise then inserts a scoped denial before that state acceptance. The client stops receiving replies and exits on timeout; it does not claim a TCP reset was sent or the conntrack entry disappeared. In production, select removal mechanisms with sessions, application, identity and operational effects in mind. Rule order is part of the evidence. Also test the required flow after containment: blocking everything could satisfy denial without preserving necessary service.
Deliver evidence with interpretation limits
Both runs retain versions, program hashes, rules, counters, outcomes and removal of temporary resources. A local result is reproducible within this scope; it establishes neither latency, capacity, redundancy nor physical safety of an installation. TCP requires response traffic: this filter is not a unidirectional data diode. Established state also does not establish that a user remains authorized. For handover, link each requirement to a positive and negative exercise, owner, result and gap. Add recovery, dependency-loss and emergency-access tests in an appropriate environment. Residual-risk acceptance belongs to the designated authority with operator participation. Use results to prepare better acceptance questions without presenting BigSavant as the official certification provider or the lab as production approval.
docker build -t dr-securityx-ot:20261008 content/labs/securityx-ot-boundaries
python3 content/labs/securityx-ot-boundaries/run.py --output /tmp/securityx-ot.json
# Disposable internal Docker network only; no physical OT devices.Removing vendor permission blocks new sessions; a deny before established acceptance interrupts the existing session’s data exchange.
Common pitfalls
Open port as authorized identity; packet counter as people count; removed rule as terminated session; TCP as a diode.
Related topics: OT inventory and dependencies · Segmentation and remote access · Physical safety and operations
The boundary is established only for the flows, states and conditions actually exercised.
Reference: Guide to Operational Technology Security, SP 800-82 Rev. 3 · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17