About KPawlak

There is a lot of documentation out there about how to connect to an AWS TGW from a VM firewall, or how to connect to AWS from Prisma Access using various methods. I found that in order to accomplish my exact needs I had to tinker a lot outside of the documentation:   1. Use AWS Native networking to receive the service connection (TGW or individual VPC) 2. Set up redundant tunnels 3. Use BGP for routing   Please see the attached file documenting how I achieved this Please note you are posting a public message where community members and experts can provide assistance. Sharing private information such as serial numbers or company information is not recommended. ... View more

While Palo Alto Networks has documented the use of HTTP Header insertion to control access to certain SaaS applications, there are many more which are not yet documented (as of July 2021). Slack in particular came up for me during testing so I wanted to share what I have found.   First of all, slack maintains documentation for allowing / denying the use of slack workspaces while on a network. A PANW firewall of any form factor (physical, virtual, Prisma Access) can use these documented HTTP headers to prevent someone from logging into non-allowed Slack workspaces. This is a binary decision.   Thankfully, slack also leverages URLs in order to do logins, uploads, downloads, etc. This means one can also use policies scoped based on URL to specifically allow certain actions / apps / files to desired workspaces based on URL, and more granularly block file uploads (for example) to other workspaces. I tested this primarily by creating a 2 tiered policy to block all file uploads to a specific slack workspace based on its associated URLs (placed into a URL filtering group) and allow slack uploads to all other workspaces. For a more secure deployment these could easily be flipped. This is a huge win for DLP use cases as one can prevent files from being shared via a 'sanctioned app,' but to a different tenant.   for reference: the url for a tenant you want to allow or blocklist is usually of the format https://my-workspace-name.slack.com/   In my testing locking a specific tenant URL blocked all my messages and files from going out, but I was still able to see existing messages others had posted to that workspace. However if I wasn't already logged in from my desktop client then logging into a blocked workspace seemed to be stopped as well as usually this involved your browser taking you to the URL for login. ... View more

