Understanding and preparing security profiles

Before you can start building a solid security rule base, you need to create at least one set of security profiles to use in all of your security rules.

Important note

Security profiles are evaluated by the first security rule that a session is matched against. If a six-tuple is matched against a security rule with no or limited security profiles, no scanning can take place until there is an application shift and the security policy is re-evaluated. It is important for all security rules to have security profiles.

The Antivirus profile

The Antivirus profile has three sections that depend on different licenses and dynamic update settings. The actions under ACTION rely on the threat prevention license and antivirus updates, WILDFIRE ACTION relies on the WildFire license and the WildFire updates that are set to periodical updates (1 minute or longer intervals), and DYNAMIC CLASSIFICATION ACTION relies on WildFire set to real time. If any of these licenses are missing from your system, the actions listed in their columns will not be applied. Application Exception allows you to change the action associated with a decoder for individual applications as needed. The actions that can be set for both threat prevention and WildFire antivirus actions are as follows:

• allow: Allows matching signatures without logging
• drop: Drops matching signatures and writes an entry in the threat log
• alert: Allows matching signatures to pass but writes an entry in the threat log
• reset-client: Drops matching packets, sends a TCP RST to the client, and writes an entry in the threat log
• reset-server: Drops matching packets, sends a TCP RST to the server, and writes an entry in the threat log
• reset-both: Drops matching packets, sends a TCP RST to the client and server, and writes an entry in the threat log

Packet captures can be enabled for further analysis by the security team or as forensic evidence. They are attached to the threat log and are limited to packets containing matched signatures.

Create a new Antivirus profile by going to Objects | Security Profiles | Antivirus.

As the following screenshot shows, we will use all the default settings:

Figure 3.1 – Antivirus Profile

We will now have a look at the Anti-Spyware profile.

The Anti-Spyware profile

The Anti-Spyware profile is extremely customizable and is built by a set of rules within the profile. These rules serve to change the default actions associated with each threat; so, if no rules are created at all, the profile will simply apply the default action for a specific signature when it is detected.

Anti-Spyware supports the same actions as Antivirus (allow, drop, alert, reset-client, reset-server, and reset-both), as well as block-ip:

• block-ip can track by source or source-destination pair and will block the offending IP for a duration of 1-3600 seconds. Tracking by source will block all connections from the client for the duration of the block, while tracking by source-destination will only block connections from the client to the target destination and will not block the same client from connecting to other destinations.

The Packet capture options include none, single-packet, and extended-capture. While single-packet only captures the packet containing the payload matching a signature, extended-capture enables the capture of multiple packets to help analyze a threat. The number of packets captured by extended-capture can be configured via Device | Setup | Content-ID. The default is 5.

Important note

Enabling packet capture on all threats does require some CPU cycles. The impact will not be very large, but if the system is already very taxed, some caution is advised.

Severity indicates the severity level of the threat that applies to this rule.

Create a new Anti-Spyware profile, as in the following screenshot, and add the following rules:

• POLICY NAME: simple-critical

  --SEVERITY: critical

  --ACTION: block-ip (source, 120)

  --PACKET CAPTURE: single-packet

• POLICY NAME: simple-high

  --SEVERITY: high

  --ACTION: reset-both

  --PACKET CAPTURE: single-packet

• POLICY NAME: simple-medium

  --SEVERITY: medium

  --ACTION: reset-both

  --PACKET CAPTURE: single-packet

• POLICY NAME: simple-low-info

  --SEVERITY: low, informational

  --ACTION: default

  --PACKET CAPTURE: disable

Your profile will now look like this:

Figure 3.2 – Anti-Spyware Profile

As you can see in the following screenshot, we need to make sure we review Category as this allows a fine-grained approach to each specific type of threat if granularity and individualized actions are needed at a later stage:

Figure 3.3 – Anti-Spyware categories

The Anti-Spyware profile also contains DNS signatures, which are split into two databases for the subscription services.

The content DNS signatures are downloaded with the threat prevention dynamic updates. The DNS Security database uses dynamic cloud lookups.

The elements in each database can be set to Alert, Allow, Block, or Sinkhole. Sinkhole uses a DNS poisoning technique that replaces the IP in the DNS reply packet, so the client does get a valid DNS reply, but with an altered destination IP. This ensures that infected endpoints can easily be found by filtering traffic logs for sessions going to the sinkhole IP. You can keep using the Palo Alto Networks default sinkhole, sinkhole.paloaltonetworks.com, or use your preferred IP.

The way that the DNS sinkhole works is illustrated by the following steps and diagram:

1. The client sends a DNS query to resolve a malicious domain to the internal DNS server.
2. The internal DNS relays the DNS lookup to an internet DNS server.
3. The firewall forges a poisoned reply to the DNS query and replies to the internal DNS server with a record pointing to the sinkhole IP.
4. The DNS reply is forwarded to the client.
5. The client makes an outbound connection to the sinkhole IP, instead of the malicious server. The admin immediately knows which host is potentially infected and is trying to set up Command and Control (C2) connections:

Figure 3.4 – How a DNS sinkhole works

Blocking instead of sinkholing these DNS queries would implicate the internal DNS server as requests are relayed through it. Make sure you set the DNS Security action to sinkhole if you have the subscription license.

The default action for the Command and Control and Malware domains is to block and change them to sinkholes, as shown. For research purposes, you can enable packet capture:

Figure 3.5 – Anti-Spyware DNS signatures

Let's now look at the Vulnerability Protection profile.

The Vulnerability Protection profile

The Vulnerability Protection profile also uses rules to control how certain network-based attacks are handled. ACTION contains the same options as Anti-Spyware: allow, drop, alert, reset-client, reset-server, reset-both, and block-ip. The reset actions send TCP RST packets. block-ip blocks all packets coming from a source and can be set to monitor source to block everything, or a source destination, to only block packets to a specific destination for an amount of time.

Host Type helps determine whether the rule applies to a threat originating from a client (upload), server (download), or either.

Make sure you review Category, as in the following screenshot, as this allows a fine-grained approach to each specific type of threat if granularity and individualized actions are needed at a later stage:

Figure 3.6 – The Vulnerability Protection profile categories

Create the following rules:

• Rule Name: simple-client-critical

  --Host Type: client

  --Severity: critical

  --Action: block-ip (source, 120)

  --Packet Capture: single-packet

• Rule Name: simple-client-high

  --Host Type: client

  --Severity: high

  --Action: reset-both

  --Packet Capture: single-packet

• Rule Name: simple-client-medium

  --Host Type: client

  --Severity: medium

  --Action: reset-both

  --Packet Capture: single-packet

• Rule Name: simple-server-critical

  --Host Type: server

  --Severity: critical

  --Action: block-ip (source, 120)

  --Packet Capture: single-packet

• Rule Name: simple-server-high

  --Host Type: server

  --Severity: high

  --Action: reset-both

  --Packet Capture: single-packet

• Rule Name: simple-server-medium

  --Host Type: server

  --Severity: medium

  --Action: reset-both

  --Packet Capture: single-packet

• Rule Name: simple-low-info

  --Host Type: any

  --Severity: low, informational

  --Action: default

  --Packet Capture: disable

Your profile should now look like this:

Figure: 3.7 – Vulnerability Protection Profile

In the next subsection, we will learn about URL filtering and its categories.

URL filtering

URL filtering leverages URL categories to determine what action to take for each category.

There are two groups of categories: custom URL categories and the dynamic categories provided by the URL filtering license.

Custom URL categories

Custom URL categories do not require a license, so you can create these objects and apply URL filtering even without access to the URL filtering license.

Go to Objects | Custom Objects | URL Category to create a new custom category and add websites. It takes a light form of Regular Expression (RegEx) matched against the address, so neither http:// nor https:// are required to match.

The string used in a custom URL category is divided up into substrings, or tokens, by separators. The ./?&=;+ characters are considered separators, so www.example.com has three tokens and two separators. Each token can be replaced by a wildcard (*) to match subdomains or entire Top-Level Domains (TLDs). Wildcards cannot be used as part of a token; for example, www.ex*.com is an illegal wildcard. Each string can be closed by a forward slash (/) or be left open by not adding an end slash. Not ending a string could have consequences if the string is very short or very common as it could match unintended longer addresses. For example, the *.com string could match www.communicationexample.org, so adding an ending slash would prevent this.

URL filtering profile

When configuring the URL filtering profile, you need to select which action to apply.

Some possible actions are as follows:

• Allow: Allows a category without logging.
• Alert: Allows a category and logs the access in the URL filtering log.
• Block: Blocks the request, injecting an HTTP 503 error and a redirect to a page hosted on the firewall explaining to the user their access was declined and the action logged.
• Continue: Injects an interactive web page informing the user that they are about to access a restricted website and provides a Continue button for them to acknowledge the risk associated with accessing the site.
• Override: Injects an interactive web page that allows the user to continue if they are able to provide a password to continue. This password can be set in Device | Setup | Content-ID | URL Admin Override. An Interface Management profile (Network | Network Profiles | Interface Mgmt) needs to be created, with the Response pages service enabled and added to the interface where users connect to for this page to work, as follows:

