Interconnecting an Acquired Firm with Overlapping Addresses
Vertex Systems is acquiring Nimbus Labs, an 80-person software firm whose network uses 10.0.0.0/8 internally, overlapping Vertex's own 10.10.0.0/16. Vertex wants immediate access for Nimbus staff to a file server in its core, and for 12 Vertex engineers to administer Nimbus build servers. The proposal is a single IPsec tunnel with no NAT, flat routing between both estates, all Nimbus staff placed on Vertex's corporate VLAN, and no traffic inspection. The deal closes in 60 days; full re-addressing is planned for month nine. Nimbus has no central logging and its firewall is managed by a local integrator. The security architect must choose between an IPsec site-to-site gateway and a remote-access VPN, and define controls using ISO/IEC 27033-4 and -5.
1. Should Vertex use an IPsec site-to-site gateway or a remote-access VPN for the interim integration? Justify the choice.
Read the worked answer
Choose an IPsec site-to-site gateway for the defined server-to-server and admin use cases, not a remote-access VPN for all 80 Nimbus staff. The requirement is controlled interconnection between two estates, which is the 27033-4 gateway scenario; a remote-access VPN (27033-5) fits individual users but would put 80 staff on Vertex's corporate VLAN, creating a large trust boundary expansion with no need. Because the address spaces overlap, a plain tunnel with flat routing will fail or create ambiguous routes. Use a gateway pair with NAT on the Nimbus side, or a routed VRF/isolated tenant, and publish only the specific file server and build-server destinations. Terminate the tunnel in a DMZ, not the core. Restrict source/destination, protocol and time windows; require MFA for the 12 engineers; log all sessions. A remote-access VPN may be a temporary exception for a few named engineers, but not the default for the whole acquired company.
2. What controls are needed to handle the overlapping address space and the low-trust acquired network?
Read the worked answer
Overlapping 10.0.0.0/8 and 10.10.0.0/16 means you cannot simply route both estates. Options: NAT the acquired servers to a dedicated range, use a VRF/isolated routing instance, or re-address early. For the 60-day interim, NAT plus strict firewall policy is pragmatic; document the translation table and avoid hiding the overlap from monitoring. Put the acquired network in a low-trust zone and the shared file server in a DMZ, not the core. Do not place all Nimbus staff on the corporate VLAN; that gives them broadcast and lateral reach. Require MFA and device posture for the 12 engineers, and a separate jump host for build-server administration. Inspect the tunnel traffic with an IPS/IDS if capacity permits; otherwise log flows and enforce allow-lists. Record the interim design as a time-bound exception with a month-nine re-addressing milestone and an owner.
3. Define monitoring and incident-handling measures for the interim third-party connection.
Read the worked answer
During the interim, monitor the tunnel as a third-party conduit: log tunnel up/down, source/destination, bytes, and denied flows; send Nimbus firewall and authentication logs to Vertex's SIEM if legally and technically feasible. Define an incident playbook for suspected compromise of the acquired estate: isolate the tunnel, disable the NAT translations, revoke the 12 engineers' credentials, preserve logs, and contact the Nimbus incident lead. Because Nimbus has no central logging and a local integrator manages its firewall, set a contractual security schedule: patch SLAs, log forwarding, notification of incidents, and joint exercises. Do not assume the acquired firm's controls are equivalent. Review the exception at 30 and 60 days. The month-nine re-addressing should be treated as a security milestone, not only an engineering task, and the risk register should show the residual risk of flat routing and limited inspection until then.