Administration Guide › Custom Roles and Policies

Custom Roles and Policies

This section contains the following topics:

Guidelines for Creating Policies

User Role Planning

Configuring Custom User Roles and Access Policies

Maintaining User Accounts and Access Policies

Example: Allow a Non-Administrator to Manage Archives

Restricting Data Access for a User: Win-Admin Scenario

Restricting Access for a Role: PCI-Analyst Scenario

Sample Policies for Custom Integrations

Sample Policies for Suppression and Summarization Rules

Guidelines for Creating Policies

All CALM access policies and scoping policies state the actions that are granted or denied to specific identities on specific resources. Policies for the CALM resource class grant or deny specified identities the ability to perform actions on application resources, also known as CALM resources. Policies for the SafeObject resource AppObject grant or deny specified identities write and read actions on an application-level resource, as indicated in the filters. Other policies for the SafeObject resource class grant or deny specified identities write and read actions on global resources.

The type of policy or policies you create depends on the resource to which you want to limit access. A summary of the policy requirements by resource follows:

• Resources requiring a CALM policy and scoping policies for AppObject
  • Event Forwarding
  • Event Grouping
  • Integration (non-agent)
  • Profile
  • Report
• Resources requiring only a CALM policy
  • AgentAuthenticationKey
  • AgentConfiguration
  • Alert
  • ALL_GROUPS
  • Connector
  • Database
  • Integration (agent-related)
  • Tag
• Resources requiring only scoping policies for the global resource
  • Calendar
  • Folder
  • GlobalUser
  • GlobalUserGroup
  • iPoz
  • Policy
  • User
  • UserGroup

The following guidelines highlight the differences in the approaches for creating policies, where differences are based on the resources you want to control.

To control access to EventForwarding, EventGrouping, Integration, Profile, and Report

The following approach applies only to policies on the CALM resources, EventGrouping, Integration, Profile, and Report. These application resources require a CALM policy and two scoping policies.

1. Create a CALM policy for one or more application resources such as Report or Integration. Specify one or more application-specific actions that are valid for the specified resources such as create, schedule, or annotate. Add the Identities to which the actions are granted or denied.
2. Create a companion scoping policy on the AppObject resource with both read and write actions. Specify the write action to let the identity edit or delete the resource, but not create it. Specify the read action to let the identity display or view the resource. Create a filter that ties back the AppObject resource to the related application resource. Specify in the filter the EEM folder path that stores the content for the specified resource or is a module for which access is required for the related application resource. Add the same Identities to this policy that you added to the related CALM policy.
3. Create a second companion scoping policy on the AppObject resource with the read action. Specify the read action to let the identity display or view the resource. Create a filter that ties back the AppObject resource to the related application resource. Specify in the filter the EEM folder path that stores the content for the specified resource or is a module for which access is required for the related application resource. Add lower-privileged users or user groups as Identities to this policy.

To control access to Alert, Database, Tag, and agent-related resources

The following approach applies to application resources that require only a CALM policy to grant or restrict access.

• Create a CALM access policy for a resource such as Connector or Tag. Specify the edit action to let the identity create, edit, and delete the resource and take any other valid action. Add the Identities to which this action is granted or denied.

  Note: Access to agent-related resources makes available the buttons from the Agent Explorer folder or its subfolders on the Log Collection subtab of the Administration tab. Access to the Alert resource lets the Identity access the Alerts tab. Access to the Tag resource lets the identity create a Tag for a custom query or report. Access to Database lets the Identity run an archive query.

To control access to global resources used in the CAELM application

The following approach applies to global resources, which require only a scoping policy to limit access.

1. Create a scoping policy for one or more global resources such as User or Policy. Specify the write action to let the identity create, edit, or delete the resource. Add the Identities to which this action is granted or denied.
2. Create a scoping policy for one or more global resources such as User or Policy. Specify the read action to let the identity view the global resource. Add the Identities to which this action is granted or denied.

   Note: Global resources are available with buttons on the User and Access Management subtab of the Administration tab.

More information:

Create a CALM Access Policy

CALM Access Policy Types

Resources and Actions

CALM Resources and EEM Folders

Global Resources and CA EEM Functionality

CALM Access Policy Types

When you create an access policy for CALM or a scoping policy, you select one of the following three types:

• Access policy
• Access control list
• Identity access control list

This choice impacts the level of detail for access policy configuration, where access policy is the broadest.

Note: The examples shown here are access policies for the CALM resource class and therefore, include actions and resources specific to CA User Activity Reporting Module.

An access policy specifies actions that are valid for any of the selected resources that are granted to all selected identities. When you create a generic policy for CA User Activity Reporting Module, you add resources belonging to the CALM resource class, and then you select actions from the displayed list. The actions you select apply to the selected resources for which they are valid. In this example, the policy allows each selected action to be performed on all the selected resources for which create is valid.

An access control list specifies actions valid for each resource separately for the selected identities. When you create a resource-centric policy, you specify what actions are permitted on each resource. You do not need to select actions for a given resource simply because they are valid. For example, you can allow create for reports but not allow create for alerts, even though create is a valid action for alerts. The access control list is the most fine-grained policy when it is implemented for one identity at a time.

An identity access control list specifies the actions granted to selected identities for all applicable selected resources. When you create an identity-centric policy, specify which identities can perform which actions (create, schedule, annotate, edit) on all the listed resources to which each action applies. If you want to restrict the Auditor from scheduling alerts, you would leave schedule blank. However, leaving schedule blank would also restrict the Auditor from scheduling reports.

Resources and Actions

When creating policies, configure an access policy for which an access filter is needed. An access filter is a filter that the Administrator can set to control what event data non-Administrator users or groups can view. For example, an access filter can restrict the data that appears on reports viewed by the specified users or groups. Access filters are automatically converted into EEM Obligation Policies. Access filters are often expressed in terms of the relative paths for the objects to which user access is limited. You can view these relative paths in the EEM Folders area of the interface.

Typically, policies that authorize actions such as create and schedule are defined with the CALM resource class and CALM resources such as reports, tags, DM and MP files, and suppression and summarization rules. Policies that authorize the read and write actions are defined with the SafeObject resource class and the AppObject resource. The Edit action is the only valid action for agent-related resources in the CALM resource class.

More specifically, actions that can be authorized for objects belonging to the CALM resource class follow:

The actions that allow users to view or edit an object belonging to the SafeObject resource class follow:

CALM Resources and EEM Folders

For every custom CALM policy involving EventForwarding, EventGrouping, Integration, Profile, or Report that you create from scratch, you create a scoping policy on AppObject. The scoping policy has read/write access that filters on the EEM paths for each CALM resource listed in the corresponding CALM policy. The same user groups that are Identities for the CALM policy are assigned as Identities to this policy. To complete the policy set, create an additional scoping policy for read only, assign an Identity that can only view the resource, and enter a filter with an EEM folder path.

Note: Whether a CALM policy requires a supporting scoping policy depends on the resource that the CALM policy uses. For example, the Database, Tag, and Alert resources are purely CALM resources and no scoping policies are required for them. Scoping policies are not required for agent-related resources either.

