Getting more restrictive in rule application and use of application policies - best approach?

[TonyDeHart]

We recently used Expedition to migrate our ASA and some rules from an older PA-3020 over to a PA-5220. It was rather involved (to me) and I had taken this project over after someone had started it.

Since our ASA did not have any concept of Applications many of the rules from our ASA were brought over as-is with specific port definitions in the rule base and no application policies applied. The best we could do was apply our default security profiles because they had already been applied mostly by having had vwires with much of the traffic passing through our PA-3020 to the ASA previously.

Now that we've successfully migrated I want to begin the steps of moving away from broader or less defined rules and in particular ones that are port based only (or worse set to ANY port).  What are the approaches people take to make this transition while avoiding accidentally shutting down a service or required traffic?

My first thought was to CLONE the rule in use and place it above the cloned source rule and place application default restrictions and/or specific applications on the NEW rule and see which rule, the NEW or OLD, is actuall yused.   We can then gradually tweak the NEW rule or make inquiries to fine tune the rule until we eventually disable the original rule below it.

Does this seem like a prudent approach?  Are there better methods or tools to use for this process?

Thanks.

[OtakarKlier]

Hello,

You have it planned the way I would do it. Place the new policy with the application above the one with the 'service' and monitor it. When using the application, I try to use the 'Application Default' service. This works most of the time, just have to watch out for application identification that uses non-standard ports.

Cheers!

[TomYoung · Accepted solution]

Hi @TonyDeHart ,

Does this seem like a prudent approach?  Yes, it is the best strategy.

Are there better methods or tools to use for this process?  Yes, the Policy Optimizer makes this a LOT easier for you.  https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PMThCAO

Click on the Apps Seen number for a rule.  Select the sanctioned apps.  (Not all apps seen are sanctioned!)  Click on Create Cloned Rule to create a cloned rule above your existing rule.  You can periodically check your L3/L4 rule and add more apps with the Add to Existing Rule button.

Thanks,

Tom

PS Check out the YouTube video on the bottom of the link!  You can skip forward to 10:35.

[TonyDeHart]

Thank you! I really appreciate the input on this!

[TonyDeHart]

Maybe I just don't know where to look but is there a way to tell if traffic hits a rule and doesn't fall into the application-default category for an application?  As an example, SSL traffic on a non-standard port - is there a way to filter on something like that? While SSL is easy, other more obscure apps could be more difficult. Is there a way to determine if the traffic matched the application-default ports?

[TomYoung]

Hi @TonyDeHart ,

The Policy Optimizer identifies traffic on non-standard ports.  Notice the "warning" icon.

However, if there is a mix of standard and non-standard, it does not show.  That is one of the reasons you create a L7 application-default cloned rule above your L4 rule and add the applications to it.  Then, the non-standard applications will hit the L4 rule and you should have the warning symbol in the Policy Optimizer.  You should clear the apps seen in the L4 rule after you add apps to the L7 rule.  https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/app-id/security-policy-rule-optimization/p...

You could also use the Log Viewer for a rule (drop down next to name) and view traffic that matches the rule.  You can select the application and destination port and change the port.dst to neq.

Thanks,

Tom

[TonyDeHart]

Thanks. The warning icon or some indication as to use of non-standard ports is what I was looking for. It is unfortunate that doesn't show when there is a mix as it certainly makes it much less useful w/o the second rule.  Your suggestion on negating standard ports is what I was doing in the logs I was just hoping there would be a warning indicator or some field you could filter on in the logs too for non-standard port use.

[TonyDeHart]

Along with these application rules and use of policy optimizer to sort out traffic, what strategies are people using to get the what the essential applications are for inbound traffic?  I've got a few rules that are port based and should be fairly specific as to the applications used, yet there are 60+ applications listed as seen on the rule.  This doesn't seem likely and in a few instances even looking at the rule doesn't show what I'd expect for an application.

For example, we have an inbound rule to a netscaler for Vmware Horizon traffic and yet I see things like ms-ds-smb-base, mssql-db-base and ssh which isn't likely valid traffic but I see no Blast or Vmware-view application listed when Blast is the only protocol we use and it appears there is an application designation for Blast.

It would seem the inbound rules are the most important to tackle first but the types of services being used requires me to be careful not to break anything mission critical.

For what it is worth, there are Warning Signs (the red triangle) next to many applications that are listed which would seem to be a good indication these aren't valid traffic. 

(This may warrant another topic and if so I'll create one.)