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.
With R80.10 Gateways, you can create a Threat Prevention Rule Base with multiple Ordered Layers. Ordered Layers help you organize your Rule Base to best suit your organizational needs. You can divide the Ordered Layers by Software Blades, services or networks. Each Ordered Layer calculates its action separately from the other Layers. If a connection matches a rule in only one Layer, then the action enforced is the action in that rule. When a connection matches rules in more than one Layer, the gateway enforces the strictest action and settings.
Important - When Threat Emulation and Threat Extraction run in MTA mode, the gateway enforces the action of the first rule matched. It does not necessarily enforce the strictest rule.
These examples show which action the gateway enforces when a connection matches rules in more than one Ordered 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 versions or higher, the IPS Software Blade is integrated into the Threat Prevention Policy.
When you upgrade SmartConsole to R80 or higher from earlier versions, but only some of the gateways are upgraded to R80 or higher, and other gateways remain in previous versions:
To see which 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.