Figure 3.8 – Interface Management Profile

As you can see in the following screenshot, the URL filtering profile requires each CATEGORY field to be set to an action individually for site access, and if USER CREDENTIAL SUBMISSION is enabled, additional filtering can be applied to decide whether a user is allowed to submit corporate credentials to a certain category. This helps prevent phishing attacks:

Figure 3.9 – URL Filtering Profile

As you can see in the following screenshot, if you want to change a lot (or all) of the actions at once, there's a shortcut to help you. If you hover your mouse over SITE ACCESS or USER CREDENTIAL SUBMISSION, there will be a little arrow that lets you select Set All Actions or Set Selected Actions:

Figure 3.10 – Set All Actions in URL Filtering Profile

A good baseline URL filtering policy can be set up as follows:

1. Set all of the categories to Alert. This will ensure that all of the URL categories are logged.
2. Set Adult, Command and Control, Copyright Infringement, Extremism, Malware, Peer-to-Peer, and Phishing and Proxy Avoidance and Anonymizers to Block.
3. Set Dating, Gambling, Games, Hacking, Insufficient Content, Not-Resolved, Parked, Questionable, Unknown, and Web Advertisements to Continue.
4. Tweak the settings in accordance with your company policy or local laws and regulations (some URL categories cannot be logged by law, for example).

The Categories set to Continue are commonly on the fringes of acceptance, but may still need to be accessed for legitimate purposes. The Continue action gives the user the opportunity to ensure that they are intending to go to this URL before actually opening the web page.

The URL filtering settings contain several logging options that may come in handy depending on your needs:

• Log container page only: This setting only logs the actual access a user is requesting and will suppress related web links, such as embedded advertisements and content links on the page that the user is visiting, reducing the log volume.
• Safe Search Enforcement: This blocks access to search providers if strict safe search is not enabled on the client side. Currently, Google, Bing, Yahoo, Yandex, and YouTube are supported.

Additional logging can also be enabled:

• User-Agent: This is the web browser that the user is using to access a web page.
• Referer: This is the web page that links to the resource that is being accessed (for example, Google or CNN linking to a resource page).
• x-forward-for: If a downstream proxy is being used by users, this masks their original source. If the downstream proxy supports enabling the x-forward-for feature, it will add the client's original IP in the c header, allowing the identification of the original user.

The following steps and screenshot show you how to enable these settings in your URL filtering profile:

1. Enable Log container page only to provide some privacy to your users and prevent the logging of embedded ad pages.
2. Enable Safe Search Enforcement.
3. Enable additional logging for User-Agent and Referer:

Figure 3.11 – URL filtering settings

The User Credential Detection tab allows you to enable credential detection (see Chapter 6, Identifying Users and Controlling Access for more details).

HTTP Header Insertion lets you control web application access by inserting HTTP headers into the HTTP/1.x requests to application providers. As you can see in the following example, this can help you control which team IDs can be accessed in Dropbox, which tenants and content can be accessed in Office 365 and Google app-allowed domains. You can create any URL that needs to have a certain header inserted to ensure users are accessing the appropriate instance:

Figure 3.12 – HTTP Header Insertion

Now, let's look at the file blocking profile.

The file blocking profile

The default strict file blocking profile contains all the file types that are commonly blocked and serves as a good template to start from. Select the strict profile and click on the clone action, as in the following screenshot, to create a new profile based on this one. If any file types do need to be allowed in your organization, remove them from the block action:

Figure: 3.13 File blocking profile clone

The direction lets you determine whether you want to only block uploads or downloads or both directions for a specific file type, as well as groups of file types. File blocking profiles also use rules so that file types can be grouped with their own directions and actions. The default action is Allow, so any file type not included will be allowed to pass through (but will be scanned if an appropriate security profile is attached to the security policy). The available actions are Alert, Block, and Continue, which works similarly to the URL filtering Continue option if the file is being downloaded from a web page that supports the HTTP redirect to serve the user a warning page before continuing with the download or upload.

Review all the file types and set the ones you want to block. Any file types that you are not sure about and would like to get a chance to review first can be set to the Alert action so that you can keep track of occurrences under monitor | logs | data filtering.

As you can see in the following screenshot, we can create sets of file types by clicking on the Add button and selecting the file type, and then setting the action:

Figure: 3.14 File Blocking Profile

We will now have a look at the WildFire Analysis profile.

The WildFire Analysis profile

