7 Critical Flaws of the Palo Alto Networks Cloud Next-Gen Firewall Service

This is a detailed follow-up to our initial analysis of the Palo Alto Networks Cloud NGFW for AWS announcement. In this blog, I’ll explore the critical gaps of the PAN Cloud NGFW offering.

These technical gaps of Palo Alto Networks Cloud NGFW can be distilled into three primary business impacts that potential customers should be aware of: 

Porous Security

Lack of advanced protections for web applications, visibility to existing traffic flows, and protections for the 100s of cloud services leaves a lot of exposed attack surface. 

Operational Overhead

Multiple security consoles and separate solutions for multi-cloud means security teams will spend lots of time setting up and maintaining network security infrastructure. And, static policies based on IP addresses mean you are back to the world of opening a ticket to make an app go live.

Compliance Concerns

Sending your traffic and encryption keys outside your cloud account boundaries raises significant compliance concerns for a product/service built on combining legacy technologies and no compliance certifications.

And now, here is my detailed analysis of seven key requirements for network security in public clouds that Palo Alto Networks Cloud NGFW completely misses:

7 Items to Review in Evaluating the Palo Alto Networks Cloud NGFW

1. Ownership and Control of Traffic & Encryption Keys
2. Protection for All Applications, Including Web Apps
3. Visibility & Protection for Cloud Services
4. Multi-Cloud Support
5. Single Pane of Glass
6. Is it Really Zero Trust
7. Cloud-friendly Licensing & Pricing

1) Ownership and Control of Traffic & Encryption Keys

The Palo Alto Cloud Next-Gen Firewall solution, both in the distributed mode and centralized mode, requires that your traffic leaves your VPC and AWS account boundary through the VPC endpoint. It then goes to the Palo Alto stack for inspection and then returns back. It’s not clear if Palo Alto is running either a single tenant or multi-tenant dataplane (i.e. if your traffic is commingled with other customers). And, in either situation how are they maintaining the isolation? 

Equally important is how they decrypt traffic for inspection. Per documentation the Cloud NGFW service (aka control plane) requires access to the AWS Secrets Manager for accessing the private keys to decrypt traffic. This means that your private keys are being shared with them creating the possibility of supply chain attacks. 

Enabling customer ownership and control of traffic and encryption keys is crucial. This is especially true when companies need to meet compliance requirements such as SOC, ISO 27001, and PCI-DSS. 

Note: In the case of Valtix, the service itself (i.e. the control plane managed by Valtix) does not have access to your private keys. Only the dataplane (Valtix Gateways) running in the customer’s cloud account have limited access, via IAM, to AWS Key Management Service (KMS). And this is fully auditable via the AWS CloudTrail logs. Valtix also undergoes annual compliance reviews for SOC2 Type II by an AICPA accredited firm and PCI-DSS by a PCI Council-approved qualified security auditor (QSA). 

2) Protection for All Applications, Including Web Apps

A comprehensive defense-in-depth approach includes protecting all traffic with a layered set of controls. This means TLS decryption followed by protections for application-specific inspections:

• Web traffic – basic OWASP top 10, advanced application-specific rules (PHP, WordPress, Joomla, Java, etc), and common attack vectors (SQL injection, cross-site scripting, remote code execution, etc). 
• Full NGFW feature suite – Application ID, IDS/IPS, antivirus/anti-malware, DLP, FQDN/URL filtering

Every compliance standard requires a web application firewall (WAF) to protect web applications for both the incoming request and response. Requirement 6.6 of PCI-DSS v3.2.1 calls out for using a WAF as a solution that detects and prevents web-based attacks on Internet-facing applications. 

Unfortunately, the Palo Alto Cloud NGFW solution does not include a WAF. And a generic NGFW cannot truly protect web applications. No security professional would do otherwise. Palo Alto themselves admit to this and recommend deploying a WAF (in quite a lengthy roundabout way). Adding a separate WAF means you deal with two different management consoles – security policies and logs. And more importantly, by fragmenting WAF from the NGFW, you lose a 3600 view of traffic flows inbound, inside your environment, and outbound. 

