<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Vulnerability profile including all signatures for specific application in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/vulnerability-profile-including-all-signatures-for-specific/m-p/44049#M32337</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;P&gt;KMacnaughton wrote:&lt;/P&gt; &lt;P&gt;The issue now is the content of the vulnerability profile itself.&amp;nbsp; 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;...&lt;BR /&gt;&lt;P&gt;I'm hoping there is a better way to solve the problem, because right now only option a) seems sustainable.&amp;nbsp; I'm really concerned with a multiplicity of 4000-signature profiles cluttering up the config file and memory.&amp;nbsp; 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.&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;So I decided to check the config file today to see how much is stored for each vuln profile.&amp;nbsp; 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.&amp;nbsp; Relative to the size of the config file itself, each vuln profile does not take much space.&amp;nbsp; So that is that issue put to rest.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;As for how much memory each vuln profile takes up, that's a mystery to us.&amp;nbsp; 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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...&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 10 Feb 2012 13:13:04 GMT</pubDate>
    <dc:creator>Mack</dc:creator>
    <dc:date>2012-02-10T13:13:04Z</dc:date>
    <item>
      <title>Vulnerability profile including all signatures for specific application</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/vulnerability-profile-including-all-signatures-for-specific/m-p/44046#M32334</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi everyone,&amp;nbsp; I've read through the Admin Guide and have done some searching in KnowledgePoint, but can't find the answer I'm looking for...&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Currently, in PANOS 4.1, in a Vulnerability profile, when one adds a rule, they can conditions to match signatures.&amp;nbsp; 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.&amp;nbsp; 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&amp;nbsp; 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.)&amp;nbsp; Or the old name, Terminal Services?&amp;nbsp; 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Is there any way to specify "include all signatures for this application" as the definition for a vulnerability profile?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 09 Feb 2012 15:29:55 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/vulnerability-profile-including-all-signatures-for-specific/m-p/44046#M32334</guid>
      <dc:creator>Mack</dc:creator>
      <dc:date>2012-02-09T15:29:55Z</dc:date>
    </item>
    <item>
      <title>Re: Vulnerability profile including all signatures for specific application</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/vulnerability-profile-including-all-signatures-for-specific/m-p/44047#M32335</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Any particular reason you wish to do this?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Because performance-wise you wont gain anything from this, perhaps lower the probability of false positive.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Cant you select a sub-category such as networking -&amp;gt; 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 09 Feb 2012 17:14:40 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/vulnerability-profile-including-all-signatures-for-specific/m-p/44047#M32335</guid>
      <dc:creator>mikand</dc:creator>
      <dc:date>2012-02-09T17:14:40Z</dc:date>
    </item>
    <item>
      <title>Re: Vulnerability profile including all signatures for specific application</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/vulnerability-profile-including-all-signatures-for-specific/m-p/44048#M32336</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;P&gt;mikand wrote:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Any particular reason you wish to do this?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;Specifically for the case where for one host we want to add an exception. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So for instance, say we have a all-hosts rule that applies default behaviour for all signatures.&amp;nbsp; Then we discover that there is a host for whom a specific signature is causing problems.&amp;nbsp; 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.&amp;nbsp; We also create a new vulnerability profile that sets an exception for the problematic signature and apply it to the specific host rule.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The issue now is the content of the vulnerability profile itself.&amp;nbsp; 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;P&gt;mikand wrote:&lt;/P&gt;&lt;BR /&gt;&lt;P&gt;Cant you select a sub-category such as networking -&amp;gt; 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;There's no application-related fields/filters in the vulnerability profile.&amp;nbsp; 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I'm hoping there is a better way to solve the problem, because right now only option a) seems sustainable.&amp;nbsp; I'm really concerned with a multiplicity of 4000-signature profiles cluttering up the config file and memory.&amp;nbsp; 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.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 09 Feb 2012 18:40:13 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/vulnerability-profile-including-all-signatures-for-specific/m-p/44048#M32336</guid>
      <dc:creator>Mack</dc:creator>
      <dc:date>2012-02-09T18:40:13Z</dc:date>
    </item>
    <item>
      <title>Re: Vulnerability profile including all signatures for specific application</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/vulnerability-profile-including-all-signatures-for-specific/m-p/44049#M32337</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;P&gt;KMacnaughton wrote:&lt;/P&gt; &lt;P&gt;The issue now is the content of the vulnerability profile itself.&amp;nbsp; 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;...&lt;BR /&gt;&lt;P&gt;I'm hoping there is a better way to solve the problem, because right now only option a) seems sustainable.&amp;nbsp; I'm really concerned with a multiplicity of 4000-signature profiles cluttering up the config file and memory.&amp;nbsp; 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.&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;So I decided to check the config file today to see how much is stored for each vuln profile.&amp;nbsp; 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.&amp;nbsp; Relative to the size of the config file itself, each vuln profile does not take much space.&amp;nbsp; So that is that issue put to rest.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;As for how much memory each vuln profile takes up, that's a mystery to us.&amp;nbsp; 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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...&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 10 Feb 2012 13:13:04 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/vulnerability-profile-including-all-signatures-for-specific/m-p/44049#M32337</guid>
      <dc:creator>Mack</dc:creator>
      <dc:date>2012-02-10T13:13:04Z</dc:date>
    </item>
  </channel>
</rss>