The WildFire Analysis profile controls which files are uploaded to WildFire for analysis in a sandbox and which ones are sent to a private instance of WildFire (for example, the WF-500 appliance). Clone the default profile to upload all files to WildFire, or create a new profile if you want to limit which files are forwarded or need to redirect files to a private cloud. If no WildFire license is available, only Portable Executables (PEs) are forwarded to WildFire.

If all file types can be uploaded for inspection, simply set a rule for any application and any file type. If exceptions exist, either create a rule to divert specific files to a private cloud, if you have a WildFire appliance in your data center, or specify which files can be uploaded, as shown:

Figure 3.15 – WildFire Analysis Profile

Next, let's learn about custom objects.

Custom objects

Some security profiles support custom objects. We have already looked at custom URL categories, but the other custom objects are explained in the following sections.

The Custom Spyware/Vulnerability objects

You can create your own signatures using RegEx to detect spyware phone-home/C2 or network vulnerabilities. The Configuration page, as shown in the following screenshots, requires basic information, such as an ID number that is between 15.000-18.000 for spyware and 41.000-45.000 for vulnerabilities, a name, a severity value, a direction, and any additional information that may be useful later on. The direction and affected client help the Content-ID engine identify which direction packets that match this signature can be expected:

Figure 3.16 – The Custom Spyware and Vulnerability objects

Under Signatures, you have two main modes of adding signatures, as you can see in the following screenshot:

• Standard: This adds one or more signatures, combined through logical AND or OR statements.
• Combination: This combines predefined (dynamic update) signatures with a timing component requiring n number of hits over x amount of time, aggregated for source, destination, or source-destination:

Figure 3.17 – The Standard or Combination signatures

Let's focus on standard signatures. From the main screen, you can add sets of signatures, which are all separated by a logical OR statement.

Once you start building a set, you need to decide on the scope. The transaction matches a signature in a single packet and the session spans all the packets in the session. If the signature you are adding to identify a threat always occurs in a single packet's payload, you should set a transaction. This will allow the Content-ID engine to stop scanning at once. If you are adding multiple strings, you can enable Ordered Condition Match, which requires the signatures to match from top to bottom in an ordered way. If this option is turned off, the last signature may be detected before the first. If you add multiple strings, you can link them by adding an AND condition.

A signature consists of the following:

• An operator, which is either a pattern, or a greater, equal, or smaller operator. Greater, equal, and smaller operators allow you to target a header, payload, payload lengths, and more. A pattern lets you match an exact string found anywhere in a packet or a series of packets.
• A context, which is where, in any of the available protocols, the signature may be found (for example, if you look for a string in http-req-host-header, that same string will not be matched if it is seen in the payload). Many contexts will be self-explanatory, as you can see in the following screenshot, but for a full list, there's a good online resource describing all the contexts at https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClOFCA0:

Figure: 3.18 – Creating signatures

• A pattern or value: If you want to, for example, match a hostname in an http request header, you would use the domain\.tld RegEx, where the backslash indicates that the dot following it is an exact match for a dot and not a RegEx wildcard.

  The available RegEx wildcard characters include the following:

Figure 3.19 – Supported RegEx wildcard characters

• A qualifier can further limit in which stage of a transaction a pattern can be matched, either in method or type. Using a qualifier is optional:

Figure 3.20 – Host Header pattern

With the above custom objects you are able to identify sessions behaving in a specific way, but this process can also be applied to identify information and keywords inside a session.

The custom data pattern

In the custom data pattern, you can add strings of sensitive information or indicators of sensitive information being transmitted. There is a set of predefined patterns, including social security numbers, credit card numbers, and several other identification numbers. You can use regular expressions to match exact strings in documents or leverage file properties. Once the appropriate parameters have been chosen, you can add these custom data patterns to a data filtering profile and, as you can see in the following screenshot, assign weights. These weights determine how many times a certain marker can be hit in a session before an alert is generated in the form of a log entry and when a session should be blocked for suspicious behavior (for example, it might be acceptable for an email to go out containing one social security number, but not multiple):

Figure 3.21 – Data filtering

Now that you've had a chance to review and configure all the available security profiles, the easiest way to apply them to security rules is by using Security Profile Groups.

Security profile groups

Now that you've prepared all of these security profiles, create a new security profile group, as in the following screenshot, and call it default. This will ensure that the group will automatically be added to every security rule you create:

Figure 3.22 – The default security profile group

Important note

It is not harmful to add all of the security policies to a security rule as Content-ID will intelligently only apply appropriate signatures and heuristics to applications detected in the session (for example, http signatures will not be matched with ftp sessions).

Also, create a Log Forwarding profile called default, but you can leave the actual profile empty for now.