You can view EEM folders from the Administration tab, User and Access Management subtab. When you select a folder such as Suppression, that path is displayed. See the following example:

You specify the EEM folder path as the value in an expression that begins with pozFolder CONTAINS, as shown in the Filters section of a Policy definition. An example follows:

The following tables provide guidelines for the value specified in the filter of a scoping policy that is related to a CALM policy that grants, or denies, access to specific CALM resources.

Note: There is not a one-to-one correspondence between the CALM resources and the folders.

Global Resources and CA EEM Functionality

You can create a scoping policy that is similar in intent to a CALM policy, except the resources are global rather than product-specific. Global resources are those resources that are used across multiple CA products. You can create policies that grant or deny access to specific global resources, accessed by buttons on the Administration tab, User and Access Management subtab.

Use the following table as a guide when creating a scoping policy that grants or denies specified Identities the ability to read and write where the resource specified is a global resource.

When creating a filter for a global resource, refer to the filter for the CALM Application Access policy as an example. One of the things the filter does is to specify what actions go with what resource. If you click Edit on a predefined policy, you can examine the source for an example of how to enter the logic.

User Role Planning

If the predefined application user groups, Administrator, Analyst, and Auditor, are insufficient for your needs, you can create custom roles with new application user groups. For example, to assign a small group of individuals to manage user accounts, where these individuals have no access to unrelated functionality in the CA User Activity Reporting Module, you could define a UserAccountAdministrator role, create a scoping policy for that role, add that role to the CALM Application Access Policy, and assign that role to the users who are to manage user accounts.

User planning for CA User Activity Reporting Module involves the following steps:

• Determining the number of users needed to administer, analyze, and audit CA User Activity Reporting Module
• Identifying the users to grant CA User Activity Reporting Module access

If you are considering creating custom roles with associated access policies, consider the following approach:

• Identify the role to assign each CA User Activity Reporting Module user
• Identify the type of access to CA User Activity Reporting Module resources is required for each role

You can also consider the following alternatives to user-defined roles (application groups):

• Configure dynamic user group policies that create dynamic user groups.
• Create global groups and treat them as application groups. That is, assign them to users and assign them to policies as Identities.

  This approach may be useful if policies are created for the purpose of restricting access by geographical location and you want the same users to have the same level of rights on multiple CA products. For example, a global group for Location-A_Admin could be assigned to users that were to administer several CA products at Location-A. Policies for each CA product could be created that grant administrative rights to the servers on which that product was installed in Location-A.

More information:

Role-Based Access

Create a Global Group

Configuring Custom User Roles and Access Policies

A user role can be a predefined application user group or a user-defined application group. Custom user roles are needed when the predefined application groups (Administrator, Analyst, and Auditor) are not sufficiently fine-grained to reflect work assignments. Custom user roles require custom access policies and modification of predefined policies to include the new role.

Administrators can create user roles and corresponding policies as follows:

1. For each role assumed by users of CA User Activity Reporting Module:
   • Identify the resources to which access must be granted.
   • Identify the actions you want to permit on each resource.
   • Identify the identities, or individuals, to whom this role applies.

     Note: Identities can be other application groups designed to make up a super group.

2. If a predefined application group is too broad for your needs, create a new application group and assign this application group to the individuals you identified. It is good practice to name a user-defined application group with a term that describes the role the assigned users are to perform.
3. Add the new application group to the CALM Application Access policy, which is an Access Control List type.
4. If the new role needs to be able to take an action on one or more resources, such as create, do the following:
   1. Configure a CALM policy that allows the new application group to create or take other valid actions the identified CA User Activity Reporting Module resources.
   2. Configure a scoping policy that grants the new application group read and write access to the AppObject resource and specify a filter that states where the identified resource is stored in the EEM folders. For each filter, enter the named attribute, pozFolder, CONTAINS and a value, where the value is the EEM Folder path beginning with /CALM_Configuration.
5. If the new role only needs to view a specific CA User Activity Reporting Module resource, configure a scoping policy that permits read access to AppObject and specify a filter where the named attribute, pozFolder, CONTAINS a value, where the value is the EEM Folder path beginning with /CALM_Configuration where that resource is stored.
6. Test the policies.
7. Assign the new role to user accounts.

Administrators can also create restrict user access with access filters. If a particular kind of restricted access applies to only one individual, you can omit assigning that person an application group, or role. To limit the access of a user:

1. Create a user but assign no role.
2. Give the user access to the CA User Activity Reporting Module application by adding the user to the CALM access policy.
3. Create a scoping policy that grants read or write access to the SafeObject, AppObject and specify a filter where the named attribute pozFolder is equal to the value of the EEM folder for the resource. For example, if the resource is reports, set the named attribute calmTag equal to the value of a report tag.
4. Create a custom access filter.

Administrators can customize user access to the CA User Activity Reporting Module resources. Consider the following examples:

• Create roles to assign specific administration responsibilities to different groups of administrators. For example, create a role such as UserAccountAdministrator. Create a policy that grants users with this role access to only the functionality needed to maintain users and groups. Such a policy must define read and write access to the GlobalUser resource as well as to the User and UserGroup resources.
• Create roles to distribute responsibilities of analysts to the various types of reports and queries based on tags. For example, create roles such as SystemAccessAnalyst and PCIAnalyst and assign analysts to just one of the restricted analyst roles. Then create policies that grant access to a subset of these resources based on tag. For example, create a policy that grants the SystemAccessAnalyst role access to reports and queries that have the System Access tag and another that grants the PCIAnalyst role access to reports and queries that have the PCI tag. Create other roles and policies based on other tags. Policies that restrict access in this way do so with access filters.

Administrators can create server-based policies using either of the following approaches:

• Restrict data

  You can restrict access to specific logs by creating a data access filter, setting the filter for receiver_name field, and specifying a value such as systemstatus or syslog.

• Restrict configuration

  You can restrict access to a particular CA User Activity Reporting Module server by creating a policy on the SafeObject resource class with AppObject as the selected resource. That is, to restrict access just to the report server configuration on a particular host, define a filter such as the following:

  pozFolder contains /CALM_Configuration/Modules/calmReporter/LogServer01
  

More information:

Create an Access Filter

Restricting Access for a Role: PCI-Analyst Scenario

Restricting Data Access for a User: Win-Admin Scenario

Sample Policies for Custom Integrations

Sample Policies for Suppression and Summarization Rules

Create an Application User Group (Role)

You can create a new application user group to support the roles you need. Once you create a new application user group, you must create access policies for that group.

One case where new access policies are not needed for a new group is when that group is given memberships to existing groups. Consider the scenario where you need one role for individuals who are dedicated to creating data mapping and message parsing files, another role for individuals dedicated to creating suppression and summarization rules, and a third role for those who can perform either of these two tasks. You might define one application user group called AdminDMMP with a policy that grants create access to the Integration resource and another group called AdminSS with a policy that grants create access to the EventGrouping resource. You could then create a third group called AdminDMMPSS with memberships to the AdminDMMP group and the AdminSS group. This third group would automatically inherit the policies from the two membership groups.

