Define the Initial Internet Gateway Security Policy
The overall goal of a best practice internet gateway security policy is to use positive enforcement of whitelist applications. However, it takes some time to identify exactly what applications are running on your network, which of these applications are critical to your business, and who the users are that need access to each one. The best way to accomplish the end goal of a policy rulebase that includes only application allow rules is to create an initial policy rulebase that liberally allows both the applications you officially provision for your users as well as other general business and, if appropriate, personal applications. This initial policy also includes additional rules that explicitly block bad applications as well as some temporary allow rules that are designed to help you refine your policy and prevent applications your users may need from breaking while you transition to the best practices.
The following topics describe how to create the initial rulebase and describe why each rule is necessary and what the risks are of not following the best practice recommendation:
Step 1: Create the Application Whitelist Rules
After you Identify Whitelist Applications you are ready to create the first part of the best practice internet gateway security policy rulebase: the application whitelist rules. Every whitelist rule you create must allow traffic based on application (not port) and, with the exception of certain infrastructure applications that require user access before the firewall can identify the user, must only allow access to known users. Whenever possible, Create User Groups for Access to Whitelist Applications so that you can limit user access to the specific users or user groups who have a business need to access the application.
When creating the application whitelist rules, make sure to place more specific rules above more general rules. For example, the rules for all of your sanctioned and infrastructure applications would come before the rules that allow general access to certain types of business and personal applications. This first part of the rulebase includes the allow rules for the applications you identified as part of your application whitelist:
Sanctioned applications you provision and administer for business and infrastructure purposes General business applications that your users may need to use in order to get their jobs done General applications you may choose to allow for personal use
Every application whitelist rule also requires that you attach the best practice security profiles to ensure that you are scanning all allowed traffic for known and unknown threats. If you have not yet created these profiles, see Create Best Practice Security Profiles. And, because you can’t inspect what you can’t see, you must also make sure you have configured the firewall to Decrypt Traffic for Full Visibility and Threat Inspection.
Create the Application Whitelist Rules
Allow access to your corporate DNS servers.
Why do I need this rule? Access to DNS is required to provide network infrastructure services, but it is commonly exploited by attackers. Allowing access only on your internal DNS server reduces your attack surface. Rule Highlights Because this rule is very specific, place it at the top of the rulebase. Create an address object to use for the destination address to ensure that users only access the DNS server in your data center. Because users will need access to these services before they are logged in, you must allow access to any user.
Allow access to other required IT infrastructure resources.
Why do I need this rule? Enable the applications that provide your network infrastructure and management functions, such as NTP, OCSP, STUN, and ping. While DNS traffic allowed in the preceding rule is restricted to the destination address in the data center, these applications may not reside in your data center and therefore require a separate rule. Rule Highlights Because these applications run on the default port, allow access to any user (users may not yet be a known-user because of when these services are needed), and all have a destination address of any, contain them in a single application group and create a single rule to enable access to all of them. Users may not have logged in yet at the time they need access to the infrastructure applications, so make sure this rule allows access to any user.
Allow access to IT sanctioned SaaS applications.
Why do I need this rule? With SaaS applications, your proprietary data is in the cloud. This rule ensures that only your known users have access to these applications (and the underlying data). Scan allowed SaaS traffic for threats. Rule Highlights Group all sanctioned SaaS applications in an application group. SaaS applications should always run on the application default port. Restrict access to your known users. See Create User Groups for Access to Whitelist Applications.
Allow access to IT provisioned on-premise applications.
Why do I need this rule? Business-critical data center applications are often leveraged in attacks during the exfiltration stage, using applications such as FTP, or in the lateral movement stage by exploiting application vulnerabilities. Many data center applications use multiple ports; setting the Service to application-default safely enables the applications on their standard ports. You should not allow applications on non-standard ports because it is often associated with evasive behavior. Rule Highlights Group all data center applications in an application group. Create an address group for your data center server addresses. Restrict access to your known users. See Create User Groups for Access to Whitelist Applications.
Allow access to applications your administrative users need.
Why do I need this rule? To reduce your attack surface, Create User Groups for Access to Whitelist Applications. Because administrators often need access to sensitive account data and remote access to other systems (for example RDP), you can greatly reduce your attack surface by only allowing access to the administrators who have a business need. Rule Highlights This rule restricts access to users in the IT_admins group. Create custom applications for internal applications or applications that run on non-standard ports so that you can enforce them on their default ports rather than opening additional ports on your network. If you have different user groups for different applications, create separate rules for granular control.
Allow access to general business applications.
Why do I need this rule? Beyond the applications you sanction for use and administer for your users, there are a variety of applications that users may commonly use for business purposes, for example to interact with partners, such as WebEx, Adobe online services, or Evernote, but which you may not officially sanction. Because malware often sneaks in with legitimate web-based applications, this rule allows you to safely allow web browsing while still scanning for threats. See Create Best Practice Security Profiles. Rule Highlights Restrict access to your known users. See Create User Groups for Access to Whitelist Applications. For visibility, create separate application filters for each type of application you want to allow. Attach the best practice security profiles to ensure that all traffic is free of known and unknown threats. See Create Best Practice Security Profiles.
(Optional) Allow access to personal applications.
Why do I need this rule? As the lines blur between work and personal devices, you want to ensure that all applications your users access are safely enabled and free of threats. By using application filters, you can safely enable access to personal applications when you create this initial rulebase. After you assess what applications are in use, you can use the information to decide whether to remove the filter and allow a smaller subset of personal applications appropriate for your acceptable use policies. Rule Highlights Restrict access to your known users. See Create User Groups for Access to Whitelist Applications. For visibility, create separate application filters for each type of application you want to allow. Scan all traffic for threats by attaching your best practice security profile group. See Create Best Practice Security Profiles.
Allow general web browsing.
Why do I need this rule? While the previous rule allowed access to personal applications (many of them browser-based), this rule allows general web browsing. General web browsing is more risk-prone than other types of application traffic. You must Create Best Practice Security Profiles and attach them to this rule in order to safely enable web browsing. Because threats often hide in encrypted traffic, you must Decrypt Traffic for Full Visibility and Threat Inspection if you want to safely enable web browsing. Rule Highlights This rule uses the same best practice security profiles as the rest of the rules, except for the File Blocking profile, which is more stringent because general web browsing traffic is more vulnerable to threats. This rule allows only known users to prevent devices with malware or embedded devices from reaching the internet. Use application filters to allow access to general types of applications. Make sure you also explicitly allow SSL as an application here if you want to allow users to be able to browse to HTTPS sites. that are excluded from decryption.
Step 2: Create the Application Block Rules
Although the overall goal of your security policy is to safely enable applications using application whitelist rules (also known as positive enforcement ), the initial best practice rulebase must also include rules to help you find gaps in your policy and identify possible attacks. Because these rules are designed to catch things you didn’t know were running on your network, they allow traffic that could also pose security risks on your network. Therefore, before you can create the temporary rules, you must create rules that explicitly blacklist applications designed to evade or bypass security or that are commonly exploited by attackers, such as public DNS and SMTP, encrypted tunnels, remote access, and non-sanctioned file-sharing applications.
Each of the tuning rules you will define in Step 3: Create the Temporary Tuning Rules are designed to identify a specific gap in your initial policy. Therefore some of these rules will need to go above the application block rules and some will need to go after.
Create the Application Block Rules
Block applications that do not have a legitimate use case.
Why do I need this rule? Block nefarious applications such as encrypted tunnels and peer-to-peer file sharing, as well as web-based file sharing applications that are not IT sanctioned. Because the tuning rules that follow are designed to allow traffic with malicious intent or legitimate traffic that is not matching your policy rules as expected, these rules could also allow risky or malicious traffic into your network. This rule prevents that by blocking traffic that has no legitimate use case and that could be used by an attacker or a negligent user. Rule Highlights Use the Drop Action to silently drop the traffic without sending a signal to the client or the server. Enable logging for traffic matching this rule so that you can investigate misuse of applications and potential threats on your network. Because this rule is intended to catch malicious traffic, it matches to traffic from any user running on any port.
Block public DNS and SMTP applications.
Why do I need this rule? Block public DNS/SMTP applications to avoid DNS tunneling, command and control traffic, and remote administration. Rule Highlights Use the Reset both client and server Action to send a TCP reset message to both the client-side and server-side devices. Enable logging for traffic matching this rule so that you can investigate a potential threat on your network.
Step 3: Create the Temporary Tuning Rules
The temporary tuning rules are explicitly designed to help you monitor the initial best practice rulebase for gaps and alert you to alarming behavior. For example, you will create temporary rules to identify traffic that is coming from unknown user or applications running on unexpected ports. By monitoring the traffic matching on the temporary rules you can also gain a full understanding of all of the applications in use on your network (and prevent applications from breaking while you transition to a best practice rulebase). You can use this information to help you fine tune your whitelist, either by adding new whitelist rules to allow applications you weren’t aware were needed or to narrow your whitelist rules to remove application filters and instead allow only specific applications in a particular category. When traffic is no longer hitting these rules you can Remove the Temporary Rules.
Some of the temporary tuning rules must go above the rules to block bad applications and some must go after to ensure that targeted traffic hits the appropriate rule, while still ensuring that bad traffic is not allowed onto your network.
Create Temporary Tuning Rules
Allow web-browsing and SSL on non-standard ports for known users to determine if there are any legitimate applications running on non-standard ports.
Why do I need this rule? This rule helps you determine if you have any gaps in your policy where users are unable to access legitimate applications because they are running on non-standard ports. You must monitor all traffic that matches this rule. For any traffic that is legitimate, you should tune the appropriate allow rule to include the application, perhaps creating a custom application where appropriate. Rule Highlights Unlike the whitelist rules that allow applications on the default port only, this rule allows web-browsing and SSL traffic on any port so that you can find gaps in your whitelist. Because this rule is intended to find gaps in policy, limit it to known users on your network. See Create User Groups for Access to Whitelist Applications. Make sure you also explicitly allow SSL as an application here if you want to allow users to be able to browse to HTTPS sites that aren’t decrypted (such as financial services and healthcare sites). You must add this rule above the application block rules or no traffic will hit this rule.
Allow web-browsing and SSL traffic on non-standard ports from unknown users to highlight all unknown users regardless of port.
Why do I need this rule? This rule helps you determine whether you have gaps in your User-ID coverage. This rule also helps you identify compromised or embedded devices that are trying to reach the internet. It is important to block non-standard port usage, even for web-browsing traffic, because it is usually an evasion technique. Rule Highlights While the majority of the application whitelist rules apply to known users or specific user groups, this rule explicitly matches traffic from unknown users. Note that this rule must go above the application block rules or traffic will never hit it. Because it is an allow rule, you must attach the best practice security profiles to scan for threats.
Allow all applications on the application-default port to identify unexpected applications.
Why do I need this rule? This rule provides visibility into applications that you weren’t aware were running on your network so that you can fine-tune your application whitelist. Monitor all traffic matching this rule to determine whether it represents a potential threat, or whether you need to modify your whitelist rules to allow the traffic. Rule Highlights Because this rule allows all applications, you must add it after the application block rules to prevent bad applications from running on your network. If you are running PAN-OS 7.0.x or earlier, to appropriately identify unexpected applications, you must use an application filter that includes all applications, instead of setting the rule to allow any application.
Allow any application on any port to identify applications running where they shouldn’t be.
Why do I need this rule? This rule helps you identify legitimate, known applications running on unknown ports. This rule also helps you identify unknown applications for which you need to create a custom application to add to your application whitelist. Any traffic matching this rule is actionable and requires that you track down the source of the traffic and ensure that you are not allowing any unknown tcp, udp or non-syn-tcp traffic. Rule Highlights Because this is a very general rule that allows any application from any user on any port, it must come at the end of your rulebase. Enable logging for traffic matching this rule so that you can investigate for misuse of applications and potential threats on your network or identify legitimate applications that require a custom application.
Step 4: Enable Logging for Traffic that Doesn’t Match Any Rules
Traffic that does not match any of the rules you defined will match the predefined interzone-default rule at the bottom of the rulebase and be denied. For visibility into the traffic that is not matching any of the rules you created, enable logging on the interzone-default rule:
Enable Logging for Traffic That Doesn’t Match Any Rules
Select the interzone-default row in the rulebase and click Override to enable editing on this rule.
Select the interzone-default rule name to open the rule for editing.
On the Actions tab, select Log at Session End and click OK.
Create a custom report to monitor traffic that hits this rule. Select Monitor > Manage Custom Reports. Add a report and give it a descriptive Name. Set the Database to Traffic Summary. Select the Scheduled check box. Add the following to the Selected Columns list: Rule, Application, Bytes, Sessions. Set the desired Time Frame, Sort By and Group By fields. Define the query to match traffic hitting the interzone-default rule: (rule eq 'interzone-default')
Commit the changes you made to the rulebase.

Related Documentation