The Second NIC You Were Told Not to Use
You hold local administrator on JUMP01 (10.10.10.15), a Windows server in the DMZ, reached from a web shell on an in-scope application server. JUMP01 has two NICs: 10.10.10.15/24 in the DMZ and 172.16.5.15/24 in manufacturing. Scope is 10.10.10.0/24 and 10.10.20.0/24. The RoE excludes 172.16.5.0/24 and states 'no interaction with OT or manufacturing systems under any circumstances'. Your objective is the ERP database at 10.10.20.40. The DMZ has no route to 10.10.20.0/24; the only path is via 172.16.5.1, a manufacturing router. Before reading the exclusion carefully you ran a single ping from JUMP01 with source 172.16.5.15 to 10.10.20.40, which succeeded. The client contact is unreachable for six hours.
1. Set out your options and recommend one.
Read the worked answer
Four options, and only one is defensible.
(a) Scan or connect from JUMP01 with source 172.16.5.15. The packets are on the excluded segment and the replies traverse an OT router. The RoE excludes the subnet 'under any circumstances', and the source address is part of the subnet. No.
(b) Add a route on JUMP01 sending 10.10.20.0/24 out the second interface. Same objection, plus you would be modifying a dual-homed host that manufacturing depends on. No.
(c) Ask the client to open a temporary path from the DMZ to 10.10.20.40, or to provide a jump host inside 10.10.20.0/24. This is the correct ask, even though it costs time. Every packet stays inside in-scope address space and the change sits under their change control, not yours.
(d) Declare the objective unachievable within the current scope. An acceptable fallback if (c) is refused; document it as a scope limitation rather than a failure.
Separately: the ping from 172.16.5.15 already happened. It is a minor scope breach and must be disclosed with the exact timestamp and the fact that nothing on the OT segment was enumerated, scanned or written.
2. How do you document and communicate this?
Read the worked answer
Write it while the detail is fresh, and write it as a scope-breach disclosure rather than a footnote in the appendix.
Include: the RoE clause relied on; the fact that JUMP01 has an undocumented second NIC, which is itself a finding because a dual-homed DMZ host is precisely the pivot path the client's architecture review missed; the exact command run; source and destination addresses; timestamps in UTC with the time source stated; and the observation that nothing was scanned or written on the excluded side. Preserve the console log and do not tidy anything on JUMP01.
Notify the client contact and the engagement manager as soon as the contact is reachable, not six hours later at the next stand-up. A possible touch of an OT segment is the category of event that gets worse with delay and better with speed.
Then add a control: from now on every command on a multi-homed host runs with an explicit source-interface flag, and the interface list of any host you land on is checked against the exclusion list before you type anything else.
3. Four hours later the contact calls and says 'fine, just do it, we accept the risk'. What is your position?
Read the worked answer
A verbal go-ahead from the same contact does not fix it. The prohibition was 'under any circumstances' in a document signed by someone else, and a phone call cannot overwrite it.
What you need is a written amendment from the RoE signatory that either removes the exclusion for 172.16.5.0/24 or names specific hosts and specific methods, for example read-only routing through 172.16.5.1 with no scanning of OT devices, and states that the client accepts the availability risk. Until that document exists, you stay out.
If they insist and the objective is business-critical, offer the least invasive version: their own staff run the command from their own management host and hand you the output. You get the evidence, they own the action on the OT segment, and there is no ambiguity about who touched what. Record the call, the request, and the amendment status in the daily log either way.