Rather than creating new application groups or roles, you can expand the roles of the predefined Analyst and Auditor roles. For example, if you want Analysts to be able to create suppression and summarization rules and you want Auditors to be able to view these rules, you could create a CALM policy that grants the ability to create summarization and suppression rules and a scoping policy that grants the ability to view or edit custom rules and assign the Analyst role to those policies. You could then create a scoping policy that grants users the ability to view suppression and summarization rules and assign the Auditor group to that policy.

Only Administrators can create new roles.

To create a new application user group (role)

1. Click the Administration tab and the User and Access Management subtab.
2. Click Groups.
3. Click the New Application Group button to the left of the Application Groups folder in the User Groups list.
4. Provide the group name and description.
5. If this new user group is to have access you have already defined for two or more user-defined application groups, select those application groups for membership. Otherwise, make no selection.

   Note: If this new group is composed of existing groups, existing policies for each of the component groups will apply to this group. No additional policies are required.

6. Click Save.
7. Click Close.

More information:

Step 2: Create the PCI-Analyst Role

Sample Policies for Suppression and Summarization Rules

Grant a Custom Role Access to CA User Activity Reporting Module

When you create an application user group, or role, be sure to add it to the predefined CALM Application Access policy. Only identities that are explicitly added to this policy can access CA User Activity Reporting Module. Identities can be individual users or members of a user group.

If you encounter a situation where users assigned to a new user group cannot log into the CA User Activity Reporting Module, verify that the Identities of the CALM Application Access policy include this group.

To grant CA User Activity Reporting Module access to a user-defined application user group

1. Select the Administration tab, click User and Access Management, and then click Access Policies on the left pane.
2. Click Scoping Policies and select CALM Application Access.
3. Under Identities, search for the new application group as follows:
   1. For Type, select Application Group.
   2. Click Search Identities.
   3. Leave Name as the attribute and LIKE as the operator. Click Search.

      The name of the new application group appears in the displayed list of identities.

   4. Select the name of the new application group and click the Move button to move the group name to the Selected Identities box.
4. Click Save.

Add an Identity to an Existing Policy

When you create a new application user group, you can add the new group to existing policies, if applicable. When you create a user that has no role but has access limited with an access filter, you can add such a user to existing policies.

Important! When working with the installed access policies, take special care not to delete them as they are not locked or protected.

If a predefined access policy is accidentally deleted, users will be unable to access the CA User Activity Reporting Module server until it is restored. You can restore policies using the safex utility.

To add an identity to an existing policy

1. Select the Administration tab, click User and Access Management, and then click Access Policies on the left pane.
2. Click the policy type, and then select the policy that applies to the new application user group. View the Identities pane.
3. For Type, select Application Group.
4. Click Search Identities.
5. Leave Name as the attribute and LIKE as the operator. Click Search.

   The name of the new application group appears in the displayed list of identities.

6. Select the name of the new application group and click the move button to move the group name to the Selected Identities box.
7. Click Save.

More information:

Step 4: Add PCI-Analyst to Existing Policies

Create a CALM Access Policy

You can create a CALM access policy to grant (or deny) one or more valid actions on one or more CALM resources.

The following CALM resources are application-specific; that is, they are used only by the CA User Activity Reporting Module product:

• Alert
• AgentConfiguration
• AgentAuthenticationKey
• ALL_GROUPS
• Connector
• Data
• Database
• EventGrouping
• Integration
• Profile
• Report
• Tag

To create a new CALM policy from scratch

1. Click the Administration tab and the User and Access Management subtab.
2. Click Access Policies.
3. Click the New access policy button to the left of the CALM folder.
4. Enter a meaningful name for the policy and, optionally, a short description.
5. If this policy is temporary, select the Calendar with the date range to which it applies.
6. Accept CALM as the resource class name.
7. Select Type in the General panel according to the following criteria:
   • Select access policy to grant or deny to all selected identities the ability to perform all selected actions on all of the selected resources to which they apply.
   • Select access control list to grant or deny to all selected identities the ability to perform only the selected actions on a selected resource.

     Note: It is not possible to save filters for multiple resources. The workaround is to create separate policies, one for each resource/filters combination.

   • Select identity access control list to grant or deny to each selected identity the ability to perform selected actions on all the selected resources to which they apply.
8. Use the Identities area to select the users or groups to which this policy applies as follows:
   1. Select Application Group for Type or one of the other options, click Search Identities, and click Search.
   2. Select identities from those available and click the Move button to move them to the Selected Identities box.
9. If the policy type is access policy, complete the access policy configuration as follows:
   1. Enter a CALM resource in the Add resource field and click Add.
   2. Select each Action that the selected identities are to be able to perform on any selected Resource, where valid actions include the following: annotate, create, dataaccess, edit, and schedule. You cannot grant the ability to perform a given action on one resource and not another where it is valid.
10. If the policy type is access control list, complete access control list configuration as follows:
    1. Enter a CALM resource in the Add resource field and click Add.
    2. Select each Action that the selected identities are to be able to perform on this Resource, where valid actions include one or more of the following: annotate, create, dataaccess, edit, and schedule.
    3. Repeat the last two steps for each resource to be addressed by this policy.

       With this type, you can grant the ability to perform an action such as create on one resource but not on another.

11. If the policy type is identity access control list, complete the identity access control list configuration as follows:
    1. For each identity selected, select the Actions to be granted or denied on all resources for which they are valid.
    2. For each resource to be added, enter a CALM resource name in the Add resource field and click Add:
12. Review the check boxes at the top and select any that apply:
    • Select Explicit Deny to change the policy from one that grants access to one that denies access
    • Select Disabled to inactivate this policy temporarily, if new.
    • Select Pre-Deployment and then select Assign Labels and add the labels if using this policy for testing purposes and you want to categorize the policies with custom labels.
13. Click Save and then click Close on the left pane.

Create a Scoping Policy

You can create a scoping policy on any global resource. Actions on scoping policies are limited to read and write.

• The following global resources are used by many CA products (applications):
  • Calendar
  • GlobalUser
  • GlobalUserGroup
  • iPoz
  • Policy
  • User
  • UserGroup
  • AppObject
• The global resource, AppObject, lets you create scoping policies on application-specific resources and modules. You do this by adding a filter that designates the relevant EEM folder where the application-specific content or module is stored.
  • EEM content folders you can use in filters with the AppObject resource include the following:
    • EventGrouping
    • Integration (Server)
    • Profile
    • Report
  • CA User Activity Reporting Module module folders you can use in filters with the AppObject resource include the following:
    • Event Log Store
    • Report Server
    • Subscription

You can create a policy from scratch if no policy exists from which you can leverage the settings. If you are creating a scoping policy associated with a CALM policy you have created, specify the same identities as those in the related CALM policy.

Only Administrators can create, edit, delete, and view access policies.

To create a new explicit grant scoping policy

