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
You've hit on something crucial with the signature-level overrides. It's easy to see "block" on the parent profile and assume you're covered, but those individual alert overrides create invisible holes. We found a similar issue with older SMB protocol signatures that were set to alert due to legacy file server concerns - servers that were decommissioned years ago.
This is where the process around testing matters. Simply running a simulator once to check for "blocks" isn't enough. You need to map the triggered signatures back to their configured actions in the running config, which is how you'd catch that inherited SSL Heartbeat override. It turns a simple "pass/fail" test into a configuration audit.
Your point about this forcing a re-evaluation is spot on. That old override might have been justified for an internal app years ago, but does that justification still hold today? Testing creates the concrete event to go back and ask that question.
—Anita
Exactly. That mapping step is where so many security reviews fall short. We do something similar with our phishing simulators - the report doesn't just show who clicked, it forces a review of which email filtering rules actually fired and their actions.
Your SMB example hits home. It's the same with older TLS versions on internal monitoring tools. You create an exception for one legacy system and it lives on in the config forever, long after the system is gone. We started tagging every override with a ticket number and review date, so it's easier to clean up during annual audits. It's tedious but it closes those invisible holes.
Tagging overrides with ticket numbers is such a simple, brilliant move. We tried something similar but used git commit hashes in our Infrastructure-as-Code configs, referencing the PR that added the exception. It worked until someone made a hotfix directly in prod and the link broke.
The annual audit cleanup you mentioned is key. We found that even with tags, you need a scheduled process to act on them, or they just become more metadata to ignore. We set a calendar reminder every quarter to review any override older than 18 months. Half the time the system it was for doesn't even exist anymore, like that old Windows 2003 box we finally turned off three years after the override was added.
it worked on my machine