Merger with Overlapping IP Ranges and Two Label Taxonomies

The existing firewall rules are unsafe because the two companies share the same address space. A rule that permits 10.10.1.5 to reach 10.10.2.20 on SMB may match a host in Company A, a host in Company B, or both, depending on routing. The broad 10.10.0.0/16-to-10.10.0.0/16 rule effectively permits large-scale east-west traffic across the merged estate, which is exactly the lateral movement path ransomware needs.

Label-based policy changes the selector from IP address to workload identity. If every workload carries consistent labels for organization, application, role, environment, and location, the PCE can allow finance app servers in Company A to reach finance databases in Company A without permitting unrelated Company B hosts that happen to share an IP range. Labels also make policy readable and portable across cloud and on-prem. The caveat is that the labels must be unique and consistently applied; overlapping IPs are tolerable only when policy does not depend on IP as the primary identity.

Recommend a single merged taxonomy before connecting the networks. Add an org dimension, for example org=A or org=B, and standardize the rest as app, role, env, and loc. Map B's function to role, service to app, stage to env, and site to loc. Keep the original B labels temporarily as custom labels for traceability, but do not build policy on two parallel schemes. Ensure application names are globally unique; if both companies have an app called checkout, rename them with an org prefix.

For PCE architecture, prefer consolidation to one PCE if the VEN versions and network path allow it. A single PCE gives one policy model and avoids split-brain rules. If consolidation cannot happen within 60 days, keep the two PCEs but enforce a shared taxonomy and document which PCE owns which workloads. Do not attempt cross-PCE label policy until the integration is proven. For the 20 percent of B workloads without VENs, either deploy VENs before inter-org enforcement or keep those workloads behind network ACLs and out of the label-based trust zone.

1. Build visibility first. Connect flow data from both PCEs and network taps where possible. Identify actual inter-org traffic, not just what the firewall permits. Rank flows by sensitivity and by whether they use SMB, RDP, or database ports.
2. Normalize labels and fix ownership. Complete the org/app/role/env/loc mapping and assign owners for the 20 percent of B workloads without VENs. Do not enforce on unlabeled workloads; they will either be excluded or blocked unpredictably.
3. Enforce a narrow inter-org deny set at the boundary. Block SMB and RDP between Company A and Company B at the interconnect first. These are high-risk lateral paths and usually not required for merger integration. Allow only documented integration flows on specific ports.
4. Use selective enforcement on high-risk workloads. Start with domain controllers, backup servers, and finance databases on both sides. Build allow rules from observed traffic, then enforce. Expand ring by ring.
5. Treat IP-based rules as temporary. If the PCEs remain separate, the boundary firewall will still need IP lists, but those lists must be small, documented, and reviewed. Do not rely on the old /16-to-/16 rule. Measure progress by reduction in permitted inter-org ports and by percentage of inter-org traffic covered by label-based policy.