Starting SASE Networking

We have a common goal to achieve this. To move users closer to the cloud services they are accessing. However, traffic sent over the Internet is all best-effort and is often prone to bad actors’ attacks and unforeseen performance issues. Over 14,000 BGP incidents occurred last year, so cloud access over the Internet varies if BGP is unstable.

No one approach solves everything, but deploying SASE ( secure access service edge ) will give you a solid posture. Secure Access Service Edge deployment is not something you take out of a box and plug in.

A careful strategy is needed, and I recommend starting with SD-WAN. Specifically, SD-WAN security creates an SD-WAN SASE design. SD-WAN is now mainstream, and cloud security integration is becoming critical, enabling enterprises to evolve to a cloud-based SASE architecture. The SASE Cisco version is called Cisco Umbrella.

**Security SASE**

As organizations have shifted how they connect their distributed workforce to distributed applications in any location, the convergence of networking and cloud security has never been more critical. And that is what security SASE is all about—bringing these two pillars together and enabling them from several cloud-based PoPs.

Designing, deploying, and managing end-to-end network security is essential in today’s constant attacks. Zero Trust SASE lays the foundation for customers to adopt a cloud-delivered policy-based network security service model.

**SD-WAN SASE**

Then, we have Cisco SD-WAN, a cornerstone of the SASE Solution. In particular, Cisco SD-WAN integration with Cisco Umbrella enables networks to access cloud workloads and SaaS applications securely with one-touch provisioning, deployment flexibility, and optimized performance.

We have several flexible options for journeying to SASE Cisco with Cisco SD-WAN. Cisco has a good solution combining Cisco SD-WAN and cloud-native security, Cisco Umbrella, into a single offering that delivers complete protection. We will get to how this integrates in just a moment.

However, to reach this integration point, you must first understand the stage in your SASE journey. Everyone will be at different stages of the SASE journey, with unique networking and security requirements. For example, you may still be at the SD-WAN with on-premises security.

Then, others may be further down the SASE line with SD-WAN and Umbrella SIG integration or even partially at a complete SASE architecture. As a result, there will be a mixture of thick and thin branch site designs.

SASE Network: First steps 

A mix of SASE journey types will be expected, but you need a consistent, unique policy over this SASE deployment mix. Therefore, we must strive for a compatible network and security function anywhere for continuous service. 

As a second stage to consider, most are looking for multi-security services, not just a CASB or a Firewall. A large number of organizations are looking for multi-function cloud security services. Once you move to the cloud, you will increase efficiency and benefit from multi-functional cloud-delivered security services.

SASE Network: Combined all security functions

So, the other initial step to SASE is to combine security services into a cloud-delivered service. All security functions are now delivered from one place, dispersed globally with PoPs. This can be done with Cisco Umbrella, a multi-function security SASE solution.

Cisco Umbrella integrates multiple services to manage protection and has all of this on one platform. Then, you can deploy it to the locations where it is needed. For example, some sites only need the DNS-layer filtering; for others, you may need full CASB and SWGs.

SASE Network: Combine security with networking 

Once we have combined all security functions, we need to integrate networking into security, which requires a flexible approach to meeting multi-cloud at scale. This is where we can introduce SD-WAN as a starting point of convergence. SD-WAN’s benefits are clear: dynamic segmentation, application optimization, cloud networking, integrated analytics, and assurance. So, we are covering technology stacks and how the operations team consumes the virtual overlay features.

Cisco SD-WAN use cases that can help you transform your WAN edge with deeper cloud integration and rapid access to SASE Cisco. So you can have Cisco Umbrella cloud security available from the SD-WAN controller and vice versa. So this is a good starting point.

Secure Access Service Edge

New connectivity structures: Let us rewind for a moment. The concept of Secure Access Service Edge is based on several reasons. Several products can be combined to form an SASE offering. The main reason for SASE is the major shift in the IT landscape.

We have different types of people connecting to the network, using our network to get to the cloud, or there can be direct cloud access. This has driven the requirements for a new security architecture to match these new connectivity structures. Nothing can be trusted, so you need to evolve your connectivity requirements. 

Shift Workflows to the cloud: There has been a shift of workloads moving to the cloud. Therefore, there are better approaches than providing a data center backhaul to users requesting cloud applications. Backhauling to a central data center to access cloud applications is an actual waste of resources.

And should only be used for applications that can’t be placed in the cloud. This will result in increased application latency and unpredictable user experience. However, the cloud drives a significant network architect shift; you should take advantage of this.

SASE Network: New SASE design

Initially, we had a hub-and-spoke architecture with traditional appliances, but we have moved to a design where we deliver network and security capabilities. This puts the Internet at the center, creating a global cloud edge that makes sense for users to access, not just go to central data because it’s there. 

This is the paradigm shift we are seeing with the new SASE architecture. So, users can connect directly to this new cloud edge, the main headquarters can join the cloud edge, and branch offices can connect via SD-WAN to the cloud edge.

So, this new cloud edge contains all data and applications. Then, you can turn the other security and network functions that each cloud edge PoP needs into a suite for the branch site or remote user connecting.

1) The need for DIA

