The Legacy Protocol on the Merged Network
During a merger, a healthcare acquirer must connect its network to a smaller clinic's flat network. The clinic runs an internal application that authenticates users with a challenge-response protocol over an unencrypted channel; the vendor says a TLS upgrade is 'on the roadmap' but not available for 9 months. The clinic's 200 staff need access to the acquirer's EHR, and 30 acquirer analysts need access to the clinic's billing system. The acquirer's security team proposes a full merge (single VLAN, shared domain). The clinic's CISO is uncomfortable. Regulatory scope: the combined entity handles PHI, and the acquirer is under a consent decree requiring network segmentation evidence. Budget allows one firewall pair and a short timeline.
1. Should the networks be fully merged, and how should the connection be architected?
Read the worked answer
Do not fully merge. A flat merge:
- collapses the trust boundary so a compromise on either side reaches PHI on both;
- makes the legacy unencrypted authentication protocol a risk to the acquirer's EHR, not just the clinic's app;
- destroys the segmentation evidence the consent decree demands.
Architecture: inter-network connection through the firewall pair with default-deny and narrowly scoped rules:
- 200 clinic staff → only the EHR endpoints/protocols they need (not the whole acquirer network).
- 30 analysts → only the billing system.
- No lateral routing between the two internal networks beyond those flows; the clinic stays its own zone.
Why this matters for the exam: the question is trust boundary placement, not 'is the protocol bad.' You contain the weak protocol inside the clinic zone and prevent it from becoming the acquirer's problem, while still delivering the business need. Segmentation is also the compliance artifact.
2. How do you handle the unencrypted legacy authentication protocol given the 9-month vendor timeline?
Read the worked answer
Accept it as a contained, compensated risk - not a silent one.
- Scope it: the protocol only runs clinic-internal. Ensure firewall rules prevent that traffic from crossing to the acquirer side, so the unencrypted credentials never traverse the shared link.
- Compensating controls: restrict source/destination to the app and its users; monitor for credential-replay patterns; consider a TLS-terminating proxy or VPN tunnel in front of the app if the vendor permits (often the vendor's 'roadmap' is just packaging - test it).
- Risk acceptance: document the residual risk with owner, expiry tied to the 9-month date, and a review trigger. This is a documented exception, which is what auditors and the consent decree want to see.
- Escalation lever: if the vendor won't move, the business decision is 'accept contained risk' vs 'replace the app.' Put that choice in front of the business owner, not the security team alone.
Trap: refusing to connect until the vendor upgrades - that stalls the merger for a risk that segmentation already contains. Security's job is to make the risk visible and bounded, not to veto the business.
3. What segmentation evidence should be produced for the consent decree, and why does 'we have a firewall' not suffice?
Read the worked answer
Evidence must prove the control works, not that it exists.
- Rule documentation: the default-deny posture, each permitted flow, and its business justification.
- Configuration exports of the firewall zones and rules, versioned.
- Test results: attempted cross-zone traffic that should be blocked is blocked (e.g., clinic host cannot reach acquirer EHR directly; only via the permitted path).
- Change control records showing rules are reviewed and approved.
- Logging/monitoring showing denied flows are alerted on.
Why 'we have a firewall' fails: a firewall with permissive rules or a flat VLAN behind it provides no segmentation. The decree (and any auditor) wants demonstrated isolation - the negative test (blocked traffic) is the proof. A device is not a control; an enforced, tested, documented boundary is.