In This Section: |
Threat Prevention lets you customize profiles that meet the needs of your organization.
Ideally, you might want to set all protections to Prevent in order to protect against all potential threats. However, to let your gateway processes focus on handling the most important traffic and report only the most concerning threats, you need to determine the most effective way to apply the Threat Prevention settings.
When you define a new Threat Prevention profile, you can create a Threat Prevention Policy which activates only the protections that you need and prevents only the attacks that most threaten your network.
This is the high-level workflow to create and deploy a Threat Prevention policy:
Note - For each Policy Layer, configure a Threat Prevention Rule Base with the Threat Prevention profile as the Action of the rule.
You can create a Threat Prevention Rule Base with multiple Policy Layers. Policy Layers help you organize your Rule Base to best suit your organizational needs. You can divide the Policy Layers by services or networks. Each Policy Layer calculates its action separately from the other Layers. In case of one Layer in the policy package, the rule enforced is the first rule matched. In case of multiple Layers:
Important - When the Threat Prevention blades run in MTA mode, the gateway enforces the automatic MTA rule, which is created when MTA is enabled on the gateway.
These examples show which action the gateway enforces when a connection matches rules in more than one Policy Layers.
Example 1
|
Data Center Layer |
Corporate LAN Layer |
---|---|---|
Rule matched |
Rule 3 |
Rule 1 |
Profile action |
Prevent |
Detect |
Enforced action: Prevent
Example 2
|
Data Center Layer |
Corporate LAN Layer |
---|---|---|
Rule matched |
Rule 3 |
Rule 1 |
Profile action |
Prevent |
Detect |
Exception for protection X |
Inactive |
- |
Enforced action for protection X: Detect
Example 3
|
Data Center Layer |
Corporate LAN Layer |
---|---|---|
Rule matched |
Rule 3 |
Rule 1 |
Profile action |
Prevent |
Detect |
Override for protection X |
Detect |
- |
Exception for protection X |
Inactive |
- |
Exception is prior to override and profile action. Therefore, the action for the Data Center Layer is Inactive.
The action for the Corporate LAN Layer is Detect.
Enforced action for protection X: Detect.
Example 4
|
Data Center Layer |
Corporate LAN Layer |
---|---|---|
Rule matched |
Rule 3 |
Rule 1 |
Profile action |
Deep Scan all files |
Process specific file type families: Inspect doc files and Drop rtf files. |
Enforced action: Deep Scan doc files and Drop rtf files.
Example 5
MIME nesting level and Maximum archive scanning time
The strictest action is:
Block combined with the minimum nesting level/scanning time, or
Allow combined with the maximum nesting level/scanning time, or
If both Block and Allow are matched, the enforced action is Block.
Example 6
UserCheck
|
HR Layer |
Finance Layer |
Data Center Layer 3 |
---|---|---|---|
Rule matched |
Rule 3 |
Rule 1 |
Rule 4 |
Profile action |
Detect |
Prevent |
Prevent |
Configured page |
Page A |
Page B |
Page C |
The first Layer with the strictest action is enforced.
Enforced Action: Prevent with UserCheck Page B.
In pre-R80 versions, the IPS Software Blade was not part of the Threat Prevention Policy, and was managed separately. In R80.xx versions, the IPS Software Blade is integrated into the Threat Prevention Policy.
When you upgrade SmartConsole to R80.xx from earlier versions, with some Security Gateways upgraded to R80.xx, and other Security Gateways remaining in previous versions:
To see which Security Gateway enforces which IPS profile, look at the Install On column in the IPS Layer.
Best Practice - For better performance, we recommend that you use the Optimized profile when you upgrade to R80 or higher from earlier versions.
Each Threat Prevention Layer contains a Rule Base. The Rule Base determines how the system inspects connections for malware.
The Threat Prevention rules use the Malware database and network objects. Security Gateways that have Identity Awareness enabled can also use Access Role objects as the Protected Scope in a rule. The Access Role objects let you easily make rules for individuals or different groups of users.
There are no implied rules in this Rule Base, traffic is allowed or not allowed based on how you configure the Rule Base. For example, A rule that is set to the Prevent action, blocks activity and communication for that malware.
The columns of a rule define the traffic that it matches and what is done to that traffic.
The sequence of rules is important because the first rule that matches traffic according to a protected scope and profile is applied.
For example, if rules 1 and 2 share the same protected scope and a profile in rule 1 is set to detect protections with a medium confidence level and the profile in rule 2 is set to prevent protections with a medium confidence level, then protections with a medium confidence level will be detected based on rule 1.
Give the rule a descriptive name. The name can include spaces.
Double-click in the Name column of the rule to add or change a name and click OK.
Threat Prevention rules include a Protected Scope parameter. Threat Prevention inspects traffic to and/or from all objects specified in the Protected Scope, even when the specified object did not open the connection. This is an important difference from the Source object in Firewall rules, which defines the object that opens a connection.
For example, the Protected Scope includes a Network Object named MyWebServer. Threat Prevention inspects all files sent to MyWebServer for malware threats, even if MyWebServer did not open the connection.
Protected Scope objects can be:
You can set the Protected Scope parameter to Any. This option lets Threat Prevention inspect traffic based on the direction and interface type as defined by the Profile assigned to the applicable rule. By default, the predefined Optimized Rule sets the Protection Scope to Any.
You can configure the traffic direction and Security Gateway interface types that send files to Threat Prevention for inspection. You do this in the Protected Scope section of the Anti-Virus or Threat Emulation Settings window. The options are:
Sends only incoming files from the specified interface type for inspection. Outgoing files are not inspected. Select an interface type from the list:
When you select the Any option in the Protected Scope section of a rule, the traffic direction and interface type are defined by the Profile assigned to that rule. If you add objects to the Protected Scope in a rule, files that match these objects are inspected for all connections.
The default global parameter for SPAN and TAP configuration is set to inspect all. You can use these commands to configure the Security Gateway to use the Protected Scope settings for SPAN and TAP with Threat Emulation.
fw ctl set int
- Changes current Protected Scope settings for SPAN and TAP, does not survive reboot$FWDIR/module/fwkern.conf
- This changes the settings after reboot.Run these commands to set the SPAN port to use the Policy instead of the global default setting (inspect all):
# fw ctl set int te_handle_span_port_interfaces_according_to_topolgy 1 # echo “te_handle_span_port_interfaces_according_to_topolgy=1” >> $FWDIR/module/fwkern.conf |
The Protection/Site column shows the protections for the Threat Prevention policy.
To add a protection to an exception:
An exception sub-rule is added to the policy.
The protections are added to the exception sub-rule.
To search for a malware in the Protection viewer:
Action refers to how traffic is inspected.
To select a profile for a rule:
Select the gateways on which to install the rule. The default is All (all gateways that have a Threat Prevention blade enabled). Put your mouse in the column and a plus sign shows. Click the plus sign to open the list of available gateways and select. If you right-click a column in the table, you can add more columns to the table from the list that shows.