A colleague recently asked me if SD-WAN could be leveraged to expedite network integration as a result of a merger or acquisition. His thoughts were that this could potentially provide a means to securely integration networks in a short amount of time.  At first I thought this made no sense — SD-WAN is not related to this challenge whatsoever. However, the idea stuck in my head like a bad catchy tune. I started thinking… maybe in certain circumstances this could work?  This post is a collection of some ideas I’ve been brewing with respect to the secure and timely integration of disparate networks using over-the-counter SD-WAN.

Mergers & Acquisitions

Whether entities are merging, separating, being acquired, or simply expanding to Greenfield locations — it’s the application and business requirements that are the most critical components driving design and implementation strategies.  Mergers and acquisitions are one of the most challenging types of integrations. Here we’ll be looking at just a single portion of the M&A – network integration. 

Information gathering is first task to accomplish when approaching a network merger.  Some common questions and requests include:

General Request for Information

• How many locations are in scope?
• Network diagram(s) outlining the WAN design.
• Network diagram(s) outlining security design.
• Sample configuration files (e.g. HQ, remote site)
• High level IP design (e.g. Showing summarization per region, location, etc.)
• List of most critical applications, and if they’re hosted internally or elsewhere

Connectivity

• Which circuit types are currently in use at remote sites (e.g. T1, MPLS, Broadband, LTE, combination)?
• For each standard site type, what is the number of circuits in use?
• Is the connectivity configuration the same for all remote sites?
• Who are the incumbent service providers providing WAN services?
• Is this a “wires only” service or a managed service?
• Are any cloud applications currently in use? If so, how are you currently connecting to them?

Routing

• Which IP protocols are in use (IPv4, IPv6)?
• Which routing protocols are in use on the WAN?
• Which routing protocols are in use for internal routing?
• Which VPN technologies are in use, if any?
• How is Internet traffic routed?
• Are sites permitted to communicate directly with each other, or does this hair-pin through some central site(s)?
• What is the impact of a WAN/circuit outage?
• Is QoS in use between sites? If so, is it currently guaranteed end-to-end?
• What percentage of traffic is Internet-based?
• Please provide bandwidth levels ingress and egress for the sites including average and peak utilizations.
• Are DCIs in use, extending L2 between data centers/colos for workload mobility or DR purposes?
• Is multicast in use, either intra-site or inter-site? 

Segmentation

• What segmentation if any is utilized on the WAN (e.g. VRFs, FWs, etc.)?
• How many sub-networks exist within a site?
• What segmentation if any is utilized on the LAN? 

Platform

• Which network and security platforms (make/model) are currently in use?

Security

• Are sites running a local firewall? If so, please describe.
• Are sites running a local IPS? If so, please describe.
• Are sites performing URL filtering? If so, please describe.
• Is NAC in use? Wired and/or Wireless?
• Are there trust boundaries?

Voice

• Is VoIP utilized at the remote sites?
• Is SIP in use between remote locations and a central data center(s)?
• Is SIP in use between remote locations?

Tools & Monitoring

• Current OAM and Management tools and capabilities
• How will the merged network be monitored?

Operations

• Do you have dedicated WAN engineers or are they part of a general Networking/IT team?
• How large/small is the organizations staff and workload to support the initiatives?
• Do you have an outsourced IT Support or is the WAN supported internally only ?
• What is the expected growth over the next 3-5 years?

M&A Specific Questions

• What are the security policies and parameters for each individual network?
• From a security perspective – a third-party audit should be considered to determine state of security.
• How will the merged network be monitored and administered?
• Where is redistribution currently being performed?
• Is it possible to consolidate onto a single IGP?
• If MPLS is in use, has an Inter-AS VPN solution been considered?
• What are the HA and FT requirements?
• Any single points of failure (SPOF) to be concerned about?
• What is the convergence time of the network, and what is the required convergence time of a single component failure?
• Is it possible to decommission any data center or POP locations to simplify operations and/or reduce costs?
• Has any network capacity planning been performed?
• Are there plans to merge WLAN (wireless) networks?
• If IP overlap exists, is NAT an option?
• Will the final merged network need/support Qos?
• Will the final merged network need/support Multicast?

Mergers & Acquisitions – Safety first

Security advisors from each entity will naturally distrust the procedures and protocols in place at the opposing entity.  This is not due to disrespect, it’s organically rooted in a Zero Trust ideology prevalent in the minds of security-centric individuals. Each component of a network will be under scrutiny. It is the responsibility of the advisory teams to cooperate and negotiate on go-forward strategies with respect to each security layer within the business model. If this is an acquisition – it’s not uncommon for the acquiring entity to dictate security policies and architecture. If this is a merger, there are typically two solutions when addressing disparities in the alignment of security policies and architecture:

1. Consolidate onto the more thorough policy with respect to the security layer in question
2. Develop a new policy or architecture alignment that meets the requirements for each entity

Connecting entities

Once it has been decided to connect disparate entity networks, decisions must be made to determine how.  Ideally, networks are connected via high speed enterprise-grade circuits. The cost benefit for organizations to quickly integrate and consolidate often challenges this approach due to the significant delay with provisioning. 

 

Because of this, network mergers often start with IPSec VPN between the two entities. Not only does it can take several months to get enterprise-grade circuits provisioned to connect the two entities at proper locations, leading to significant delays in integration, but VPN is also initially preferred due to minimal impact from a routing and security perspective. VPN is by no means a long-term solution. However, VPN can be relatively simple to instantiate with minimal impact to current architecture.  VPN devices typically support NAT.  This is important because IP Addressing overlap will likely exist between merging networks.  NAT at either end will guarantee that the IP addresses map to some other non-overlapping IP space.  From a routing perspective, merging entities can decide whether they desire to statically route networks over the crypto domain, or exchange routes dynamically with a routing protocol such as OSPF, EIGRP or BGP.  Each option comes with its own challenges and benefits and will depend on the environment capabilities.

Important to keep in mind, VPN will typically utilize the pre-existing circuits, creating a tunnel that now competes with production Internet traffic between entities.  This raises a new series of questions. How much bandwidth is available?  Can egress traffic be prioritized to prevent congestion? How does this impact SLAs?

From a security perspective, terminating VPN tunnels behind a DMZ will allow for greater control and visibility of the communications traversing the path.  Firewalls, intrusion prevention systems, anti-malware systems, and security packet brokers can be leveraged on each side of the tunnels before permitting traffic to enter the LAN. Ideally, a centralized SIEM will monitor all devices and flows between these network paths. However, too often are networks merged and firewall policies relaxed because both sides are under pressure to expedite whilst neither side fully understands what is actually needed. This blind trust leads to poor design, undocumented band-aids, and unnecessarily privileged access. Certain vulnerabilities may be detected between networks, but who is to say that user X should be capable of accessing application Y?

SD-WAN – An Alternative Approach

Some of these challenges can be overcome with the advent of technologies such as SD-WAN.  First, instead of waiting for costly and arduous enterprise circuits to be provisioned, and instead of tunneling VPN traffic over pre-existing Internet circuits, consider the alternative of rapidly procuring fast commodity Internet circuits at each site. These types of circuits can be turned up in days, provide high speed connectivity and are extraordinarily low cost. Moreover, you can bundle multiple circuits at each site, increasing available bandwidth and intelligently routing particular traffic over particular paths.

Other benefits include integrated security, deep application visibility, and policy centralization.  Rather than excessively permitting access by blinding opening firewall rules, a better approach is to centralize intelligence and start profiling communication over the links to appropriately build least-privilege access policies.

Seizing Opportunity – Internet Edge Post-M&A

Each entity being merged will have a number of Internet egress points.  This could be anywhere from a small handful to tens of thousands.  Determining routing requirements such as public IP space and BGP consolidation is critical, however, protecting the public edge is of the utmost importance. Sometimes it is decided to utilize the mature security strategy of a single entity and replace or consume the edge security operations under a retrofitted architecture.  Herein lies significant challenges with integrating, managing, and monitoring multiple security solutions at multiple entities. Companies have a tough enough time as it is maintaining their current setup of security applications at all of their locations.  Such applications include unified threat management, firewalls, IPS, AV, Proxy or URL filtering, access control, and data protection.

 

Let’s consider a potentially better and more modern approach by adopting a new security architecture that covers all merged entities. The logic behind this is twofold.  First, the new security architecture will serve as neutral grounds for a consolidated security team.  Second, a new security architecture provides the opportunity to scale security, increase visibility, and centralize control. It’s likely the entities are utilizing cloud applications or some flavor of XaaS. Now is a prime opportunity to adopt a new architecture that encompasses Cloud Web Security, Cloud Access Security Brokers, and Software-defined Security.  Putting this all together with SD-WAN between the entities and we’re starting to see the picture. 

My closing thoughts

Will SD-WAN be the answer for all M&As?  Definitely no.  Where do I see this potentially being leveraged?  I see potential for small-to-medium network integrations, especially if time is a concern.  My logic behind this is simple – no waiting for circuits, no reliance on existing Internet circuits, and granular uniformity of security policies while applications and users get on-ramped. On the other hand, maybe it’s ludicrous and overly complicated to consider SD-WAN, whether interim or permanent.  Keep thinking long-term and how integrations can be advantageous for developing new designs and strategies – cloud, DIA, and so on.  Agree or disagree?  Feel free to drop thoughts in the comments. At minimum, it’s a good exercise to think about the challenges of integrating networks. I hope your brain was firing while reading through the post.