Default policy elements

Predefined Policies, Template Policies, and Inspection Policies provide an easy starting point for determining what kinds of rules your system needs.

Four kinds of policy elements are used in the policy configuration for Engines, Master Engines, and Virtual Engine Engines:

A Template Policy is a policy that can be used as the basis for Policy or other Template Policy elements. The rules in the Template Policy are copied as inherited rules into the Policies and Template Policies that are based on the Template Policy. You can edit the inherited rules only by editing the original Template Policy from which the rules were inherited.
An Inspection Policy element is a set of Inspection rules that are referenced from the Inspection tab of Policy and Template Policy elements. You can use the same Inspection Policy in multiple Policy and Template Policy elements.
A Sub-Policy element is a section of IPv4 Access rules that you can insert into Policies and Template Policies. The rules in the sub-policy are conditional rules that allow you to define matching criteria that determines whether the sub-policy applies to a connection. You can edit the rules by editing the sub-policy where the rules belong.
A Policy element gathers together all rules from the different policy elements. Policies include the rules added directly to the Firewall, IPS, or Layer 2 Firewall Policy, the rules from the higher-level Template Policy, and possibly rules from one or more sub-policies. For example, an IPS Policy is always based on an IPS Template Policy element, and a Layer 2 Firewall Policy is always based on a Layer 2 Firewall Template Policy element.

The hierarchy of how rules are inherited between the main policy elements is shown in the following illustration.

Figure: Rule inheritance (without Inspection rules inherited from Inspection Policies)

In this illustration, Template Policy A is the basis for Template Policy B, so Template Policy B contains all rules defined in Template Policy A.

Template Policy B also contains all rules in a Sub-Policy, as well as rules defined directly in Template Policy B.

The example Policy inherits the following rules:

All rules in Template Policy A.
All rules in Template Policy B.
All rules in the Sub-Policy.

In addition to the inherited rules, the example policy also contains any rules that the administrators add to it directly. In the policy, the administrators can only edit the rules that were added directly to the policy. To change rules inherited from Template Policy A, Template Policy B, or the Sub-Policy, they must edit the policy in which the rules were originally defined.

A hierarchy such as the one outlined here is useful to:

Reduce the need for creating the same or similar rule in several policies. For example, any rule added to Template Policy A is also added to any policy created based on that template. The next time the policies based on Template Policy A are installed on the engines, the new rule is used on all those engines. There is no need to edit each individual policy separately.
Restrict the editing rights of administrators. For example, administrators who are granted rights to only policies cannot edit the rules defined in the Template Policies on which the policies are based. Their actions have no effect on rules that are placed above the row where the Template Policy allows them to insert new rules. In the hierarchy shown in the illustration, the insert points for the Policy are defined in Template Policy B. Template B can be edited only in the place where there is an insert point in Template Policy A.
Reduce the likelihood of mistakes affecting important communications. Template Policies can be reserved for defining only the rules for essential communications, so that most daily editing is done in the lower-level policies. If the Template Policy is properly designed, rules in the lower-level policy cannot override the rules in the Template Policy. Good organization also makes it easier to read policies, and reduces the risk of errors.
Improve processing performance. Using sub-policies, whole blocks of rules can be skipped during processing when a connection does not match the rule that directs the traffic processing to the sub-policy. Using sub-policies reduces the processor load, which can lead to better throughput if the processor load is constantly high.

The default policy elements are introduced into the Secure SD-WAN Manager when you import and activate a recent dynamic update package (for example, during the installation). The elements might change when you install newer update packages. None of the default policy elements can be changed. However, you can make copies of the default policies if you have to create a changed version.

