Application Allow List Example
Keep in mind that you do not need to capture every application
that might be in use on your network in your initial inventory.
Instead you should focus on the applications (and general types
of applications) that you want to allow. Temporary rules in the
best practice rulebase will catch any additional applications that
may be in use on your network so that you are not inundated with
complaints of broken applications during your transition to application-based
policy. The following is an example application allow list for an
enterprise gateway deployment.
Application Type | Best Practice for
Securing |
|---|---|
SaaS Applications | SaaS application service providers own and
manage the software and infrastructure, but you retain full control
of the data, including who can create, access, share, and transfer
it. Generate a SaaS applications usage report to
check if SaaS applications currently in use have unfavorable hosting characteristics
such as past data breaches or lack of proper certifications. Based
on business needs and the amount of risk you’re willing to accept, use
the information to:
|
Sanctioned Applications | These are the applications that your IT
department administers specifically for business use within your
organization or to provide infrastructure for your network and applications.
For example, in an internet gateway deployment these applications
fall into the following categories:
Tag all sanctioned applications with the
predefined Sanctioned tag. Panorama and firewalls consider
applications without the Sanctioned tag as unsanctioned applications. |
General Types of Applications | Besides the applications you officially
sanction and deploy, you will also want to allow your users to safely
use other types of applications:
Begin with wide application
filters to gain an understanding of what applications are in use
on your network. You can then decide how much risk you are willing
to assume and begin to pare down the application allow list. For
example, suppose multiple messaging applications are in use, each
with the inherent risk of data leakage, transfer of malware-infected files,
etc. The best approach is to officially sanction a single messaging application
and then begin to phase out the others by slowly transitioning from
an allow policy to an alert policy, and finally, after giving users
ample warning, a block policy for all messaging applications except
the one you choose to sanction. In this case, you might also choose
to enable a small group of users to continue using an additional
messaging application as needed to perform job functions with partners. |
Custom Applications Specific to Your Environment | If you have proprietary applications on
your network or applications that you run on non-standard ports,
it is a best practice to create custom applications for each of
them. This way you can allow the application as a sanctioned application
(and apply the predefined Sanctioned tag) and lock it down to its
default port. Otherwise you would either have to open up additional
ports (for applications running on non-standard ports), or allow
unknown traffic (for proprietary applications), neither of which
are recommended in a best practice Security policy. If you
have existing Application Override policies that you created solely
to define custom session timeouts for a set a of ports, convert
the existing Application Override policies to application-based
policies by configuring service-based session timeouts to maintain
the custom timeout for each application and then migrating the rule
to an application-based rule. Application Override policies are
port-based. When you use Application Override policies to maintain
custom session timeouts for a set of ports, you lose application
visibility into those flows, so you neither know nor control which
applications use the ports. Service-based session timeouts achieve
custom timeouts while also maintaining application visibility. |
Most Popular
Recommended For You
Recommended Videos
Recommended videos not found.