1. Click the Administration tab and the User and Access Management subtab.
2. Click Access Policies.
3. Click the New Scoping Policy button to the left of the Scoping Policies folder.
4. Create a meaningful name for the policy. For example, include the role or roles to which it applies and the tasks that are scoped. View the names of the predefined policies for examples of how this standard can be used.
5. Enter a short description that more fully describes what the more cryptic name implies.
6. Typically, you will accept SafeObject as the resource class name.
7. Select Type in the General panel according to the following criteria:
   • Select access policy to grant or deny to all selected identities the ability to perform all selected actions on all of the selected resources to which they apply.
   • Select access control list to grant or deny to all selected identities the ability to perform only the selected actions on a selected resource.

     Note: It is not possible to save filters for multiple resources. The workaround is to create separate policies, one for each resource/filters combination.

   • Select identity access control list to grant or deny to each selected identity the ability to perform selected actions on all the selected resources to which they apply.
8. If the policy type is access policy or access control list, use the Identities area to select the users or groups to which this policy applies.
   1. Select Application Group for Type, click Search Identities, and click Search.
   2. Select identities from those available and click the Move button to move them to the Selected Identities box.
9. If the policy type is access policy, all actions are selected for all resources by default. To customize this, complete access policy configuration as follows:
   1. Select a resource from the Add resource drop-down list and click Add.
      • Select AppObject if the resources to which read or write access is to be configured are CA User Activity Reporting Module-specific resources.
      • Select User and GlobalUser for access to Users buttons on the Administration tab, User and Access Management subtab.
      • Select UserGroup and GlobalUserGroup for access to Groups buttons on the Administration tab, User and Access Management subtab.
      • Select Policy for access to the Access Policies, EEM Folders, and Test Policies buttons on the Administration tab, User and Access Management subtab.
      • Select Calendar for access to the Calendars button on the Administration tab, User and Access Management subtab.
      • Select iPoz for access to the Password Policy and User Store buttons on the Administration tab, User and Access Management subtab.
   2. Select read to grant/deny view access; select write to grant/deny edit access. If you select neither, all actions are selected.

      Note: To grant/deny create access, you must define a CALM access policy and select CA User Activity Reporting Module resources individually.

   3. Add a generic filter that applies to the selected resources, if needed.
10. If the policy type is access control list, complete access control list configuration as follows:
    1. Select a resource from the Add resource drop-down list and click the Add (+) button.
    2. Select read, write, or both for Actions.
    3. Click the Edit Filters button to open the filter form. Create a filter for the associated resource by selecting or entering values for the Left type/value, Operator type/value, and Right type/value.
    4. If the filter includes a resource name as a value, select the check box labeled Treat resource names as regular expressions. Otherwise, leave this check box cleared.

    Important! Define one policy for each resource/filters combination.

11. If the policy type is identity access control list, complete the identity access control list configuration as follows:
    1. For Type, select one of the displayed options. For example, select Application Group, click the Search Identities link, and click the Search button to display the members of the type you selected.
    2. Select the identities and click the move button to populate the Selected Identities pane.
    3. For each identity selected, specify read or write or both.

       The identity-specific actions apply to all the selected resources. That is, a given identity can view, view and edit, or just edit all of the selected resources.

    4. Add the resources to which the identity-specific actions are to be granted or denied.
12. Review the check boxes and select any that apply:
    • Select Explicit Deny to change the policy from one that grants access to one that denies access
    • Select Disabled to inactivate this policy temporarily, if new.
    • Select Pre-Deployment and then select Assign Labels and add the labels if using this policy for testing purposes and you want to categorize the policies with custom labels.
13. Click Save and then click Close on the left pane.

More information:

Step 3: Create Win-Admin System Access Policy

Create a Policy Based on an Existing Policy

You can create a new access policy by copying an existing access policy and modifying the copy. This procedure can save you the time it takes to manually duplicate the specifications of an existing policy that requires only minor modifications to satisfy your current requirements.

Only Administrators can create, edit, delete, or view access policies.

To create a policy based on an existing policy

1. Click the Administration tab and the User and Access Management subtab.
2. Click Access Policies.
3. Select either CALM or Scoping Policies, depending on the type of policy you want to use as a template.
4. Click the name link to open the policy to copy.
5. Click Save As.

   The Explorer user Prompt dialog appears.

6. Enter the name for the new policy to be based on the open policy and click OK.
7. Make the needed modifications.

   For example, replace the copied Identity with the name of the role (user-defined application user group) to which this policy applies. Consider modifying the actions permitted on the copied resources. Consider clicking Filters and specifying an additional filter for the new role.

8. Click Save, and then click Close.
9. Verify the new policy definition.
   1. Re-select the policy type to display the view of all policies.
   2. Compare the new policy with the original policy and verify that all planned changes are reflected in the new policy.
   3. Click Close.
10. Test the policy.

More information:

Step 5: Create a Policy Based on Analyst Report View-Edit Policy

Test a New Policy

You can test whether a new policy is syntactically correct with the Test Policies feature. The Test Policies feature lets you run ad-hoc queries against the access policies you define. You can consider a permission as a request: "Can {identity} perform {action} against the resource of type {resource class} and of name {resource} [with the following attributes}] [at the {specified time}]?" A result of ALLOW means that the identity you entered can perform the specified action on the specified resource with the specified attributes at the specified time.

Before you begin, have your policy at hand.

To test a policy

1. Click the Administration tab and the User and Access Management subtab.
2. Click Test Policies.

   The Permission Check Parameters page appears.

3. If the policy you plan to check was one where you selected Pre-Deployment and added labels, then check the check box that indicates you want to include pre-deployment policies and add the associated labels.
4. Complete the entry fields. If your policy includes filters, specify the filters in the order that they appear in the policy.
5. Click Run Permission Check.
6. Observe the result and proceed in one of the following ways:
   • If the result is ALLOW, log on to CA User Activity Reporting Module as a user specified as an identity in this new policy and test the effectiveness, scope, and coverage of the before putting it into production use.
   • If the result is DENY, verify your entries on the query. If they are correct, return to the policy or and make the needed correction there.

More information:

Step 3: Create Win-Admin System Access Policy

Create a Dynamic User Group Policy

A dynamic user group is composed of global users that share one or more common attributes. A dynamic user group is created through a special dynamic user group policy where the resource name is the dynamic user group name and membership is based on a set of filters configured on user and group attributes.

You can create a dynamic group composed of Users, Application Groups, Global Groups, or Dynamic Groups. For example, you can create a dynamic group of Global Groups or Application Groups based on Name, Description, or Group Membership. Or, you can create a dynamic group of Users with different roles based on a common attribute in their global user profile, for example:

• Job title
• Department or office
• City, state, or country

Only Administrator can create Dynamic User Group Policies.

To create a dynamic user group policy

1. Click the Administration tab and the User and Access Management subtab.
2. Click Access Policies.
3. Click New Dynamic Group Policy.

   The New Dynamic Group Policy page appears.

