Introduction
Once, there was only a “threat prevention” subscription to leverage those capabilities that, generically, are collected under the name “IPS”.
Between those capabilities there’s an engine looking for bad actors inside files that pass through the firewall. In a very intuitive way its name is “Antivirus” and, more or less, it works like every similar software, searching through a database of malware signatures. Historically, threat prevention subscription enable the option to automatically update that database daily with new signatures.
Although always useful, over time the frequency of daily updates has become insufficient to cope with so-called “zero days”. Moreover, the signature database cannot grow indefinitely, and for every new signature introduced it became necessary to remove another, perhaps obsolete or not particularly critical. Also for this reasons, about 10 years ago with PAN-OS 6.0 Wildfire technology was introduced.
Wildfire basics
The working mechanism of Wildfire is well known, so I won't go into too much explanation. At the heart of the technology there’s a cloud sandbox (managed by Palo Alto Networks) that takes unknown files from customer firewalls and execute them to analyse their behaviour, producing a response verdict. If that verdict is deemed malicious, a new threat signature gets created. Every five minutes, a package with new signatures is made available for download from the firewalls with an active Wildfire subscription.
If we look back to our antivirus engine, one big advantage of this subscription becomes immediately clear, as the interval between signature updates goes from 24 hours to 5 minutes. There’s more: since PAN-OS 8.0, if the firewall has an active PAN-DB URL Filtering subscription, Wildfire can also analyse links in e-mail messages and report phishing websites, so that URL Filtering can block them within 5 minutes since initial discovery.
A broader look
Speaking instead of the ability to send unknown files to Wildfire for analysis, in all honesty I have never been able to fully appreciate the benefits, clearly excluding community (correction: community AND Palo Alto) benefits. Let me explain what I mean.
OK, in theory there is a chance of being the first victim of malware that no one has ever seen before (the so-called patient zero), a very very low chance. But if it were to happen, would the 5-minute gap (between Wildfire verdict and the ability to stop the malware through antivirus engine) be enough to avert disaster?
For me the answer is no.
We’ll talk later about the newest Wildfire features like real-time signature updates and hold mode, but for the time being my view is that the ability to secure patient zero is still a pipe dream, although maybe we are not too far from achieving it.
So the question is: should we continue to share our precious files with Palo Alto for the sake of the world, given the very low probability to benefit from it? Or perhaps it would be wiser to just take signatures and avoid sharing our know-how?
All in all, for me this time the answer is yes, we should upload our files where reasonable. Because Palo Alto takes very seriously our privacy, and also because, let's face it, our data is the fuel for the engine which over time gives us better and better security.
Real-time signature updates
With the release of PAN-OS 10 the option to retrieve Wildfire signatures in real-time has been introduced. You might think the goal of this option is to allow signature retrieval without any delay, but there’s more and, though, it’s not all fun and games.
Remember we mentioned that the signature database downloaded on the firewall has a limited size: with the real-time option this limitation is no longer present, as the firewall can query a supplemental archive of “replaced” signatures, that is signatures that have been removed from the main database to make room for others.
Sounds good doesn’t it? More signatures == more security is the idea…
…but the cruel reality, at least in my experience, is different. More signatures == more false positives, and almost the same security.
What I mean is that when I enabled this feature, especially on large environments, I had to deal with tenths of false positives every time, all coming from the supplementary database. Signatures coming from that database are easy to recognise looking Threat Vault, where the current release is shown as “N/A”. This and also this knowledge base articles explains well the situation.
I’ve discussed the issue with TAC, sending them several false positives samples. They disabled some of the signatures I reported, by the way the real problem is that I'm having a hard time remembering if I've had a match at least once of a real threat coming from the supplementary database. Most likely not.
The sad conclusion is: unless the client explicitly requests it, I no longer enable this feature. In my experience, there is no worse thing than giving the customer the feeling that a device is not behaving reliably, and that is exactly what happens in this situation.
Taking a cue from my favourite game (chess, of course), this move was quite an inaccuracy.
I would really, really, really love to have a flag or a command to enable real-time lookup not including supplementary database. Maybe someday I’ll try to open a feature request.
Hold mode
What about the next move? Since PAN-OS version 11.0 a new Wildfire option called Hold Mode is available. At first sight it looks interesting, the idea is to hold the file transfer until the Wildfire engine gets a verdict, but there are a couple of points to clarify.
First of all, it is important to point out that the firewall holds the file transfer waiting for real-time signature lookup (and not for file upload). This means that real-time signature updates must be enabled, with the pros and cons explained in the previous section. And also, what if the uploaded file is unknown to Wildfire and doesn’t have a signature? Well, although I haven't tested this scenario yet, I think I can say that the firewall can't wait for the file to be detonated in the sandbox. Also because the default timeout for signature verification is 1000ms (1 second), definitely too little for the execution in the Wildfire cloud.
Thus, another step toward patient zero protection, but full coverage is still yet to come.
One important thing to note: if you enable hold mode, you should enable in turn the option to reset the session in case of timeout, otherwise there is no point.
Conclusions
Wildfire is the perfect example of a feature that is very easy to set up, but behind the scenes has a very complex mechanism. The goal of this article is to explain a part of this mechanism, I hope you enjoyed it! Please feel free to post comments if you would like to discuss this topic further, and if you would like to give me a hand in making this blog even richer please consider buying me a coffee or two!