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...
... View more