- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
We have Palo Alto appliances and we have Sourcefire IDS appliances running side by side in various configurations at work. I can't emphasize enough how convenient it is to be able to have an IDS event fire off from our Sourcefire boxes, and when I drill into the event I can actually see the rule that was written that matched on the event.
In my experience it's to the point where weeding out legitimate traffic that was false positively identified as malicious entirely depends on my ability to read the rule that fired off.
For this reason we now essentially run two IDS/IPS solution... Palo Alto's threat and vulnerability subscription, and the Sourcefire VRT rule subscription.
What would be a "game changer" in this regard would be if Palo Alto released their rules to customers and followed essentially the Sourcefire model of "open rules, released a month late." Right now I can't do a lot with the Palo Alto threat events that fire off, because while I can open up a pcap of the network traffic involved in the event, I have absolutely no idea why the event was trigered by PA's threat engine.
I personally somewhat agree with the difference that I dont want to see two branches but rather a single one meaning that the current rules (well db) should be made "open" for paying customers.
That is not only it would be easier to duplicate an already existing threatid/appid and add/remove whatever is needed but as you mentioned when debugging to find out if its a false-positive (or false-negative).
This could of course also be handled through NDA but best would be if the db would be available through the gui/cli.
One argument against this might be that the bad guys (and girls) would then will be able to analyze their way through a PA but the same way as security should never rely on obscurity (even though you perhaps shouldnt bring everything onto the lap of the attacker) I think the same applies in this case (open source vs closed source).
The bad guys (and girls) could just bruteforce their way through a PA before releasing the exploit (meaning not having the db open for customers doesnt really block any bad guys/girls) and the competitors has most likely already tools to dig into the internals of the PA device (which also means that not having the db open for customers doesnt really block any bad competitors) - which leaves us that the only thing that NOT showing up how threatid/appid's are constructed is protecting from is the paying customers... which is somewhat akward...
So TLDR: I would also like PA to release actual content of both threatid and appid which would aid during debugging but also when one need to construct custom threatids/appids...
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!