netsec-generalist Network Security Professional Practice Questions

While SAML handles the user identity part of authentication, the firewall needs a way to validate the client certificate presented by the GlobalProtect agent. This is accomplished using a Certificate Profile. The Certificate Profile is configured with the CA certificate that signed the client certificates. This allows the firewall to verify the authenticity and validity of the client certificate during the authentication process. It is a mandatory component for enabling client certificate-based authentication.

A rule allowing the generic 'ssl' application is a major visibility blind spot. The best practice is to implement SSL Forward Proxy decryption. Once the traffic is decrypted, App-ID can accurately identify the specific applications running inside the SSL tunnel (e.g., 'google-drive', 'salesforce', 'github'). The administrator can then create granular Security policy rules for these specific applications, allowing for tailored threat prevention profiles and much tighter security control.

The firewall uses two main processing paths. The Slow Path (or session setup path) is used for the first packet of a new session, where policy lookups, App-ID, and Content-ID are performed. Once the session is established and deemed eligible for acceleration, it is offloaded to hardware. All subsequent packets for that session are processed entirely in the Fast Path for maximum performance, bypassing the more intensive Slow Path processing.

SSL Forward Proxy is a legitimate man-in-the-middle operation. The firewall intercepts the client's SSL/TLS session, establishes its own session to the destination server, and then creates a new session back to the client, signing the server's certificate with its own 'forward trust' certificate. Because clients' browsers do not inherently trust the firewall as a Certificate Authority, they will present a certificate warning. Deploying the forward trust certificate to the clients' trusted CA stores makes the browser trust the firewall, eliminating these warnings and allowing decryption to occur seamlessly.

The log message 'policy-deny' explicitly indicates that the traffic is being dropped by a security policy. Since the diagram shows an intended 'allow' rule (Rule #5) and a final 'deny' rule (Rule #20), the most probable cause of an intermittent 'policy-deny' is that another, more specific deny rule exists between Rule #1 and Rule #4 that is sometimes matching the user's traffic. Palo Alto Networks firewalls process rules from top to bottom and stop at the first match. An intermittent issue could be caused by the application changing behavior or ports, causing it to match a different, higher-priority deny rule.

In a Zero Trust model using GlobalProtect, enforcing device compliance requires both collecting HIP data and applying it in policy. While the Security policy rule correctly identifies the user group via User-ID, it is ineffective at checking device posture without a HIP Profile attached. The HIP Profile defines what constitutes a 'compliant' device, and adding this profile to the rule ensures that traffic will only match if both the user and the device posture criteria are met.

For SSL Inbound Inspection to work, the firewall must be able to act as the destination web server. This requires importing the server's certificate and its corresponding private key. Additionally, because the server's certificate is signed by an internal CA, the firewall itself does not inherently trust this CA. You must import the internal root CA certificate onto the firewall and explicitly configure it as a Trusted Root CA to validate the server certificate's chain of trust.

In a hub-and-spoke topology where traffic is forced through a firewall, the private IP addresses from the spoke VNet are not routable on the public internet. The firewall must translate the source IP addresses of the traffic from the spoke VNet to its own public-facing IP address before sending it to the internet. This requires a Source NAT (SNAT) policy. Without it, return traffic from the internet will not know how to get back to the originating private IP in the spoke VNet.

Prisma SD-WAN continuously monitors the health of all available paths based on metrics like latency, jitter, and packet loss. If a path, such as the MPLS link, fails to meet the configured health thresholds, it will be marked as down or degraded. Even if a path policy explicitly directs traffic to that link, the SD-WAN controller will automatically reroute the traffic to the next-best available path (the broadband link) to maintain connectivity, bypassing the preferred path.

A complete Prisma Access solution requires several components. A Service Connection is essential to connect the Prisma Access backbone to the private applications in the AWS VPC. Remote Network connections are needed to securely connect the physical office locations to Prisma Access. Finally, GlobalProtect must be deployed on user devices to provide secure access for mobile and remote users, ensuring they connect to the nearest Prisma Access node for low-latency performance.