Firstly, most customers want to leverage Direct Internet Access (DIA) circuits because they want the data center to be something other than the aggregation path for most of the traffic going to the cloud. Then, we have complications or requirements for some applications, such as Office 365.

In this case, there is a specific requirement from Microsoft. Such an application can not be subject to the proxy. Office365 demands DIA and should be provided with Azure ExpressRoute, for example.

2) Identity Security

Then, we will consider identity and identity security. We have new endpoints and identities to consider. We must consider multiple contextual factors when determining the risk level of the identity requesting access. Now that the premier has shifted, how do I have complete visibility of the traffic flow and drive consistent identity-driven policy—not just for the user but also for the devices?

3) Also, segmentation. How do you extend your segmentation strategy to the cloud and open up new connectivity models? For segmentation, you want to isolate all your endpoints, and this may include IoT, CCTV, and other devices. 

**Identity Security Technologies**

Multi-factor authentication (MFA) can be used here, and we can combine multiple authentication factors to grant access. This needs to be a continuous process. I’m also a big fan of Just in Time access. Here, we only give access to a particular segment for a specific time. Once that time is up, access is revoked. This certainly reduces the risk of Malware spreading. In addition, you can isolate privileged sessions and use step-up authentication to access critical assets.

Security SASE 

SASE Cisco converges the network, connectivity, and security into a user service. It is an alternative to the traditional on-premises approach to protection. And instead of having separate silos for network and security, SASE unifies networking and security services and delivers edge-to-edge protection.

All-in-one box

SASE is more of a journey to reach than an all-in-one box you can buy and turn on. We know SASE entails Zero Trust Network Access (ZTNA), SD-WAN, CASB, FWaaS, RBI, and SWG, to name a few. 

SASE Effectivity wants to consolidate adequate security and threat protection through a single vendor with a global presence and peering relationships. 

**SASE connectivity: SD-WAN SASE**

Connectivity is where we need to connect users anywhere to applications everywhere. This is where the capabilities of SD-WAN SASE come into play. SD-WAN brings advanced technologies such as application-aware routing, WAN optimization, per-segment topologies, and dynamic tunnels.

**SD-WAN Driving Connectivity** 

Now, we have SD-WAN that can handle the connectivity side of things. Then, we need to move to control based on the security side. Control is required for end-to-end threat visibility and security. So, even though the perimeter has shifted, you still need to follow the zero trust model outside of the traditional boundary. 

Multiple forms of security drive SASE that can bring this control; the main ones are secure web gateways, cloud-delivered firewalls, cloud access security brokers, DNS layer security, and remote browser isolation. We need these network and security central pillars to converge into a unified model, which can be provided as a software-as-a-service model.

**Building the SASE architecture** 

There can be several approaches to forming this architecture. We can have a Virtual Machine (VM) for each of the above services, place it in the cloud, and then call this SASE. However, too many hops between network and security services in the VM design will introduce latency. As a result, we need to have a SASE approach that is born for the cloud. A bunch of VMs for each network and security service is not a scalable approach.

SASE: Microservices Architecture

Therefore, a better approach would be to have a microservices, multi-tenancy container architecture with the flexibility to optimize and scale. Consider the SASE architecture to be cloud-native.

A multitenant cloud-native approach to WAN infrastructure enables SASE to service any edge endpoint, including the mobile workforce, without sacrificing performance or security. It also means the complexities of upgrades, patches, and maintenance are handled by the SASE vendor and abstracted away from the enterprise.

Cisco Umbrella is built on a cloud-native microservices architecture. However, the umbrella does not alone provide SASE; it must be integrated with other Cisco products to provide the SASE architecture. Let’s start with Cisco SD-WAN.

Cisco SD-WAN: Creating SD-WAN SASE

SD-WAN grew in popularity as a more agile and cloud-friendly approach to WAN connectivity. With large workloads shifting to the cloud, SD-WAN gave enterprises a more reliable alternative to Internet-based VPN and a more agile, affordable alternative to MPLS for several use cases.

Underlay – Overlay Network Design

In addition, by abstracting away underlying network transports and enabling a software-defined approach to the WAN, SD-WAN helped enterprises improve network performance and address challenges such as the high costs of MPLS bandwidth and the trombone-routing problem. 

SD-WAN is essential for SASE success and is a crucial building block for SASE. SASE Cannot Deliver Ubiquitous Security without the Safeguards SD-WAN Provides, Including:

• Enabling Network Address Translation (NAT)
• Segmenting the network into multiple subnetworks
• Firewalling unwanted incoming and VLAN-to-VLAN traffic
• Securing site-to-site/in-tunnel VPN

So, SD-WAN can ride on top of any transport, whether you have an MPLS or internet breakout, and onboard any users and consumption model. This is a good starting point for SASE. Here, we can use SD-WAN embedded security as a starting point for SASE.  

Example: Underlay & Overlay with GRE

SD-WAN Security Stack: SD-WAN SASE

The SD-WAN security stack is entirely consistent on-premises and in the cloud. SD-WAN supports the enterprise firewall, which is layer 7 aware, an intrusion prevention system built on SNORT, URL filtering, advanced malware protection, and SSL proxy.

