The application whitelist includes not only the applications you provision and administer for business and infrastructure purposes, but also other applications that your users may need to use in order to get their jobs done, and applications you may choose to allow for personal use. Before you can begin creating your best practice internet gateway security policy, you must create an inventory of the applications you want to whitelist.
Map Applications to Business Goals for a Simplified Rulebase
As you inventory the applications on your network, consider your business goals and acceptable use policies and identify the applications that correspond to each. This will allow you to create a goal-driven rulebase. For example, one goal might be to allow all users on your network to access data center applications. Another goal might be to allow the sales and support groups access your customer database. You can then create a whitelist rule that correspond to each goal you identify and group all of the applications that align with the goal into a single rule. This approach allows you to create a rulebase with a smaller number of individual rules, each with a clear purpose.
In addition, because the individual rules you create align with your business goals, you can use application objects to group the whitelist to further simplify administration of the best practice rulebase:
Create application groups for sanctioned applications —Because you will know exactly what applications you require and sanction for official use, create application groups that explicitly include only those applications. Using application groups also simplifies the administration of your policy because it allows you to add and remove sanctioned applications without requiring you to modify individual policy rules. Generally, if the applications that map to the same goal have the same requirements for enabling access (for example, they all have a destination address that points to your data center address group, they all allow access to any known user, and you want to enable them on their default ports only) you would add them to the same application group. Create application filters to allow general types of applications —Besides the applications you officially sanctioned, you will also need to decide what additional applications you will want to allow your users to access. Application filters allow you to safely enable certain categories of applications using application filters (based on category, subcategory, technology, risk factor, or characteristic). Separate the different types of applications based on business and personal use. Create separate filters for each type of application to make it easier to understand each policy rule at a glance.
Use Temporary Rules to Tune the Whitelist
Although the end-goal of a best-practice application-based policy is to use positive enforcement to safely enable your whitelist applications, the initial rulebase requires some additional rules designed to ensure that you have full visibility into all applications in use on your network so that you can properly tune it. The initial rulebase you create will have the following types of rules:
Whitelist rules for the applications you officially sanction and deploy. Whitelist rules for safely enabling access to general types of applications you want to allow per your acceptable use policy. Blacklist rules that block applications that have no legitimate use case. You need these rules so that the temporary rules that “catch” applications that haven’t yet been accounted for in your policy don’t let anything bad onto your network. Temporary allow rules to give you visibility into all of the applications running on your network so that you can tune the rulebase.
The temporary rules are a very important part of the initial best practice rulebase. Not only will they give you visibility into applications you weren’t aware were running on your network (and prevent legitimate applications you didn’t know about from breaking), but they will also help you identify things such as unknown users and applications running on non-standard ports. Because attackers commonly use standard applications on non-standard ports as an evasion technique, allowing applications on any port opens the door for malicious content. Therefore, you must identify any legitimate applications running on non-standard ports (for example, internally developed applications) so that you can either modify what ports are used or create a custom applications to enable them.
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 here 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
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 —These are the applications that you must allow to enable networking and security, such as ping, NTP, SMTP, and DNS. IT Sanctioned Applications —These are the applications that you provision and administer for your users. These fall into two categories: IT Sanctioned On-Premise Applications —These are the 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 are those where the software and infrastructure are owned and managed by the application service provider, but where you retain full control of the data, including who can create, access, share, and transfer it (for example, Salesforce, Box, and GitHub). Administrative Applications —These are 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).
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: General Business Applications —For example, allow access to software updates, and web services, such as WebEx, Adobe online services, and Evernote. Personal Applications —For example, you may want to allow your users to browse the web or safely use web-based mail, instant messaging, or social networking applications. The recommended approach here is to begin with wide application filters so you can 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 you find that Box, Dropbox, and Office 365 file-sharing applications are all on use on your network. Each of these applications has an inherent risk associated with it, from data leakage to risks associated with transfer of malware-infected files. The best approach would be to officially sanction a single file-sharing 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 file sharing 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 file-sharing 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 them. This way you can allow the application as a sanctioned application 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.

Related Documentation