: Application Allow List Example
Focus
Focus

Application Allow List Example

Table of Contents

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:
  • Block existing applications with unfavorable hosting characteristics immediately.
  • Create granular policies that block applications with unfavorable hosting characteristics to prevent future violations.
  • Identify network traffic trends of the top applications that have unfavorable hosting characteristics so you can adjust policy accordingly.
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:
  • Infrastructure Applications—Applications that you must allow to enable networking and security, such as ping, NTP, SMTP, and DNS.
  • IT Sanctioned Applications—Applications that you provision and administer for your users. These fall into two categories:
    • IT Sanctioned On-Premises Applications—Applications you install and host in your data center for business use. With IT sanctioned on-premise applications, the application infrastructure and the data reside on enterprise-owned equipment. Examples include Microsoft Exchange and active sync, as well as authentication tools such as Kerberos and LDAP.
    • IT Sanctioned SaaS Applications—SaaS applications that your IT department sanctions for business purposes, for example, Salesforce, Box, and GitHub.
  • Administrative Applications—Applications that only a specific group of administrative users should have access to in order to administer applications and support users (for example, remote desktop applications).
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:
  • General Business Applications—For example, allow access to software updates for tolerated applications and to web services such as WebEx, Adobe online services, and Evernote.
  • Personal Applications—For example, you might allow users to browse the web or safely use web-based mail, instant messaging, or social networking applications, including consumer versions of some SaaS 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.