“This last year has been challenging, but the IT industry has really stepped up to ensure that users are able to work remotely safely, and everyone should be proud of what’s been accomplished so far,” says Reid Nilson, Senior Field Security Architect, speaking at CDW’s BTEX 2021 virtual event. “However, with users working remotely, it’s driven home the fact that the traditional security platform is changing.”
It’s 10 p.m. – do you know where your users are?
“If you think about where our users and applications are today, they could be anywhere,” says Nilson. “Users may be at an office location, or they could be working from home. Applications may be in the data centre, or they could be hosted on software as a service (SaaS).” That’s why it’s time to examine how the remote network branch edge can be built to support this changing security perimeter.
Drivers for network branch edge modernization
“In discussions with customers across Canada, they’re all in different spots in their IT journey,” says Nilson. “Some were early adopters of SaaS applications like Office 365, Salesforce or G Suite, and others are just beginning the cloud journey. For many clients, this journey starts with a hybrid environment, where they have a mix of on-prem and cloud applications.”
“Another change has been the evolution of new, as-a-service offerings, such as virtual desktop infrastructure (VDI) or bare metal. These new services are forcing the network connectivity layer to be able to connect to these new applications. Remote branch sites are typically connected using private MPLS circuit, MPLS in combination with IPsec VPN, or an internet connection with a VPN tunnel.”
“These solutions tend to be static,” says Nilson. “For MPLS sites, new sites could be added to the MPLS private network, but this would require engaging the service provider, and they would build out a new connection, that typically takes months. Other challenges for MPLS is that connections may be constrained to the region that the service provider is active in, or the available bandwidth from that particular connection isn’t enough.”
“IPsec VPN is more flexible to add tunnels, but it does require that both sides of the connection be configured, and for full mesh or large networks, this just isn’t scalable.”
Challenges with legacy solutions
“When we look at how these solutions operate, they typically rely on the routing table to make decisions about how to steer traffic,” says Nilson. “If the site has a single internet or MPLS connection, this is easy, because the traffic only has one way to go. But if the remote site has multiple connections, then it gets a bit trickier. Legacy solutions will generally have features for load balancing or prioritization of the links, but this still relies on the routing table and can get complex. The branch network device will only be aware of the status of directly connected interfaces. If there are problems upstream, in the provider network, it may not be able to detect those problems, such as latency or packet loss, and will continue to use that link.”
“The network branch device may also have a limited awareness of application traffic. Using quality of service (QoS) in the past to mark traffic properly is tough, and having application awareness built in, without marking, with QoS, makes it a lot easier to prioritize traffic.”
“When I talk to customers that have these challenges, I would talk to them about SD-WAN. And there are a lot of SD-WAN vendors out there.”
3 must-have features for SD-WAN solutions
- Centralized management console: For SD-WAN solutions built from the ground up, this will typically be a SaaS offering that’s including with the licensing for the overall solution. Other vendors will have a management appliance that the customer is responsible for deploying, either in the data centre or in an IaaS provider in the cloud.
- Zero-touch deployment: When an appliance is connected to the management solution, it will be assigned to the customer portal based on serial number or other identifiable information, and will be available for the customer to claim. Once it’s been claimed in the console, the device can be configured remotely. When you have a large number of sites, it’s a lot easier to have the vendor ship the device right to the site rather than bringing it pre-configured to a central site, shipping it out, and hoping that it works.
- Analytics: Each SD-WAN vendor will have a number of reports built in to the management console, including top applications and utilization, and may include user information, depending on the integration with the customer environment.
“All of these features put together make it a really compelling solution, even if the sites only have one internet connection,” says Nilson.
Network security considerations for SD-WAN
Any organization must have security as a core consideration, says Nilson. “When we have a new SD-WAN device connecting to the network, and it dials home, that device must be authenticated and validated before it is allowed to connect to the network.”
“Each SD-WAN solution will offer some type of segmentation at the branch level. Use cases for this segmentation would be creation of a dedicated, internet-only zone for a guest wireless network, or an isolated network that can only reach a data centre for PCI compliance.”
However, inter-zone communication can vary between SD-WAN solutions. “Generally, solutions that are SD-WAN from the ground up will have basic firewall functionality, but firewalls with SD-WAN add-on licences will have complete NGFW features like threat and sandboxing. When considering zoning at the site, the main consideration is what kind of east-west traffic there is, and what inspection is needed.” For Guest and PCI zones, there would be no east-west traffic, as they are isolated from everything else in the branch.
“If the branch solution we’re looking at is meant to address backhauling internet traffic to a hub location, we still have to consider some type of URL filtering, and possibly sandboxing, at the site,” says Nilson. “For some solutions, you would be looking at a secure access services edge (SASE) solution, which could provide those features like URL filtering, in combination with an SD-WAN appliance.”
Using SD-WAN solutions for applications in the cloud
“If you’re looking at deploying a new cloud solution in infrastructure as a service (IaaS), then you can deploy SD-WAN appliances to that particular cloud provider and then build tunnels to that application from your hub site,” says Nilson. “When we’re talking about applications, it’s really important that SD-WAN has that application awareness, especially if we’re looking at sites with multiple transport connections.”
“When it comes to transport, it could be LTE, internet or MPLS, and we may have preferences on where particular applications go. Within the SD-WAN solution, we’re able to build out policies through the management console to have one of those links serve as the first option for an application like VoIP. If we retain our MPLS solution, because we’re able to get really good quality from our provider, we’re able to steer that VoIP traffic onto that connection and keep it there.”
“But if we encounter problems, we have enough information coming from the network, and that SD-WAN appliance has enough intelligence to make a decision that this link isn’t healthy anymore, and I need to switch over to another one,” Nilson says. “With SD-WAN, we would typically have a device at the remote network, and one at the data centre, and they’re able to exchange information about their pathing as well.”
“Adding all these things together with the management console allows the administrator to define policy centrally, so instead of going to every single device, they’re able to go to one spot, and push this policy to all devices. This is really a big advantage for large-scale networks.”
Make sure to bookmark this page for more coverage of BTEX 2021.
