End-of-Life (EoL)
Application Whitelist 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 whitelist 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 whitelist.
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
the 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. |
Recommended For You
Recommended Videos
Recommended videos not found.
