This is a pretty rudimentary example, but it does a good job of illustrating the problem. Every application other than a few known bad ones are being allowed over any port on the network. This results in a very large attack surface (there are many applications over which an attack can be delivered), and the ability to block unsanctioned applications requires a very manual response (every bad application has to be identified and added to the block rule).
The recommended action is to take the opposite approach, by only allowing applications that are sanctioned by the organization. This results in a much smaller attack surface (anything not explicitly allowed is implicitly denied), and the ability to block unsanctioned applications is automatic (whether it is known or unknown). All that said, how do we get there? The following methodology can be used in any organization, but it does require buy-off from management in order to determine what applications should be sanctioned vs. unsanctioned.
As shown above, all sanctioned applications are manually defined and added to the first rule. All unsanctioned applications are manually defined and added to the second rule. Finally, all other traffic hits the third rule. The third rule is reserved for applications that are either traversing non-standard ports or have not yet been added to the sanctioned or unsanctioned rules. A custom report referencing the rule can be created and ran to gather all applications identified via the tolerated rule over a certain period of time (i.e. 30 days).
Over time, all applications will be identified and can be added to either the Sanctioned or Unsanctioned rules. There may be some instances where administrators will have to create secondary sanctioned rules for applications that are sanctioned, but are traversing non-standard ports (i.e. a web server that is accessed over TCP port 8080). Once you are satisfied, Unsanctioned and Tolerated rules can be deleted, as anything that is not explicitly allowed in the Sanctioned rule will be implicitly denied in the default deny rule.
This is a great way to migrate from a legacy blacklist, layer 4-based policy approach, to a positive control model that reduces attack surface and leverages the platform the way it was intended.
My next post details how to leverage the new Policy Optimizer feature (available in PAN-OS 9.0) that makes migrating to App-ID and a positive control model even easier.
