Next-Gen Cloud Network Security: Mastering NGFW Enterprise in GCP
Overview
Welcome to a new series of articles that dives deep into the heart of cloud network security with a comprehensive exploration of NGFW Enterprise.
Let’s see what it is, how it works, and some recommendations for its deployment. In the articles to follow, we’ll delve deeper into the intricacies of TLS configuration and provide best practices for crafting effective firewall policy rules.
Next Generation Firewall Enterprise (NGFW Enterprise) comes as part of the broader Cloud NGFW offering: the GCP fully-distributed firewall offering. You can read more about it in the official documentation.
NGFW Enterprise is a scalable, Google-managed Intrusion Prevention System (IPS), using the Palo Alto Networks threat engine.
Navigating the challenges of deploying and managing NVAs in the cloud, especially across multiple regions, is a familiar pain point for many organizations.
NGFW Enterprise steps in to alleviate these burdens, freeing you from the complexities of VM management, licensing, intricate configurations, and potential performance bottlenecks.
Architecture
NGFW Enterprise is made of different resources that wire together in many different ways.
The core components are visually represented in green within the accompanying diagram.
Let’s go through each of them.
Security Profiles (and Security Profile Groups)
Security profiles leverage Palo Alto’s threat signatures (automatically updated every 48 hours) to define threat criticality and appropriate actions for each level. These profiles function as global resources at the organization level.
You can override default severities based on specific threat IDs and adjust default actions associated with each severity level.
Security profile groups don’t require additional configurations. They simply map firewall policy rules to a security profile. They are also org-level, global resources. We’ll delve deeper into the interaction between firewall policy rules and these components shortly.
Firewall Endpoints (and Firewall Endpoint Associations)
These are what I like to call the “engines” of the system.
They are clusters of Palo Alto machines, providing inspection capabilities within a specific zone of your organization.
Importantly, they’re designed for resilience — not a single point of failure. They automatically scale in and out, based on traffic volume, ensuring smooth operation.
You can link each firewall endpoint up to 50 VPCs in your organization using Firewall Endpoint Associations. These associations operate at the project level within a zone.
Firewall Endpoint Associations simply link Firewall Endpoints to VPCs and TLS inspection policies (we’ll talk more about this in the TLS section down below).
Each firewall endpoint can handle up to 10 Gbps without TLS inspection (more on this later) and 2.5 Gbps inspecting TLS.
Firewall Policy Rules
Binding Firewall Endpoints to your VPCs allows traffic inspection, but doesn’t automatically route traffic through it. To enforce inspection, you’ll need to create specific firewall policy rules.
You can now use the new apply_security_profile_group action, within both hierarchical and global network firewall policies. This action lets you specify the desired security profile group for traffic inspection.
In short, you should leverage the same firewall policy rules you were using for L3/L4 firewall, but instead of specifying actions like “allow”, “deny”, or “goto-next”, you now use the new action to send traffic for inspection.
A fail-open approach
It’s very important to know that, at the moment of writing, NGFW allows the traffic:
- In the unlikely case an endpoint completely fails
- If you deploy VMs in zones where Firewall Endpoints are not present
You can overcome these by:
- Monitoring the health of your Firewall Endpoints (more below)
- Enabling organization policies that prevent users to deploy machines outside a set of well known zones in your organization
Manage your Palo Alto deployment
Palo Alto Panorama appliances currently can’t manage Firewall Endpoints. NGFW Enterprise is a fully managed Google solution, so configuration is done through Security Profiles, and logs are viewed in Cloud Logging.
Monitoring your endpoints
You can monitor your endpoints by leveraging the networksecurity.googleapis.com/firewall_endpoint metric in Cloud Monitoring. For each endpoint, you can retrieve its status (whether it’s healthy), the bytes sent and received, and the number of threats intercepted. Just like any other metric, you can set alerts. For example, the system can proactively notify you when the endpoint’s health deteriorates or new threats are detected.
Logging
Like most GCP products, NGFW Enterprise provides detailed logs about intercepted threats. To help you navigate this information, I’ve created a diagram that visually groups and connects the key log fields. I believe it’s fairly self-explanatory, so feel free to review it at your own pace.
Traffic you cannot inspect
It’s important to understand what traffic NGFW Enterprise cannot inspect. These limitations are inherent to the fully-distributed Google firewall and other Google products, not specific to NGFW Enterprise itself.
Traffic in-transit
NGFW operates on the hypervisors where the VMs live. As such, NGFW won’t be able to inspect in-transit traffic. This affects both traditional L3/L4 firewall rules and those using the new apply_security_profile_group action.
Therefore, effective firewall policies can only be applied where your VMs reside, not in empty VPCs used solely for routing.
Consider a typical hub-and-spoke architecture (illustrated in the first diagram below) to visualize this.
Firewall policy rules configured in the hub will have no impact, as traffic between on-premises and spokes merely transits through it.
However, you can still control traffic by:
- Placing ingress and egress firewall policies directly in the spokes
- Utilizing your own Network Virtual Appliance (NVA), either on-premises or within GCP
Managed Services
Google frequently deploys managed services within their own dedicated VPCs, connecting to user VPCs via Private Service Access (PSA) or Private Service Connect (PSC).
While you can’t create firewall policies within these Google-managed VPCs, you can establish egress rules to inspect traffic flowing from your VMs to these services.
However, what happens to traffic traversing your VPC to access these managed services? Consider this scenario: two VPCs serve as the entry point for hybrid connectivity from on-premises, and one also connects to a Cloud SQL instance using PSA.
As discussed earlier, inspecting traffic that merely transits through the user VPC isn’t possible. If inspecting and filtering this traffic is essential, integrating NGFW Enterprise with traditional NVAs remains the solution.
Serverless Resources
Serverless ingress is not (and never has been) controlled with firewall rules, but rather with IAM. For example, a service account or a user need to be cloud functions invokers in order to be able to call a cloud function directly. Given you can’t apply firewall policies to serverless resources, you won’t even be able to inspect the traffic towards them.
Terraform Support
The Terraform Google provider is ready to accomodate your NGFW Enterprise deployment. Here is the list of resources:
- network_security_security_profile
- network_security_security_profile_group
- network_security_firewall_endpoint
- network_security_firewall_endpoint_association
- network_security_tls_inspection_policy
We also added support for NGFW Enterprise in Fabric FAST, adding a new network-security stage.
Conclusions
In conclusion, NGFW Enterprise presents a compelling solution for enterprises seeking to enhance their cloud security posture without the complexities of managing traditional NVAs. While it offers numerous advantages in terms of scalability, automation, and threat detection capabilities, it’s important to be aware of its limitations regarding traffic inspection in transit, managed services, and serverless resources.
As GCP keeps evolving, NGFW Enterprise stands as a valuable tool for fortifying your security framework. By carefully considering its strengths and limitations, you can effectively leverage its features to safeguard your critical assets and data within the dynamic cloud landscape.
Hope you enjoyed the intro and I’ll see you very soon with following articles on NGFW Enterprise design considerations and a deep-dive on TLS.