Table 1. Default policy elements for Engines
Element type	Default name	Description
Firewall Template Policy	Firewall Template	A Template Policy that contains the predefined Access rules necessary for the firewall to communicate with the Secure SD-WAN Manager and some external components. The Firewall Template Policy uses Inspection rules from the No Inspection Policy. The rules in the No Inspection Policy do not enforce inspection.
Firewall Template Policy	Firewall Inspection Template	Firewall Template Policy that uses Inspection rules from the High-Security Inspection Template.
Firewall Sub-policy	DHCP Relay	A Sub-Policy containing rules that allow the firewall to relay DHCP requests from a host in one internal network to a DHCP server in a different network, as well as DHCP requests from VPN clients to an internal DHCP server.
IPS Template Policy	High-Security IPS Template	IPS Template Policy that uses Inspection rules from the High-Security Inspection Template. A Template Policy containing the predefined Access rules necessary for the IPS engine to communicate with the Secure SD-WAN Manager and some external components. The High-Security IPS Template Policy provides an easy starting point for determining what kinds of rules your system needs.
IPS Template Policy	Medium-Security IPS Template	IPS Template Policy that uses Inspection rules from the Medium-Security Inspection Policy.
IPS Policy	Customized High-Security Inspection IPS Policy	Example of a customized IPS Policy that uses Inspection rules from the Customized High-Security Inspection Template. Used in testing IPS at ICSA Labs and NSS Labs.
IPS Policy	Default IPS Policy	Basic IPS Policy that uses Inspection rules from the High-Security Inspection Template. Can be used as a starting point for creating a customized IPS Policy. The Default IPS Policy does not add any rules to the rules defined in the IPS Template. It allows you to install the predefined rules in the IPS Template on the IPS engine right after installation. (Template Policies cannot be installed on the engines.)
Layer 2 Firewall Template Policy	Layer 2 Firewall Template	A Template Policy that contains the predefined Access rules necessary for the Layer 2 Firewall to communicate with the Secure SD-WAN Manager and some external components. The Layer 2 Firewall Template uses Inspection rules from the No Inspection Policy. The rules in the No Inspection Policy do not enforce inspection.
Layer 2 Firewall Template Policy	Layer 2 Firewall Inspection Template	A Template Policy that is based on the Layer 2 Firewall Template. The Layer 2 Firewall Inspection Template uses Inspection rules from the High-Security Inspection Template. The Layer 2 Firewall Inspection Template enables deep inspection for all traffic.
Layer 2 Interface Policy	Layer 2 Interface Template	A Template Policy that contains rules for traffic detected by Capture Interfaces, Inline IPS Interfaces, and Inline Layer 2 Firewall Interfaces on firewalls.
Inspection Policy	No Inspection Policy	Suitable for Firewall deployments, in which only packet filtering is needed. Disables deep packet inspection.
	Medium-Security Inspection Template	For Firewalls, Layer 2 Firewalls, inline IPS deployments in asymmetrically routed networks, and IPS deployments in IDS mode. Terminates reliably identified attacks and logs Situations that have some degree of inaccuracy. Low risk of false positives.
	High-Security Inspection Template	For Firewall, Layer 2 Firewall, and inline IPS use. Extended inspection coverage and evasion protection. Not for asymmetrically routed networks. Terminates reliably identified attacks, and Situations that have some inaccuracy. Moderate false positive risk.
	Customized High-Security Inspection Policy	This policy is an example of a highly customized Inspection Policy for network environments in which unconditional inspection coverage and evasion protection are required. The risk of false positives is high in production use.

You can add new Template Policies without basing them on any existing Template Policy.

However, in most cases we recommend using the IPS Template as the starting point for your customized IPS Template Policies and IPS Policies. We recommend using the Layer 2 Firewall Template as the starting point for your customized Layer 2 Firewall Template Policies and Layer 2 Firewall Policies.

Situations are the central elements in the Inspection rules of your Inspection Policies. The Situation elements detect exploit attempts against known vulnerabilities and other commonly known security threats. Dynamic updates include new and updated Situations. New patterns in traffic might begin to match when a new dynamic update is activated and you refresh the Inspection Policy.

In most environments, we recommend using the High-Security Inspection Policy as the starting point for Inspection Policies. The High-Security Inspection Policy provides extended inspection coverage. It also protects the network against evasions, which are attempts to disguise attacks to avoid detection and blocking by network security systems. The only difference between the rules in the High-Security Inspection Policy and the Medium-Security Inspection Policy is in the way the Inspection rules handle Situations that are categorized as Suspected Attacks. The High-Security Inspection Policy terminates Suspected Attacks with an alert, whereas the Medium-Security Inspection Policy only logs Suspected Attacks.

Situations that belong to the Suspected Attacks category contain basic fingerprints. Suspected Attacks also contain traffic patterns that might indicate malicious activities but are not any verified attack patterns. Suspected Attacks can detect zero-day attacks (attacks that are not yet publicly known), but can sometimes block some legitimate traffic if the traffic pattern resembles malicious activities.