conduit-security-designlisted

## When to Use - Specifying security controls for conduits defined in the zone design. - Hardening an existing conduit found permissive during audit. - Designing a new zone-to-zone flow before it is deployed. - Producing the conduit register that firewall teams implement from. ## Prerequisites - Zone and conduit design from `ot-network-segmentation-design` with the conduit list. - Observed traffic baseline from `passive-ot-network-discovery` for each conduit. - Protocol capability per conduit: which protocols support TLS, signing, or authentication natively. - Firewall platform capability for the boundary device. - Credentials: none. This skill produces documents. - Authorization: security manager and network owner review the completed register. - Upstream skills: `ot-network-segmentation-design` for the conduit list. ### Safety This skill is passive. It produces design documents only. ## Workflow 1. Per conduit, record the traffic ground truth from the baseline: protocol, direction, source and destination pairs, session rate. A conduit spec that contradicts observed traffic will fail at implementation. 2. Flow direction decision. Requirement: sessions originate from the more trusted zone where the protocol allows it. Anchor: SR 5.2. Decision: controller responses to HMI polls are replies, not sessions. New-session initiation from L1 or L2 toward L3 is denied unless a named function requires it. Trade-off accepted: some legacy protocols need the controller to open the