iConsole User Guide › iConsole Administration › User Administration › Security Models

Security Models

Security models ensure that reviewers can only see events they are permitted to see when searching the CMS database.

You can choose which security models are available on your CMS. You can also have multiple security models active at the same time, though each reviewer is linked to a single model.

For example, some reviewers may only be permitted to see events linked to users in their own management group. Other reviewers may only be permitted to see specific types or categories of events.

CA DataMinder supports the following security models:

Management Group (Standard)

This is the default model, optimized to allow fast searching. It is based on the CA DataMinder user hierarchy.

It uses e-mail addresses (including synthesized addresses for participants in Web and Application Monitor events) to map participants to CA DataMinder users. Under this model, reviewers can only view events where at least one participant was in their management group when the event was captured.

You can also include this model in a hybrid with a Policy model (see below).

Management Group (Standard, Self-Exclude)

This model prevents reviewers from seeing their own events. As above, reviewers can only view events where at least one participant was in their management group. However, under this model the search results also exclude any events in which the ‘logged-on user’ (that is, the reviewer) was a participant.

You can also include this model in a hybrid with a Policy model (see below).

Management Group (Sender)

Under this model, when a reviewer runs an e-mail search, they can only view events where the e-mail sender was in their management group when the event was captured.

Important! This sender-centric security model is only appropriate for e-mail searches. Searches for other event types will return zero results.

You can also include this model in a hybrid with a Policy model (see below).

Management Group (Sender, Self-Exclude)

This model prevents reviewers from seeing their own e-mails (or any other events) when they run a search.

As above, reviewers can only view events where the e-mail sender was in their management group. However, under this model the search results also exclude any events in which the ‘logged-on user’ (that is, the reviewer) was a participant.

You can also include this model in a hybrid with a Policy model (see below).

Policy (Standard)

This model ensures that reviewers can only see specific types of event. For example, this model can be used to ensure that HR reviewers only see events that relate to HR issues such as employee behavior, while Legal reviewers only see events that relate to legal issues such as litigation threats or a breach of attorney client privilege.

The model is based on policy classes. For categorization purposes, you can associate individual triggers with a policy class, such as ‘Employee Behavior’ or ‘Legal’. When a trigger fires, the policy class is stored with the associated event.

Likewise, each reviewer has a policy role. A policy role links a user to a collection of policy classes. In effect, the policy role determines which policy classes a user is permitted to see. When the user runs a search, the results only include events associated with these policy classes.

Before using this security model, you must define policy classes for triggers in your user policies, define your policy roles, and assign policy roles to your reviewers.

• Policy classes are described in the Policy Guide.
• Policy roles are described in the Administration Guide.

You can also include this model in a hybrid with a Management Group model (see below).

Policy (Standard, Self-Exclude)

This variant of the Policy model prevents reviewers from seeing their own events. As above, reviewers can see only specific types of event. However, the search results also exclude any events in which the reviewer was a participant

Before using this security model, you must define policy classes for triggers in your user policies, define your policy roles, and assign policy roles to your reviewers.

You can also include this model in a hybrid with a Management Group model (see below).

Policy (All Events, Restricted Triggers)

This variant of the Policy model allows reviewers to see any events in the CMS database when they run a search. That is, no events are excluded from the search results.

However, the reviewer can only see trigger and audit details for events covered by their policy role. Specifically, the Search Results screen only shows trigger and audit details for events associated with policy classes in the reviewer's policy role. If the search results include events associated with other policy classes, trigger and audit details for these events are hidden in the Search Results screen.

Before using this security model, you must define policy classes for triggers in your user policies, define your policy roles, and assign policy roles to your reviewers.

You can also include this model in a hybrid with a Management Group model (see below).

Hybrid Models: Management Group and Policy

If required, you can add a hybrid model on your CMS. This combines the Management Group and Policy models. Its effect is to restrict reviewers so they can only see specific types of event associated with users in their management group. For example, under this model a reviewer in the Legal team can only review legal events associated with members of their management group.

You can create hybrid models from any Management Group variant and any Policy variant. For example, you can create a hybrid from the 'Management Group (Self Exclude)' and the 'Policy (All Events, Restricted Triggers)' models. Here, a reviewer can only see events associated with users in their management group. But they cannot see events in which they were themself a participant and they cannot see trigger and audit details for events not covered by their policy role.

Before using this security model, you must define policy classes for triggers in your user policies, define your policy roles, and assign policy roles to your reviewers.

Unrestricted

This model is not subject to row level security (RLS). It permits reviewers to see any database items (events, users, triggers, and so on) when they run a database query. For example, Search results or reports are not restricted by policy class or the reviewer’s management group. This model is required by:

• CA DataMinder administrators. Paradoxically, this security model restricts the extent to which administrators can edit the CMS database. Specifically, it prevents administrators from inadvertently updating the CMS database when they exercise their 'Admin: Allow Unrestricted SQL Searches' privilege.
• CA DataMinder user accounts set up explicitly for use by external reporting tools that require full access when searching the Data Warehouse for events.

  Note: If the user of an external reporting tool is subject to row level security, CA DataMinder applies that user's security model (typically a Management Group model) when the user runs a report.

Note: You can only assign the Unrestricted security model to a CA DataMinder user if you have the 'Admin: Disable security model filtering' administrative privilege.

Important! Certain reports and the Review Queue are not designed for use with Policy security models. See the reference below for details.