4. For Name, enter a group name that indicates what this group of users has in common. Optionally, enter a description.
5. Select a policy type. The default is Access Policy.
6. Select Identities as follows:
   1. For Type, select User, Application Group, Global Group, or Dynamic Group and click Search Identities.
   2. For Attribute, Operator, and Value, enter the expression that sets the criteria for membership in this group and click Search.

      For example, if you selected User, you could enter Job Title Like Manager and click Search to find all of the users who have the job title of Manager.

   3. Select from the displayed identities those who are to be members of this dynamic group and click the Move arrow to move your selections to the Selected Identities box.
7. For Actions, select belong.
8. In the Add resource field, enter the value you entered in the Name field and click the Add button. This indicates that the selected identities belong to the dynamic group resource you just created.
9. Optionally, add more filters.
10. Click Save.
11. Click the Dynamic User Group Policies link and verify the new dynamic user group you created. For example:

    

Create an Access Filter

You can create an access filter to restrict access to log data meeting the filter criteria. By default all CA User Activity Reporting Module application users have query access to event log data stored in the event log stores of the active CA User Activity Reporting Module server, peer servers in a meshed federation or descendant servers in a hierarchical federation.

You can restrict access to the event log store of one or more specific CA User Activity Reporting Module servers by creating a data access filter. You can apply an access filter to an individual or a group.

To create an access filter for a user-defined role

1. Click the Administration tab and the User and Access Management subtab.
2. Click New Access Filter.

   

   The Access Filter Design wizard appears.

3. For Details, enter the name and description for the filter.
4. Click Identities. Select an Identity type, click the search button to show available identities, and use the shuttle control to select the ones to which this access filter applies.

   For example, select the application group you created for this purpose.

5. Set the access filters.
   1. Click Access Filters.
   2. Click the New Event Filter button.

   

   1. Add one or more expressions that define the access filter.
   2. Click Save and Close.

   The Access Filter you created appears.

6. Click Close.

More information:

Create an Application User Group (Role)

Step 4: Create Win-Admin Data Access Filter

Maintaining User Accounts and Access Policies

As an Administrator, you can perform the following maintenance tasks on user accounts and access policies:

• Lock a user account so the user cannot log onto CA User Activity Reporting Module
• Unlock user accounts that have been locked, if the password policy does not permit any user to unlock a locked user account.
• Add new user accounts
• Edit existing user accounts
• Lock or delete user accounts that belong to individuals who no longer need access to CA User Activity Reporting Module
• Edit existing access policies
• Delete access policies that are no longer needed
• Create, edit, or delete delegation policies
• Create, edit, or delete access filters with their corresponding auto-generated obligation policies
• Create a super role from existing roles with limited access
• Add a new custom role and corresponding access policies

Create a Calendar

You can create a new calendar to help restrict user access during certain time periods. Calendars work as part of access policies. When you define a calendar, you can include or exclude time blocks in hours, days of the week, or dates.

To create a calendar

1. Click the Administration tab, then click User and Access Management, then click the Calendars button.

   The Calendars page appears.

2. Click the New Calendar icon at the top left of the calendar list.

   The New Calendar details pane appears.

3. Enter a name that specifies the target policy, and provide a description of the intended use.
4. Use the calendar icons to set start and end dates for the calendar.
5. Click Add Include Time Block or Add Exclude Time Block to create exception periods within the main effective period of the calendar.
6. Click Save, and then click Close.

More information:

Add a Calendar to a Policy

Add a Calendar to a Policy

When creating a policy, you can select an existing calendar that specifies when the specified identities can perform the selected actions on the specified resources. A calendar can define start and end dates and time blocks in hours or days of the week.

To add a calendar to a policy

1. Click the Administration tab and the User and Access Management subtab.
2. Open the policy to which this calendar applies
   1. Click Access Policies
   2. Select the policy type.
   3. Select the policy.
3. Open the Calendar drop-down list and select the calendar you created for this policy.

   

4. Click Save to save the addition of the calendar to an existing policy.

More information:

Create a Calendar

Example: Limit Access to Work Days

You can restrict the time of day or days of the week a given user group can access CA User Activity Reporting Module by creating a calendar for the times to grant access, creating a custom role, creating a new policy based on the policy providing CA User Activity Reporting Module access, and assigning the calendar and custom role to this policy.

Example--Limit External Auditors' Access to CA User Activity Reporting Module to Weekdays

To limit certain group's access to CA User Activity Reporting Module to business days, create a calendar for weekdays and add it to the policies that grant auditors specific access.

For example, if you wanted to limit External Auditor's access to CA User Activity Reporting Module to business hours, create a calendar that specifies weekdays, Monday through Friday, 9 a.m. to 5 p.m., for all months of the year.

Create a role for external auditors.

Open the CALM Application Access scoping policy and save it as ExternalAuditors-CALM Application Access, select the Weekdays 9-5 calendar and select the user group External Auditors as the identity.

Important! Use the Calendar feature only with policies that grant access. Do not use it with policies that deny access.

More information:

Create an Application User Group (Role)

Create a Policy Based on an Existing Policy

Add a Calendar to a Policy

Create a Calendar

Export Access Policies

You can export all policies of a selected type at any time, both predefined policies and custom policies. Exporting policies is a good way to keep a current backup.

An export creates an XML file for each selected policy, where all XML files are zipped into a file named CAELM[1].xml.gz.

To export access policies

1. Click the Administration tab and the User and Access Management subtab.
2. Click Access Policies.
3. Select the type of access policy to export and click Export.

   The File Download dialog appears.

4. Click Save and save the file with a unique name.
5. Click Close.

More information:

Back Up All Access Policies

Delete a Custom Policy

You can delete a custom policy for any of the following reasons:

• You saved it under a different name and plan to make no other changes, so you need to delete the duplicate.
• You no longer have active memberships in the Identities defined to the policy, so the policy is no longer in use.

Important! Take care not to delete a predefined policy. Should this occur, you can restore it if you exported a backup.

To delete a custom policy

1. Click the Administration tab and the User and Access Management subtab.
2. Click Access Policies.
3. Select either CALM or Scoping Policies, depending on the type of policy you want to delete.
4. Click the name of the policy to be deleted.
5. Click Delete.
6. Click OK to confirm the deletion.

Delete an Access Filter and Obligation Policy

You can delete an access filter and the obligation policy generated by the filter to remove the data access limitation.

Do not delete the obligation policy generated by the filter from Access Policies.

To delete an access filter and its obligation policy

1. Click the Administration tab, click User and Access Management.

   The Access Filter List appears at the top of the left pane.

2. Select the filter to delete and click the Delete Access Filter button.

   

   The Delete Access Filter Confirmation warning message appears.

3. Click Yes to remove the selected access filter and the associated obligation policy.

Example: Allow a Non-Administrator to Manage Archives

Suppose you want to allow a non-Administrator group to manage auto-archiving. You could create a group called ArchiveAdministrator, a CALM policy that allows the edit action on the resource database. This allows read access on the archive catalog of databases for querying, write access on the archive catalog for ReCatalog, and the ability to use LMArchive utility for manual archiving or the restore-ca-elm shell script for restoring auto-archived databases.

