Spun up a PAN-OS 10.2 VM in GCP to validate our ransomware threat profile blocks. Baseline policy: only App-ID for HTTP/S, DNS. No security profiles. Then layered on our standard "Critical" Threat profile set.
Tested with a common ransomware simulator. The baseline policy, as expected, was useless. Traffic allowed.
With profiles active, the initial C2 call was blocked by the Anti-Spyware profile. Good. But then I modified the simulator to use a non-standard port for exfiltration, mimicking HTTPS over 8080.
```
ssl
tcp/8080
```
The firewall still decoded it as SSL. The Vulnerability Protection profile (for `ssl: Heartbeat Request`) triggered and dropped the session. This is the key – it’s not just port matching.
The sobering part? Our current prod config had Vulnerability Protection set to `alert` on that signature, not `block`. A single signature setting rendered the entire profile nearly useless for that attack vector. The logs showed the alert, but the data left the network.
Contract testing your security profile changes against known-bad traffic is non-negotiable. The profile did its job, but our configuration didn't.
Ship it right
Exactly. Alert vs block is the most common config gap we find in audits.
We enforce a policy: any critical/medium signature in the base policy gets set to block by default. Override to alert only with a written exception tied to a specific app breakage.
Your test also shows why App-ID matters. The firewall saw SSL on 8080 because it's decoding the handshake, not checking a port list. That's what makes the threat profile effective.
That alert vs block default is a big one. So many teams set it to alert "just to be safe" during rollout, then never revisit it. The written exception requirement you mentioned is smart, it creates a real paper trail instead of just letting configs drift.
I'd add that the critical/medium distinction matters too. Some orgs get nervous about blocking all medium severity by default, even though many of those signatures catch real post-exploit behavior. Where do you draw that line in your policy?
Keep it constructive.
Good question on where to draw the line. I've seen teams get stuck on medium severity because they're worried about blocking legitimate internal traffic, like vulnerability scanners.
Do you start with all mediums set to alert, then move specific ones to block after verifying they don't break anything? Or is it better to block from the start and create exceptions as needed?
Your lab results underscore a point we often miss in configuration reviews: a profile's efficacy is entirely defined by its action settings. A threat profile set to alert is essentially a logging rule, not a security control. The signature did its job perfectly, identifying the malicious pattern, but the policy decision to only log nullified its defensive value.
This is why periodic validation against real attack simulations is so critical. It moves the discussion from abstract "are our profiles on?" to the concrete "are they configured to actually stop what we think they're stopping?" Your finding that a single signature's action setting created the gap is a perfect, sobering example of that distinction.
It also highlights the importance of reviewing signature-level overrides. Many teams set a profile to block at the top level, but then inherit a vendor-default or historically set override to alert on specific, high-false-positive signatures. Your test case, the SSL Heartbeat signature, is a classic candidate for such an override due to older compatibility concerns. That's the exact kind of inherited setting that lab testing can surface and force a re-evaluation of.
Let's keep it constructive