Apply segmentation and controlled remote access to an OT scenario

What you should be able to do

Apply a defensive segmentation and remote-access plan to a fictional maintenance task while preserving operational requirements and limiting access to the authorized purpose.

Why segmentation matters

Operational technology, or OT, includes systems that monitor or control physical processes. Grouping equipment by function and need allows the project to define which communications should cross boundaries. NIST’s OT security guidance discusses segmentation while considering operational performance and safety [1]. A fiber link is a transmission medium, not an access-control policy. Likewise, assigning VLAN numbers does not prove that traffic between zones is restricted. Document the allowed communications and the controls that enforce them.

Controlled remote access

CISA guidance recommends strong authentication for remote access, separation of IT and OT, and logging of important access infrastructure [2]. Remote-access practice also emphasizes enabling access when needed rather than leaving unnecessary access available [3]. Apply these principles through a site-approved architecture. They do not authorize an apprentice to deploy a new gateway, change a firewall or install remote-control software on a production device.

Read the diagram

The left box represents a named support user using the approved access method and multifactor authentication. The center box represents a controlled access zone with gateway/jump-host functions. The right box represents one approved OT engineering host. The connecting lines represent policy-controlled sessions. They do not imply unrestricted network routing between all three zones. Each boundary must enforce the approved destinations and services. No direct Internet-to-controller path is shown. The drawing is a teaching concept, not a complete firewall, identity or high-availability design.

Worked through

A vendor specialist needs to examine exported diagnostic logs on ENG-01. The operations owner approves access from 14:00 to 15:00 on the stated maintenance date. The ticket identifies the named user, task, approved managed device/access method, MFA requirement, gateway/jump path and ENG-01 as the destination. It allows log review only. Controller writes, unrelated cells and software installation are outside the scope. The local operations contact remains available. The access system records authentication and relevant session events, with session activity recording where approved and supported. The ticket names the person responsible for closure and evidence retention. The logs are assumed already exported through the owner’s process; this scenario does not authorize extraction from controllers.

Worked through

Express the requirement as source identity, approved device/session context, destination, required service, permitted task and validity window. Add the responsible owner and evidence reference. For RA-01, the destination is ENG-01, not the whole OT subnet. A generic “vendor VPN allowed” statement is too broad to describe the intended task. The exact technical controls and required ports must come from the approved system design. No port-opening recipe or live configuration is provided here.

Original scope-change exercise

At 14:35, the specialist asks to edit PLC logic to investigate a suspected fault. That work is outside RA-01. Record the request and refer it to the control-system change process. Do not broaden the current permissions because the user is already authenticated. Authentication establishes identity; authorization defines which actions are allowed. If approved later, the new work needs its own scope, operational coordination, prerequisites and rollback arrangements.

Original timing exercise

The access window is 60 minutes long. The specialist finishes at 14:42, 42 minutes after the start, leaving 18 minutes in the original window. The task’s early completion is a reason to close the session and remove the temporary authorization through the agreed process. Do not treat the remaining time as permission to explore other systems. Verify the actual access state. A ticket marked closed is not evidence that an active session ended or a temporary rule expired.

Preserve operations

Review proposed segmentation changes against known traffic flows, application behavior and recovery requirements. Blocking an undocumented but necessary service can disrupt operations. Use the site’s approved testing, maintenance window and rollback plan. Do not run broad active scans, interrupt controller communications or test emergency disconnection on a live process solely for this lesson. The plan should define how access can be ended safely when needed and who coordinates that action with operations.

Evidence to retain

Keep the approval ticket, identity and destination scope, access start/end records, relevant logs, exceptions, changes authorized separately and confirmation that temporary access was removed. Protect sensitive logs and credentials under the site’s handling rules. The instructional example uses fictional names and contains no real secrets or target addresses.

Practice questions

1. Does using fiber enforce segmentation?
2. Does a VLAN label alone prove an effective access boundary?
3. What destination does RA-01 authorize?
4. Does successful MFA authorize PLC logic changes?
5. How long is the window, and how much remains at 14:42?
6. Why verify session termination instead of relying only on ticket closure?
7. What must be considered before changing OT access rules?

Answers

Where beginners go wrong

Sources