Application Allow List Example
Table of Contents
Expand all | Collapse all
-
- What Is a Best Practice Internet Gateway Security Policy?
- Why Do I Need a Best Practice Internet Gateway Security Policy?
- How Do I Deploy a Best Practice Internet Gateway Security Policy?
- Create User Groups for Access to Allowed Applications
- Decrypt Traffic for Full Visibility and Threat Inspection
-
- Transition Vulnerability Protection Profiles Safely to Best Practices
- Transition Anti-Spyware Profiles Safely to Best Practices
- Transition Antivirus Profiles Safely to Best Practices
- Transition WildFire Profiles Safely to Best Practices
- Transition URL Filtering Profiles Safely to Best Practices
- Transition File Blocking Profiles Safely to Best Practices
- Create Best Practice Security Profiles for the Internet Gateway
- Monitor and Fine-Tune the Policy Rulebase
- Remove the Temporary Rules
- Maintain the Rulebase
Application Allow List Example
You don't need to capture every application that might be in use on your network in your initial
inventory. Instead, focus on the applications that you want to allow. Temporary rules
catch other applications that might be on your network, so you're not inundated with
complaints about broken applications during a transition to application-based policy.
The following table shows 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. To control SaaS applications, use SaaS Security
(subscription required). If you use SaaS Security, use SaaS Policy Recommendation
to control SaaS applications on the firewall. If you don't have a SaaS Security subscription, generate a SaaS application 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:
Many SaaS applications have enterprise and consumer (personal)
versions, but unrestricted use increases the risk of sensitive data
leaving your network. HTTP Header Insertion
enables you to control which versions of SaaS applications you allow
on your network. For example, you can allow the enterprise version
of Box or Office 365 and block consumer versions. HTTP header
insertion reduces the attack surface by allowing only the version of
each SaaS application that you want to sanction or tolerate for the
personal use of your users. |
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. |
Tolerated Types of Applications | In addition to applications you officially sanction, you also need to allow users to safely
access other types of tolerated applications:
Begin with broad application filters to understand which applications are on your network. Decide
how much risk you are willing to assume and pare down the
application allow list. For example, you might have multiple
messaging applications in use, each with the inherent risk of data
loss, transfer of malware-infected files, etc.
The best approach is to sanction a single messaging application and
then slowly transition from an allow policy to an alert policy, and
after giving users ample warning, to a block policy to phase out the
other messaging applications. You might also choose to enable a
small group of users to continue using additional messaging
applications as needed to perform job functions with partners. |
Custom Applications Specific to Your Environment | Create custom applications
for proprietary applications or applications that you run on
non-standard ports. This enables you to allow the application as a
sanctioned application (and apply the predefined Sanctioned tag) and
lock it down to its default port. Otherwise, you 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 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. Then migrate each rule to an application-based rule.
Application override policies are port-based and don't provide
application visibility into traffic, so you don't know or control
which applications use the ports. Service-based session timeouts
achieve custom timeouts while maintaining application
visibility. |