A container architecture enables everything except the enterprise firewall; automated security templates exist. So, based on the intent, the SD-WAN component of vManage will push the config to the WAN edge so that the security services can be turned on.

And all of this can be done with automated templates from the SD-WAN controller. It configures the Cisco Umbrella from Cisco SD-WAN. What I find helpful about this is the excellent integration between vManage—essentially, streamlining security. There are automated templates in vManage that you can leverage to achieve this functionality in Cisco Umbrella.

Cisco Umbrella: Enabling Security SASE

The next level of the SASE journey would be with Cisco Umbrella. So, we still have the SD-WAN network and security capabilities enabled. An SD-WAN fabric provides a secure connection to connect to Cisco Umbrella, gaining all the benefits of the SD-WAN connecting model, such as auto tunnel and intelligent traffic steering.

This can be combined with Cisco Umbrella’s cloud security capabilities. So, with these two products combined, we are beginning to fill out our defense in the depth layer of security functions. Multiple security features will also work together to strengthen your security posture.

SD-WAN SASE: Connecting the SASE Network 

We use a secure IPsec tunnel for SD-WAN to connect to Cisco Umbrella. An IPsec tunnel is set up to the Cisco Umbrella by pushing the SIG feature template. So, there is no need to set up a tunnel for each WAN edge at the branch.

The IPsec tunnels at the branch are auto-created to the Cisco Umbrella headend. This provides deep integration and automation capabilities between Cisco SD-WAN and Cisco Umbrella. You don’t need to design this; this is done for you.

IPsec Tunnel Capabilities

What type of IPsec capabilities do you have? Remember that each single IPsec tunnel can support 250 Mbps and burst higher if needed. In the case of larger deployments, multiple tunnels can be deployed to support higher capacity. So, active-active tunnels can be created for more power. There is also an excellent high available with this design. You have an IPsec tunnel established to primary Cisco Umbrella PoP.

If this Cisco Umbrella goes down, all the services can be mapped to a secondary Umbrella data center in the same or a different region if needed. It is doubtful that two SASE PoPs will go down in the areas of the same region.

Hybrid Anycast handles the failure to secondary SASE PoP or DR site. You don’t need to design this; it is done automatically for you. So, with this design, Cisco has what is known as a unified deployment template called the “Secure Internet Gateway Template.” 

Active-active tunnels

The Cisco SD-WAN vManage auto-template allows up to 4 active tunnels, operating at 250 Mpbs each from a single device. The Cisco SD-WAN can then ECMP load-balance traffic on each of the tunnels. Eight tunnels can be supported, but only four can be active.

These tunnels are established from a single Public IP address using NAT-T, which opens up various design options. Now, you can have active-active tunnels, weighted load balancing, and flexible traffic engineering with a unique template.

We know that each tunnel supports 250 Mbps. We now support four tunnels with ECMP for increased throughput. These four tunnels can give you 1Gbps from the branch to the Cisco Umbrella headend. So, as a network admin, you can pass 1Gpbs of traffic to the Umbrella SIG to maintain performance. 

IPsec Tunnel configuration 

For weighted load balancing, we can have, let’s say, two tunnels to the Cisco Umbrella with the same weight. These are two DIA circuits with the same bandwidth. So when the importance is confirmed the same for the different ISPs, the traffic will be equally load-balanced. Cisco uses per-flow load balancing and not per-packet load balancing. The Cisco load balancing is done by flow pinning, where a flow is dictated by hashing the four Tuple. 

So, for example, there will be a static route pairing to both tunnels, and the metric will be the same; you can also have an unequal-cost multi-path use case. You may have small branch sites with dual DIA circuits and different bandwidths and entitlements.

Traffic can be steered at 80:20 over the DIA circuits to optimize the WAN. If you had a static route statement, you would see different metrics. 

Example Technology: IPsec

Policy-Based Routing to Cisco Umbrella

You can also have policy-based routing to Cisco Umbrella. This allows you to configure flexible traffic engineering. For example, you would like only specific application traffic from your branch to Umbrella. So, at one branch site, you should send Office 365 or GitHub traffic to Cisco Umbrella; then, at Branch 2, you should send all traffic. This would include all cloud and internet-bound traffic. So we can adopt the use case for each design requirement. 

Policy-based routing to the Cisco Umbrella allows you to select which applications are sent to the Umbrella, limiting what types of traffic are routed to the Umbrella by their presence; here, we are leveraging Deep Packet Inspection (DPI) for application classification within data policy. All of this is based on an app-aware data policy. 

Layer 7 Health check 

You will also want to monitor the IPsec tunnel health during brownouts. An underlying transport issue could cause this. And dynamically influence traffic forwarding based on high-performing tunnels. Here, Cisco has an L7 tracker with a custom SLA that can be used to monitor the tunnel health. The L7 tracker sends an HTTPing request to the Umbrella service API ( service.sig.umbrella.com) to measure RTT latency and then compares this to the user’s configured SLA. If tunnels do not meet the required SLA, they are marked down based on the tracker status. The traffic will then go through the available tunnels.