What is Prisma Access SASE? Beginners Guide
In this blog post, we will go through Prisma Access SASE Fundamentals and what problems it solves for enterprises. The goal of this post is to go through Prisma Access Solutions by comparing them to traditional Network Designs.
Overview
If you're a Network or Security engineer eager to learn about Prisma Access SASE, I bet you've done a quick online search and been swamped with marketing jargon. My goal here is simple, to discuss Prisma Access and SASE from a hands-on technical viewpoint, breaking down the core problems it addresses.
For those seeking a straight-to-the-point explanation, Prisma Access SASE is, at its core, a Firewall-as-a-Service (FWaaS), and if needed, it can be integrated with SD-WAN. What Palo Alto offers is a group of firewalls in the cloud, ensuring they're both scalable and available across the globe.
The Need for SASE - A Real-world Example
Before diving deeper into SASE, let's set the scene with an example. Suppose you manage an Enterprise with 30+ offices worldwide and it's growing fast. Additionally, your users are distributed across different regions and countries.
This setup brings two main challenges.
- Remote Access VPN Challenge - For Remote Access VPN, you need to set up firewalls to handle VPN connections. If you want redundancy, you're looking at multiple firewalls. And then there's the issue of latency. Having a user in the USA connect through a UK-based firewall isn't efficient. Plus, ensuring that all these firewalls have consistent security policies can be a tough task. If you've ever managed such a setup, you know how tricky it can be.
- Rapid Expansion Issues - With the company growing quickly, opening a new office means getting a new firewall, setting it up, and making sure its security policies align with all other branches. It's a time-consuming and complex process.
If there were a solution to tackle all these challenges, it would be a game-changer. This is where SASE comes into play.
What is Prisma Access SASE?
Prisma Access is a Secure Access Service Edge (SASE) solution developed by Palo Alto Networks. It is a cloud-based platform that combines networking and security in a single offering.
You must have been living under a rock if you haven't heard the term SASE (pronounced 'saasy') in the last few years. Gartner introduced the concept of Secure Access Service Edge (SASE) back in 2019. Palo Alto describes SASE as
SASE is the convergence of wide area networking or WAN, and network security services like CASB, FWaaS and Zero Trust, into a single, cloud-delivered service model.
Traditional Network Architecture
Before diving into what SASE is, let's look at the current Network Architecture and its challenges.
Existing network approaches and technologies simply no longer provide the levels of security and access control digital organizations need. In the past, many operations were centralized within the data centre, but the tide has changed. The rise in remote users, coupled with a shift towards SaaS applications, has led to data no longer being confined to the data centre but instead flowing towards various cloud services. With all these, the need for a new approach to network design has risen.
Traditional Network Design
Traditional Remote-Access VPN Challenges and Limitations
With traditional networks, the Remote Access VPN usually terminates on the HQ or Data Centre firewalls and then breaks out to the Internet. Since the Pandemic, employees have been working remotely in a distributed fashion and most of the SaaS applications are hosted in public clouds.
- Backhauling Internet traffic to the data centre or HQ can dramatically decrease the user experience.
- Inconsistent security policies based on the user's physical location
- Using SaaS or Cloud Applications over remote-access VPN can decrease the user experience.
Traditional Branch Office Challenges and Limitations
Traditional branch office networks use either MPLS or site-to-site VPN between each remote site and headquarters or a hub-and-spoke design with data centre functions as the hub.
This design works very well if the majority of the applications are hosted in the HQ or the DC and bandwidth requirements are not very high. I'm writing this post at the end of 2023 and many applications have now migrated over from the DC to public clouds.
This approach introduces performance issues because traffic originating from the branch offices now has to traverse the MPLS circuit, and perimeter firewall before reaching out to the host located in the public cloud.
Implementing Palo Alto Networks Prisma Access - Tom Piens
If you want to learn more about Prisma Access, I highly recommend "Implementing Palo Alto Networks Prisma Access" by Tom Piens. Please note, Packt reached out to me and provided a copy for review, but I don't receive any incentives for advertising this book here. We all know how good Tom is with his Palo Alto knowledge.
Prisma Access SASE Approach
Prisma Access SASE provides a Cloud-Delivered Networking and Security solution that enables Remote Users and branches to connect to a nearby cloud firewall, providing secure access to the Internet and all applications.
You can think of it as having a bunch of firewalls spread across the globe and connecting all of your branch offices, DCs and public cloud environment to it. Those firewalls and infrastructure are fully managed by the SASE provider, Palo Alto in this case.
Please keep in mind that you are still responsible for creating security policies, security profiles, user-id etc. The SASE provider takes care of upgrading the OS, scaling up and down depending on the demand, and managing the routing between the managed firewalls.
Prisma Access breaks down into three primary components or use-cases, Mobile Users for remote access VPN, Remote Networks for branch office connectivity, and Service Connections for Data Centre connectivity. We'll dive deeper into each of these options in the following section.
Prisma Access Mobile Users
With Prisma Access Mobile Users, you connect to a Cloud Firewall (MU-SPN to be precise) that Palo Alto manages. We are still responsible for configuring all sorts of Global Protect configurations such as the subnet, split-tunnelling, security policies etc. Palo Alto just manages the infrastructure and the firewalls. If there is a sudden increase in demand, Palo Alto spins up additional nodes in the background and ensures the load is managed appropriately. The nodes are also globally distributed so, if a user is in the UK, he/she will be connecting to a firewall that is closer to the UK.
Traffic from the mobile endpoint to the Internet traverses the VPN tunnel (SSL in most cases) to the Mobile Users Security Processing Node (MU-SPN) and then directly to the Internet. The node automatically translates the source IP address of the traffic to its external IP address, ensuring all return traffic flows through the node. Prisma Access has a single security policy that it shares across all the firewalls/modes.
In a nutshell, you will still use the Global Protect application to connect to the VPN but behind the scenes, the VPN terminates on the Prisma Access node instead of your own on-premise firewall.
Prisma Access Remote Networks
Remote Networks (RN) connect to branch offices that require secure connectivity to and from the Internet, as well as Prisma Access.
Prisma Access RN is primarily designed to securely connect branch offices to Prisma Access. At this point, the immediate question is - why go through this? Connecting the remote sites to Prisma Access means they can traverse the Internet safely where the security policies will be enforced centrally. The remote sites can also communicate with each other using Prisma Access's backbone network.
Remote Networks create a Remote Network Security Processing Node (RN-SPN) which provides similar functionality as a Palo Alto next-generation firewall. Remote networks are metered, which means that a customer is allocated a specific amount of bandwidth to the compute location, and there is a cost associated with this allocated bandwidth.
To connect your remote network locations to Prisma Access, you can use the Palo Alto firewall or a third-party, IPSec-compliant device including SD-WAN, that can establish an IPSec tunnel to the service. So, in a nutshell, you create an IPSec tunnel back to Prisma Access and send all the traffic to the cloud to be inspected.
Prisma Access Service Connections
A Service Connection, also known as a Corporate Access Node (SC-CAN), allows Mobile Users and Users at Remote Networks to access internal resources and lets your Mobile Users and Remote Networks communicate with each other. Please note that there is no Security Enforcement for Service Connection. So, traffic leaving an SC location and arriving at Prisma Access won't be inspected.
At this point, you might wonder about the difference between Remote Networks (RN) and Service Connections (SC). Here's a simple way to differentiate, If you're looking to enforce security policy for both inbound and outbound connections, go with RN; else, choose SC.
Take a branch office, for instance. It’s unlikely for such an office to host services or applications that require inbound access. However, it certainly needs a way to access the internet - making RN the optimal choice.
On the other hand, a Data Centre is often equipped with services and applications demanding inbound access, especially from Remote Access users or users at branch offices. In such scenarios, Service Connection can be used.
Prisma Access Routing
Just to summarize, Remote Networks terminate their IPSec connections on the Prisma Access RN-SPN node. Service Connections terminate their IPSec connections on the SC-CAN node and Mobile Users terminate their VPN connections MU-SPN node as shown below.
Prisma Access supports highly redundant routing mesh and VPN tunnels among Remote Network Security Processing Nodes (RN-SPNs) and Service Connection Corporate Access Nodes (SC-CANs) across regions. Dynamic routing is deployed internally in Prisma Access for routing and eBGP is used to peer with customer firewalls.
Remote Networks form a full mesh of routing with each other and Service Connections. Mobile Users (MU-SPN) form an IPSec tunnel to the nearest Service Connection (SC-CAN)
MU-SPNs always connect to the geographically closest SC-CAN. Through this SC-CAN, Mobile Users can reach any Remote Network within a single hop. If an outage in the cloud causes routing or tunnel issues, this traffic traverses a different path to reach the remote Network.
Quick Note on Prisma SD-WAN
While Prisma SD-WAN truly deserves a dedicated blog post, I'll touch upon some points here:
- Manual Setup Without SD-WAN/ION - In the traditional approach, without SD-WAN, setting up IPSec tunnels from your branch offices or data centres to Prisma is a manual process. This can be a hurdle, adding layers of complexity – precisely what SASE aims to simplify.
- ION Devices from Prisma - Prisma introduces ION (Instant-On Network) devices that make SD-WAN almost as easy as plug and play (similar to Meraki)
- Pre-Configuration Flexibility - A standout feature is the ability to configure these ION devices even before physically handling them. Once deployed, they automatically establish tunnels back to Prisma and deliver detailed app-centric analytics.
Therefore, when deciding on your branch offices, it's valuable to weigh the merits of traditional NGFW against the ease and capabilities of ION devices.
What's not so good about SASE?
While SASE brings numerous advantages to the table, it also comes with certain drawbacks. Here are some areas where SASE might not shine as brightly:
- Vendor Lock-in - Once you've chosen a SASE vendor and have been using their solution for a few years, it might be challenging to switch to another vendor or solution. This dependence can limit flexibility in the long run.
- SASE Provider Issues - Since the entire system relies on the infrastructure of the SASE provider, any technical glitches or downtimes they experience directly impact us. It's like putting all your eggs in one basket - if the basket breaks, all the eggs are at risk.
- Troubleshooting Challenges - With the SASE model, we don't have direct access to the cloud firewall. This makes troubleshooting more difficult. For tasks as basic as taking packet captures directly on the firewall, we might need to raise a support ticket, await a response, and then possibly schedule a call with a TAC. It adds an extra layer between the problem and its resolution.
Conclusion
As a side note for those trying to remember the essence of SASE, I like to think of it as "Secure Access to Services from any Edge". This not only helps in recalling the term but also captures the fundamental idea behind it.
SASE (Prisma Access in this case) provides a straightforward approach to address the challenges faced by distributed networks. By centralizing security policies and reducing the complexities associated with expansion, it offers a practical solution for modern enterprise connectivity needs.