ZENworks management is based on a Manage by Exception model. This model assumes that a significant number of devices or users have the same base requirements; these base requirements become the rule and are applied to all (or most) devices or users, while the differences are handled as individual exceptions. The following sections provide a best practice approach to deploying security policies through the Manage by Exception model.
The ZENworks Endpoint Security Agent is location aware. This allows it to apply different security policies based on its detected network environment matching defined locations or a default Unknown location.
If you have locations in which you want to enforce different security policies, you should define them before you begin creating policies. This allows you to design policies that best support your locations.
Because locations apply to multiple areas of Novell ZENworks 11, creation of locations is not covered in this ZENworks Endpoint Security Management Policies Reference. For location information, see the ZENworks 11 SP2 Location Awareness Reference.
There are 10 types of security policies. Each one covers a specific area of device security. Most contain multiple options and concepts that you need to clearly understand. Taken together, the policies can seem overwhelming. You should choose one policy type and focus on how it needs to be deployed in your organization. Then focus on the next one.
The Security Settings policy protects the Endpoint Security Agent. The Location Assignment policy determines which security locations are available to devices or users. Because of the nature of these two policies, we recommend that you address them first.
ZENworks supports both device-assigned and user-assigned security policies. You can assign policies to any devices that are registered in your Management Zone. If your ZENworks system is connected to an LDAP user source, you can assign policies to users defined in the source.
As you plan the deployment of a security policy, you should consider whether it is best assigned to devices or to users:
Device Assignment: Device-assigned policies are applied regardless of the user that is logged in. Be aware that security policies apply to workstation devices only. If you assign a security policy to a server device, it is not applied.
User Assignment: User-assigned policies are applied only when the assigned user is logged in. If the user moves from one device to another, the policies move with the user and are applied when the user logs in to the device.
In some cases, you might need to use both types of assignments. For example, you could create a base Firewall policy and assign it to devices. Then, if you have specific users who have different firewall requirements, you could create the appropriate Firewall policy and assign it to the users.
When the same-type policy (such as a Firewall policy) is assigned to both a device and the device’s user, you must decide which policy takes precedence. You do this by specifying the conflict resolution rule on the device-assignment. There are four rules:
User Last: Applies the device-assigned policy first and then the user-assigned policy.
Device Last: Applies the user-assigned policy first and then the device-assigned policy.
User Only: Applies the user-assigned policy. If there is no user-assigned policy, the device-assigned policy is applied.
Device Only: Applies the device-assigned policy. Ignores the user-assigned policy.
The ZENworks management hierarchy contains four levels:
A device or user (the object) is assigned policies directly. A device or user also inherits policies assigned to its zone or to a folder or group in which the device is a member.
Whenever possible, you should assign a policy at a level (or levels) that encompasses the majority of devices or users to whom the policy applies. For example, if all devices in your organization require data encryption, you might assign a Data Encryption policy to the Management Zone and handle policy exceptions with assignments to device groups or individual devices. However, if only a specific group of devices require data encryption, you might decide to organize those devices into a device group and assign a Data Encryption policy to the device group.
When you create a policy, you provide each policy setting with a value. This is either an absolute value or thevalue. The value lets the setting value be inherited from the next higher policy in the policy hierarchy.
If, as suggested in Practice 4, you take advantage of the management hierarchy as you make policy assignments, policy settings inheritance becomes an important tool to successfully combine multiple policies into the one effective policy that is enforced on the device.
For example, assume that you create a base Firewall policy. You assign the policy to the Management Zone so that all devices inherit it. In the policy, you set the ACL value to allow 802.1x protocol packets. However, you have one group of devices for which you need to deny 802.1x protocol packets. You create a second Firewall policy, leave all setting values configured toexcept for the ACL value which you set to deny 802.1x protocol packets, and assign the Firewall policy to the device group. The Firewall policy assigned to the device group is closest to the device (in the policy hierarchy), so it takes precedence. All values are inherited from the zone Firewall policy except for the 802.1x ACL value, which uses the device group Firewall policy.
Multi-valued settings, such as thelist in the Firewall policy, do not include an value. Instead, multi-valued settings are combined. In the previous example, the Port/Protocol Rules lists in the two Firewall policies (the zone policy and the device group policy) would be combined into one list in the effective Firewall policy.
In some cases, you might not want a policy to inherit values from a policy higher in the hierarchy. For example, you might not want the device group Firewall policy to inherit thelist from the zone Firewall policy. Therefore, you can configure policies to block inheritance of higher-level policies.
A global policy is applied in all locations. A location-based policy is applied only in the locations specified in the policy.
If a policy’s settings are not dependent on location, use a global policy. Even if some of the policy’s settings are dependent on location, consider using a global policy to set the base policy and then creating location-based policies to override the location-dependent settings. When you use global and location-based policies together, the location-based policy settings override the global policy settings.
As you deploy security policies within your zone, we recommend that you create global policies and assign them at the highest level possible, preferably the zone. The global policies should include the policy settings that provide the base security required by the majority of your organization’s devices.
The Endpoint Security Agent enforces one policy of each type on a device. This policy is the effective policy, which is determined by evaluating and manipulating all assigned policies (of the same type) according to ordering and inheritance rules.
To successfully deploy the intended policy to a device, you need to fully understand how assigned policies are going to be ordered based on assignment type (device or user), assignment level (zone, folder, group, and object), and policy location type (global or location-based). You also need to know how policy setting inheritance is applied once the order is determined. These concepts are covered in Section 5.0, Effective Policies.
To ensure that security policies provide the results that you expect, we recommend that you test them on one or more devices before distributing them to all intended users and devices. For instructions, see Section 10.0, Testing Security Policies.