Prepare and test your skills
Prepare and test your skills
Threat inspection profiles for application traffic are Layer 7 controls on Cloud Next Generation Firewall (Cloud NGFW) (opens in a new tab) that combine intrusion detection and prevention, malware analysis, and granular firewall rules. Traffic flows from clients and load balancer proxies to application backends, and Cloud NGFW inspects the application payload before the allow or deny decision is applied. Tuning means aligning signatures, actions, and logging to application criticality, then feeding findings into a central monitoring loop for continuous adjustment.
Intrusion detection and malware scanning at Layer 7 add application-aware inspection on top of network firewall enforcement. Cloud NGFW performs inline inspection that helps defend against OWASP Top 10:2025 risks including A01: Broken Access Control and A05: Injection. Cloud Intrusion Detection System (Cloud IDS) operates as a complementary network sensor, while Google Security Operations (Google SecOps) ingests telemetry from firewalls, endpoints, identity providers, and multi-cloud sources to correlate events and coordinate response playbooks.
Malware handling depends on threat intelligence and runtime context flowing into the same pipeline. Agentic Threat Intelligence uses data from Mandiant and VirusTotal to automate reverse engineering of code, analysis of malware, and generation of custom threat briefings. Wiz Defend integrates with Google SecOps to monitor runtime behavior, configurations, identities, and vulnerabilities inside the cloud environment and to send prioritized alerts with forensic evidence. The agentic SOC in Google SecOps can then automatically investigate alerts, provide technical context and recommendations, and help create or fill gaps in detection rules.
Rule scope in Cloud NGFW defines exactly which traffic a threat inspection profile applies to. Each firewall rule binds a VPC network to a set of targets, a direction, a priority, an action on match, a source filter, and specific protocols and ports. Traffic flows from the defined source to the tagged backend, and only matching packets are inspected under that profile, which keeps critical production applications under stricter control than lower-risk workloads.
Practical tuning starts from deny-by-default and documented justification of every allowed service, protocol, and port. Hardened baselines block generic access to infrastructure ports and overly permissive paths:
For load-balanced applications, three patterns show how scope is narrowed. The fw-allow-health-check ingress rule allows TCP port 80 from Google Cloud health checking systems at 35.191.0.0/16 and 130.211.0.0/22 to targets tagged allow-health-check or allow-hc. The fw-allow-proxy-only-subnet ingress rule allows TCP port 80 from the proxy-only subnet ranges to backends tagged allow-proxy-only-subnet, so traffic flows from the managed proxy to zonal network endpoint groups. The fw-allow-ssh ingress rule allows TCP port 22 to targets tagged allow-ssh, and its source range should be restricted to administrator addresses rather than 0.0.0.0/0 for critical systems.
Exam tip: Health-check allow rules must use the Google health-check source ranges 35.191.0.0/16 and 130.211.0.0/22; the Cloud NGFW parser then uses the log action and direction fields to populate the correct Unified Data Model fields.
The log pipeline for Cloud NGFW moves firewall telemetry into Google SecOps for correlation and tuning. Collection requires a Google SecOps instance, an active and configured Cloud NGFW deployment, and privileged access to Cloud NGFW logs. Logs flow from Cloud NGFW to a Cloud Storage bucket, then through a configured feed to Google SecOps, where parser version 2.0 extracts connection details, threat information, rule details, and network information.
Ingestion and review follow an ordered sequence:
gcp-ngfw-logs, with location, storage class, access model, and encryption selected before creation.action and direction to populate the Unified Data Model correctly.This loop connects perimeter enforcement to long-term risk management. Projects are grouped into dedicated perimeters by environment tier such as production, outbound API requests are routed through the VPC network, and Access Context Manager access levels evaluate corporate IP subnets, identity claims, and device health at ingress. When alerts show missed attacks or false positives, the team adjusts which applications carry the strictest inspection, updates allowed ports and sources, and maintains a pre-approved break-glass process for emergency response.
Analysis of application traffic logs for Cloud NGFW means interpreting Layer 7 inspection results and feeding them into centralized monitoring and response. Cloud NGFW produces two linked signals for inspected traffic: a firewall policy rules log for the initial Layer 3 and Layer 4 decision, and a URL filtering log (opens in a new tab) from the firewall endpoint for the Layer 7 domain and session analysis. Google Security Operations ingests both signals, normalizes them into its data model, and makes them available for anomaly detection, policy validation, and incident response.
Firewall policy logs record the network-layer decision before application inspection occurs. Cloud NGFW first logs a firewall policy rules logging entry when traffic is evaluated by a firewall rule. That entry records network-layer facts such as source IP address, destination IP address, source and destination ports, protocol, and time of inspection, and it answers whether the traffic matched a rule and whether logging was enabled on that rule.
If the matching rule enables Layer 7 inspection and logging, traffic flows next from the rule engine to the firewall endpoint for deeper inspection. The firewall endpoint then analyzes the domain and Server Name Indication (SNI) and creates a separate URL filtering log for the same connection. That second log carries application-layer facts such as domain name, traffic source, traffic destination, connection 5-tuple, intercepting instance identity, and detection time. The order is fixed: first the VPC firewall rules entry, then redirection to the endpoint, then the URL filtering entry. To view URL filtering output, query Cloud Logging Logs Explorer for the log name networksecurity.googleapis.com/firewall_url_filter, where the resource type for endpoint-generated entries is networksecurity.googleapis.com/FirewallEndpoint.
Domain and session details in URL filtering logs show what the firewall endpoint actually observed at Layer 7 and in the TLS session. Application-layer details center on the uri field, which holds the domain and subdomain information read from the traffic. Session-layer details center on SessionLayerDetails, which holds the sni string read from the traffic and the protocolVersion used at the session layer.
Where the endpoint reads the domain depends on the HTTP version, because newer versions do not always carry a host header:
| HTTP version | How the firewall endpoint reads the domain |
|---|---|
| HTTP less than 1 | From the first host header field |
| HTTP1 | From the first host header field for HTTP version 1.x |
| HTTP2 | From the authority pseudo-header or from header blocks of header, continuation, or push_promise frames, because the host header is optional |
The session protocol version identifies the TLS version observed for the connection. The observed values include:
Together, the domain source, SNI, and TLS version let an analyst distinguish expected application behavior from anomalies, such as an unexpected SNI for a destination, outdated TLS versions, or domains that should have been blocked by policy.
Exam tip: The VPC firewall rules log and the URL filtering log are separate entries in a fixed order — first the rule evaluation, then the FirewallEndpoint URL filtering log named networksecurity.googleapis.com/firewall_url_filter — so correlate them by matching IP addresses, ports, protocol, and time.
The export pipeline to Google Security Operations moves firewall telemetry from Cloud Logging into long-term security analytics. Logs flow from Cloud NGFW to Cloud Logging, then through a Log Router sink to a Cloud Storage bucket, then into Google Security Operations through a configured feed where parser version 2.0 maps fields into the Unified Data Model (UDM). The parser extracts connection details, threat information, rule details, and network information, performing type conversions, renaming, and conditional logic based on the action and direction fields so source, destination, and verdict populate correctly in UDM.
Prerequisites for the pipeline must be in place before export works reliably:
The ingestion pipeline follows an ordered sequence:
gcp-ngfw-logs, choosing location, storage class or Autoclass, access controls, labels, and encryption.NGFW-Export-Sink with a Cloud Storage destination such as gs://gcp-ngfw-logs/ and a filter that selects Cloud NGFW and URL filtering logs.The bucket sits on the storage side of the trust boundary, while Log Router sits on the logging side and Google Security Operations sits on the analytics side. The sink depends on the bucket existing first, and the feed depends on both the sink delivering objects and the service account having access. If any dependency breaks, logs stop flowing into the security operations workflow even though firewall enforcement continues.
Policy validation with Layer 7 logs confirms whether inspection policy works as designed and where it needs tuning. Repeated allows to a domain that policy intended to deny, sudden growth in hits for one rule, new SNI values for a known service, or downgraded TLS versions across many clients all signal either misconfiguration or emerging malicious behavior. Comparing the firewall rule log verdict with the endpoint URL filtering result shows whether the Layer 4 allow correctly led to Layer 7 inspection and whether the final domain decision enforced the intended category or custom list.
Once normalized into UDM, the same telemetry feeds broader monitoring and incident response. Connection, threat, rule, and network fields become searchable entities in the Google Security Operations security information and event management (SIEM) system, where analysts can hunt across firewall, endpoint, identity, and cloud telemetry, build detections on anomalous domains or high-risk SNI patterns, and trigger playbooks for containment. Because the parser preserves action, direction, addresses, ports, rule identity, and threat context, responders can move directly from a URL filtering alert to the affected workload, the responsible policy, and the scope of similar connections without re-collecting raw logs.
Granular application-based security rules on Cloud NGFW control traffic by what the application reveals at Layer 7, not only by source IP address and TCP port. A firewall policy rule still matches network, direction, source, and destination, but when Layer 7 inspection is enabled the decision can also use domain and subdomain in the URI, SNI, and HTTP and TLS versions observed by a firewall endpoint. This moves enforcement beyond allowing tcp:80 or tcp:443 toward allowing or denying specific applications and services carried inside those connections.
Port-based allows remain the foundation that Layer 7 inspection builds upon. A traditional Cloud NGFW and VPC firewall rule defines a network such as lb-network, a direction of INGRESS, an action on match of allow, a set of target tags or target VMs, a set of source IPv4 ranges, and an allowed protocol with ports. Traffic flows from the defined source range to the tagged destination, and the rule permits only the listed protocol and ports while denying everything else that does not match. An internal Application Load Balancer (opens in a new tab) setup uses the same pattern to connect proxies to backends inside a VPC network.
Three common rules show the least-privilege starting point:
fw-allow-health-check permits ingress TCP probes from Google Cloud health checking systems at 130.211.0.0/22 and 35.191.0.0/16 to backends tagged load-balanced-backend or allow-health-check, narrowed in practice to health-check ports such as tcp:80.fw-allow-ssh permits ingress TCP port 22 to VMs tagged allow-ssh, where the source range should be restricted to administrator systems instead of 0.0.0.0/0 when possible.fw-allow-proxies permits ingress TCP ports 80, 443, 8080 or service port 9376 from the proxy-only subnet range such as 10.129.0.0/23 to backends tagged load-balanced-backend, so traffic flows from load balancer proxies to the backend VMs.Granular application rules depend on these Layer 3 and Layer 4 allows because the firewall endpoint only receives traffic that the firewall policy first evaluates and forwards. If the base rule blocks the client IP, server IP, or TCP port, Layer 7 analysis never occurs, so least-privilege ports and sources should be combined with domain and SNI controls.
The inspection flow through firewall endpoints separates network reachability from application identity on the same connection. The firewall endpoint is the Cloud NGFW inspection point that performs application-layer analysis after initial firewall evaluation. The policy enforcement point evaluates the connection against the firewall policy, and the firewall endpoint then reads HTTP host information and TLS SNI from the traffic to identify the requested domain and service.
Traffic subject to a rule with Layer 7 inspection and logging follows an ordered sequence:
Exam tip: A connection with Layer 7 logging produces two logs in order — first the VPC firewall rules logging entry, then the separate networksecurity.googleapis.com/firewall_url_filter log from the networksecurity.googleapis.com/FirewallEndpoint resource.
Application signals for granular decisions describe the domain identity and protocol version that the firewall endpoint reads from live traffic. The uri field carries the domain and subdomain information extracted from the request, while the sni field in SessionLayerDetails carries the Server Name Indication read from TLS traffic. A granular rule can therefore distinguish two different services that share the same destination IP address and TCP port 443 by their requested domain and SNI values.
How the firewall endpoint reads the domain depends on the HTTP version in use:
| HTTP version | Meaning | Where the firewall endpoint reads domain information |
|---|---|---|
| Less than HTTP/1 | HTTP version less than 1 | First host header field |
| HTTP1 | HTTP version 1.x | First host header field |
| HTTP2 | HTTP version 2.x | Authority pseudo-header or header blocks of header, continuation, or push_promise frame types, because the host header field is optional |
The session-layer protocol version provides a second decision axis for granular policy. The protocolVersion field records the TLS version that the firewall endpoint observes at the session layer, which lets policy distinguish legacy from modern encrypted sessions even when the SNI is the same:
TLS1_0 indicates TLS version 1.0.TLS1_1 indicates TLS version 1.1.TLS1_2 indicates TLS version 1.2.TLS1_3 indicates TLS version 1.3.Choose stricter handling when traffic uses outdated HTTP behavior or legacy TLS versions, and reserve broad allows for modern, explicitly identified applications where domain, SNI, and version all match the intended service.
Tracing connections across both log types links a network-level allow to the application identity that triggered URL filtering. The firewall policy rules log identifies the connection by 5-tuple and inspection time, while the URL filtering log identifies the same connection by client IP, client port, server IP, server port, protocol, domain, and SNI. Comparing the two logs shows which firewall rule evaluation led to which Layer 7 verdict, so an operator can trace an application block back to its exact client and server endpoints.
To view URL filtering logs, search Logs Explorer for the log networksecurity.googleapis.com/firewall_url_filter and filter on the FirewallEndpoint resource and connection fields. For example, a rule evaluation from source 192.0.2.0 port 47644 to destination 192.0.2.1 port 80 with logging enabled produces a firewall log and then a URL filtering entry where clientIp is 192.0.2.0, clientPort is 47644, serverIp is 192.0.2.1, serverPort is 80, and protocol is TCP. The URL filtering entry also records detectionTime and interceptInstance details such as zone, VM, and project ID, which together identify where Cloud NGFW intercepted the connection for inspection.
35.191.0.0/16 and 130.211.0.0/22, while proxy traffic must be limited to the proxy-only subnet and SSH should avoid 0.0.0.0/0 for critical systems.networksecurity.googleapis.com/firewall_url_filter from resource networksecurity.googleapis.com/FirewallEndpoint.gcp-ngfw-logs, then into Google Security Operations where parser version 2.0 normalizes fields into the Unified Data Model.The firewall policy rules log is written first and records the Layer 3 and Layer 4 rule evaluation including source and destination IP addresses, ports, protocol, and time of inspection. If the matching rule enables Layer 7 inspection and logging, the firewall endpoint then creates a separate URL filtering log named networksecurity.googleapis.com/firewall_url_filter that records application-layer facts such as domain name, Server Name Indication, traffic source and destination, and detection time.
Logs flow from Cloud NGFW to Cloud Logging, then through a Log Router sink to a Cloud Storage bucket such as gcp-ngfw-logs, then into Google SecOps through a configured Google Cloud NGFW Enterprise feed. Parser version 2.0 then normalizes the records into the Unified Data Model by converting data types, renaming fields, and applying conditional logic based on action and direction.
Health-check allow rules must permit ingress TCP port 80 from Google Cloud health checking systems at 35.191.0.0/16 and 130.211.0.0/22 to backends tagged allow-health-check or load-balanced-backend. Proxy traffic should be separately limited to the proxy-only subnet and SSH should be restricted to administrator addresses rather than 0.0.0.0/0 for critical systems.
An enterprise has deployed Cloud Next-Generation Firewall (Cloud NGFW) Enterprise with Intrusion Prevention Service (IPS) profiles and TLS inspection to secure sensitive workloads within a VPC network. The Security Operations Center (SOC) is investigating suspicious outbound Layer 7 application traffic suspected of being command-and-control (C2) communication.
The security team must:
Which logging analysis and integration strategy should the security engineer implement?
Last updated