Using SVR to Avoid a SolarWinds Network Segmentation Hack
In the news recently, there was a reported major infiltration of a WAN network, in which unauthorized entry was obtained through how network segmentation was configured. Provisioning security in multiple elements, where everything must be perfect, is exceptionally hard. Sprinkle a large number of these devices over a large geographic area, then add in different interface types (DSL, DIA, LTE), and one can have a real mess on their hands. If one must use CIDR block masks or ACL’s that are unique at each location or define specific translations at each location, it may be untenable.
Our WANs need to support security zones that span from a branch location to a datacenter or cloud. This is essential for compliance in many cases. PCI for example requires complete network segmentation for elements involved. Some of the techniques for this today include:
• Carrier based MPLS
• L3VPN with VRFs
• Large numbers of /28 routes with virtual firewalls/NATs
• IPSEC Tunnels for each security zone
All of these methods are complicated and require very specific provisioning that is often site-specific. When every network element is uniquely provisioned, network management becomes very difficult. Even with NET-OPS techniques, mistakes can be made. Furthermore, resolving issues and debugging connectivity can add considerable operating expenses.
The site-specific configuration complexity can make the network as a whole vulnerable to attack. A configuration mistake in MPLS can provide unfettered access to a customer’s network. Managing a large number of VRF’s requires deep attention to detail as the address spaces are overlapping and identical, and a mistake can have dire consequences. VRF’s also require MPLS underlays that include LDP protocols. The stack of complexity and coordination between layers opens up new attack vectors for hackers. Often the tools used to provision and monitor this stack of complex protocols open up additional vectors of attack (i.e. SolarWinds).
What is needed is a very simple way to manage network segmentation. This need will be multiplied manyfold as 5G network slicing becomes prevalent. The requirements for network segmentation (in priority order) are:
• A limited set of branch configurations that are identical and tested
• Mapping of branch segmentation techniques (VLANs, CIDRs, Interfaces) to global namespace (multi-customer, muli-site)
• Specific network routing table per namespace
• Directional controls (i.e. ACL’s and Access Controls)
• Unique authentication and encryption for each namespace
Juniper Network’s Secure Vector Routing technique can address all of these. With secure vectors, security zones (VLANs, CIDRs, Interfaces) can be mapped to a hierarchical namespace that uses “domain like” words. For example VLAN 1 could be mapped to a tenant called “voice.company1” at one location, while VLAN 2 could be mapped to tenant “voice.company2” at another. Because of the hierarchical text name, there is an unlimited number of segments available. Because words are used that humans understand, errors are far less likely. The hierarchy also allows different available route tables that are nested, which is not possible with VRF’s or VLAN’s. Using named tenants also fits in very nicely with how 5G slices are intended to work.
After defining your tenant name spaces, services can be defined that enable connectivity. Services are collections of workload addresses or a range of addresses. Most useful SaaS services have many ranges of addresses that are frequently updated. Office365, Zoom, and most SaaS vendors publish their lists of CIDR blocks where their services are delivered from. With Secure Vector Routing, a word is used to describe services, which is in fact this collection of destinations.
To make the segmented network easy to manage, we now have a simple text-based word for both a group of clients (A Tenant) and a group of workloads (A Service). Juniper’s Secure Vector Routing combines these two concepts at route resolution time to create a globally manageable set of service-specific vectors for WAN management.
One advantage of Juniper’s Secure Vectors is that they extend into public and private clouds. None of the current public clouds support VLAN’s. They do support simple route tables and ACLs. But as soon as you run a Juniper Session Smart Router in the cloud, you can now have branch to cloud network segmentation that works without any cloud-based API’s.
WAN Network Segmentation is too complicated. These complications create points of vulnerability. Juniper’s Secure Vector Routing can simplify and mitigate this.
Contact us to learn more about Secure Vector Routing and how to simplify your network to avoid a SolarWinds type network segmentation hack.