There are many articles, guides, and resources available across various Palo Alto Networks properties to guide users on how to best protect their organizations from ransomware. After spending some time to find many of them, I thought I would share with everyone.   High level from what I could find there were a few high level recommendations from resources like Unit 42:   1. Block network-borne ransomware (NGFW + Security subscriptions)   Someone made a great write up on the knowledge base about best practices for general ransomware prevention. Unit42 as well seems to publish research on specific attackers like (ex: Darkside) which give more specific guidance. If you read the first link, you'll see there are several action items to take and I've tried to link documentation and best practice pages as best I can for these:   Decrypt traffic where possible for visibility (Best Practices) Attackers can move around infra to change source IPs, harder to change tools - often need to see into the body of traffic to detect effectively     Use file blocking profiles to block unneeded, malicious payload types For file types allowed, follow Wildfire Best Practices Enable DNS Security on firewalls 80% of malware uses it in some way -> C2, Exfil Sinkhole traffic to tag and then reduce access of infected hosts     Leverage vulnerability protection profiles Overall best practices Specific to Exploit Kits and Phishing Attach (at a minimum) to all internet traffic policies Optimally E-W as well where possible to prevent lateral spread Leverage EDLs to block known bad IPs and domains Keep up to date on all content packages     2. Prevent Ransomware on endpoint with Cortex XDR     Cortex Endpoint Protection Modules Anti-ransomware Local (static) Analysis + Wildfire (dynamic and sandboxing) Windows, Mac, and Linux look to be supported by 1 or both of above Make sure these modules are enabled   3. Leverage SOAR to quickly respond & automate hunting for threats   SOAR platforms and playbooks are great to document and automate responses. Cortex XSOAR has a lot of OOTB content and playbooks for certain scenarios which can be great references (even if you can't get a SOAR tool in your arsenal today). Ransomware is one of these. Full documentation here.   4. Contain and recover with experts on hand   In addition to products, Palo Alto Networks is doing a lot of work in consulting, services, etc these days to be a full partner to customers and not just a tech vendor. Below are some links to a bunch of the services available - one of which is a Ransomware Readiness to look at current state of an org and map a path to be ready to fight off ransomware attacks.   Proactive Proactive Assessments - "who can help me understand my risk/posture" 3rd Party risk assessments (partners and acquisitions) : "How do I know my business partner / potential acquisition has a clean house?" Ransomware Readiness : "If I suffer a ransomware attack, how can I make sure it won't impact my operations & I won't be forced to pay?" Breach Readiness : "Do I have my response procedures planned, documented, and ready to go if we suffer a breach so that we can mitigate damage?" Threat Intel and Briefings "who can keep me up to date on current trends in the threat landscape so I know what to be looking for?" Reactive Find out if you have been compromised : "How do I know if recent attack XXXX affects/affected me?" I nvestigate Advanced Persistent Threats in your environment : " How do I confirm if a sneaky threat actor is or is not already lurking in my business waiting for the right moment?" Incident Response Retainers - 'If I get breached who will help me" Remediate Business Email Compromise : "How do I quickly respond to this specific type of attac k?"   Finally, an excellent general resource (as linked in the comments below) is the Unit42 Incident Response and Data Breach Report, which goes into great detail about major trends and action plans to mitigate (including but not limited to Ransomware).   ... View more

In a lot of conversations recently I've found that many, many people are confused by the names and functions of Cortex - especially given the rapid expansion of the platform. In this post I'm going to try to distill the basics of each product with as little jargon as I can and help people figure out which things they are and are not looking for from the platform.   "Cortex"   -> name of the overall product platform for enabling Security Operations teams, technologies, and workflows. All other components referenced below are a part of this platform   Cortex XDR Prevent   -> Endpoint Protection agent. Table of capabilities   here. Modules and OS coverage   here. This solution is designed to protect endpoints from various types of compromise and builds upon the concepts of Anti-Virus and NGAV that the industry have leveraged for years. This includes, but is not limited to, the protections of our legacy endpoint protection tool "Traps"   Cortex XDR Pro (for endpoint)   -> same agent as above, but with EDR functionality enabled. EDR gathers important forensic data from endpoints and feeds into the combined Cortex platform (architecture described here) to allow Palo Alto Networks to detect many more types of threats in your environment. Detection coverage discussed within our docs   here (see sections that include 'XDR agent' as data sources) as well as   analyzed by MITRE, a 3rd party organization.   Cortex XDR Pro (per TB)   -> same Cortex platform for analytics and threat detection, but augmenting the EDR data set with Firewall logs and 3rd party data. See   here to understand use case coverage (all sections that do not require the XDR agent can be accomplished with this license alone).   Cortex XSOAR -> Orchestration and Automation platform for designing, documenting, and automating security and incident response workflows. Some top use cases are referenced   here   Cortex Xpanse   -> discover your attack surface   from the outside / attacker perspective.   This has many, many applications. For example, when acquiring or merging with another business it can allow you to do strong due diligence on their security posture before your unify your organizations or complete a purchase.   Or when a new vulnerability is released such as CVE-2021-21985 and Ars Technica writes that Shodan has already discovered 5K vulnerable servers on the internet on the same day, you might be thinking 'uh oh, is one of them ours? do we need to go into full incident response mode?". Normally you'd go try to pull some asset inventory or something to figure it out, but hey maybe someone spun up something you didn't know about in an IaaS provider and it isn't encompassed in there. That's stressful ... well XPanse, by scanning the whole internet, would be able to tell you if you needed to get to work ASAP or if you can sit this one out!   ... View more

At the time of this writing, the process for redistributing User-ID info from Prisma Access to on-prem firewalls is documented publicly here:   https://docs.paloaltonetworks.com/prisma/prisma-access/prisma-access-panorama-admin/configure-user-based-policies-with-prisma-access/redistribute-userid-information-for-users-and-networks   However this document does not capture an important caveat. In the case of multiple Service Connections existing, each GlobalProtect Gateway nodes will share the User-ID info with 1 of the Service Connection nodes, usually the closest node to it. For example I was working on a tenant with Service Connections in US-West and Us-Northwest. When I logged into a gateway based in US-Northwest, the US-Northwest Service connection received my user-id info, but the US-West Service Connection did not. This is important because if you're going to follow the above linked process, you will have to reference multiple/all service connections user agent IP addresses in order to get the info on all users coming in via GlobalProtect. I suggest using the following resources to identify if user <-> ip mappings have propagated to the local firewalls:   https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm5bCAC   https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClR1CAK   And as always, after you redistribute, make sure to enable User-ID on the zones on the on-prem firewalls. ... View more

Broadly speaking, there are a few ways to bridge Prisma Access (or a VM/physical firewall for that matter) into your public cloud environment. I will be using AWS as my example by very broadly these ideas still apply.   AWS documents 4 ways to connection via VPN here. We're focused on the S2S use case, which as you can see they reference 2 options - the VGW (Virtual Gateway) and the TGW (Transit Gateway).   VGW Broadly speaking again, the VGW is a per-VPC resource for connecting an individual VPC to a 'customer gateway' - which in this case would be Prisma Access. This is a straightforward option and we have public documentation on how to do it here. Please note that this documentation is assuming you're onboarding it as a 'Remote Network'. If your Prisma Access deployment is primarily centered around your users working from home / on the road, then you may not have a remote network license. Instead you would onboard this as a 'Service Connection' but the high level workflow is similar on the AWS side.   Limitation of this option: the VGW does not do segmentation within the VPC at L7. You can use Security Groups in AWS to create IP based ACLs for access to certain resources in your VPC, however you will not be able to write a policy to allow a specific user group to have access to a certain EC2 instance using a specific application, so truly achieving a Zero Trust architecture is going to be a challenge.    You could potentially shore that up by also installing VM-Series firewalls inside this VPC and directing inbound traffic there but that is an extra step.   The other *MAJOR* limitation of this approach is that as of the time of my writing this (March 2021), a VGW drops all traffic destined for an IP not in the VPC it is attached to. So if you have 2+ VPCs, you will need 2+ service connections with this deployment model.   TGW:   The Transit Gateway is a much more scalable approach and is frequently pointed to in our reference architecture guides for AWS. It does take more work to set up but can be a phenomenal tool for linking many VPCs and is also a recommended tool for enabling E-W traffic monitoring and segmentation using the Gateway Load Balancer VM-Series Integration.    This is much more recommended, does not have the routing limitation I referenced for the VGW above, and can help you insert other use cases moving forward. For organizations that can do so, we recommend going with a TGW based architecture for multiple use cases.   VM-series:   The last option is to directly insert VM-Series firewalls into your VPC and terminate the IPSec tunnel to that/those EC2 instances. This gives you the security benefits and removes the routing / dropping traffic to other VPCs issues of the VGW architecture, but is a bit less effort to set up than the TGW architecture. This is often a good starting point for organizations that will look to deploy the TGW architecture, but are not there yet and want to get the ball rolling on their Prisma Access deployment.     ... View more

Hi all,   I've found that this is a frequent question that comes up for new and existing Prisma Access customers. Long story short there are a couple of ways to go about this.   The most advanced and scalable option would be to use a solution like Cortex XSOAR  to automate things. For example, if you were to deploy a new Mobile User location, Cortex XSOAR can help you allowlist new egress IPs from your tenant, as is discussed here . There are many other use cases, such as automatically updating your SAML provider to expect authentication requests from this new gateway, and more. I cannot recommend enough going down this path if you can.   However, for customers just getting started or who don't have the budget for such tools, you can take some other approaches leveraging the API and automation options of Prisma Access.   Full Documentation for understanding the Prisma Access API is available here: https://docs.paloaltonetworks.com/prisma/prisma-access/prisma-access-panorama-admin/prisma-access-overview/retrieve-ip-addresses-for-prisma-access   However in short form, you may choose to either allowlist the hostnames of the gateways we orchestrate and deploy for you through your tenant, or you may allowlist the IP addresses.    The hostnames are immutable unless you choose to turn on/off a node location, whereas the IPs can change and grow to accommodate failover events for maintenance or scale out activities.   To get the hostnames to whitelist, you may use the UI:   For Panorama managed please go to   Panorama > Cloud Services plugin > Status > Network Details > Mobile Users - GlobalProtect   Here you will find the portal address as well as the gateway addresses of your tenant   For Cloud managed, please open the Prisma Access App and go to    Manage > Mobile Users > GlobalProtect Setup > Infrastructure, and click the gear icon in the ‘Infrastructure Settings’ Box   You portal hostname should be readily available near the top of the page, and the list of gateway FQDNs should be near the bottom if you scroll down   If you need to allowlist IPs specifically, please feel free to leverage and customize this script to query the API. This was field created just to save time and is not a TAC supported tool so if API changes have been made since its last update let your SE know, but TAC will not be able to help you and there is no SLA to update it:   https://github.com/chairforce2/Prisma-PAN-OS-API-Queries/blob/main/prisma-access-get-IPs.sh   You will need your API key to do so. You can follow step 1 here to do this for a Panorama managed Prisma Access tenant, and follow step 1 here instead for Cloud Managed Prisma Access. ... View more

As of the time of this writing (May 2020), there are some caveats / required steps for HTTP header insertion into GDrive applications that are not clearly documented. The purpose of this post is to close that gap until documentation is amended to correct this (Documentation has now been updated - Oct 2020 update)   1. Decryption All google apps are encrypted (shocking I know) so you do need to institute SSL Decryption. I created what might be an overzealous decryption policy but it got the job done. Decryted the following categories: business-and-economy, computer-and-internet-info, content-delivery-networks (this CDN one was a surprise but needed), intenet-communications-and-telephony, low-risk, online-storage-and-backup, search-engines, web-based-email Plus a custom URL category for GDrive Cached URLs - see this KB article:   Identifying and Blocking Google Drive when Using Chrome-cached Session 2. HTTP/2 -> HTTP/1.1 Google Apps also use HTTP/2 instead of HTTP/1.1 for performance improvements. However it is not possible at this time for our technology to insert headers into HTTP/2 traffic. When configuring the SSL Forward proxy decryption, check the flag for stripping ALPN in the decryption profile you apply to this traffic. When you strip the ALPN value, this causes traffic to default back to HTTP/1.1, where we can insert headers. From a user's perspective this shouldn't change the app usage, it will just cause a performance reduction (YMMV) from a network perspective. At this point, some apps, like Gmail, will have the headers properly insert, but you will see that others still continue with the default (non-blocked) behavior, such as GDrive 3. To close the final gap, you will have to create a rule at the top of the security policy set that blocks the QUIC App-id. This is because Google uses their proprietary QUIC protocol to deliver GDrive and some other apps, instead of the standard HTTP over TLS, in which we cannot decrypt and insert headers. If you block the QUIC protocol, it will default back to HTTP/2 over TLS, then the decryption with ALPN stripped will further turn it into HTTP/1.1 and finally you will have header insertion working. For the header insertion, I also included the following domains in the HTTP Header Insertion config of the URL filtering profile (may be more coverage than needed but did this for an eval so was less concerned with tuning that getting the W): *.google.com *.gmail.com *.googleusercontent.com *.drive.google.com *.gstatic.com ... View more