Most Deep Security elements and settings operate on multiple hierarchical levels starting a parent Base Policy level, going down through multiple levels of child Policies, and finishing at the level of the Computer to which the final Policy is assigned. Deep Security provides a collection of Policies that you can use as initial templates for the design of your own Policies tailored to your environment:

Child Policies inherit their settings from their parent Policies. This allows you to create a Policy tree that begins with a base parent policy configured with settings and rules that will apply to all computers. This parent policy can then have a set of child and further descendant policies which have progressively more specific targeted settings. Your Policy trees can be built based on any kind of classification system that suits your environment. For example, the Deep Security branch in the Policy tree that comes with Deep Security has two child Policies, one designed for a server hosting the Deep Security Manager and one designed for the Deep Security Virtual Appliance. This is a role-based tree structure. Deep Security also has three branches designed for specific operating systems, Linux, Solaris, and Windows. The windows branch has further child Policies for various sub-types of Windows operating systems.
In the Windows Policy editor on the Overview page, you can see that the Windows Policy was created as a child of the Base Policy. The Policy's Anti-Malware setting is Inherited (Off):
This means that the setting is inherited from the parent Base Policy, and that if you were to change the Anti-Malware setting in the Base Policy from Off to On, the setting would change in the Windows Policy as well. (The Windows Policy setting would then read Inherited (On). The value in parentheses always shows you what the current inherited setting is.)
The Windows Server 2008 Policy is a child Policy of the Windows Policy. Here the Anti-Malware setting is no longer inherited -- it is overridden and hard-set to On:
Looking further into the Windows 2008 Server Policy, we can see that Intrusion Prevention is also On, and looking at the Intrusion Prevention page we see that a set of Intrusion Prevention Rules are assigned:
The Intrusion Prevention Rules that are included in this Policy are copies of the Intrusion Prevention Rules stored by the Deep Security Manager which are available for use by any other Policies. If you want to change the properties of a particular Rule, you have two choices: modify the properties of the Rule globally so that the changes you make apply to all instances where the Rule is in use, or modify the properties locally so that the changes you make only apply locally. The default editing mode in a Computer or Policy editor is local. If you click Properties on the Assigned Intrusion Prevention Rules area toolbar, any changes you make in the Properties window that appears will only apply locally. (Some properties like the Rule name can't be edited locally, only globally.)
Right-clicking a rule displays a context menu which gives you the two Properties editing mode options: selecting Properties... will open the local editor window and Properties (Global)... will open the global editor window.
Most of the shared Common Objects in Deep Security can have their properties overridden at any level in the Policy hierarchy right down to the individual computer level.
You can always assign additional Rules at any Policy or computer level. However, Rules that are in effect at a particular Policy or computer level because their assignment is inherited from a parent Policy cannot be unassigned locally. They must be unassigned at the Policy level where they were initially assigned.
You can see the number of settings that have been overridden on a Policy or a computer by going to the Overrides page in the computer or Policy Editor:
Overrides are displayed by protection module. You can revert system or module overrides by clicking the Remove button.
Most Vulnerability Protection elements and settings operate on multiple hierarchical levels starting a parent Base Policy level, going down through multiple levels of child Policies, and finishing at the level of the Computer to which the final Policy is assigned. Vulnerability Protection provides a collection of Policies that you can use as initial templates for the design of your own Policies tailored to your environment:

Child Policies inherit their settings from their parent Policies. This allows you to create a Policy tree that begins with a base parent policy configured with settings and rules that will apply to all computers. This parent policy can then have a set of child and further descendant policies which have progressively more specific targeted settings. Your Policy trees can be built based on any kind of classification system that suits your environment. Vulnerability Protection also has branches designed for specific operating systems. The Windows branch has further child Policies for various sub-types of Windows operating systems.
In the Windows Policy editor on the Overview page, you can see that the Windows Policy was created as a child of the Base Policy.The Policy's Firewall setting is Inherited (Off):
This means that the setting is inherited from the parent Base Policy, and that if you were to change the Firewall setting in the Base Policy from Off to On, the setting would change in the Windows Policy as well. (The Windows Policy setting would then read Inherited (On). The value in parentheses always shows you what the current inherited setting is.)
The Windows 7 Desktop Policy is a child Policy of the Windows Policy. Here the Firewall setting is no longer inherited -- it is overridden and hard-set to On:
Looking further into the Windows 7 Desktop Policy, we can see that Intrusion Prevention is also On, and looking at the Intrusion Prevention page we see that a set of Intrusion Prevention Rules are assigned:
The Intrusion Prevention Rules that are included in this Policy are copies of the Intrusion Prevention Rules stored by the Vulnerability Protection Manager which are available for use by any other Policies. If you want to change the properties of a particular Rule, you have two choices: modify the properties of the Rule globally so that the changes you make apply to all instances where the Rule is in use, or modify the properties locally so that the changes you make only apply locally. The default editing mode in a Computer or Policy editor is local. If you click Properties on the Assigned Intrusion Prevention Rules area toolbar, any changes you make in the Properties window that appears will only apply locally. (Some properties like the Rule name can't be edited locally, only globally.)
Right-clicking a rule displays a context menu which gives you the two Properties editing mode options: selecting Properties... will open the local editor window and Properties (Global)... will open the global editor window.
Most of the shared Common Objects in Vulnerability ProtectionDeep Security can have their properties overridden at any level in the Policy hierarchy right down to the individual computer level.
You can always assign additional Rules at any Policy or computer level. However, Rules that are in effect at a particular Policy or computer level because their assignment is inherited from a parent Policy cannot be unassigned locally. They must be unassigned at the Policy level where they were initially assigned.
You can see the number of settings that have been overridden on a Policy or a computer by going to the Overrides page in the computer or Policy Editor:
Overrides are displayed by protection module. You can revert system or module overrides by clicking the Remove button.