BackOffice UserGuide
BackOffice UserGuide
(On-Premise) 7.1
Back Office Users Guide
Contact Information
Go to the RSA corporate web site for regional Customer Support telephone and fax numbers:
www.emc.com/domains/rsa/index.htm
Trademarks
RSA, the RSA Logo, eFraudNetwork and EMC are either registered trademarks or trademarks of EMC Corporation in the
United States and/or other countries. All other trademarks used herein are the property of their respective owners. For a list of
RSA trademarks, go to www.emc.com/legal/emc-corporation-trademarks.htm#rsa.
License Agreement
This software and the associated documentation are proprietary and confidential to EMC, are furnished under license, and
may be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice
below. This software and the documentation, and any copies thereof, may not be provided or otherwise made available to any
other person.
No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Any
unauthorized use or reproduction of this software and the documentation may be subject to civil and/or criminal liability.
This software is subject to change without notice and should not be construed as a commitment by EMC.
Note on Encryption Technologies
This product may contain encryption technology. Many countries prohibit or restrict the use, import, or export of encryption
technologies, and current use, import, and export regulations should be followed when using, importing or exporting this
product.
Distribution
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS
PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Copyright 20132014 EMC Corporation. All Rights Reserved. Published in the USA.
July 2013
Revised: March 2014
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Contents
Preface................................................................................................................................... 9
About This Guide................................................................................................................ 9
RSA Adaptive Authentication (On-Premise) Documentation ............................................ 9
Support and Service .......................................................................................................... 10
Before You Call Customer Support........................................................................... 10
Contents 3
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
4 Contents
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Contents 5
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
6 Contents
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Contents 7
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Preface
Preface 9
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Release Notes. Provides information about what is new and changed in this
release, as well as workarounds for known issues. It also includes the supported
platforms and work environments for platform certifications. The latest version of
the Release Notes is available on RSA SecurCare Online at
https://knowledge.rsasecurity.com.
Security Best Practices Guide. Provides recommendations for configuring your
network and RSA Adaptive Authentication (On-Premise) securely.
Web Services API Reference Guide. Describes RSA Adaptive Authentication
(On-Premise) web services API methods and parameters. This guide also
describes how to build your own web services clients and applications using web
services API to integrate and utilize the capabilities of Adaptive Authentication
(On-Premise).
Whats New. Highlights new features and enhancements in
RSA Adaptive Authentication (On-Premise) 7.1.
Workflows and Processes Guide. Describes the workflows and processes that
allow end users to interact with your system and that allow your system to interact
with RSA Adaptive Authentication (On-Premise).
10 Preface
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Report Viewer With the Report Viewer Security Analyst Back Office
application, you can view Database
daily, weekly, and monthly
reports created by the RSA
Data Center. Reports from
the RSA Data center are
synchronized with the Report
Viewer application for
accurate reading of the files.
Note: Fore more information about the Administration Console, see the
Operations Guide.
3. From the Organization drop-down menu, select the organization that you want to
view.
The organizations are displayed hierarchically, with child organizations listed
below parent organizations.
Note: By default, Back Office applications log off users who are inactive for 30
minutes. You can configure this time period in the Administration Console. For more
information, see the topic about configuring Back Office applications parameters in
the chapter Administration Console in the Operations Guide.
Password Change
When the system administrator defines a user password, the password is automatically
assigned an expiration date. This date is configurable in the Administration Console.
The default value is 90 days. For more information, see the Operations Guide. If you
attempt to log on to a Back Office application using an expired password, a window
opens in which you can define a new password. The new password is required for the
next logon attempt.
An administrator may change your password for any one of several reasons, for
example:
The administrator suspects that your password was compromised.
Your password is routinely changed for preemptive security reasons.
Note: You cannot access the Case Management application until you set a new
password.
Note: The system supports localization of the Back Office applications to one
language. You cannot use different languages for different users, organizations, or
applications.
Note: You can also use the External Identity Provider framework to manage users in
an External Identity Store. For more information, see the Operations Guide.
User Management
You can manage users and their ability to access the Back Office applications by
adding users, viewing user details, editing user details, unlocking users, and removing
users from the system. You use the Application Users page to perform tasks related to
user management. Users created in Access Management are not end-user customers,
but rather belong to an organization using the Adaptive Authentication system.
The following users are created by the system by default:
admin
Note: Do not use the admin user provided by the system as a regular user. RSA
recommends that you use the admin user to create additional admin users that you
can assign to people within your organization. You must maintain the system
admin user as a superuser.
editor
fraudanalyst
reviewer
You cannot remove these users from the system or edit user details, as indicated on the
UI.
A newly created user can be associated with any of the following:
Role. The level of authorization for a user. A role can be associated with one or
more module. Each role can be associated with different permissions. For more
information, including a definition of predefined roles in the system, see Role
Management on page 24.
Important: A user with an assigned role can only access a Back Office application
if the role is also associated with the corresponding module. Predefined roles are
automatically associated with corresponding modules. The modules available
correspond to the Back Office applications. For a list of modules associated with
each role, see Access Management Roles on page 28.
Important: Users cannot change their own permissions using the Access Management
application.
Important: If a user does not log on immediately after installation, RSA recommends
that the administrator change the default password to prevent security breaches.
Organizations Lists all of the organizations to which the user has access.
Modules Lists the RSA Back Office applications that the user has permission to
use.
Action Contains links to the View, Edit, and Remove pages, depending on the
users permissions:
View. View all user details (read-only).
Edit. Edit all user details.
Remove. Remove user names from the system.
Add a User
You add a user in the Access Management application to create a user who can access
the Back Office applications.
Note: On the initial logon to the system, a new user is required to change the default
password.
To add a user:
1. On the Application Users page, click Add New User.
The User Details page is displayed.
2. In the Add User Details section, enter the user details.
The following table describes the actions required for each of the fields in the Add
User Details section.
User Name Enter a unique name for the user. This is a required field.
Note: A user name must be unique. You cannot enter a user name
that is identical to an existing user name.
Locked At Indicates lock out details, including the lock-out time, for a user
who repeatedly enters an incorrect password and exceeds the
allowed number of authentication attempts.
3. In the Organizations section, from the Available list, select the organizations to
which you want the user to have access, and click the right-arrow to include them
in the Selected list.
For more information about Organizations, see Organization Management on
page 33.
4. In the Roles section, from the Available list, select the roles that you want to
assign to the user, and click the right-arrow to include them in the Selected list.
5. Click Save.
3. From the Available lists, select the organizations and roles that you want to
associate with that user, and click the right arrow to move the selections to the
Selected lists.
4. Click Save.
Unlock a User
If a user attempts to log on, but access is locked, an administrator must reset the user
password. Resetting the password unlocks the user immediately. If the administrator
user does not change the password, the lock-out is released after a set period of time,
and the user can try to log on again.
Note: The default time frame is 30 minutes, but you can configure this time in the
Administration Console. For more information, see the section about configuring
Back Office applications parameters in the Operation Guide.
Remove a User
If a user can be removed from the system, the Remove link is displayed in the user
interface. The Remove link is not displayed for predefined users.
To remove a user:
1. On the Application Users page, in the row for the user that you want to remove,
click Remove in the Action column.
2. When prompted to confirm the removal, click OK.
Role Management
Each user is assigned a role, and each role is associated with different permissions.
You can manage the various Back Office user roles by adding roles, editing roles, and
removing roles from the system. You use the Application Roles page to manage roles.
For more information on system roles, see Access Management Roles on page 28.
For a user to access a Back Office application, you must assign the user one or more
roles. Each role is associated with one or more modules. In the Access Management
system, a module represents one of the Back Office applications.
A user with an assigned role can only access a Back Office application if the role is
also associated with the corresponding module. By default, roles are associated with
their corresponding modules.
In general, a user only sees interface elements that relate to the specific permissions
assigned to the user. For example, if a user has PolicyManager permissions but does
not have ListManager permissions, the user sees the Manage Lists screen but does not
see the buttons used for creating and deleting lists or the blue hyperlinks used to edit
lists. Similarly, a user without permissions related to the Policy Management module
does not see the Policy Management tab in the Back Office Application Suite.
Note: The spelling of the role names in the user interface do not include spaces. For
example, the fraud analyst role is written as fraudanalyst, and the operator manager
role is written as operatormanager.
Role Details
The Roles table displays all of the roles in the system and the related details. The
following table describes the columns displayed in the Roles table.
Role Name Name of a role in the system (both predefined and user-created roles).
Sortable column.
Description Description of the role, such as what a user with the role is allowed to
do within the system.
Mode Permissions associated with that role. Modes include create, read,
update, and delete. The checkbox for a mode is selected if the mode is
allowed for the role. Sortable column.
Important: The modes available are only relevant for roles used within
the Access Management application.
Modules Lists the Back Office applications that the role has permission to use.
Action Custom roles contain View, Edit, and Remove links in this column.
Predefined roles contain the View link in this column.
Add a Role
You can create a role to associate a group of users with a given set of permissions.
When you add a role in the Access Management application, you are creating a role
within the Back Office applications.
To add a role:
1. On the Applications Roles page, click Add New Role.
The Role Details page is displayed.
2. In the Role Name field, enter a unique name for the new role.
3. (Optional) In the Description field, enter a description of the role.
4. In the Mode section, select one or more checkboxes to define the permissions for
the role. The possible permissions are Create, Read, Update and Delete.
Note: The Create, Read, Update, and Delete parameters in this section only affect
role permissions for the Access Management application.
5. In the Modules section, from the Available list, select one or more modules.
6. Click the right-arrow to move the modules into the Selected list.
7. Click Save.
Remove a Role
You can remove a role from the system if you do not need the role anymore. After you
remove a role, the role no longer appears in the Roles list. You cannot remove
predefined roles from the system.
Important: Removing a role from the system may limit the ability of current users to
access certain Back Office applications. If a current user is assigned a role, and then
that role is deleted, the user will no longer have the permissions associated with the
deleted role.
To remove a role:
1. On the Application Roles page, from the Roles list, select the role that you want to
remove.
2. In the Action column, click Remove.
3. In the confirmation message, click OK.
Important: A user with an assigned role can access a Back Office application only if
the role is also associated with the corresponding module. By default, roles are
associated with the corresponding modules.
csr A user with this role can view and update activities in the csr
(Customer Customer Service application, and can view the Lookup User casemanagement
Support page in the Case Management application. A user with the csr
Representative) role can handle user calls, view recent activities of a user to
troubleshoot the user problem, and search all users, not just
those with cases.
For more information on the specific permissions associated
with this rule, see Case Management Role Permissions on
page 31.
CMAPIExtract A user with this role can retrieve and view Case Management casemanagementAPI
data concerning events (activities) and cases.
CMAPIUpdate A user with this role can retrieve, view, and update Case casemanagementAPI
Management data concerning events (activities) and cases. With
this particular role, a user can lock data retrieved for update
purposes.
fraudanalyst A user with this role can research and analyze fraud patterns to casemanagement
define antifraud strategies, and verify whether cases include
fraudulent activity.
For more information on the specific permissions associated
with this rule, see Case Management Role Permissions on
page 31.
ListManager A user with this role can view, edit, and delete lists. A List PolicyManagement
Manager user can view rules, custom facts, and custom event
types but cannot create, edit, or delete these objects.
Note: A user with this role can only edit lists if the user has
access to the default organization.
operator A user with this role can review, work with, and manipulate casemanagement
cases in the Case Management application. A user with the
operator role can search for a relevant case, update a case, and
move to the next case. A user with this role might have specific
expertise, such as with account takeover fraud.
operatormanager A user with this role can supervise activity in the Case casemanagement
Management application, and perform the following actions:
Manage operators
Supervise case reviews performed by operators
Audit an operators work queue to increase productivity
Override operator decisions in cases
Define custom sorting and case filtering
Divide operators logically rather than randomly
PolicyManager A user with this role can create, edit, and delete rules, custom PolicyManagement
facts, and custom event types. A user with the PolicyManager
role can approve a status change made to a rule by another user.
A user with the PolicyManager role can also view lists but
cannot create, edit, or delete lists.
Note: Only a user with the PolicyManager role who has access
to the default organization can create, edit, or delete custom facts
or custom event types.
PolicyViewer A user with this role can view rules, custom facts, custom event PolicyManagement
types, and lists.
For more information on the specific permissions associated
with this rule, see Policy Management Role Permissions on
page 32
RuleManager A user with this role can create, edit, and delete rules, custom PolicyManagement
facts, and custom event types but cannot approve pending rules.
Note: Only a user with the RuleManager role who has access to
the default organization can create, edit, or delete custom facts
or custom event types.
This user can view lists but cannot create, edit, or delete them.
This user can submit a request to change the status of a rule, but
a PolicyManager or SeniorPolicyManager user must approve
the request before the status change occurs.
For more information on the specific permissions associated
with this rule, see Policy Management Role Permissions on
page 32.
SeniorPolicy A user with this role can create, edit, and delete rules, custom PolicyManagement
Manager facts, and custom event types, as well as approve all pending
rules. A user with this role can approve a status change made to
a rule by another user, and can also perform self-approval on
status changes made to a rule. This user can view lists but
cannot create, edit, or delete lists.
Operator Fraud
Permission Admin Operator CSR
Manager Analyst
Process X X X X
Queue
Lookup User X X X X X
View the X X X
Queue
Operator Fraud
Permission Admin Operator CSR
Manager Analyst
Manage X X
Operator
Group
Manage X X
Operator
Research X X X X
Activities
Important: Some permissions are available only to users that are granted access to the
default organization.
Policy
Policy Manager /
Policy Rule List
Manager / Senior
Policy Viewer Rule Manager List Manager
Permission Senior Policy
Viewer (Default Manager (Default Manager (Default
Policy Manager
Org) Org) Org)
Manager (Default
Org)
View Rule X X X X X X X X
Edit Rule / X X X X
Request
Status Change
Approve X X
Status Change
(for Others)
View Custom X X X X X X X X
Fact
Edit Custom X X
Fact
View Custom X X X X X X X X
Event Type
Edit Custom X X
Event Type
Policy
Policy Manager /
Policy Rule List
Manager / Senior
Policy Viewer Rule Manager List Manager
Permission Senior Policy
Viewer (Default Manager (Default Manager (Default
Policy Manager
Org) Org) Org)
Manager (Default
Org)
View List X X X X X X X X
View List X X X X
Content
Edit List X
Import / X
Export
Create Policy X X X X X X X X
Report
Duplicate X X
Rule
The following conditions also apply to the Policy Management role permissions:
A user with the SeniorPolicyManager role can also perform self-approval on
status changes made to a rule.
Only a user with access to the default organization can view the
Last Modified By and Created By fields in the Manage Lists, Manage Custom
Facts, and Manage Custom Event Types pages.
Any role that is associated with the PolicyManagement module receives the same
permissions as the PolicyViewer role. A user with this role can view rules, custom
facts, custom event types, and lists and can also create policy reports.
Organization Management
Each organization consists of a collection of users. An organization can also have
multiple groups. You can manage organizations by adding organizations, viewing
organizational details, and editing organizational details. You use the Application
Organizations page to display and manage all of the organizations that exist in the
system.
The hierarchy of organizations in the Access Management application and in the
Adaptive Authentication system is defined as follows:
An organization identifies any user who belongs to the organization.
A user of the Back Office applications is identified by a unique user name. This
uniqueness allows a user to belong to more than one organization.
An end user is identified by a user name and organization. Two end users with the
same user name can belong to different organizations.
Organizations can include suborganizations. The organization is the parent and
each sub-organization is a child in the system hierarchy.
An organization cannot be deleted from the system. All organizations are stored in
the database.
An organization can only be viewed by a user who has access to that organization
or its parent organizations. A user with access to the default organization, can
view all organizations.
Add an Organization
When you add an organization in the Access Management application, you create a
organization within the Adaptive Authentication system. After an organization is
created in the system, you cannot remove the organization. You cannot edit the name
of an organization. After you create an organization in the system, you cannot change
the name. Only the organization description and parent can be changed.
To add an organization:
1. On the Application Organizations page, click Add New Organization.
The Organization Details page is displayed.
Note: If you attempt to create a loop in the hierarchy, for example, an organization
is both a child and parent of the same organization, an error message appears and
the organization is not saved.
Important: If you change the parent of the organization, it may take up to five
minutes for the change to be reflected in the system.
3. Click Save.
Group Management
A group is a subunit of an organization. Groups provide a way of further organizing
end users within organizations. You can create a hierarchy of groups, but all groups in
a hierarchy must belong to the same organization.
Groups in the Access Management application relate to the Adaptive Authentication
system as follows:
There is no default group.
An end user can belong to any group within an organization.
An end user can be moved from one group to another within an organization.
An end user in a specific organization cannot belong to more than one group.
Any user with roles that allow read, write, or create in the Access Management
application is permitted to correspondingly view, edit, or add groups.
Organization Name of the organization to which the group belongs. Sortable column.
Name
Group Parent The parent of the group in the group hierarchy. Sortable column.
Action Lists the actions that the user is permitted to perform. A link for each
available action is provided.
Add a Group
You can add a group to organize end users within an organization. The Group Name
and the Organization Name together serve as a unique key.
To add a group:
1. At the bottom of the Application Groups page, click Add New Group.
2. On the Group Details page, in the Add Group Details section, do the following:
a. In the Group Name field, enter a name for the group.
Note: If you create a loop in the hierarchy, for example, if a group is both a parent and
a child of the same group, an error message appears.
Important: If you change the parent of the group, it may take up to five minutes
for the change to be reflected in the system.
3. Click Save.
3 Managing Policies
Introduction to Policy Management
Introduction to Rules
Rule Management
Policy Export and Import
List Management
Custom Facts Management
Custom Event Type Management
Policy Report
The Policy Management application helps organizations create a risk-management
policy in line with the unique security needs of the organizations. Well-defined
policies help prevent harmful, fraudulent activity and keep the number of false
positives to a minimum. Each policy contains a set of rules that define actions that
take place in specific circumstances. For more information, see Introduction to Rules
on page 41.
The Policy Management application acts as an additional security layer on top of the
Risk Engine, which provides the core functionality of determining the risk level of a
given event. The Policy Management application uses the Risk Engine, along with
other data, and allows you to define a policy based on this data. The rules that you
create in your organizational policy are loaded into the Policy Engine of the Policy
Management application, which then executes the policy.
3: Managing Policies 39
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
You can create an organization in the Access Management application. For more
information, see Organization Management on page 33. When you create an
organization, a blank policy is automatically created to correspond with the
organization. You can base the policy of a newly created organization on that of an
existing one by duplicating rules from another organization. For more information, see
Duplicate Rules to Another Organization on page 62.
Reference Policy
The Adaptive Authentication system includes a default reference policy that you can
import into the Policy Management application. You can use the reference policy as a
starting point for constructing the policy for your organization.
The reference policy includes a predefined set of rules that are based upon both
sign-on and transaction event types. The rules in the reference policy cover a broad
range of end-user event types and protect against common fraud risks. For more
information about the rules that make up the reference policy, see Appendix B, Rules
in the Reference Policy.
The rules in the reference policy are both risk-based and device-based. Risk-based
rules rely on data taken from the Risk Engine, while device-based rules rely on device
matching and data taken from end-user devices. Risk-based rules can be activated
only after the necessary Risk Engine learning period. Before the learning period is
over, the risk score is not consistent and may not reflect end-user behavior for the
specific customer population. For more information, see Risk Score on page 48.
The rules in the reference policy have a status of Work in Progress. To activate the
rules, you must change the status of the rules to either Test or Production. For more
information, see Status Change on page 50.
Rules in the reference policy with an action of Challenge are assigned the following
Authentication Methods, in order:
OOB PHONE
OOB SMS
KBA
QUESTION
Note: You must configure Authentication Methods before the methods are applied to
end users. For more information, see the Operations Guide.
Note: Depending on your organizational policy needs, RSA recommends that you
consider importing the reference policy after product installation. The rules in the
reference policy help protect against many common fraud risks. After you import the
reference policy, you can add rules and edit or delete rules as you see fit.
40 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Policy Refresh
The policy refresh process seamlessly implements changes made to a policy in the
production environment, without the need to restart the application servers. The
Adaptive Authentication system polls the Policy Management Database to check for
policy revisions every sixty seconds.
Types of policy revisions that trigger the policy refresh process include the creation of
any rules or lists, changes made to any rules (edit, delete, or status change) or lists
(edit, delete, or update values), duplication of a policy, and import of a policy. For
more information on rule status changes, see Status Change on page 50.
A policy is loaded to the Policy Engine if both of the following conditions are met:
Revisions have been made to the policy after the current version was loaded to the
Policy Engine.
The status of the revised rule is, or was, Production or Test.
For more information on the policy refresh process, see the Operations Guide.
Note: A policy refresh impacts the data that is available in a Policy Report. For more
information, see Generate a Policy Report on page 80.
Introduction to Rules
A rule contains an event type, a condition or set of conditions, and an action. The
action is triggered by an event when the condition or conditions are met. For example,
a Deny action can be triggered for the Sign In event type, if the Risk Score is above
900.
A rule also contains other details, such as the name of the rule and the status of the
rule. For more information about these rule details, see General Rule Parameters on
page 58.
You can assign a priority to each rule, and the rules are checked in the order of their
priority. The lower the number, the higher the priority. For example, a rule with a
priority of 3 is checked before a rule with a priority of 5. After one rule is found to be
true, the action is triggered, and the system stops checking the rules with lower
priority.
3: Managing Policies 41
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
It is possible that no production rules will be activated when an end user performs a
certain event. This may occur if an organization does not have any rules in its policy
or if none of the existing rules are triggered. In such a case, a default, fallback rule is
activated. When the fallback rule is activated, the Allow action is triggered. For more
information, see Actions on page 47.
Event Types
An event type is an end-user activity that is protected by the Adaptive Authentication
system. An event type triggers a rule when the conditions associated with the rule are
met. For example, if the event type is Payment, the selected rule will apply when the
end user makes a deposit online.
The Adaptive Authentication system is shipped with a predefined list of event types.
For more information, see Appendix C, List of Event Types. In addition to event types
in this predefined list, you can create custom event types. For more information, see
Custom Event Type Management on page 75.
Note: A single rule can be applied to multiple event types. In this situation, if any of
the events occur and all the conditions are met, the rule is triggered.
Conditions
Conditions are built from the following logical elements:
Expressions
Facts
Operators
A condition is a set of logically defined expressions that must be fulfilled for the
action of a rule to be triggered. Each rule can contain multiple conditions, which are
connected to each other by the AND operator. If all conditions are true, the rule is
triggered and the defined action is performed. For more information, see Expressions
on page 44.
Each condition consists of at least one expression. Multiple expressions within a
condition can be logically connected to each other by the OR or AND operators. For
more information, see Operators on page 44.
42 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
The following figure shows the logical workflow of a condition after an event is
performed.
Event
Event performed as
defined in rule
Is expression within
Yes No
condition true?
No
Condition
OR OR
AND AND
operator No operator
operator operator
(default) (default)
Condition is Condition is
not met not met
Does another
condition exist within
this rule?
No
Action
The following example shows the various components that can make up a condition.
The sample expression represents the number of days that have passed since the
account was opened:
Expression: IF days since end user changed the address is Equal to 5
Category: Account Details
Fact: # of Days Since Last Address Change (Integer)
3: Managing Policies 43
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Operators: Equal to
Value: 5
Expressions
An expression is the basic building block of a condition and can be thought of as the
first half of an If-Then conditional statement. The action is the second half. If the
expressions within a condition are true, then the action is performed.
Expressions can be made up of logically connected facts, operators, and values.
Several expressions can be combined with the operators OR or AND.
Facts
A fact is a core data element that the Policy Engine processes to determine if the rule
is triggered. A fact might contain information about the device, the end user, or the
end-user activities.
Examples:
Change from previous risk score.
Whether or not Java is disabled.
The city's IP city code.
The Adaptive Authentication system is shipped with a default fact list. For more
information, see Appendix A, List of Facts. In addition to default facts, you can create
custom facts. For more information, see Custom Facts Management on page 72.
Categories
Facts are grouped into categories for accessibility purposes. For example, the Risk
Score category groups facts that relate to the risk score of the current event, such as
Transaction Risk Score and Change From Previous Risk Score.
Values
A value is a quantifiable attribute of a fact that defines the situation during which a
rule is triggered. Values are divided into the following categories:
Technical. For example, the contents of a predefined list.
Numeric. For example, the Risk Score.
Boolean. For example, whether the device IP is different from the event IP (A true
or false value).
Operators
An operator is a logical or mathematical function that connects multiple data
elements. Operators can be used to define fact values, to connect multiple expressions,
and to connect multiple conditions.
44 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Fact Operators
The following operators can be used when defining fact values.
Equals Boolean
Country
Double
ENUM
Float
Integer
IP Address
Long
Risk Score
String
Empty Country
ENUM
String
3: Managing Policies 45
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Between Double
Float
Note: Between specifies a
Integer
range of values that includes
the range boundaries. A value IP Address
between x and y is greater Long
than or equal to x and less Risk Score
than or equal to y.
Within String
User ID
Note: The relevant operators will differ from fact to fact. The Within and Not Within
operators are relevant only for the List category.
Expression Operators
The following operators are available for use between expressions.
Operator Description
46 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Condition Operator
The following operator is available for use between conditions.
Operator Description
Actions
An action is a predefined outcome that occurs when the condition is fulfilled and the
rule is triggered. Actions are performed only if the rule status is Production. For more
information, see Rule Status on page 49.
Only one action can be defined for each rule. The exception to this is the Review
action, which can be set to generate a case together with another action.
The following table describes the different action types. To configure these
parameters, see General Rule Parameters on page 58.
Challenge Request that the end user authenticate by selecting Manually (When
one of the authentication methods. authentication fails,
For more information, see Authentication Methods succeeds, or in both
on page 47. situations)
The Rule Manager can select whether a case is
created in Case Management if authentication
succeeds or fails.
Deny Deny the end user access to the system or deny the Manually
transaction.
Authentication Methods
You can use authentication methods to challenge end users to perform an action that
verifies their identity before they are allowed to continue. These methods are used in
high-risk situations to prevent fraudulent activity. The particular challenge method
used depends upon which rule is triggered. The end user must successfully pass the
challenge to continue with the current activity.
The following authentication methods are available in the Adaptive Authentication
system:
Knowledge-Based Authentication (KBA). The end user is asked a series of
personalized questions based on available data sources.
3: Managing Policies 47
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Note: You can configure existing authentication methods using the c-config-mcf.xml
file. For more information, see the Operations Guide.
You can install additional authentication methods for use in the Adaptive
Authentication system. For more information, see the Authentication Plug-in
Developers Guide.
After you install additional authentication methods, you can add these methods to the
list of methods available in the Policy Management application. You can do this using
the Authentication Methods parameter located in the Authentication Methods
component of the Administration Console. You can also use this parameter to remove
existing, built-in authentication methods from the list that appears in the Policy
Management application. For more information, see the chapter Configure
Authentication Methods in the Operations Guide.
When you select the Challenge action, you can define which method is used to
challenge the end user. You can select and prioritize multiple methods from the
available list. The system selects the first available method relevant for the end user.
The end user can only be challenged using authentication methods for which the end
user is registered.
For example, if SMS, email, and Phone are selected as Authentication Methods with
SMS having highest priority, email second priority, and Phone lowest priority, an end
user who is not registered for SMS is challenged with the email method.
Risk Score
Risk Score is one of the fact categories that you can use to create a rule in the Policy
Management application. The RSA Risk Engine evaluates each online activity,
tracking over one hundred indicators to detect fraudulent activity. The Risk Engine
produces a unique risk score, between 0 and 1,000, for each online activity. The higher
the risk score, the greater the likelihood that an activity is fraudulent.
48 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
You can use the risk score to understand the risk level of an activity in relation to all
end user activities. For example, if you choose to challenge any activity with a risk
score greater than 900, you can expect 0.25 percent of all activities to be reviewed.
This information also helps you estimate the number of cases that operators need to
process.
Risk-based rules should only be promoted to Production status after the necessary
Risk Engine learning period. Until this period has finished, the risk score is not stable
and may not be entirely accurate. During the learning period, you can run risk-based
rules with a status of Test in order to examine the potential results of your policy.
Note: If you upgrade from a previous version of Adaptive Authentication, you can
continue to use risk-based rules without waiting for the Risk Engine learning period to
finish.
For more information, see the section about Risk Engine Parameters in the Operation
Guide.
Case Creation
You can flag a transaction for review by creating a case. When a transaction is
flagged, a case is created in the Case Management application when the rule is
triggered.
The Create Case feature performs the same action as the Review action but can be
applied in addition to the actions that you apply to a rule. Creating a case is optional
and does not need to be applied.
If you select the Challenge action, you can choose to create a case when the end user
passes authentication, fails authentication, or in both situations.
For more information, see Chapter 4, Managing Cases.
Rule Status
You can assign one of the following statuses when creating a rule:
Work in Progress. The rule does not run on production data.
Test. The rule runs on production data, but no action takes place (except for the
option to create a case). Statistics are collected to analyze the effectiveness of test
rules. When a rule is triggered, the activity is recorded in the database.
Production. The rule runs on production data and actions take place.
In addition, the following status can also apply to rules:
Suspended. The rule was recently running on production data (had a status of Test
or Production) but was suspended for some reason.
To properly manage a policy, you can test rules before you put the rules into
production. This testing allows you to view the potential results of a newly created
rule without directly affecting the end-user activity. After a rule has been sufficiently
tested and appears stable, you can move the rule to production, where the rule is fully
implemented.
3: Managing Policies 49
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
While a rule has a status of Test, it is still triggered if it has a higher priority than a rule
with a status of Production. In such a situation, the action of the rule in production is
triggered in addition to any case created by the rule.
Status Change
Before the rule status can be changed, some rules require the approval of a user with
PolicyManager or SeniorPolicyManager permissions. For more information on rule
statuses, see Rule Status.
The following figure shows the possible status changes that can be made for rules.
The following table lists all status changes that require the approval of a user with
PolicyManager or SeniorPolicyManager permissions.
Test Production
Test Suspended
Production Suspended
Production Test
50 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Suspended Production
Suspended Test
If you want to change the status of a rule, you must first submit a status change
request. If the status change requires approval, the pending status of the rule reflects
the status that you requested. A user with sufficient permissions must approve the
status change request for the current status to change. If the rule does not require
approval, the current status is changed immediately.
Each rule has an indication of the current and pending state of the rule, as follows:
Current Status. The status that the rule has right now.
Pending Status. The status that will be applied to the rule if a status change
request is approved by a user with sufficient permissions.
You cannot edit or delete a rule with a status of either or Production, or any rule that
has a pending status. To edit or delete such a rule, you must first change the status to
either Suspended or Work in Progress.
Rule Management
You can use the New Rule wizard to create rules. After you create and save a rule, the
rule appears in the Manage Rules table. You can manage rules using the Manage Rules
table.
3: Managing Policies 51
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
You can use the toolbar at the top of the table to perform relevant policy actions, such
as adding a new rule or exporting a policy. After you create and save a rule, it appears
in the Manage Rules table. After you delete a rule, the rule no longer appears in the
Manage Rules table.
You can also use the table to easily select and manage existing rules. After you select a
rule, you can edit or delete the rule. When you select a rule from the Manage Rules
tables, a detailed summary of the rule appears in the section under the Manage Rules
table.
Note: Only the last comment is displayed. If there are multiple comments, you can
click the hyperlink to view all comments.
Note: You can use your mouse to hover over X items found on the toolbar to see a
breakdown of the number of rules according to the current status.
52 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
You can filter rules by Event Type, Current Status, Pending Status, and Action, using a
checkbox to select the field or fields that you would like to view. For example, you can
use the filter in the Action column to view only those rules that have Deny as the
action.
You can rearrange the columns on the Manage Rules table by dragging and dropping a
column to another location.
Add a Rule
You can add a rule to define what action the Adaptive Authentication system takes
during online transactions. You can use the New Rule wizard to define and create
these rules. Each rule dictates an action to be taken for a particular end-user behavior.
To add a rule:
1. Click the Manage Rules link in the Policy Management application.
2. Click New > New Rule.
3. Complete the fields on the General page. For a description of each field, see
General Rule Parameters on page 58.
4. Click Next.
5. On the Conditions page, do the following:
a. From the Category drop-down list, select a category.
Note: The data in the Fact and Operator drop-down lists changes according
to the category selected. The order of the two lists varies according to the
category selected. The Operator list might appear before the Fact list.
3: Managing Policies 53
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
e. (Optional) To add a new expression, click Add New Expression, and repeat
steps a through d.
To define how multiple expressions are connected to each other, from the Join
Multiple Expressions by drop-down list, select AND or OR. The selected
operator will apply to all expressions within the condition.
f. (Optional) To remove an expression, click Remove expression.
Each condition must contain at least one expression. You can only remove an
expression if there are at least two expressions.
g. (Optional) To duplicate an expression, click Duplicate.
When you duplicate an expression, all the fields are copied except the value
field or fields.
h. (Optional) To add a new condition, click Add New Condition, and repeat
steps a through e.
6. Click Next.
7. On the Actions page, do the following:
a. From the Action drop-down list, select an action.
For a description of the available actions, see Actions on page 47.
54 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Note: If you select Challenge, two checkboxes appear, which allow you to
create a case when authentication fails or when it succeeds. Select the
appropriate checkbox.
8. Click Next.
9. Review the rule details on the Summary page. To edit any part of the rule, click
Edit at the top right of the section that you want to change.
10. Click Finish.
3: Managing Policies 55
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
The following operators are not supported by the Comparison of Policy Facts
enhancement:
Between
Not Between
Within
Not Within
Is Empty
Compare Facts
You can use the Rule wizard to compare facts within rules that you create.
To compare facts:
1. Select a source category from the Category drop-down list.
2. Select the source fact from the Fact drop-down list.
3. Select a fact comparison operator from the Operator drop-down list.
Note: This selection determines if the purpose of the rule is to compare facts. The
Rule wizard utility adjusts the user-interface accordingly.
56 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Edit a Rule
You can edit a rule to change any of the details. All rule fields are available for editing.
To edit a rule with a status of or Production, you must first change the status to Work
in Progress or Suspended. For more information, see Status Change on page 50.
To edit a rule:
1. Click the Manage Rules link in the Policy Management application.
2. In the Manage Rules table, click the Rule Name of the rule that you want to edit.
The Summary page is displayed.
3. Click Edit at the top right of the section that you want to change.
4. Change the section as necessary.
Use the Next and Back buttons to navigate between sections, or click the section
links at the top of the screen (General, Conditions, Actions, and Summary).
5. Click Save & Exit to save your changes and return to the Manage Rules table.
3: Managing Policies 57
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Delete a Rule
You can delete a rule to remove the rule from the system and prevent the rule from
functioning. When you delete a rule, the rule is no longer available in the Manage
Rules table.
To delete a rule:
1. Click the Manage Rules link in the Policy Management application.
2. Select the checkbox of the rule or rules you want to delete.
3. Click Delete.
Rule Name Unique name that you assign to the rule. The rule name is unique Yes
per policy. An informative name, for example, Challenge
Forbidden IP Address, can help to quickly locate the rule and
understand the purpose of the rule.
The maximum length of rule names is 80 characters. You can use
special characters in the rule name.
Status The current status for this rule. The following options are Yes
available:
Work In Progress. The rule can be edited but is not running
on production data.
Test. The rule is running on production data, and cases can be
created, but no action takes place.
Production. The rule is running on production data, and all
actions take place.
Any rule assigned a status of Test or Production is initially saved
with a status of Work In Progress. After a user with
PolicyManager or SeniorPolicyManager permissions approve
the status change, the rule will reflect the originally assigned
status.
58 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Event Type The type of end-user activity that triggers a rule when all rule Yes
conditions are met.
In addition to predefined event types, custom event types appear
in this list, marked with an icon.
You can select one event type or several event types.
Order The priority assigned to a rule, indicating the order in which the Yes
rule is triggered. A lower number represents a higher priority and
a higher number represents a lower priority. When a production
rule is triggered, all rules with a lower priority will not be
triggered.
The default value for this field is one position lower than the
lowest-ordered existing rule. For example, if the lowest-ordered
existing rule is 8, the default value is 9. To add a rule as last in
line, leave the default value that is displayed in the field. If you
choose a value currently assigned to an existing rule, the existing
rule and all lower-ordered rules are moved one priority level
lower. For example, if you assign a priority of 5 to a rule, the
existing rule with a priority of 5 is assigned a lower priority of 6,
and similarly with all other rules.
The Available Range values represent the possible values that
you can assign to the rule. The highest value in the range of
values is automatically assigned as the order of the rule.
The Policy Engine receives and evaluates only rules with a status
of or Production. A rule with a status of Work in Progress is not
sent to the Policy Engine. In such a case, the Policy Engine
checks the relative order of the remaining rules. For example, if
there are three rules in the system, and the rule with an order of 2
has a status of Work in Progress, the Policy Engine receives only
the rules with orders of 1 and 3 and will assign the latter rule a
lower priority.
3: Managing Policies 59
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Note: You can cancel only one status change request at a time.
60 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Note: A user with PolicyManager permissions can approve the status of a rule only if
the request was made by another user. A SeniorPolicyManager can approve all status
change requests.
Note: A user with PolicyManager permissions can reject the status of a rule only if the
request was made by another user. A SeniorPolicyManager can reject all status change
requests.
3: Managing Policies 61
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Important: Do not make any changes to the policy while you perform the duplicate
action.
Note: After the completion of the duplicate process, a policy refresh occurs. The
duplicated rules are immediately activated in the target organization, and the rule
status of all rules remains the same. Policy data that existed before the duplicate
action is removed from the database and will not appear on a Policy Report. For
more information, see Policy Refresh on page 41.
62 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
3: Managing Policies 63
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
To export a policy:
1. Click the Manage Rules link in the Policy Management application.
2. Click Export Policy.
The Export Policy dialog box displays the location of the export directory.
The name of the exported file is aaboPolicyExportFile_<time>.xml, where
<time> is the date and time that you performed the export.
A checksum file is also created during the export process, named
aaboPolicyExportFile_<time>.xml.md5, to ensure the integrity of the exported
file during the import operation.
Note: The values contained in any hashed lists remain hashed. Otherwise, the
exported file is a readable XML file.
3. Click Export.
Important: To access the imported data, the new environment must contain the same
organizations that existed in the original environment. If an organization does not
exist, you cannot access the policy data of that organization. When you import all
policy data, a policy refresh occurs. Policy data that existed in the new environment
before the import is removed from the database and will not appear on a Policy
Report. For more information, see Policy Refresh on page 41.
To import a policy:
1. Click the Manage Rules link in the Policy Management application.
2. Click New > Import Policy.
3. In the Import Policy dialog box, enter the filename that you want to import.
64 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Important: When you import all policy data, you replace the existing policy data
for all organizations.
List Management
A list is a fact category that groups together facts of a specific type. You can use lists
to define which countries, IP addresses, end users, and strings are considered
malicious, safe, or suspicious. After you create lists, you can use the lists to build
conditions in the New Rule wizard. You can either use the predefined lists or create
custom lists.
When you create a new lists in the system, the list will be available to all
organizations, and not only for the organization that it was created for. If you add or
delete a list, or change values in a list, it will affect all organizations that have rules
which use that list.
All facts in a list must have the same type of value, known as a List Type. For
example, all facts in the IP on VIP List must have a List Type of IP Address. This
means that all fact values in this list must be in the form of a valid IP address.
The following List Types are available:
Country
IP Address
String
User ID
After you create and save a list, the list appears in the Manage Lists table. You can
manage lists using the Manage Lists table. For more information, see Manage Lists
Table on page 66.
3: Managing Policies 65
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
You can use the menu items at the top of the table to perform relevant policy actions,
such as adding a list. You can also use the table to edit lists. You can perform the
following actions from the Manage Lists table:
Add a List
Edit a List
Delete a List
List Summary
When you select a list from the Manage Lists table, a detailed summary of the list
appears in the section below the Manage Lists table. The summary section contains
the list name, the creator of the list, and the date modified, along with the information
described in the following table.
66 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Note: The information you see in the summary section depends on your role
permissions. For more information, see Role Management on page 24.
Element Description
List Content A table that lists all the values in the list.
Value
Organization (User ID only)
Last Modified By
Date Modified
Related Rules A table that lists all the active rules that use the list in one of the
conditions.
Add a List
You add a list to categorize a group of fact values together. You can then create rules
based on these lists.
3: Managing Policies 67
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Note: When entering values in a list of countries, use the two-letter code specified by
the ISO 3166 standard. These values are case-sensitive, and need to be capitalized.
68 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Important: You can choose to either add the imported values to the existing list
values or replace all existing content with the imported values.
3. Click Import.
4. (Optional) To delete values, select the checkboxes of the values that you want to
delete, and click Delete.
5. Click Save.
3: Managing Policies 69
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Edit a List
You can edit a list to change list details and revise or add new content. All list fields
are enabled for editing except for the List Type field. While you are editing a list, the
list is locked for editing, and no other user can edit the list.
To edit a list:
1. Click the Manage Lists page in the Policy Management application.
2. From the Manage Lists table, in the List Name column, click the list that you want
to edit.
3. In the List Details section, edit the details as necessary.
For a description of each field, see General List Parameters on page 71.
4. In the List Content section, do one of the following:
Edit a single value or range of IP values:
a. In the Value column, click the value or range of values that you want to
edit.
b. In the Edit Value dialog box, enter the new value or values, and click
Update.
If you are editing a range of IP values, you can use either IPv4 or IPv6
values. However, both the From and To values must be the same IP
version.
c. Repeat these steps for any additional values.
(Optional) Add a Single Value to a List.
(Optional) Add a Range of IP Values to a List.
(Optional) Import a Set of Values to a List.
(Optional) To delete values, select the checkboxes of the values that you want
to delete, and click Delete.
5. Click Save.
Delete a List
You can delete a list to completely remove the list from the Manage Lists table. A
deleted list is not available when you are using the New Rule wizard or editing a rule.
You cannot restore a list that is deleted from the system.
You cannot delete a list that is currently being used in a rule. You cannot delete
multiple lists if any of the lists marked for deletion are currently being used in a rule.
You must either remove those lists from any rules or delete the other lists separately.
To delete a list:
1. Click the Manage Lists page in the Policy Management application.
2. Select the checkboxes of the lists that you want to delete.
3. Click Delete.
4. When prompted to confirm the deletion, click Yes.
70 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Important: You must select the checkbox for the user names to be recognized as
hashed. However, selecting the checkbox does not automatically hash the values.
If you select the checkbox, you must manually enter hashed values to the list. If
you clear the checkbox, you need to manually enter plain values to the list. You
must manually reenter the appropriate values each time you select or clear the
checkbox. For more information, see the Operations Guide.
2. Manually hash the user name values that you want to add to the User ID list using
SHA1 hexadecimal encoding.
3. For each User ID, add the hashed user name and organization name (not hashed)
to the User ID list.
Note: The hashed user names are not case sensitive. The organization names are
case sensitive.
For more information about adding values to lists, see Add a Single Value to a List
on page 67 and Import a Set of Values to a List on page 69.
List Type The List Type designates the type of values contained Yes
in the list.
3: Managing Policies 71
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Status The current status for this list. The following options Yes
are available:
Enabled (default). The list is available for use when
creating new rules, appears in the Manage Lists
table, and appears in existing rules.
Disabled. The list is not available for use when
creating new rules, but still appears in the Manage
Lists table, and still appears in existing rules.
72 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Note: The information you see in the summary section depends on your role
permissions. For more information, see Role Management on page 24.
Element Description
Related Rules A table that lists all the active rules for the organization that use
the custom fact in one of the conditions.
Note: You can add up to 20 different custom facts per SOAP API request. By default,
the application is configured for up to 1000 total custom facts for the Back Office
application. Contact RSA to configure the maximum number of custom facts for the
Back Office application.
Important: The maximum length of a value for a custom fact, using the UTF-8
character set, is 90 bytes.
4. Click Save.
3: Managing Policies 73
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Custom Fact
Description Required
Attribute
Fact Type The fact type designates the type of value contained in Yes
the fact.
The following predefined fact types are available:
Boolean
Double
Float
Integer
IP Address
String
74 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Custom Fact
Description Required
Attribute
Status The current status for this fact. The following options Yes
are available:
Enabled (default). The fact is available for use when
creating new rules, appears in the Manage Custom
Facts table, and appears in existing rules.
Disabled. The fact is not available for use when
creating new rules, but still appears in the Manage
Custom Facts table, and still appears in existing
rules.
Important: To trigger rules that are based on custom event types, you must add the
appropriate custom event type to the online banking API and send the event type via
the SOAP API to the Adaptive Authentication system. For more information, see the
section that discusses Web Services API Data Elements in the Web Services API
Reference Guide.
3: Managing Policies 75
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Note: The information you see in the summary section depends on your role
permissions. For more information, see Role Management on page 24.
Element Description
Related Rules A table that lists each active rule that uses the custom event
type in one of the conditions of the rule.
Note: The Custom Event Type Name and Predefined Event Type fields are not
available for editing.
76 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Note: You can only edit the Status and Description fields.
4. Click Save.
Custom Event
Description Required
Type Attribute
Custom Event Unique name assigned to the event type. This name Yes
Type Name cannot be the same as any other event type in the system.
The maximum length of an event type name is 50
characters.
Predefined Event A list of all event types that are predefined in the system. No
Type You can select an event type from the list to link a newly
created custom event type to a predefined event type.
For example, you can create a custom event type,
International, and link it to the predefined event type,
Payment. The new custom event type is named
Payment - International.
Status The current status for this event type. The following Yes
options are available:
Enabled (default). The event type is available for use
when creating new rules, is included in the Manage
Custom Event Types table, and is included in existing
rules.
Disabled. The event type is not available for use when
creating new rules, but is included in the Manage
Custom Event Types table, and is included in existing
rules.
3: Managing Policies 77
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Custom Event
Description Required
Type Attribute
Policy Report
The policy of an organization contains rules that can trigger a wide variety of actions.
To get a broad picture of the results of your organizational policy, you can generate a
Policy Report. For example, by analyzing the Policy Report, you can make more
informed decisions about whether or not to promote a test rule to production, whether
to remove a rule from production entirely, or whether to add or remove event types
from a rule. A Policy Report displays all rules that are running in a production
environment (rules with a status of or production) for a given organization.
For each rule, the Policy Report displays the following information:
Rule Order. The priority assigned to a rule, indicating the order in which the rule
is triggered. A lower number represents a higher priority and a higher number
represents a lower priority. After a production rule is triggered, all production
rules with a lower priority will not be triggered. All rules with a higher priority
than the triggered production rule are also triggered.
Note: Rules that are not running in a production environment are not displayed.
As a result, there may be gaps in the rule order.
Rule Name. The unique name that you assigned to the rule.
Associated Event Type(s). The type of end-user activity that triggers the rule
when all rule conditions are met. Multiple event types can be assigned to a single
rule. In the report, each row represents a different event type. Any rule may,
therefore, be represented by multiple rows in the report.
Status. The current status for this rule. Only rules with a status of Test or
Production are evaluated by the Policy Engine and appear in the Policy Report.
Rule Action. The predefined outcome that occurs when the condition is fulfilled
and the rule is triggered.
Number of times rule triggered. The number of times that the rule is triggered,
irrespective of whether the rule status is or Production.
78 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Allow, Challenge, Deny, and Review. These four columns list the number of
times each respective action is applied to end users when this rule is triggered.
When a rule is triggered, no action is applied to the end user, but one or more rules
can be triggered at the same time that a production rule is triggered. When this
production rule is triggered, an action is applied to the end user. These parameters,
therefore, indicate the number of times a production rule results in an action for
any given rule, whether the production rule itself or a rule that is triggered along
with the production rule. You can use this number to evaluate the potential result
of a rule if the status was changed to Production.
For more information on these parameters, see General Rule Parameters on page 58.
You can use the data provided in the Policy Report to analyze and adjust the state of
your policy. For example, you may see that your policy triggers too many instances of
step-up authentication (challenge action). In other words, your policy may be
consistently applying the challenge action to a large number of end users who pose no
threat to the system. This can potentially cause unnecessary inconvenience for the end
user and can create a preventable financial burden for your company.
Using the Policy Report as a diagnostic tool, you can fine-tune your policy to improve
the end-user experience. For example, you may have a rule that challenges any end
user with a risk score of more than 800. After viewing the Policy Report, you may
decide to raise the threshold of that rule to 850.
Additionally, you may find that your policy results in the creation of too many cases in
the Case Management application. Your organization may be unable or unwilling to
handle the quantity of cases created by your current policy. Using the Policy Report,
you can analyze the foreseeable case load and adjust your policy accordingly.
3: Managing Policies 79
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
If the end user performed the Add_Payee transaction one time and received a risk
score of 899, the Policy Report would look as follows.
Number
Rule Rule Event Rule of times
Status Allow Challenge Deny Review
Order Name Type Action rule
triggered
This Policy Report shows that each of the three rules was triggered once since the last
policy refresh. The Challenge column indicates that, for each triggered rule, the
Challenge action was applied once. You can use this information to analyze how the
rules would perform if promoted to production. In this case, both Rule A (test) and
Rule B (test) were triggered at the same time that the Challenge action was applied by
Rule C (production). If either rule had been a production rule, the rule would have
resulted in the associated rule action.
Note: You may want to generate and save your report before a policy refresh. You can
then compare this data with newer data.
80 3: Managing Policies
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
3: Managing Policies 81
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
4 Managing Cases
Case Management Application Overview
Case Management Functionality
Case Assignment
Case Grouping
Lifecycle Milestones of Cases
Case Workflows
Case Management Menu
Case Status
Case Mode
Process Queue Management
View the Queue
Look Up an End User
Case Update
Manually Set a Resolution for an Activity
Operator Group Management
Operator Management
Research Activities
Snooze Mode
Top Risk Score Contributors
Custom Facts
This chapter describes how to use the Case Management application.
4: Managing Cases 83
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Flagged Activities
Flagging of activities is done based on the following:
An activity flag is triggered automatically by the system in the following
situations:
An end user is asked for additional authentication and fails to pass the
challenge.
A triggered policy rule results in a system flag if the Create Case option is
selected in the Policy Management application. For information about policy
rules, see Chapter 3, Managing Policies.
System flags are read-only. The following system flags are used.
System Flag Icon
Flagged by production rule
84 4: Managing Cases
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Not flagged
Note: There is no feedback sent to the Risk Engine for cases that are only
flagged by test rules and do not have any event resolution.
If the system flags an activity for an end user who already has an open case, the
newly flagged activity is added to the existing case for that end user.
Each end user with one or more flagged activities has only one case.
An operator can manually set a resolution for an activity in the Recent Activities
section of Research Activities or in Case Management > Lookup User. This
resolution overrides any flagging performed automatically by the system for case
resolution and Risk Engine purposes only.
For more information, see Manually Set a Resolution for an Activity on page 109.
Note: A case expires after the logical end time of the case has passed. This parameter
is defined by the date of the event that created the case + Y days forward. The default
is 10 days. You can configure this, using the Case Management Logical End Time
Offset parameter in the Back Office Applications section in the Administration
Console.
4: Managing Cases 85
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Challenge Scenarios
This topic describes various scenarios related to the Action type of Challenge and
explains how and when a case enters Case Management for each scenario.
In these scenarios, the Policy Management user selects the Create Case (when
authentication fails) checkbox, and the end user then performs an activity that triggers
a rule with an action of Challenge.
The end user is allowed a certain amount of time to successfully complete
authentication, during which the case has a status of Pending and is only visible on the
Research Activities page. This time period is configurable by changing the Queue
Visibility Time Offset parameter in the Case Management section of the Back Office
Applications component of the Administration Console. For more information, see the
Operations Guide.
86 4: Managing Cases
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
End User Fails and Then Completes Authentication within Allowed Time
If the end user fails authentication within the allowed time period but then retries and
completes authentication successfully within the same allowed time period, no case is
created at the end of this time period.
The workflow, assuming a default time period of 30 minutes, is as follows:
1. Authentication (challenge) leads to a 30-minute window.
2. End user fails authentication.
3. End user reauthenticates and succeeds within the 30-minute time frame.
4. No case is created for the end user activities.
The following figure describes this scenario.
Note: In cases where both a production rule and a test rule are triggered for the same
transaction, the production rule has a higher priority. For example, if a Challenge
production rule is fired together with a Decline test rule for a transaction and the end
user passes authentication, no case is created in the Case Management application.
End User Fails and Then Completes Authentication After Allowed Time
If the end user does not complete authentication successfully, opens a new browser or
tries to perform the same activity, and passes authentication, a case still enters the
Case Management application. The case includes the activity for which the end user
failed authentication, even though the end user successfully passed authentication
later for that same activity. A row listing the activity and the successful authentication
result is displayed on the Case Details page, enabling the operator to see that the end
user passed authentication for an activity after initial failure.
4: Managing Cases 87
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Case Assignment
A case is assigned to an operator in an organization. If each organization has an
operator, all cases are eventually assigned. Cases are assigned based on the following
criteria:
The system first attempts to assign a case to an operator according to a group
filter. The default group filter is used if:
The case does not match any of the group filters.
The case matches one of the group filters but there are no operators associated
with that group.
A case that matches a non-default group filter is assigned to any operator
associated with that group filter if the operator has access to the user organization
for the group.
A case that does not match any of the non-default filters is assigned to an operator
from the default group if the operator has access to the user organization.
An unassigned case is assigned to an operator from the organization of the case. If
there is no operator for the organization, the case is assigned to an operator from
the default organization.
A case that is manually created from events can be automatically assigned from
either the Lookup User page or from the Research Activities page.
Note: RSA recommends that you use this option if you want a case to be
handled promptly.
To create a case and add the case to the queue for assignment to an available
Case Management user, click Queue.
88 4: Managing Cases
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Case Grouping
Each case is assigned to a group for case management purposes.
Default Group
A case is assigned to the default group (DEFAULT_GROUP) if there are no other
groups or if the case does not match the parameters specified for the existing group.
The default group includes cases that do not fit into any other operator-created groups.
The initial default group is system generated, but you can designate a new group as the
default group. You must assign at least one operator to the default group. If you are
working in a multi-organization environment, RSA recommends that at least one
operator from each sub-organization is associated with the default group.
Operator Group
Cases can be grouped according to case properties. You can filter the queue for cases
with specific parameters. For more information, see Operator Group Management on
page 111.
RSA recommends that you create several operator groups with filters.
4: Managing Cases 89
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Open Case has no Can add new events Open and Active. A case that has no
resolution. to the case (for resolution and has not expired.
active cases only). Open and Expired. A case with no
resolution that has expired.
Expired Logical end time for a Cannot add new Open and Expired. A case with no
case has passed. events to the case. resolution that has expired.
Need to create a Closed and Expired. A closed case
new case, and add that has expired.
the events to the
new case.
Closed Case has a resolution, Can reopen a case to Closed and Active. A closed case that
either fraud or add events to it (for has not expired.
genuine. active cases only). Closed and Expired. A closed case
that has expired.
Case Workflows
There are system workflows in place that are related to case creation and to case
handling.
90 4: Managing Cases
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
The following table describes the Case Management menu and submenu items and
the type of activities that you can perform in that area of the application.
Process Queue Review cases in the queue, investigate cases, and update cases in
the system
Add reported fraudulent events to an existing case
Lookup User Find cases and end user data for a specific end user
Create a new case
Add reported fraudulent events to an existing case
4: Managing Cases 91
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Research Activities Search for activities using filters for case attributes
Create a new case
Add reported fraudulent events to an existing case
92 4: Managing Cases
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
The Recent Account Activity section displays all end user activities that exist within
the time range of the case. The time range of the case is defined by logical start time
and logical end time. These times are defined when the case is created based on the
date of the event that created the case. The following figure shows the Recent
Account Activity section and the Detailed Activity Information section that appear
on the Lookup User, Process Queue, and Research Activities pages.
4: Managing Cases 93
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Field Description
System Flag An icon indicating what type of rule triggered the creation of
a case or the marking of an event as suspicious.
Risk Score The risk score that this event received from the Risk Engine.
ATM Account The account number of the card used during the ATM
transaction.
Challenge Successful If the policy action was Challenge, this field displays N if the
challenge was not successful or Y if the challenge was
successful. If the policy action was not Challenge, the field
displays N/A.
Accumulated User-Payee This field is mapped to the WSDL data element in event
Payments in USD details that represent the accumulation of payments in USD
made to the payee account.
94 4: Managing Cases
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Risk Score Contributors Contributor Name The top four factors that contributed to
the risk score.
Account Open Date The date that the last account was
opened.
This field is mapped to the WSDL data
element user Data/last Account Open
Date.
Online Enrollment Date The date that the end user enrolled in the
service. Potential fraud predictor: cross
channel fraud, new account fraud.
This field is mapped to the WSDL data
element user Data/online Service
Enroll Date.
Address Change Date The date that the end users address
record was last changed or created.
Password Change Date The date the end users password record
was last changed or created. Potential
fraud predictor: cross channel fraud,
account takeover fraud.
Card Age (days) The age, in days, of the end users debit
or credit card.
4: Managing Cases 95
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Card PIN Change Date The date when the card PIN was last
changed.
Payee/Other Account External Account The routing code of the payee or other
Routing Code account.
96 4: Managing Cases
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Location Details IP City The city of the IP address from the end
users device.
4: Managing Cases 97
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
98 4: Managing Cases
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Case Status
When a case is closed and assigned a resolution status, the information is updated to
the Adaptive Authentication system using a web service call. The RSA Risk Engine is
updated with case resolution information about closed cases. The following table
describes the status of a case and its life cycle.
Status Description
Open Case
New
When: Default, after creating, before processing.
Next step: Start processing.
Couldnt contact user When: After processing started, tried to reach end user
with no success.
Next step: Contact again later (end user might call back).
4: Managing Cases 99
RSA Adaptive Authentication (On-Premise) 7.1 Back Office Users Guide
Status Description
Closed When: A user closes a case after resolving it. The case
resolution is automatically chosen, and the event and case
resolution are sent to the Risk Engine.
Next step: One of the following actions occurs:
The operator manually selects an event resolution from
the drop-down list.
The case is automatically closed because the case was
open for a number of days beyond that allowed for the
maximum case duration. If the case is automatically
closed, the default event resolution is Suspected
Fraudulent. For more information, see Case Resolution
on page 110.
Expired When: The logical end time of the case has expired.
Case Mode
The mode identifies the status of the triggered rule from the Policy Management
application that created the case in the Case Management application. A case can have
a mode of either Test or Production. For more information, see Rule Status on
page 49.
You should be aware of the following issues regarding case modes:
There is no feedback sent to the Risk Engine for cases that are only flagged by test
rules and do not have any event resolution.
A mode can automatically change from Test to Production if the same event that
originally triggered the case for a particular end user is triggered again by a
production rule or if you manually change the event resolution for the case.
Case Priority
In the View the Queue and Process Queue pages, the list of cases is organized by the
time that the case must be reviewed, not by the risk associated with the case. This
order is determined by an algorithm that analyzes the proximity of the case to the
following two times:
Review Deadline. Parameter that is defined for a case when the case is created.
This value is taken from the parameter defined in the Administration Console. For
more information, see the chapter Administration Console in the Operations
Guide.
Next Contact. Parameter chosen if an operator updates the case status to Could
not contact user.
In general, the closer a case is to the times defined in these two parameters, the higher
it will appear on the queue menu. Closed cases are not returned to either queue.
Note: Cases with a mode of Test are prioritized below cases with a mode of
Production. As a result, the highest priority Test case is listed below the lowest priority
Production case.
On the View the Queue page, a lock icon and the operator ID of the assigned
operator is displayed.
Note: The Advanced tab does not include an organization filter. The organization
that you select from the Organization drop-down list during logon is used for the
filter.
3. Click Filter.
All cases matching the search criteria are returned as results in the View the
Queue table.
Activity Type Select from the list of activity types. For more No
information, see Appendix C, List of Event Types.
Risk Score In the From field, enter the minimum risk score for No
the filter. In the To field, enter the maximum risk
score for the filter.
Production Rule ID Select a Rule ID associated with the cases you want No
to view.
Note: The User Status field can have one of the following pre-defined values:
DELETE, LOCKOUT, NOTENROLLED, UNLOCKED, UNVERIFIED, or
VERIFIED.
The User Type field can have one of the following pre-defined values:
PERSISTENT, NONPERSISTENT, BAIT, or N/A.
Note: The Must be reviewed before field represents the time remaining for
this case to be considered as high priority. If the case is not assigned before
the time specified in this field, the case is displayed lower in the queue.
Case History. Displays historical case data. Only displayed if a case exists for
the end user.
Recent Account Activity. Displays recent events including: date, activity,
flagged by the system, Event Resolution, risk score, IP Address, IP Country,
Rule ID, Policy Action, ATM Account.
Detailed Activity Information. Displays account details, activity details,
payee/other account, location details, and device details.
Note: The default number of view details per page view is set to five. If you want to
change the default number of view detail lines on display, configure the Case
Activities Per Page parameter in the Back Office Applications component of the
Administration Console. For more information, see the Operations Guide.
If an end user is found but does not have an associated case, the Case Management
application displays all recent activities for that end user.
Note: As is true for the overall system behavior, events that are presented and can be
flagged are limited in number and by date range.
Case Update
There are two ways to update a case:
Using Lookup User. For more information, see Update a Case Using Lookup
User on page 108.
Using the Process Queue. For more information, see Update a Case in the
Process Queue on page 108.
Note: If a Test case becomes a Production case, the case is not automatically
reassigned to a different operator group. You must manually reassign the case to a
different operator group.
For information about manual flagging, see Manually Set a Resolution for an
Activity on page 109.
3. Click Save Changes to update the case and save Case Details and Recent Account
Activity.
Note: If you click Go in the Recent Account Activities section, you save the changes
made in the Event Resolution drop-down list and refresh the entire Update Case page.
This resets any unsaved changes that you made in the Update Case page. If you click
Cancel, you cancel changes made in the Case Details section only.
Case Resolution
Case resolution defines the final conclusion regarding the case as reached by an
operator. Case resolution can also refer to the case findings as confirmed or reported
by the user. When an operator closes a case, the case resolution is automatically
selected based on the event resolutions of the case. Only an operator can close a case
and only if there is at least one event in the case that is flagged (system flagged or
custom marked). The Event Resolution options are listed in the following table along
with the icons that represent each option in the user interface.
Event Resolution Icon
Confirmed Fraudulent
Suspected Fraudulent
Unknown
Assumed Genuine
Confirmed Genuine
An event that is flagged by the system based on rules from the Policy Management
application is a system-flagged event. A system-flagged event is one where the case
resolution is set to Suspected Fraudulent unless the operator manually sets the
resolution to Confirmed Genuine or Unknown.
Note: The list of available organizations can only be changed in the Access
Management application. For more information, see Chapter 2, Managing Access to
the Back Office Applications.
Note: If you use default filtering of the queue, custom filtering fields also use the
default mode. If current settings are different from the default, they are reflected in the
filtering field options.
Note: You cannot delete a group that contains an operator. If an operator exists
within a group that you try to delete, an error message is displayed requesting that
you remove the operator from the group.
Note: Only operator groups belonging to the current organization appear in the Select
Operator Group drop-down list.
After editing the operator group, you can set the filter settings as the default operator
group.
Operator Management
A user with admin or operatormanager permissions can manage the user activities of
operator users in the system. Before you can assign an operator a case, you must
assign the operator to an operator group. An operator must have the operator role
assigned within the operators user profile. Role assignment is performed in the
Access Management application. For more information, see Chapter 2, Managing
Access to the Back Office Applications.
The Manage Operators page includes the following functionality:
Add an Operator to an Operator Group
Change the Operator Group of an Operator
Research Activities
The Research Activities page allows research of end user activities and cases. You can
define fraud policies that allow you to investigate and identify fraud patterns, so an
organization can take action such as setting a new policy or rule.
Research activities are performed at the activity level, not at the case level. All
activities can be researched, not only flagged activities.
The Research Activities page is used for fraud policy-making and allows you to
investigate and identify fraud patterns, so an institution can take action such as setting
a new policy or rule.
You use the Research Activities page to research end user activities and cases.
Last 30 days.
Last 90 days.
Specific From and To dates selected using the calendar icons to define a date
range in the format. From MM/DD/YYYY To MM/DD/YYYY.
Additional filters:
Note: Select any relevant filter to enable that activitys drop-down menu or text
box. The checkboxes are unavailable by default.
Display a Case
You display a case to read and analyze case details.
To display a case:
On the Research Activities page, click Display Case.
The View Case page opens. The View Case page is a read-only view of case
information. The edit fields and drop-down menus are disabled, and checkboxes are
not displayed.
Edit a Case
Before You Begin
Make sure that you have the required permissions to update a case.
To edit a case:
On the View Case page, click Update to edit the case.
Snooze Mode
Snooze mode allows you to skip a case in the queue and return to the case at a later
time. When you skip a case, the case is put into snooze mode for a set period of time.
The default time period is 30 minutes. This period can be configured in the Case
Management section of the Back Office Applications component within the
Administration Console.
The Snooze icon appears next to the case on the View the Queue page. To see the
start time of the snooze period, move your cursor over the Snooze icon. The time that
is displayed is 24-hour time. A case in snooze mode will be moved to next in line for
processing after the snooze time has ended, based on the case priority.
Note: The list of risk score contributors was updated in version 7.0.
Custom Facts
You can define custom facts in the Policy Management application. A fact is a core
data element which the Policy Engine processes to determine if the rule is triggered.
Once you create and save a custom fact successfully, you can build rules with the fact.
You can add up to 20 different custom facts to the system. Defining these facts adds
new fact names and the associated values to the Detailed Activity Information
section. For more information, see the topic about custom facts in Chapter 3,
Managing Policies.
Note: The Customer Service application logs you off after a set period of inactivity.
Keep this in mind while viewing an end users information. For more information, see
Log Off from a Back Office Application on page 15.
Note: Changes to an end users account status may occur due to activities performed
in Case Management and may not be reflected in the Customer Service application.
For example, if a case is changed to Genuine Confirmed in Case Management,
authentication is unlocked.
Depending on the current status of the account, different buttons are available above
the activity table. The availability of the following buttons is dependent on the account
status type for which they are needed:
Unenroll. Available in all end user account states except Deleted.
Terminate authentication sessions. Available in all end user account states
except Deleted.
Account Locking
You can lock end user accounts if any of the following occur:
An end user fails authentication.
An end user calls and wants to lock the account because the account information
was stolen or there was unauthorized access to the account.
An end user is delinquent in payments and the account needs to be locked.
An end user is no longer a member of the organization and the account needs to be
deleted. You can lock the account before deleting it.
An end users account can also be locked if the end user incorrectly answered the
challenge questions too many times. The Adaptive Authentication system
automatically locks an account in that case.
Account Unenrollment
When you unenroll an end user, the end users account information is made
inaccessible but it is not removed from the database. Although the account
information is flagged for deletion, the actual information is never removed from the
Adaptive Authentication system. If the end user tries to log on to an account that is
unenrolled, the end user cannot access the account information.
Deleted accounts are removed from the system if the scheduled task DeleteUsers is
configured to run after the billing period is over. If the end user is in the DELETED
status, you must use the createUser or analyze AutoCreate request to re-create the
deleted end user.
For more information, see the chapter on logs and reports setup in the Operations
Guide.
Note: If you do not see a particular organization or its reports, contact the
appropriate party within your company for access to view the reports.
Report Characteristics
Reports are generated from processed activity logs. Each report covers the end-user
sessions for a specific range of time. Typically, the time range is daily, weekly, or
monthly, except for system trends, which are weekly and monthly.
Note: In a report that covers multiple days, some rules do not fire every day. The
report designates no firing of a rule on a day by a zero (0), which appears periodically
throughout the report.
Time ranges are not configurable. Set up the reporting schedule and time period by
working with RSA Customer Support. If you are viewing the reports with the Report
Viewer, make sure to maintain the directory structure provided by RSA Central. For
more information, see the chapter on logs and reports setup in the Operations Guide.
Important: In general, these logs do not contain sensitive customer data. Data is only
used to examine aggregate behavior and User IDs can be obscured through a hashing
algorithm. To hash User IDs, you must configure the ID Masking parameter in the
Administration Console. Consequently, individual users cannot be identified by User
IDs. For more information about the ID Masking parameter, see the chapter
Administration Console in the Operations Guide.
Note: If dates in a week straddle two months, reports from that one week period are
grouped inside the directory of the first of the two months. For example, if March 31
is a Wednesday and April 1 is a Thursday, a report that focuses on activities during this
time period are grouped inside the March directory.
Report Types
The following report types are available:
Billing Report. Includes statistics used for billing purposes. A roll-up version of
the report contains data from several customers. Customers with multiple
organizations or service providers may find the roll-up version useful for billing
each organization.
Authentication Plug-In Billing Report. Statistics used for billing of the
Authentication Plug-In service. There is a roll-up version of this report.
Blocked Users Report. A detailed report that shows the hashed User IDs for end
users who were denied access to your online application, the rule that caused each
end user to be blocked, and the date and time that each end user was blocked.
Case Management Report. Statistics on case activity and fraudulent transactions
as represented by the Case Log and Events Marking Log from the Case
Management application.
Case Trends Report. A summary of the Case Management Report over a period
of time. This report is generated for weeks and months, instead of days.
eFraudNetwork Report. Counts attempts to access the online system by people
from IP addresses identified in the RSA eFraudNetworkTM service as high risk and
records the result of the attempt.
Forensics Summary Report. Statistics on Risk Analysis parameters, such as
usage by geographical location.
Policy Summary Report. A count of the recommended policy actions and
reasons for each recommendation. The report includes the rules that fired a given
recommended action.
Policy Trends Report. A summary of the Policy Summary Report over a period
of time. This report is generated for weeks and months, instead of days.
Risk Factor Report. Includes the total count of the risk factors that are fired
regarding a transaction, not only the ones that result in recommended actions.
Risk Factor Trends Report. A summary of the Risk Factor Report over a period
of time. This report is generated for weeks and months, instead of days.
System Usage Report. A summary of the business events, such as total logon
attempts, challenges, and lockouts.
System Trends Report. A subset of the System Usage Report, which provides a
breakdown of the events in the System Usage Report by day.
Report Format
RSA provides access to reports every day. To access reports, you must send the log
files to RSA and then download the reports. Reports are available as PDF or CSV
files.
A report consists of a data table that provides the bulk of the report information.
The report structure is:
Header
One section for each different transaction type
An overall section for all transaction types
Footer
Start Report:
==============================
Transaction Type: X
(report content with potentially multiple sections)
==============================
End of Report
CSV Files
CSV format is recognizable by many analysis software packages, so the data from the
reports can be easily be exported to such a tool for further analysis. RSA consistently
maintains the structure of each report and notifies customers in advance if there are
unavoidable changes to the structure.
Header Description
All reports start with a standard header that identifies the report and any pertinent
information about the report. The header contains the following:
Report Name. Identifies the report.
Report Version. Each report has a version number that signifies the Adaptive
Authentication version used to generate this report.
Reporting Period Date and Time. Each report shows activity for a specific time
range. The values show the date and time zone:
Daily reports list two dates, which indicate a 24-hour period starting on the
first date. For example, December 30 to December 31 is equivalent to a one
day period.
Weekly reports start with Sunday and end the following Sunday. The report
covers a 7-day calendar week that includes Sunday through to and including
the following Saturday. For example, June 18 (Sunday) to June 25 (Sunday)
covers one calendar week which includes June 18, 19, 20, 21, 22, 23, and 24.
Monthly reports list two months. The report covers a period of a full month.
The period begins from the beginning of the first month and continues
through to the start of the first day of the next month. For example, January 1
to February 1 is listed as the report period for the month of January.
Report Creation Date. The date on which the report was generated.
Customer Name. Your name.
Organization. If your organization includes multiple layers of organizations,
Organization is the specific institution to which the report applies. Otherwise,
Organization is the same as the Customer Name.
Header Format
The following is the report header format:
Report Name
Version #
Start Date Month Day, Year
End Date Month Day, Year
Timezone XXX
Creation Date Month Day, Year
Customer Name
Organization Name
Footer Description
All reports end with an end tag line so that you are assured that you received the entire
report.
Note: If the report is an aggregative report for all organizations under the default
organization, the OrganizationName parameter does not appear in the report name.
Parameter Description
<OrganizationName> The name of the organization for which the report was run. The report contains
data on the parent organization all its suborganizations.
This parameter does not appear in an aggregated report, which contains data for all
customer organizations.
<DateTimeGenerated> The date and time that the report was run.
The parameter is a single unit representing date and time in
YYYYMMDDHHMMSS format.
A report run at 1:01 p.m. on April 16, 2012 is shown as 20120416130100. If two
reports exist with the same name, view the one with the latest DateTimeGenerated
stamp for the most up-to-date report.
The following table lists examples of valid report types and the naming conventions
that the reports use.
Note: If the report is an aggregative report for all organizations under the default
organization, the OrganizationName parameter does not appear in the report name.
Billing 20120331_BillingReport_DAILY_20120403041822.pdf
eFraudNetwork 20120521_EFNSummary_DAILY_20120612141617.csv
Report Content
Billing Report
Authentication Plug-In Billing Report
Blocked Users Report
Case Management and Case Management Trends Reports
eFraudNetwork Report
Forensic Summary Report
Policy Summary and Policy Summary Trends Reports
Risk Factor Report and Risk Factor Trends Reports
System Usage and System Trends Reports
This topic describes the content of the reports and provides report examples.
Billing Report
RSA generates a Billing Report for your institution based on the Billing Logs sent by
your company. RSA uses the data from these daily reports to create the billing
invoices that are sent to your company.
Billing report information can vary due to:
The number of end users enrolled in the Adaptive Authentication system
The number of active end users during a given billing period
RSA consolidates billing information based on different parameters, such as:
All the data for a given customer
All the data centers for a particular institution
Note: If no recent billing data is available, RSA uses the most recent data but notifies
you in the report that the most recent logs for that period were not received.
Total number of calls made to the Authentication Plug-In for your company
Note: Calls that the Authentication Plug-In triggers are billed regardless of the result.
Possible results include successful authentication, failed authentication, unreachable
numbers, busy lines, and rejected calls.
Note: The User ID will only be hashed if the ID Masking parameter is selected in
the Administration Console. For more information, see the Operations Guide.
Note: The Blocked Users Report gives you a complete date and time stamp. Make
sure that your CSV reader, for example, Microsoft Excel, can import this complete
date and time stamp without any modification.
Unknown
Total
Note: The Events Marking Log contains a list of all cases closed on the day the log
was run. For events that were manually flagged, the specific resolution is listed. For
all other events, the resolution is listed as Unknown.
The Case Management Trends Report is a subset of the Case Management Report and
provides a breakdown by day within the reporting period. These reports break down
the Case Management activities into statistics that you can use to track the number of
cases being created and closed while also tracking the instances of fraud.
eFraudNetwork Report
The eFraudNetwork (EFN) Report uses the Audit Logs and identifies the IP addresses
listed in the eFraudNetwork service that pose a potential risk. Based on this
information, this report provides risk analytic information on the following:
The number of logons that correspond to IP addresses listed in the eFraudNetwork
service.
The logons not challenged that correspond to those potentially high-risk IP
addresses listed in the eFraudNetwork service.
The report consists of a table that shows the range of risk scores relative to the number
of times the following elements occurred:
Logon. The number of end users logging on to your online system that have a
high eFraudNetwork score.
Unchallenged. The number of instances in which end users log on without being
challenged, despite using IP addresses listed in the eFraudNetwork service.
If the Unchallenged element of the report is empty, this indicates that no end users
from high-risk IP addresses accessed your online system during the reporting
period listed on the report.
Denied. The number of instances in which end users do not gain access to your
online system, based on the documented IP addresses listed in the eFraudNetwork
service.
Challenge Failed. The number of instances in which end users are challenged
during logon and fail the challenge.
Challenge Succeeded. The number of instances in which end users are
challenged during logon and successfully meet the challenge requirements.
You can use this report to assess the effectiveness of your company policies and
procedures in preventing access by end users with high-risk IPs.
The following figure shows an example of an eFraudNetwork Report.
Top 10 unique ISPs that logged on to your system and the total number of times
for each ISP, listed in descending order.
Top 10 unique regions (states, provinces, and counties) that accessed your system
and the total number of times for each region, listed in descending order.
All countries that accessed your system and the total number of times for each
country, listed in descending order.
Each country is identified by its two-digit Alpha-2 ISO 3166-1 country code.
Top 10 unique cities that accessed your system and the total number of times for
each city, listed in descending order.
Note: The top number counts are based on the assumption that Forensic Logs contain
forensic information for a minimum of 10 cities, 10 regions, 10 ISPs, and 40 IP
addresses. A report may contain less than these minimum values if your Forensic Logs
did not receive the preset minimum values.
Important: Percentages refer to the percentage of times a risk factor occurs out of all
potential risk factors for a specific transaction type. Because the percentage relates to
one transaction type, the total of percentages for all transaction types is not 100
percent and has no significance.
Note: For Web Services customers, the appearance of a zero (0) in the Total
User Logons count is normal, because RSA does not receive a successful end
user logon reported in the logs. See USER_SIGNIN in the events table for a
count of the number of end users logging onto your system. This count is a
close approximation to Total User Logons.
Note: Unique Users are counted differently than Total Users. The Unique
Users element counts only those end users who are unique.
For example, if User XYZ logs on five times in one day, Unique User only
counts User XYZ once, but Total User counts User XYZ five times.
A List of Facts
The following table shows the fact categories, the name for each fact, the name of the
fact in previous versions, the fact type, and a description of the fact. For more
information, see Facts on page 44.
Account Details # of Days Since First DaysSinceFirstHit Integer The number of days that
Logon passed since the first time the
end user was detected.
ATM Details # of Days Since Card N/A Integer The number of days that
Issued passed since the end users
card was issued.
ATM ZIP Code N/A String The 10-digit code for the
neighborhood in which the
ATM is located.
Channel Activity Channel ChannelIndicatorType String The channel from which the
Indicator Indicator event is coming.
The possible values are:
ATM
BRANCH
CALL_CENTER
IVR
MOBILE
OTHER
WEB
Device Details Cookie Less than 5 cookieLT5DaysOld Boolean Specifies whether the cookie
Days Old is less than 5 days old.
Location City Name from ipCityCode String The city name taken from the
Details GeoIP GeoIP.
Refer to MaxMind
documentation for supported
values.
Country Code from IPCountryCode String The country code taken from
GeoIP the GeoIP.
Refer to MaxMind
documentation for supported
values.
Country Code from N/A String The country code taken from
Geolocation File the geolocation file.
(Mobile)
Region Code from IpRegion String The region code taken from
GeoIP GeoIP.
Refer to MaxMind
documentation for supported
values.
Payee Details # of Days Payee is payeeProfileAge Integer The number of days that the
Associated with User payee is associated with the
end user.
Risk Score Risk Score score Number The risk score received from
the RSA Risk Engine.
Possible values are between 0
and 1,000.
Transaction Day of the Week CurrentDayOfWeek String The day of the week of the
Details transaction.
Possible values are the
numbers 1-7, corresponding
to the days of the week:
1. Sunday
2. Monday
3. Tuesday
4. Wednesday
5.Thursday
6. Friday
7. Saturday
Trojan Activity # of Days Since N/A Integer The number of days that have
Trojan Infection passed since the time that a
Trojan infection was detected
on the end users computer.
1 Very High All Logon event Condition 1 Category: Risk Score Action: Deny
Risk types Fact Name: Risk Score Create a Case: Yes
Activities All Transaction
Operator: Greater Than
event types
Value: 990
Condition 1 Expression 2
Expression Operator: OR
Category: Account Details
Fact Name: User ID
Operator: Within
Value: User on Gold List
Condition 1 Expression 2
Expression Operator: AND
Category: Device Details
Fact Name: User Device Not
Bound
Operator: Equals
Value: TRUE
Condition 2 Expression 1
Expression Operator: AND
Category: Location Details
Fact Name: Country Code
from GeoIP
Operator: Within
Value: Country on Black List
Custom List: Country on
Black List
Condition 2 Expression 2
Expression Operator: AND
Category: Device Details
Fact Name: User Device Not
Bound
Operator: Equals
Value: TRUE
Condition 1 Expression 2
Expression Operator: AND
Category: Device Details
Fact Name: User Device Not
Bound
Operator: Equals
Value: TRUE
Condition 2 Expression 1
Expression Operator: AND
Category: Location Details
Fact Name: Country Code
from GeoIP
Operator: Within
Value: Country on Watch List
Custom List: Country on
Watch List
Condition 2 Expression 2
Expression Operator: AND
Category: Device Details
Fact Name: User Device Not
Bound
Operator: Equals
Value: TRUE
6 User Not Session Sign-in Condition 1 Category: Account Details Action: Review
Persistent Fact Name: Registered User Create a Case: Yes
of the System
Operator: Equals
Value: FALSE
ACTIVATE_CARD The user attempts to activate a card (for example, debit, credit)
ADD_PAYEE The user attempts to add a new payee to their list of payees
CARD_PIN_CHANGE The user attempts to change the PIN of a credit or debit card.
CHANGE_ALERT_SETTINGS The user attempts to change their settings for receiving alerts (for
example, an alert when a change is made to their account)
CHANGE_AUTH_DATA The user attempts to change their authentication data (for example,
phone number, challenge questions)
CHANGE_LIFE_QUESTIONS The user attempts to change the questions/answers they want to see if
they are challenged by this form of additional authentication
CHANGE_PASSWORD The user attempts to change the password they use to access the
organizations online system
CHANGE_STATEMENT_SETTINGS The user attempts to change their settings for statement display or
receipt
CLIENT_DEFINED The organization attempts to define their own event type to use
instead of or in addition to the RSA default event types. The RSA
Risk Model is run on the event type combination.
ENROLL The user attempts to enroll into the organizations online system
NULL NA
REQUEST_NEW_CARD The user requests a new card (for example, debit, credit).
WITHDRAW The user attempts to initiate a withdrawal from the users account.