The Road to M&A Hell is Paved with Good (IP-based) Intentions

Originally published by Zscaler.

Written by Martyn Ditchburn, Director of Transformation Strategy, Zscaler.

TCP/IP-based communications have been the cornerstone of corporate networks for more than 30 years. Organisations like Cisco excelled at training an army of mechanical TCP/IP converts who trained countless others to create company networks based on the address space 10.0.0.0/8. The primary hosting location (core network) usually began with 10.1.0.0. Beyond seeding an initial address space for CORP.NET, network admins could pretty much use this address space however they wanted.

As TCP/IP networks grew to accommodate additional office geographies, hosting locations, and flexible working practices via VPNs, subtle differences in network address space crept in. For one company, 10.10.0 is the Singapore office. For another, it could represent a branch in Brazil.

The reality is, TCP/IP works brilliantly when everything is uniform and contiguous. Extending networks is a breeze when you have something new and shiny to plug in. A problem arises, however, when bolting together two things that are the same. What if you want to join two networks together?

This is the harsh reality when technically joining two organisations. Address spaces overlap and are often not contiguous.

Clash of the networks

Overlap in the IP address space creates a consistent challenge when bringing two organisation networks together because the addresses invariably clash. “Use network address translation,” I hear people say.

Well, yes, NAT and double NAT are viable approaches and will work well for small organisations with few locations. But this simply isn't practical for joining two or more large corporations or for serial acquirers with many disparate networks.

I have seen many a network team member display signs of PTSD from joining networks together during M&A scenarios. The speed at which board members expect combination activities to take place puts massive pressure on already overloaded teams. The added complexity of these environments makes ongoing support and maintenance an even heavier burden. Success is never guaranteed and can take many months or even years to complete, if it happens at all.

Let’s take a closer look at some of the typical features of these classic network integrations:

1. The establishment of a VPN or dedicated circuit – Complicated by IP address space clashes resulting in use of complex NAT, having to Re-IP one or more locations results in complex global routing tables. This can take months to resolve.
2. A poor user experience – Unlike mesh networks or well-thought-out hub-and-spoke architecture, users on both sides of the organisation can experience poor performance during M&A integrations due to backhauling traffic or saturation on a small number of bridging connections. The number of these links is often dictated by where security appliances are located or what’s possible given the available network address space.
3. Pervasive security issues – “Buying a breach” is a common concern for CISOs during M&A. Transactions often require additional endpoint software and the need to align antivirus, monitoring, and patching agents. These are costly to buy and difficult to maintain. Data loss is also a significant concern for organisations forced to downsize their workforce. Disgruntled insiders are a real threat and often prompt the purchase of complicated DLP tools.
4. Firewall explosions – Preventing lateral movement often requires additional firewalls. Larger, expensive appliances might be needed to accommodate the extra traffic. The resulting data volume can overwhelm teams and leave them poorly positioned to meet strict project deadlines.

I would expect an average timeline of 3-6 months to complete

Such integrations can take three to six months, and invariably result in sub-optimal expense and complexity, not to mention overburdened support teams and frustrated users. In short, foul-tasting network spaghetti!

The price of doing business?

IT teams have struggled with mergers and acquisitions for over two decades. But what can be done? I have tried a range of alternate solutions, including VDI, app streaming, multiple VPNs, and a host of other cloud-based options. None were a silver bullet. Why? Because they all are either based on principles of TCP/IP-based networks or compromise the user experience.

So, how do IT teams save themselves the trip to M&A integration hell? Well, in short, abandon all hope of using a network. Zero trust architecture is a far more elegant solution to the problem. A software-defined, cloud-based platform approach offers greater flexibility and a single solution for addressing connectivity, security, and user experience.

Let’s look at the same M&A integration concerns, this time through the lens of zero trust network architecture (ZTNA):

1. Connectivity – ZTNA leverages proxy-based architecture to give users access to private apps without bridging networks. Deploying connectivity endpoints on any cloud or virtual hosting platform allows for rapid deployment. It serves as an overlay, so any internet-capable method can be used (and every company has more than one of those). Internet bandwidth is also far cheaper and quicker to obtain than dedicated circuits.
2. A great user experience – Because ZTNA appliances can operate on any network medium, any number of them can reside right next to existing applications. There is no backhauling of traffic. Being able to plug in multiple identity solutions means both organisations can use the same connectivity endpoints irrespective of their identity integration progress.
3. Security – Zero trust platforms often come with unifying agents that provide access to various security capabilities, including DLP, sandboxing, TLS traffic inspection, and CASB. This means they are simple to deploy and easy to maintain. In addition, they can log each transaction and, through the scaling capabilities of cloud, accommodate any traffic through point without additional expensive hardware.
4. Firewalls – Fundamentally, ZTNA does not join networks together. Therefore, there is no need to purchase additional firewalls to accommodate it.

Abandoning TCP/IP connectivity in favour of a zero trust approach was, for me, the silver bullet I was looking for. Integrating in a matter of days saves time and money better spent on new products and services that contributed to a stronger bottom line. Never again will I use classic, network-based approaches to joining companies’ networks together and neither should you.