To allow specified non-Administrators to handle archiving

1. Create a role called ArchiveAdministrator.
   1. Select the Administration tab and then the User and Access Management subtab.
   2. Select Groups.
   3. Click New Application Group.
   4. Enter ArchiveAdministrator as the name.
   5. Click Save.

      The Application Group, or role, ArchiveAdministrator is created.

   6. Click Close.
2. Create a CALM policy to allow edit access to the database resource.
   1. Click Access Policies.
   2. Click New Access Policy to create a new CALM policy.
   3. Type ArchiveAdministrator policy in the Name field.
   4. Type ArchiveAdministrator can run the LMArchive utility and the restore-ca-elm shell script for the description.
   5. For Identities, select Application Group as the Type, click Search Identities, and then click Search.
   6. Select ArchiveAdministrator and then click the move arrow.
   7. Type Database under Add resource and click Add.
   8. Select edit as the Action.

   

   1. Click Save. Click Close
3. Test the policy and verify that the result is ALLOW.

   

4. Grant the ArchiveAdministrator role the ability to log on to CA User Activity Reporting Module.
   1. Click CALM under Access Policies.
   2. Select CALM Application Access.
   3. Under Identities, search for the Application Group ArchiveAdministrator, and move it to Selected Identities.

   

   1. Click Save. Click Close. Click Close.

      The User and Access Management tab appears with the buttons in the left pane.

5. Assign the ArchiveAdministrator role to one or more users.
   1. Click Users.
   2. Enter the name of a person to whom you want to assign this role as the Value under Search Users and click Go.

      The selected user name appears under the Users folder.

   3. Select the link for the selected user.
   4. Click Add Application User Details.
   5. Move Archive Administrator to the Selected User Groups list.

   

   1. Click Save. Click Close.
   2. Repeat for each user to whom you want to assign this role.
   3. Click Close.
6. (Optional) Review the results from CA User Activity Reporting Module.
   1. Click Log Out to log out as the Administrator.
   2. Log in as a user to whom you assigned the role ArchiveAdministrator.
   3. Click the Administration tab, Log Collection subtab.
   4. Select Archive Catalog Query.
   5. Observe that you use the Query and ReCatalog buttons.
7. (Optional) Run the restore-ca-elm restore script with the credentials of the user defined with the ArchiveAdministrator role to verify the policy works as expected.

More information:

Restore Auto-Archived Files

Restricting Data Access for a User: Win-Admin Scenario

You can limit reports users can view to those with a specified tag. You can limit the data users can view on those reports to data generated from specified event sources. Limiting access to reports with a given tag is done with an access policy. Limiting data access to events returned to a particular CA User Activity Reporting Module server is done with an access filter. With an access filter defined, a role assignment is optional. That is, you can create a new user, assign no role, and limit data access for that user with an access filter.

Consider the scenario for ABC company with four data centers in the U.S. The Administrator wants to give the Windows Administrator in the Houston region read access to Windows events processed by the domain controller in the Houston area. Windows events processed by the CA User Activity Reporting Module server installed on the Houston domain controller are sent from sources where the host names begin with the string, ABC-HOU-WDC.

This example walks you through creating a user called Win-Admin and ensuring that this user can only view reports that have a System Access tag and that the data on these reports is limited to events from event sources with host names that begin with the known naming convention.

The example provides details for each of the following steps:

1. Create the new user, Win-Admin.
2. Give Win-Admin basic access to CA User Activity Reporting Module. Add this identity to the CALM Application Access policy.
3. Restrict access to reports for Win-Admin to those tagged as System Access. Create a scoping policy with read access to AppObject with filters that specify the EEM folder where Reports are stored and specify the calmTag is equal to System Access. Test the policy.
4. Limit the data Win-Admin can view to that generated by the domain controller in Win-Admin's region. Create an access filter, named Win-Admin Data Access, that limits the query and report data Win-Admin can view to Windows events from event sources with a hostname that begins with ABC-HOU-WDC.
5. Log onto CA User Activity Reporting Module as the Win-Admin user and evaluate the access provided by the policies.
6. If the access is too limited for the user to perform intended tasks, extend the access with additional policies.

More information:

Step 4: Create Win-Admin Data Access Filter

Step 1: Create the Win-Admin User

Step 3: Create Win-Admin System Access Policy

Step 6: Extend Granted Actions

Step 1: Create the Win-Admin User

You can create a user without a role (application group) if you specify data access with an access filter.

Step 1 of the complete process for restricting data access in this way is to create the user.

You create a user only if the global user account is not available for import from an external directory. When creating such an account, do not add application user details. In this example scenario, Win-Admin is the user name.

If you search for users, the new name appears in the list

More information:

Create a Global User

Step 2: Add Win-Admin to the CALM Application Access Policy

The second step in restricting data access of a user named Win-Admin is to grant this identity access to the CA User Activity Reporting Module application.

Add the new user to the CALM Application Access policy. The procedure is the same as granting CA User Activity Reporting Module access to a new role except when you search identities, you specify Type as User.

More information:

Grant a Custom Role Access to CA User Activity Reporting Module

Step 3: Create Win-Admin System Access Policy

Step 2 grants access to log on to the CA User Activity Reporting Module application.

Step 3 restricts, or scopes, access to the CA User Activity Reporting Module application after logon. At the broadest level, you can grant read only access or both read and write access to the specified identities.

Selection of policy type determines the granularity at which you can specify permitted actions.

• Access Policies permit selected actions on applicable selected resources.
• Access Control List Policies let you specify what actions are permitted on each added resource.
• Identity Access Control List policies let you specify what actions on applicable resources are permitted by each identity.

You can permit limited access to a resource by creating a filter that specifies the EEM folder for that resource and then specifying restrictions on the folder.

This example demonstrates how to restrict access to read access in general with further restrictions to a specific feature. Specifically, Step 3 restricts the Win-Admin user to viewing system access reports. The following example shows how to create a scoping policy called Win-Admin System Access that grants read access to the SafeObject, AppObject and specifies filters that restrict report access to those with the System Access tag. It also demonstrates how to test the policy, and after verification how to remove the pre-deployment setting.

The General area of a scoping policy designed to specify application access to read only or both read and write specifies SafeObject as the resource class name. The following example shows the policy name of Win-Admin System Access. It is a good practice to select Pre-deployment for a new policy until you have tested it and are satisfied it is ready for use in a production environment.

You can grant access to either users or groups. In this example, access is granted to the new user Win-Admin.

The "highest-level" policy created for CA User Activity Reporting Module is the CALM Access Policy, where CAELM is the application instance. This scoping policy is to specify that the read action is allowed on the application objects, AppObject, which refers to all the application features.

You can further limit the specified action allowed on all objects by specifying filters. Filters are often specified in pairs, where the first filter specifies the CA EEM folder where data related to a given feature is stored and the second filter specifies a restriction on objects in that location. The first filter in the following example limits CA EEM folder access to the folder where the reports resource is stored. Specifically, it specifies that the pozFolder contains /CALM_Configuration/Content/Reports. The second filter limits access to reports with the tag System Access by specifying calmTag is equal to System Access.

