Vulnerability profile including all signatures for specific application

[Mack]

Hi everyone,  I've read through the Admin Guide and have done some searching in KnowledgePoint, but can't find the answer I'm looking for...

Currently, in PANOS 4.1, in a Vulnerability profile, when one adds a rule, they can conditions to match signatures.  We can provide a string to match on Threat Name, for example I could add a rule with 'ftp' in the threat name and that rule will match all signatures that contain 'ftp' in the name.  I can also specify a rule that triggers on a specific category or severity level and any signature that matches the category or severity will be included in the profile.

However, what if I want to build a profile that includes all signatures for only a particular application, for example Remote Desktop? I can't use category or severity, as that will match all signatures.  I could add a rule with Threat Name = 'RDP'... but what if some signature names do not include RDP, but rather Remote Desktop Protocol? (BTW, this is the case.)  Or the old name, Terminal Services?  I could add rules for all three, but if Microsoft changes the name again and the newly released signatures use that name, our profile won't automatically include them.

Is there any way to specify "include all signatures for this application" as the definition for a vulnerability profile?

[mikand]

Any particular reason you wish to do this?

Because performance-wise you wont gain anything from this, perhaps lower the probability of false positive.

Cant you select a sub-category such as networking -> remote-access? This would cover the threats regarding remote-access stuff. However there can be other threats more general that one should look for aswell so I would stick to use a profile which will look for as many bad things as possible.

To lower the probability of false positives you could use low and informational severity set to action=default and medium, high and critical severity set to action=block. Do this for both spyware and vulnerability and then create a profile-group who will use your custom groups.

[Mack]

mikand wrote:
Any particular reason you wish to do this?

Specifically for the case where for one host we want to add an exception.

So for instance, say we have a all-hosts rule that applies default behaviour for all signatures.  Then we discover that there is a host for whom a specific signature is causing problems.  Since we don't want to turn that signature off for all hosts, we create a new rule just for that specific host and application.  We also create a new vulnerability profile that sets an exception for the problematic signature and apply it to the specific host rule.

The issue now is the content of the vulnerability profile itself.  Do we a) create a clone of the all-hosts-all-sigs vuln profile and except the problem signature, essentially giving us two near-identical, full-size profiles stored in the config file and memory, or do we b) create a vuln profile that only includes signatures that apply to the application in the host-specifc rule and except the problem signature there, giving us one full-size and one small-size profile to store.

Obviously my initial question was posed to see if scenario b) is actually a possibility without us having to revisit each of the special profiles once a week to add any new signatures.

mikand wrote:
Cant you select a sub-category such as networking -> remote-access? This would cover the threats regarding remote-access stuff. However there can be other threats more general that one should look for aswell so I would stick to use a profile which will look for as many bad things as possible.

There's no application-related fields/filters in the vulnerability profile.  The only option I see is to create a bunch of text-string match rules and hope that they collect all the signtures we need.

I'm hoping there is a better way to solve the problem, because right now only option a) seems sustainable.  I'm really concerned with a multiplicity of 4000-signature profiles cluttering up the config file and memory.  We have 800 rules or so to migrate from our old firewall and right now it looks like we could end up with several hundred full-size, single-exception profiles.

[Mack]

KMacnaughton wrote:
 
The issue now is the content of the vulnerability profile itself.  Do we a) create a clone of the all-hosts-all-sigs vuln profile and except the problem signature, essentially giving us two near-identical, full-size profiles stored in the config file and memory, or do we b) create a vuln profile that only includes signatures that apply to the application in the host-specifc rule and except the problem signature there, giving us one full-size and one small-size profile to store.
...
I'm hoping there is a better way to solve the problem, because right now only option a) seems sustainable.  I'm really concerned with a multiplicity of 4000-signature profiles cluttering up the config file and memory.  We have 800 rules or so to migrate from our old firewall and right now it looks like we could end up with several hundred full-size, single-exception profiles.

So I decided to check the config file today to see how much is stored for each vuln profile.  The config file is XML, meaning that it's bloated by structure/markup, but the vuln profiles only contain the select rules, which are 8 attributes in size, and the exceptions, which are also only a few attributes each.  Relative to the size of the config file itself, each vuln profile does not take much space.  So that is that issue put to rest.

As for how much memory each vuln profile takes up, that's a mystery to us.  One would assume that the programmers have come up with an efficient way to store profiles in memory and to do profile-signature matching as part of their one-pass architecture.

This might suggest that the memory concerns are moot and that option a) is viable, except for the bugaboo that many near-identical vuln profiles would have to be edited if we decided to change the default behaviour for a signature category or severity (e.g. we decide to block all medium severity threats instead of default action).

Maybe there will be an inheritance feature added, so that we can create an instance of a 'template' policy and the child instance will inherit any non-conflicting changes from the parent template...