Exceptions

After setting a Master Policy that determines how accounts will be managed in the entire organization, you can create exceptions to add granularity as needed and set different behavior for specific platforms that will override the corresponding rules set by the Master Policy. Execptions can be set for a scope of accounts associated with a specific platform. The Master Policy, together with the exceptions defined on each platform, determine the resultant behavior of the system on each account, based on its Platform.

To define more granularity for a specific scope of accounts, such as the Windows PCI accounts, after you define the Master Policy, you can duplicate a Windows platform in Platform Management and define an exception that contains specific rules that are relevant to Windows PCI only. The unique combination of the Master Policy rules together with the exception ensures that each platform is managed exactly according to your needs, with minimum configuration.

Initially, when a user adds an exception, it inherits all values from the Master Policy and these values still adopt any changes made in the Master Policy. However, if a user changes the value of any setting in the exception, either basic or advanced, the new value overrides the value that was inherited from the Master Policy and disconnects the setting value from the Master Policy. To emphasize this, a broken chain icon is displayed next to the ‘disconnected’ setting.

In addition, any changes made in a Master Policy after an exception is created do not affect any settings in the exception that override the Master Policy; they only affect the settings in the exception that inherit directly from Master Policy. This is especially relevant when a rule contains several basic and advanced settings, and some of the exception settings may inherit values from the Master Policy and some override it.

For example, an enterprise decides that users can connect directly to target systems (“Click to Connect”) but can still view passwords when needed (i.e. utilize the “Show” or “Copy” functions). However, the Windows PCI accounts cannot be viewed by users and can only be accessed through the ‘Connect’ button. In this case, an exception will be created for the rule that defines that users can connect directly to target systems on a Windows PCI platform. The basic setting remains without changes (meaning that it inherits from the Master Policy), while the advanced setting that determines that users can view passwords will be disabled, overriding the Master Policy.

The following scenario describes a typical workflow using the Master Policy and Platform Management technical settings.

In a large enterprise that manages multiple accounts on local and remote machines, a Risk Manager has issued a security policy defining that all passwords in the organization must be changed every 90 days. In response, the IT/IS Group Manager informed him that passwords for the Windows PCI systems in the organization’s US offices only need to be changed once a year. In addition, the Vault Administrator has suggested using a different port to manage Windows_US PCI systems.

To ensure compliance with enterprise and standard policies, the Compliance Auditor emphasizes the importance of compliancy and wants to know how to verify that all accounts comply with the Master Policy.

The new Master Policy enables all the above users to get what they want:

■ The Master Policy defines password changes for all privileged accounts every 90 days.
■ An exception is created within the Master Policy to change passwords on Windows PCI systems in the US offices once a year.
■ The Compliance Auditor can see the effective accounts policy that is enforced throughout the organization in the Master Policy, and can view compliancy to it in the standard compliance report.
■ Finally, technical settings that are set in the new Platform Management page enable the Vault administrator to set a different port or any other technical settings for all accounts that are managed on the Windows_US PCI system.