After saving a policy, you can search for it to review. You can search for policies by name, identity or resource. You can enter a partial value. You can also enter multiple criteria. Examples for this scenario follow.

Searching by the full name displays the one policy you need.

Searching by identity only displays all policies that apply to this identity including those that apply to all identities.

Searching by resource only where the resource is AppObject displays all system supplied and custom policies that grant read or read and write access to any identity.

When the custom policy you search for displays on the policy table, examine the values, including the filters. If you notice anything that requires correction, you can click the name link to redisplay the policy for editing.

It is a good practice to test each new policy. Be sure to enter the attribute/value pairs in the order you entered the filters, with the higher-level attribute first.

Verify that the result is ALLOW.

After verifying the result is ALLOW, clear the Pre-Deployment setting on the policy. Otherwise, you will not be able to log in as Win-Admin to evaluate what this user can do.

More information:

Test a New Policy

Step 4: Create Win-Admin Data Access Filter

Step 3 restricts the Win-Admin user to viewing system access reports. This level of access allows the Win-Admin user to view system access reports across all four regions of the ABC company.

Step 4 creates an access filter to limit the data the Win-Admin user can view to the system access reports for the Houston domain controller.

Creating a data access filter begins with specifying its name. The name used in this scenario is Win-Admin Data Access.

You specify the identities to which the access filter applies in the Identities area. A filter can apply to users or groups. In this scenario, this access filter applies only to the Win-Admin user.

For Access Filters, you define each condition in terms of the value for a CEG column. Values following the LIKE operator can contain either of the following wildcard characters:

• _ (underscore character) - represents any single character
• % (percent sign) - represents a string containing any number of characters

The first filter for this scenario takes advantage of the fact that all Windows events are prefixed with NT-. To limit the data to Windows events, you can specify that the event_logname CEG column must have data that includes the string NT-%. To further limit Windows events to those from a specific domain controller, this example specifies that event_source_hostname must have data that includes a string using local conventions. The value ABC-HOU-WDC% is based on a naming convention of a hyphenated name composed of abbreviations for the company, the region, and the prefix for the domain controller type.

Note: In the absence of event sources with a standardized naming convention, you can create a keyed values list with the desired event_source_hostnames and use the keyed values list name as the value.

When there are only two filters and the logic is AND, parentheses are not required. If you enter a complex expression, such as the following, parentheses are required.

(event_logname like NT-% 
And event_source_hostname=ABC-%) 
Or (event_logname like CALM-% 
And event_source_hostname=XYZ-%)

When you save a data access filter, its name is displayed in the access filter list.

A search for policies matching the Win-Admin user name displays the three policies for All Identities plus another three: the CALM Application access policy where Win-Admin was added, the Win-Admin System Access policy created from scratch, and the data policy that is added automatically when you define an access filter. The data policy is listed first in the following. You can also view it under Obligation policies. You never create Obligation policies directly with CA User Activity Reporting Module.

More information:

Create an Access Filter

Step 5: Log on as Win-Admin User

Before you create policies for a given user or application user group, log on as that user or group member and determine what you can and cannot do. First, verify that the restrictions you expect to be in place are working. Second, verify that you can perform the tasks you expect such users to do.

For this scenario, you expect to be able to view only reports or action alerts that are tagged with System Access. In the example, the only available query tag filter is System Access. Therefore, the expectation is verified.

A quick way to test an access filter is to use the Prompts function. However, this function is not available to the Win-Admin user. All the prompt queries have the tag "Event Viewer". Access to Prompt Filters can be granted with the policy filter calmTag=Event Viewer.

The best way to test an access filter is to review the data displayed on a report. Consider the following access filter. The event_logname CEG column begins with NT- and the CEG column event_source_hostname begins with ABC-HOU-WDC, an abbreviation for the ABC company, Houston location, Windows Domain Controller.

event_logname Like NT-% AND event_source_hostname Like ABC-HOU-WDC%

The following example shows a report viewed by the user to whom this access filter applies. Notice the data in the Log Name column begins with NT- and the data in the Source column begins with ABC-HOU-WDC.

Step 6: Extend Granted Actions

The policies and access filter defined in steps 2, 3, and 4 of this example enable the Win-Admin user to view System Access reports, with limits on the data. With this access alone, the Win-Admin user cannot schedule a report, schedule an alert, or annotate a report. To do these things, add Win-Admin to the Analyst Auditor Report Server Access Policy and the Analyst Create-Schedule-Annotate policy. Example of these policies with Win-Admin added follow:

For Win-Admin to be able to create a report, this user needs write access added to the Win-Admin System Access policy. This requires opening the Win-Admin System Access policy for editing and adding write to the permitted actions.

For Win-Admin to be able to use prompts, the filter for Win-Admin System Access can be modified such that the attribute calmTag equals either System Access or Event Viewer.

Restricting Access for a Role: PCI-Analyst Scenario

You can create a role that is similar to a predefined role and quickly create policies modeled on predefined policies. The user-defined role may be similar to the predefined role in that it provides the same access to the same resource types, but different in that it limits access based on a filter not present in the predefined role. There may be several policies to which this predefined role has been added as an identity. If the configuration of any policy is such that it applies to your new role, you just add the new role to the existing policy. If the configuration is such that you need to change the type, the resources, the actions, or the filters, you can create a new policy from a copy of the existing one.

This example walks you through creating a role for an analyst that is to work only with reports that have a PCI tag. The associated policy for this role is created from a copy of an existing policy for all Analysts.

The process involves the following procedures:

1. Plan the policies you need. Begin by identifying the existing policies to leverage for the new role.
2. Create the new application user group (role), PCI-Analyst.
3. Give the PCI-Analyst basic access to CA User Activity Reporting Module. Add this identity to the CALM Application Access policy.
4. Give the PCI-Analyst the same access to report servers and create report ability that Analysts have. Add the PCI-Analyst identity to the identified policies.
5. Restrict report access to those reports tagged with the PCI calmTag. Use the policy that grants the ability to view and edit reports as a template to modify.
6. Assign the PCI-Analyst role to a test user for evaluation.
7. Log in as the test user and evaluate access.

   If the access allowed by the role and policies is what you expect, assign the role to all individuals who are to analyze PCI reports.

Step 1: Plan the Role and Policies to Create

Suppose you want to create a role similar to Analysts, but restrict access to PCI-related reports and queries. Plan a name for the role that describes its function, for example, PCI-Analyst.

Before you begin creating new roles, or application user groups, consider the policies that are required to support the new role. It is a good practice to identify the existing policies that are candidates for use as templates. Under Identities, look for the role that is similar to the one you are planning.

In this example scenario, that role is ug:Analyst. Under Search Policies, check Show policies matching identity, enter the identity, ug:Analyst, and click Go. The policies displayed include those for All Identities and those where ug:Analyst is explicitly named under Identities.

The policy names that include this role follow:

