<?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: Feature Request - Security Profile policy in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/feature-request-security-profile-policy/m-p/157382#M51621</link>
    <description>&lt;P&gt;It is easy to do in CLI.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;gt; set cli config-output-format set&lt;/P&gt;&lt;P&gt;&amp;gt; configure&lt;/P&gt;&lt;P&gt;# show rulebase security | match "profile-setting group"&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Copy output to Notepad.&lt;/P&gt;&lt;P&gt;Find and replace all old security profile names with new one.&lt;/P&gt;&lt;P&gt;And paste those commands back into CLI window.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;# commit&lt;/P&gt;</description>
    <pubDate>Fri, 19 May 2017 11:16:59 GMT</pubDate>
    <dc:creator>Raido_Rattameister</dc:creator>
    <dc:date>2017-05-19T11:16:59Z</dc:date>
    <item>
      <title>Feature Request - Security Profile policy</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/feature-request-security-profile-policy/m-p/157336#M51614</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;One thing about configuring security profiles is that when I like to change a security profile, there are so many security rules to update with the correct profile. I know I can change the profile itself and all policies using that profile will be affected but that is not always what I want. In my view it would be much better to place security profiles in their own policies - like decryption, authentication etc. Then we can add the the profile to exactly the type of traffic we want without needing to bother with what security rule that traffic hits. What do you think?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 19 May 2017 09:04:08 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/feature-request-security-profile-policy/m-p/157336#M51614</guid>
      <dc:creator>mgusta</dc:creator>
      <dc:date>2017-05-19T09:04:08Z</dc:date>
    </item>
    <item>
      <title>Re: Feature Request - Security Profile policy</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/feature-request-security-profile-policy/m-p/157382#M51621</link>
      <description>&lt;P&gt;It is easy to do in CLI.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;gt; set cli config-output-format set&lt;/P&gt;&lt;P&gt;&amp;gt; configure&lt;/P&gt;&lt;P&gt;# show rulebase security | match "profile-setting group"&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Copy output to Notepad.&lt;/P&gt;&lt;P&gt;Find and replace all old security profile names with new one.&lt;/P&gt;&lt;P&gt;And paste those commands back into CLI window.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;# commit&lt;/P&gt;</description>
      <pubDate>Fri, 19 May 2017 11:16:59 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/feature-request-security-profile-policy/m-p/157382#M51621</guid>
      <dc:creator>Raido_Rattameister</dc:creator>
      <dc:date>2017-05-19T11:16:59Z</dc:date>
    </item>
    <item>
      <title>Re: Feature Request - Security Profile policy</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/feature-request-security-profile-policy/m-p/157386#M51623</link>
      <description>&lt;P&gt;Ok, thanks for the tip. That does have it´s use cases. My most recent scenario was when I wanted to try out the credential url filtering. With my suggestion all I would have had to do was add a sec. profile policy with the test user as source and apply to traffic from trust to untrust. Instead I had to create a clone of the current url filtering profile, add that to multiple (cloned, and added test user as source) security policies for traffic from trust to untrust.&lt;/P&gt;</description>
      <pubDate>Fri, 19 May 2017 11:49:31 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/feature-request-security-profile-policy/m-p/157386#M51623</guid>
      <dc:creator>mgusta</dc:creator>
      <dc:date>2017-05-19T11:49:31Z</dc:date>
    </item>
    <item>
      <title>Re: Feature Request - Security Profile policy</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/feature-request-security-profile-policy/m-p/157562#M51664</link>
      <description>Hi &lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/12792"&gt;@mgusta&lt;/a&gt;&lt;BR /&gt;&lt;BR /&gt;I understand your point and there are definately some situations where your request could be useful. But personally I think you would also loose some granularity/visibility. For me it is better to choose per security policy rule what inspection should be applied. In addition I normally work work with security Profile groups. If I then need to test/change somethin for a specific user/group I simply clone the existing rule and add the new security profiles.&lt;BR /&gt;This also gives you the flexibility to apply different log forwarding profiles to specific rules. Ok this can now in PAN-OS 8 also be done with log gorwarding profile match lists but if you have a lot of specific cases for log forwarding (critical threat alerts--&amp;gt;snmp, traffic to sinkhole zone--&amp;gt;email,wildfiresubmissions to incident management--&amp;gt;http, ...) this will also add some complexity to the forwarding which is in some cases easier to handle with security policies with specific security profiles.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;Remo</description>
      <pubDate>Sat, 20 May 2017 09:58:00 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/feature-request-security-profile-policy/m-p/157562#M51664</guid>
      <dc:creator>Remo</dc:creator>
      <dc:date>2017-05-20T09:58:00Z</dc:date>
    </item>
  </channel>
</rss>

