The last few years have really forced organizations to the remote workforce era. Many people were sent home due to Covid and will never return to an office and why should they? We as a nation proved for almost a whole year that we could be remote workers and still make the world go round. While some organizations are calling back their employees, others are trying to make their remote workforce more productive and secure. I had recently had the opportunity to work with a technology solution made by Palo Alto Networks called Prisma Access. Prisma Access is said to be “Security Service Edge” and is a cloud delivered platform. Like we don’t have enough “cloud” offerings these days already. It is my belief that the goal of the product is allow users to be always on the corporate network and allow them to have service gateways for their VPN connectivity in the regions they reside in. I also believe this removes the responsibility from the on-prem hardware and leans more on Palo Alto to provide that service and SLA for the organizations users. When you think about the overhead that remote workforce brings to your VPN concentrators or firewalls, offloading your users to a cloud service makes sense.
Organizations that are current Palo Alto customers and already use their firewall management product, Panorama, will more than likely integrate the Prisma Access technology into the Panorama platform to keep that “Single Pane of Glass” that us Network Engineers love so much. The other option looks to be a cloud based management platform hosted by Palo Alto. I cannot really talk to that as that is not the path we took. Prisma Access integrates into Panorama via a cloud services plug-in. The installation of this plug-in will provide visibility into the Prisma Access infrastructure. You will be able to explore things like status of Service Connections, Cortex Data Lake, and Mobile Users that leverage the Global Protect client.
A Prisma Service connection is the connectivity that allows the Prisma Access Virtual Firewalls to connect to your on-prem firewalls via IPSec-VPN tunnel. This allows your Prisma Access remote users to access internal resources. Cortex Data Lake is the cloud based logging server where all Prisma Access logs are sent for viewing and troubleshooting. Prisma Access uses the Global Protect client that on-prem firewalls use as well when creating a remote user scenario so from a user standpoint they will not see much difference if they are moving to Prisma from an on-prem solution.
Remote users will use Service Connections to gain access to an organizations internal resources like authentication, Active Directory Services, File Servers, and so on. When a remote user wants to use the internet they will use the Prisma Access Cloud internet rather then back-hauling all the internet traffic to your local datacenter, which so many of us are use to doing in past scenarios. This is a tough one for some Security and Network folks as we love CONTROL of things, but stand firm, we are still going to create our own policies, URL filtering, Threat prevention, and other things we want to use to protect the remote workforce.
Remote Users can connect to multiple Prisma Access Gateways within many regions in the US and other countries as well. Rest assure no matter where your remote users are located there is a Prisma Access Gateway near them. I am not sure of their Prisma Access/Cloud backbone to get that traffic over to your Service Connection, but I assume it can move data pretty fast so the users will not suffer much latency. The Global Protect client portion of the product is not different in how it is configured for the client except some things need to be configured in the Portal/Gateway section and others need be configured in the Cloud Services area of the Panorama.
A new thing for me was Palo Alto’s Cloud Identity Engine, or CIE as they call it. The CIE consists of Directory Sync for users in the organization and Cloud Authentication Services, which authenticates organization users. The Cloud Authentication Service uses SAML 2.0 which is becoming more and more popular these days. If and when the user tries to authenticate, that request is redirected to the Cloud Authentication Service, which then redirects that request to the SAML provider. If that is successful then the firewall maps the user and applies the security policy which they are trying to authenticate for. The Directory Sync portion of the CIE can leverage an on-prem directory which requires an agent or what I prefer to use, Azure AD. Might as well keep as much in the cloud as possible, right?
The functionality of the firewall as it relates to Device Groups and Templates works the same as if you had an on-prem firewall. Prisma creates a Mobile User template which controls the policies for all Mobile Users and is then pushed to the Prisma Cloud. I find it easy to just think of Prisma Access as a cluster of Firewalls I have deployed in the cloud, but have some limitations on what I can do with them and how much visibility I have into them.
While there are many other components to Prisma Access that I may not have mentioned here I tried to touch on the 100ft view ones. I also did not dive real deep in any of these components either as that is not the point of this article. I wanted to give a very broad overview of the product so that some understanding could be communicated before I gave my personal thoughts.
I believe the Palo Alto Prisma Access product has come a long way in the last few years from when I first saw the overview of it at Ignite 2019. After the recent weeks of implementing the product I can say that having an understanding of Palo Alto firewalls will only set you up for success when deploying this solution. I have seen very similar configurations within the project implementation that were true when I was deploying Global protect on-prem before Prisma Access was a thing. What Prisma Access lacks is visibility from a troubleshooting standpoint. As an Engineer, I like to have my CLI access and the ability to run debugs to get down to the nitty gritty of the issue. After a few weeks its seems when issues arise a ticket has to be created and you must play the “How fast can we get an engineer on the phone…”. If you have directory sync issues all you can really do is check the CIE for the status of the sync and make sure you are using the correct DN from Azure. Other than that, you have zero visibility into the backend of the Prisma Access solution. Palo Alto does have what is called Prisma Access Insights which gives you visibility into the SASE environment of Prisma, but I still feel it lacks that “Technical Engineer” visibility we need to troubleshoot things. Maybe that is the idea for the product, take more away from the On-Site engineers so they can focus on other meaningful things. The other challenge is logging. Cortex Data Lake seems to be the way things are moving and I think that is reasonable. I mean many organizations are moving to things like Splunk Cloud, which I think Cortex is a lot like that. Some organizations like all their logs in a single area, so while the Panorama integrated Prisma Access can show logs in the Panorama, they are not stored within the Panorama like other firewalls logs. If you want your Cortex logs put into the organization SEIM like Splunk you will have to use the log forwarding option in Cortex to achieve this. The only other thing I found interesting is that Palo Alto has not figured out how to export Cortex logs to Palo Alto Expedition (Their Migration Tool). They have told me that Cortex logs are much different in format than firewalls logs so they have not thought of that yet. I love to use Expedition to parse logs and really pair down my security policies using machine learning. Thankfully the Policy Optimizer will still work with Prisma Access so there is that.