• Under Scoping, CALM Application Access
• Under Scoping, Analyst Auditor Report Server Access Policy
• Under Scoping, Analyst Report View-Edit Policy
• Under CALM, Analyst Create-Schedule-Annotate policy

For each of the candidate policies, examine the definition and determine which of the following actions to take:

• Add the new role as an identity to which this policy applies. This is the best choice if the policy applies to the new role without change.

  This action is appropriate for the following policies in this example:

  • CALM Application Access, which defines all identities who can access CA User Activity Reporting Module.
  • Analyst Auditor Report Server Access Policy, which defined all identities who can schedule reports and alerts against all available report servers. This role requires no limitation on report servers.
  • Analyst Create-Schedule-Annotate policy
• Save the policy as a new name and modify its definition.

  This action is appropriate for the following policy in this example, where the new copy would include only the new identity and would have an additional filter to limit the read/write access to reports tagged PCI:

  • Analyst Report View-Edit Policy

Step 2: Create the PCI-Analyst Role

You can create a custom role to represent any task that multiple users perform with the CA User Activity Reporting Module application. A role is the same thing as an application user group.

Step 1 of the process of restricting access for a role is to create the role.

When creating a custom role that is not a superset of an existing role, do not make a selection from Available User Groups.

More information:

Create an Application User Group (Role)

Step 3: Add PCI-Analyst to the CALM Application Access Policy

After creating any new role, the next step is to give this role basic logon ability to the CA User Activity Reporting Module application. By default, only the predefined roles have logon access. Add this application group to the CALM Application Access policy.

More information:

Grant a Custom Role Access to CA User Activity Reporting Module

Step 4: Add PCI-Analyst to Existing Policies

Once you identify the policies that apply to an application user group of which the new role is a subset, you add the new role to the current list of Identities.

For this scenario, add the PCI-Analyst role to the following existing policies:

• Analyst Auditor Report Server Access Policy
• Analyst Create-Schedule-Annotate policy

More information:

Add an Identity to an Existing Policy

Step 5: Create a Policy Based on Analyst Report View-Edit Policy

When you create a policy based on an existing policy, you copy the existing policy and save it to a new name. Then, you rename it, edit the description to fit the new role, and replace the existing identities with your new identity. When the policy you are using as a template provides access that is too broad for your new role, you create filters to limit that access.

For the PCI-Analyst scenario, you copy the Analyst Report View-Edit policy, save it to a new name, open the new policy, replace the identity with the PCI-Analyst group, and add a filter to limit report access to those reports tagged with the PCI calmTag.

It is a good practice to test a policy based on an existing policy just as you would a policy you created from scratch. When you test a policy with a filter, be sure to enter the filter exactly as it is entered in the policy. When you enter a group name for identity, be sure to prefix it with ug:, for example, ug:PCI-Analyst.

More information:

Create a Policy Based on an Existing Policy

Test a New Policy

Step 6: Assign the PCI-Analyst Role to a User

After creating a new role and its supporting policies, it is a good practice to log on as a user with just this role assigned to evaluate whether the access provided is what is needed. Once verified, the new role can be added to the accounts of all users who are to perform the tasks for which the role was designed.

You can create a temporary user account for the purpose of testing a new role and then delete that account when testing is complete. Or, you can create a user called Test-User and replace the role assignment at each reuse.

More information:

Assign a Role to a Global User

Step 7: Log in as a PCI-Analyst and Evaluate Access

Verify that the policies are sufficient to limit access to reports and alerts tagged as PCI. Assign the PCI-Analyst role to a user and log into the CA User Activity Reporting Module as that new user.

View report tags. Verify that the reports you can view are only those with the PCI tag.

Schedule a report. Verify that the reports you can schedule are only those with the PCI tag.

Create a report. Verify that the only available tag for the new report is PCI.

Sample Policies for Custom Integrations

You can give non-Administrators the ability to create custom integrations by creating one custom role, one CALM policy, and one scoping policy. You can give other non-Administrators the ability to view custom integrations by creating an additional custom role with an associated scoping policy. You add both custom roles to the CALM Application Access policy and assign users to these roles.

The following example procedure shows you how to do this:

1. Create an application user group called Create-DM-XMP-Files.
2. Create an application user group called View-DM-XMP-Files.
3. Grant Create-DM-XMP-Files and View-DM-XMP-Files access to the CA User Activity Reporting Module product.

   

4. Create a CALM policy that grants Create-DM-XMP-Files the ability to create data mapping files and message parsing files using common event grammar while logged on to CA User Activity Reporting Module.

   

5. Create a scoping policy that grants Create-DM-XMP-Files the ability to edit and view the custom DM files and XMP file saved to the EEM folder /CALM_Configuration/Content/Mapping or /CALM_Configuration/Content/Parsing using common event grammar.

   

   

6. Create a scoping policy that grants View-DM-XMP-Files the ability to view the custom DM files and XMP file saved to the EEM folder /CALM_Configuration/Content/Mapping or /CALM_Configuration/Content/Parsing.

   Note: The CEG policy grants all Identities rights to view the Common Event Grammar.

   

   

7. Test the policies.
8. Assign users to both Create-DM-XMP-Files and View-DM-XMP-Files.

Sample Policies for Suppression and Summarization Rules

You can authorize non-Administrators to create custom suppression rules and custom summarization rules by creating one custom role, one CALM policy and one scoping policy. You can give other non-Administrators the ability to view custom suppression rules and custom summarization rules by creating an additional custom role with an associated scoping policy. You add both custom roles to the CALM Application Access policy and assign users to these roles.

The following example procedure shows you how to do this.

1. Create an application user group called Create-SUP-SUM-Rules.
2. Create an application user group called View-SUP-SUM-Rules.
3. Grant both roles access to the CA User Activity Reporting Module product.

   

4. Create a CALM policy that grants Create-SUP-SUM-Rules users the ability to create summarization and suppression rules or import them while logged on to CA User Activity Reporting Module.

   

5. Create a scoping policy that grants Create-SUP-SUM-Rules users the ability to view or edit custom summarization or suppression rules that have been saved to the EEM folder, /CALM_Configuration/Content/Rules/Suppression or /CALM_Configuration/Content/Rules/Summarization.

   

   

6. Create a scoping policy that grants View-SUP-SUM-Rules users the ability to view custom summarization or suppression rules.

   

   

7. Test the policies
8. Assign users to the new roles. For example, external auditors may want to be able to view your summarization and suppression rules. To permit this, you could assign a role similar to View-Sup-Sum-Rules to such users.

An alternative to creating two new roles explicitly for the create/edit/view task and the view-only task is to expand the roles of the predefined Analyst and Auditor roles. For example, you could eliminate steps 1, 2, 3, and 8 of the previous procedure and instead assign the Analyst as the identity to EventGrouping Create policy and View-Edit-SUP-SUM-Rules and assign the user group Auditor as the identity to View-SUM-SUP-Rules.

More information:

Create an Application User Group (Role)

Grant a Custom Role Access to CA User Activity Reporting Module

Assign a Role to a Global User

Test a New Policy