Purpose
Contain compromise without interrupting care
Segmentation does not prevent every phishing email, stolen credential or vulnerable device. Its purpose is to stop one foothold becoming an organisation-wide incident. RACF-CC prioritises explicit traffic flows, protected management access and containment of devices that cannot support modern endpoint controls.
What good looks like
Trust zones have documented purposes; traffic crosses them only for a defined service need; infrastructure management is isolated; remote access lands in restricted areas; and higher-risk devices have compensating controls.
Risk picture
Common containment failures
VLANs without enforcement
Logical separation offers little containment when broad rules permit unrestricted traffic between zones.
Exposed management plane
General endpoints that can reach switches, firewalls or hypervisors may gain control of the boundaries themselves.
Legacy and connected devices
Unsupported, medical, monitoring, CCTV and embedded devices may expose unnecessary services or weak protocols.
Uncontrolled bridging
Multi-homed hosts, incorrect trunks and wireless mappings can bypass intended inspection points.
Remote-access sprawl
Multiple gateways and exposed services expand the internet-facing attack surface.
Limited east-west visibility
Perimeter monitoring may miss discovery and movement occurring entirely inside the network.
Prioritised action
The RACF-CC network control set
| Priority | Control direction | Outcome | Evidence |
|---|---|---|---|
| First | Restrict infrastructure management to approved administrative paths and harden management protocols. | Protects the controls that enforce segmentation. | Access tests and configuration exports. |
| First | Replace broad inter-zone permissions with explicit source, destination, service and owner records. | Reduces lateral movement and blast radius. | Rule review and reachability tests. |
| Next | Contain legacy, IoT, medical, monitoring and CCTV devices to required flows. | Compensates for limited endpoint protection. | Dependency map and permitted-flow tests. |
| Next | Apply staged access-layer protections and disable unused connectivity. | Reduces rogue-device and local manipulation risk. | Switch baselines and port reviews. |
| Next | Separate corporate, guest, resident and unmanaged wireless access and egress. | Prevents non-corporate activity crossing trust boundaries. | SSID, VLAN, trunk and egress validation. |
| Next | Consolidate remote access and terminate sessions into restricted landing zones. | Contains compromise of an external access path. | External exposure inventory and flow tests. |
| Develop | Add targeted, low-noise monitoring at high-risk boundaries. | Improves internal visibility without unsustainable alert volume. | Alert review and tuning records. |
Safe implementation
A four-phase roadmap
Phase 1
Protect control points
- Inventory zones and management interfaces
- Remove unsafe management exposure
- Review broad internal rules
- Start log-first dependency discovery
Phase 2
Enforce containment
- Create explicit inter-zone allows
- Contain high-risk device classes
- Validate wireless separation
- Stage access-layer safeguards
Phase 3
Improve visibility
- Monitor selected internal boundaries
- Consolidate remote pathways
- Review denied and unexpected flows
- Test containment scenarios
Phase 4
Modernise
- Replace unsafe bridging and legacy dependencies
- Consider stronger access control
- Modernise wireless architecture
- Review segmentation as services change
Map dependencies before blocking
Network changes can immediately affect care applications, monitoring, telephony and remote support. Observe traffic, test representative workflows, approve change and rollback plans, then validate both permitted and prohibited paths.
Observe dependencies before enforcing network boundaries
Audit/log-only → pilot → validate → enforce → monitor → reviewFirewall, segmentation and remote-access changes should begin with traffic evidence and representative path testing, then expand with service-owner approval and rapid rule rollback. Use the Safe Enforcement Pattern →
Contain legacy dependencies deliberately
Segmentation is often a central compensating safeguard, but it needs verified permitted paths, restricted administration, useful monitoring and an accountable treatment decision. Use the legacy-risk treatment guide →
Govern supplier-controlled pathways
Remote support and shared network dependencies need an internal owner, explicit permitted routes, evidence, incident contacts and a workable revocation or exit path. Use the Supplier and Third-Party Risk guide →
Evidence and assurance
Prove that boundaries work
Residual risk and escalation
Record network exposure that cannot yet be removed
What may remain unresolved?
Flat legacy segments, ageing switches or firewalls, broad application flows, unmanaged connected devices and supplier-controlled remote pathways may remain outside the desired boundary model.
Unknown dependencies, care-device limitations, unavailable maintenance windows, supplier control or replacement cost can prevent immediate segmentation.
Restrict internet and management exposure, limit allowed destinations, strengthen identity controls, monitor boundary traffic and document approved remote paths.
The accountable service or device owner owns the operational dependency, supported by network administrators and governance.
Review at the risk-defined interval and after network redesign, supplier change, new care technology or material service migration.
Evidence of lateral movement, active exploitation, unexpected cross-zone access, unsupported perimeter equipment, supplier compromise or control failure affecting care.
Recording does not equal acceptance. Broad trust and legacy connectivity need approved safeguards, ownership and a dated reduction or replacement decision.
References
Standards alignment
- NIST SP 800-207: Zero Trust Architecture — no implicit trust based on location or ownership.
- NIST SP 1800-35: Implementing Zero Trust Architecture — practical implementation patterns.
- NIST SP 800-53 Revision 5 — boundary protection and information-flow controls.
Continue
Reduce the weaknesses inside each boundary
Domain 4 establishes a repeatable way to find, prioritise and remediate vulnerabilities and unsafe configurations.