3) Visibility & Protection for Cloud Services

15 years ago, Palo Alto Networks made the right choice of building an NGFW that included all the relevant protections needed for enterprise networks (primarily outbound and east-west traffic). Today’s public cloud world consists primarily of:

• Internet-facing web applications
• 10s of public cloud services (IaaS & PaaS) per application/workload

Traditional NGFWs only have visibility and control for traditional (aka legacy) applications using APP-ID. But what about the 100s of cloud services on AWS, Azure, or GCP? 

Recent vulnerabilities like OMIGOD, Azurescape, and Log4Shell show that cloud services can also be exploited. Relying on IAM policies alone to control access is not sufficient as demonstrated by the Capital One breach: IAM policies are hard to configure correctly and can still be abused by an attacker assuming the server’s identity. Your network security solution must provide defense in depth even for the cloud provider’s services that we assume are secure. 

4) Multi-Cloud Ready

The Palo Alto Cloud NGFW is for AWS only and uses the AWS Firewall Manager for all management, and there are other solutions for other clouds:

• Cloud IDS for GCP – which has no support to inspect encrypted traffic
• VM-Series for Azure – traditional firewall appliances with complex ARM templates

With this complex picture, it will be incredibly challenging for customers to build a comprehensive cloud security strategy. They will need separate deployments for each, separate security policies, logs, and maintenance. A recent survey by Valtix shows that 95% are moving fast to adopt a multi-cloud as a strategic priority in 2022. HashiCorp State of Cloud Strategy Survey reveals that 76% of organizations are already multi-cloud, and 47% of them see security as a major challenge. If multi-cloud is not a key requirement of your cloud security architecture and decisions, it probably should be.

5) Single Pane of Glass

The Palo Alto Cloud NGFW uses the AWS Firewall Manager (FMS) for deployment and security policy, while logs are sent to AWS S3, CloudWatch, or Kinesis. And there’s still the traditional Panorama management server. Plus, if you use a separate WAF (as mentioned before), now you have many consoles to deal with. Without an integrated console that combines workload context, traffic, and threat data with threat intelligence, the new PAN service makes your life even more difficult. 

While PAN made an incredible leap 15 years ago with the APP-ID capability, today’s cloud world also provides visibility to existing DNS (Route 53) queries and VPC flow logs. Cloud-native security services already incorporate all relevant cloud logs to help customers discover their applications, find security gaps in existing traffic flows, and then defend them with dynamic security policies based on workload identity. 

Finally, you will have more consoles to deal with if you are operating in multiple clouds. 

6) Is it Really Zero Trust

A major claim in the Palo Alto announcement is that it supports zero trust architecture. But their security policies only support static policies using IP addresses. Zero trust requires dynamic context-specific policies, i.e., different policies for dev/test/prod or frontend/app-tier/backend or based on trust levels. IP addresses in public clouds are ephemeral, a static policy does not allow microsegmentation or zero trust. 

A simple example: it is very common for new applications/workloads to be deployed via automation (AWS CFT, Terraform, etc), or for applications to auto-scale. How does a static security policy based on IP addresses deal with this? Does it allow granular policies for dev/test/prod/compliance or frontend/app-logic//backend or more granular microservices-based architectures? A basic need is to allow dev systems wider access, say github.com/*, while production or compliance systems can only connect to github.com/myOrgRepo. 

7) Cloud-friendly Pricing

A simple cloud-friendly pricing model should include no more than 1 or 2 metrics. You want predictable pricing and clarity in the budgeting and purchase process. The Palo Alto Cloud Next Gen Firewall includes multiple pricing components with additional upsells for what should be essential security features.

Summary: Palo Alto Networks Cloud NGFW 

In summary, it is an admirable attempt at porting old technology for the new age, but there are serious flaws in this offering. We believe there is a better way with a platform that continuously adapts to the elasticity of public clouds, takes minutes to deploy and operate, and improves the productivity of your security teams.

You can verify this using this AWS Workshop for Valtix tutorial with our Free Tier.