Drag and Drop
CSM Rules Inheritance
A. See below explanation
Correct Answer: A
Explanation/Reference:
Introduction
Shared policies enable you to configure and assign a common policy definition to multiple devices.
Rule inheritance takes this feature one step further by enabling a device to contain the rules defined in a shared policy in addition to local rules that are specific to that particular device. Using inheritance, Security Manager can enforce a hierarchy where policies at a lower level (called child policies) inherit the rules of policies defined above them in the hierarchy (called parent policies). Note If a policy bundle includes a shared policy that inherits from other shared policies, those inherited rules are also applied to any devices on which the policy bundle is applied.
Rule Order When Using Inheritance
An access list (ACL) consists of rules (also called access control entries or ACEs) arranged in a table.
An incoming packet is compared against the first rule in the ACL. If the packet matches the rule, the packet is permitted or denied, depending on the rule. If the packet does not match, the packet is compared against the next rule in the table and so forth, until a matching rule is found and executed.
This first-match system means that the order of rules in the table is of critical importance. When you create a shared access rule policy, Security Manager divides the rules table into multiple sections, Mandatory and Default. The Mandatory section contains rules that cannot be overridden by the local rules defined in a child policy. The Default section contains rules that can be overridden by local rules.
Figure 5-2 describes how rules are ordered in the rules table when using inheritance.
Benefits of Using Inheritance
The ability to define rule-based policies in a hierarchical manner gives you great flexibility when defining your rule sets, and the hierarchy can extend as many levels as required. For example, you can define an access rule policy for the device at a branch office that inherits rules from a parent policy that determines access at the regional level. This policy, in turn, can inherit rules from a global access rules policy at the top of the hierarchy that sets rules at the corporate level.
In this example, the rules are ordered in the rules table as follows:
– Mandatory corporate access rules
– Mandatory regional access rules
– Local rules on branch device
– Default regional access rules
– Default corporate access rules
The policy defined on the branch device is a child of the regional policy and a grandchild of the corporate policy. Structuring inheritance in this manner enables you to define mandatory rules at the corporate level that apply to all devices and that cannot be overridden by rules at a lower level in the hierarchy. At the same time, rule inheritance provides the flexibility to add local rules for specific devices where needed.
Having default rules makes it possible to define a global default rule, such as æ<1>eny any any? that appears at the end of all access rule lists and provides a final measure of security should gaps exist in the mandatory rules and default rules that appear above it in the rules table.
Inheritance Example
For example, you can define a mandatory worm mitigation rule in the corporate access rules policy that mitigates or blocks the worm to all devices with a single entry. Devices configured with the regional access rules policy can inherit the worm mitigation rule from the corporate policy while adding rules that apply at the regional level. For example, you can create a rule that allows FTP traffic to all devices in one region while blocking FTP to devices in all other regions. However, the mandatory rule at the corporate level always appears at the top of the access rules list. Any mandatory rules that you define in a child policy are placed after the mandatory rules defined in the parent policy.
With default rules, the order is reversed – default rules defined in a child policy appear before default rules inherited from the parent policy. Default rules appear after any local rules that are defined on the device, which makes it possible to define a local rule that overrides a default rule. For example, if a regional default rule denies FTP traffic to a list of destinations, you can define a local rule that permits one of those destinations.
IPS Policy Inheritance
Event action filter policies for IPS devices can also use inheritance to add rules defined in a parent policy to the local rules defined on a particular device. The only difference is that although active and inactive rules are displayed together in the Security Manager interface, all inactive rules are deployed last, after the inherited default rules.
Signature policies for IPS devices use a different type of inheritance that can be applied on a persignature basis.
Explanation/Reference:
Introduction
Shared policies enable you to configure and assign a common policy definition to multiple devices.
Rule inheritance takes this feature one step further by enabling a device to contain the rules defined in a shared policy in addition to local rules that are specific to that particular device. Using inheritance, Security Manager can enforce a hierarchy where policies at a lower level (called child policies) inherit the rules of policies defined above them in the hierarchy (called parent policies). Note If a policy bundle includes a shared policy that inherits from other shared policies, those inherited rules are also applied to any devices on which the policy bundle is applied.
Rule Order When Using Inheritance
An access list (ACL) consists of rules (also called access control entries or ACEs) arranged in a table.
An incoming packet is compared against the first rule in the ACL. If the packet matches the rule, the packet is permitted or denied, depending on the rule. If the packet does not match, the packet is compared against the next rule in the table and so forth, until a matching rule is found and executed.
This first-match system means that the order of rules in the table is of critical importance. When you create a shared access rule policy, Security Manager divides the rules table into multiple sections, Mandatory and Default. The Mandatory section contains rules that cannot be overridden by the local rules defined in a child policy. The Default section contains rules that can be overridden by local rules.
Figure 5-2 describes how rules are ordered in the rules table when using inheritance.
Benefits of Using Inheritance
The ability to define rule-based policies in a hierarchical manner gives you great flexibility when defining your rule sets, and the hierarchy can extend as many levels as required. For example, you can define an access rule policy for the device at a branch office that inherits rules from a parent policy that determines access at the regional level. This policy, in turn, can inherit rules from a global access rules policy at the top of the hierarchy that sets rules at the corporate level.
In this example, the rules are ordered in the rules table as follows:
– Mandatory corporate access rules
– Mandatory regional access rules
– Local rules on branch device
– Default regional access rules
– Default corporate access rules
The policy defined on the branch device is a child of the regional policy and a grandchild of the corporate policy. Structuring inheritance in this manner enables you to define mandatory rules at the corporate level that apply to all devices and that cannot be overridden by rules at a lower level in the hierarchy. At the same time, rule inheritance provides the flexibility to add local rules for specific devices where needed.
Having default rules makes it possible to define a global default rule, such as æ<1>eny any any? that appears at the end of all access rule lists and provides a final measure of security should gaps exist in the mandatory rules and default rules that appear above it in the rules table.
Inheritance Example
For example, you can define a mandatory worm mitigation rule in the corporate access rules policy that mitigates or blocks the worm to all devices with a single entry. Devices configured with the regional access rules policy can inherit the worm mitigation rule from the corporate policy while adding rules that apply at the regional level. For example, you can create a rule that allows FTP traffic to all devices in one region while blocking FTP to devices in all other regions. However, the mandatory rule at the corporate level always appears at the top of the access rules list. Any mandatory rules that you define in a child policy are placed after the mandatory rules defined in the parent policy.
With default rules, the order is reversed – default rules defined in a child policy appear before default rules inherited from the parent policy. Default rules appear after any local rules that are defined on the device, which makes it possible to define a local rule that overrides a default rule. For example, if a regional default rule denies FTP traffic to a list of destinations, you can define a local rule that permits one of those destinations.
IPS Policy Inheritance
Event action filter policies for IPS devices can also use inheritance to add rules defined in a parent policy to the local rules defined on a particular device. The only difference is that although active and inactive rules are displayed together in the Security Manager interface, all inactive rules are deployed last, after the inherited default rules.
Signature policies for IPS devices use a different type of inheritance that can be applied on a persignature basis.
