Security ‘Of’ the Service

Once an enterprise’s connectivity requirements are understood, it’s important to consider how to go about securing the HQ, branches and cloud-based applications. For example, imagine an enterprise with an HQ, branches and cloud connectivity [infrastructure as a service (IaaS) and SaaS] that has signed up to a managed SD-WAN service.

The first consideration must be the security of the service itself, including any underlying transport, as well as the different SaaS applications consumed. Service infrastructure security includes distributed denial of service (DDoS) protection, encryption of user data as well as control traffic, any required certifications such as SOC 2 or ISO 27002, as well as network operations center (NOC) training, security protocols, monitoring and incident response. Where data residency is a requirement, such as GDPR in the EU, the service must follow suit. So, include in any vendor or provider RFI how the solution(s) under evaluation ensures data integrity and reliability. 

Other business process considerations include who will handle key management: the enterprise, the provider, or both, and what this means for how traffic is handled across the WAN. Planners must also have a firm grasp of identity and access management (IAM) requirements/single sign-on (SSO). And, it’s important to consider the ramifications of Shadow IT, where employees access unsanctioned SaaS applications. This is potentially mitigated by monitoring.

HQ and Branch Security Options

HQs have traditionally deployed physical firewalls for connectivity outside of the enterprise, as well as for connectivity—SD-WAN included—to one or more cloud providers. Traffic internal to the enterprise— including cloud workloads such as AWS VPCs—remain within the firewall perimeter. Conversely, traffic to trusted SaaS applications such as Office 365 or Salesforce will traverse a simpler L4 FW and NAT.  Ideally, these IaaS/PaaS/SaaS handoffs are regionally based, optimizing application performance via cross-connects from the SD-WAN provider’s PoPs to the corresponding public cloud or SaaS application. For example, an engineer in Romania would connect via the SD-WAN service to a handoff to AWS or Box in Central Europe, rather than having to backhaul to the US or even to the UK (Figure 2, below). 

Figure 2: Evolved connectivity, with SD-WAN connection to IaaS/PaaS/SaaS and local or
cloud-based firewall for internet traffic

Alternatively, the HQ may dispense with the traditional firewall and rely instead on a cloud-based service, an option quickly gaining in popularity. Considerations here include cloud firewall scalability and geographical distribution, how this impacts provisioned bandwidth, and costs. In any case, the heavyweight security stack is under siege at the branch, now delivered as part of a cloud-based service. Gartner has described this trend in their “Market Trends: How to Win as WAN Edge and Security Converge Into the Secure Access Service Edge” report.