This post originally appeared on LinkedIn on July 7, 2020.
After all the effort and long legal hassle, the mission is accomplished: Your merger or acquisition is complete! Two companies are now one. The hard work is done! Well, not so fast.
Now begins a structural process dreaded by many IT teams: connecting two disparate company infrastructures into a cohesive unit. This means long hours, costly process creation, and complex patchwork to provide both sets of users with cross-company connectivity. If only there were a simpler and more efficient way to accomplish these goals. There is: Zero Trust Network Access (ZTNA).
The purpose of M&A is to combine resources for two (or more) companies to advance defined business goals. What often gets in the way of resource availability is access. Different companies use different networks, architectures, and systems to house and distribute resources to their workforce. One of the first CIO priorities during and after a merger is providing easy and—more importantly—secure access to newly acquired or merged data, infrastructure, and applications to people in both companies.
In a perfect world, all acquired companies would come with a straightforward and complete integration plan. Flip a switch, and employees, systems, applications, networks, data centers, and facilities synchronize automatically, no hassles. If only it were ever that simple. Some enterprises create dedicated teams and draft playbooks to standardize integration activities, all in an effort to realize the strategic and financial benefits of acquisitions sooner.
Full system integrations can be extraordinarily complex and—thanks to unanticipated scope creep—more expensive than initial assessment. Cost-constrained parent companies stretch integration out over an extended timeline, ranking system importance and prioritizing the integration process in phases. In the meantime, employees are left to fend for themselves with disparate, isolated systems that don’t necessarily enable cross-communication between users. And the integration phases that do move forward have to fight for resources with competing priorities and initiatives.
This ad-hoc integration approach rarely yields an acceptable outcome. The costs of Integrating legacy technologies into a cohesive network is a nightmare to estimate and contain. Yearly budget refresh cycles often don’t take this integration into account, and the money allocated for updating hardware, systems, and applications isn’t sufficient for one company (let alone two). This leads to ongoing maintenance and security efforts for multiple disparate networks—which is its own cost and resource nightmare.
Companies attempting to integrate legacy network and security infrastructures after an acquisition or merger often resort to “creative” ways to get users access to resources in disparate networks—jury-rigged efforts that could poke holes in firewalls and secure access protocols. And with these jury-rigged solutions come increased security concerns, user issues, and troubleshooting nightmares for IT. Operation teams spend countless hours trying to identify and resolve issues due to the network address translations (NAT), routing, and firewall rule manipulations.
Fully integrating two legacy networks can be a costly and time-consuming process. Newly-acquired infrastructure may not natively offer employees access to parent-company applications. And parent-company employees may not have access to newly-acquired resources. So IT outfits employees with VPN connectivity. These VPN connections work, but strain network resources—especially as the number of VPN users climbs. Worse, the increased VPN connections extend both networks’ attack surfaces.
VPN access is a poor substitute for direct connectivity. Managing it is costly, and VPNs introduce risk. And of course, dealing with more than one acquisition at a time further complicates these issues. The VPN approach produces gaps in security: But how can you avoid incurring that risk? The (unintuitive) answer is to not converge networks in the first place.
ZTNA provides a simple solution: Add connectors to each network data center, add a software agent to each user’s device, and set policies that allow users to connect to the applications they need, accessible from either network (or from wherever users connect).
ZTNA uses policies to authorize user access to applications and networks. ZTNA accelerates M&A time to value, providing cross-company connectivity for users in weeks rather than months or years (or never!).
ZTNA (also known as a software-defined perimeter, or SDP) is a set of technologies that operates on an adaptive trust model: Trust is never implicit, and access is granted on a “need-to-know,” least-privileged basis as defined by granular policies. ZTNA gives users seamless and secure connectivity to private applications without ever exposing the network, apps, or data to the internet. Connectivity is direct, delivered via nearby computing-edge cloud services, and accessible from anywhere. (In this way, ZTNA can ultimately supplant a corporate network with outdated perimeter security.)
Unlike network-centric solutions like VPNs or firewalls, ZTNA takes a fundamentally different approach to securing access to internal applications based on four core principles:
With ZTNA in place, IT may never need to bother with full acquired-company-infrastructure integration. Managing user access to authorized applications (governed by user- and app-centric policies) provides application segmentation without requiring network segmentation. Once a user is added to a policy and application authorization is granted, a user can gain access to an application on either network without requiring the networks to be connected.
Managing integration complexities like IP remediation and circuit overlaps isn’t trivial: Merging networks is complicated, time-consuming, prone to error, and expensive. ZTNA provides immediate access to internal resources for joined organizations. And—for whatever reason—if a parent company still wants to integrate acquired infrastructure, that work can be conducted behind the scenes and without the same urgency, since users already have access to necessary resources/applications. With the proper planning, systems can be included in the budget planning cycle and then migrated during refresh either to an enterprise data center or the cloud.
ZTNA never inherently trusts anyone from inside or outside the network until verified. (ZTNA removes the distinction between “inside” and “outside” since connectivity is secured between the user and application. Security is not based on gateway access through a secured network perimeter.) Access to internal business systems or applications can be granted only after authorization. Network access is not required, and applications are masked from the open internet.
After M&A activity, ZTNA allows IT teams to focus on integrating data, systems, and applications on their own terms, where and however it best meets the business’ needs. In the meantime, workforces from each company can access whatever resource they need, wherever it may be, and from wherever they may connect without complex network integrations, without VPN security exposure and resource use, and without expensive retooling of network architectures.
Pamela Kubiatowski is Sr. Director of Transformation Strategy (Consultant) at Zscaler.