RSA Identity Governance and Lifecycle

Transcription

1 RSA Identity Governance and Lifecycle Supplemental Administrative Guidance V7.0.1

2 Contents Introduction... 3 Intended Audience... 3 References... 3 Evaluated Configuration of the TOE... 4 Installation and Configuration... 5 Auditing... 7 ESM_EAU ESM_ICD ESM_ICT FAU_GEN FAU_STG_EXT FTA_SSL FTA_SSL FTA_SSL_EXT FTP_ITC FTP_TRP FTA_TAB FTA_SSL.3 & FTA_SSL_ESXT ESM_EAU.2 & ESM_EID FTM_MOF FMT_SMR FIA_USB Audit Locations Audit Events Monitoring Change Requests Access Certification Rule Remediation Server Side Logs... 23

3 Introduction RSA Identity Governance and Lifecycle provides organizations the ability to act with insight to reduce identity based risks and drive informed security decisions. RSA Identity Governance and Lifecycle simplifies how access is governed and streamlines access requests and fulfillment to deliver continuous assurance of compliance by automating the management of user entitlements throughout the user s lifecycle. With control and visibility into all user access privileges, you improve your ability to safeguard access to information assets by quickly identifying orphaned accounts, inappropriate user access and violations of policy, such as segregation of duties, that introduce risk to the business. Designed for ease of use, RSA Identity Governance and Lifecycle enables IAM teams to easily connect to target systems, administer and manage ongoing policy creation, certification campaigns and system maintenance without costly customized coding, resulting in greater self sufficiency and repeatable success as your IAM program expands. The configuration that was part of the target of evaluation (TOE) includes RSA Identity Governance and Lifecycle version with licenses for Governance and Lifecycle interacting with an Active Directory server and an Oracle database as example endpoints. Intended Audience This document is intended for administrators that are responsible for installing, configuring, and supporting RSA Identity Governance and Lifecycle. Guidance is provided in this document on how to configure and exercise the security functions that were claimed as part of the common criteria (CC) evaluation. The reader is expected to be familiar with the Security Target for RSA Identity Governance and Lifecycle version and the general CC terminology that is referenced in it. This document references the Security Functional Requirements (SFRs) that are defined in the Security Target document and provides instructions for how to perform the security functions that are defined by these SFRs. References The following guides are included as part of the documentation for RSA Identity Governance and Lifecycle: [1] RSA Identity Governance and Lifecycle Installation Guide V7.0.1 [2] RSA Identity Governance and Lifecycle Upgrade and Migration Guide V7.0.1 [3] RSA Identity Governance and Lifecycle Database Setup and Maintenance Guide V7.0.1 [4] RSA Identity Governance and Lifecycle Public Database Schema Reference V7.0.1 [5] RSA Identity Governance and Lifecycle: Data Access Governance Module with StealthAUDIT 7.1 Getting Started [6] RSA Identity Governance and Lifecycle Appliance Updater Guide

4 [7] RSA Identity Governance and Lifecycle Solution Integration Guide: Configuring WildFly Clustering [8] Online help (accessible from RSA Identity Governance and Lifecycle user interface) In addition, the following document was created in support of the CC evaluation of RSA Identity Governance and Lifecycle: [9] RSA Identity Governance and Lifecycle Common Criteria Security Target Evaluated Configuration of the TOE The target of evaluation included the following environment: Component RSA Identity Governance and Lifecycle version Application Server Server TLS Active Directory Details Installed on IBM WebSphere as a J2EE application. The TOE has the following components enabled: Access Certification Manager, Business Role Manager, Access Request Manager, Rules, Automated Fulfillment (AFX), and Password Management. The TOE also includes the GUI and Web Services API features. Collectors and connectors were configured to collect data into the product and push changes out. The Data Access Governance component was not a part of the CC evaluation, but may also be included in the configuration. IBM WebSphere application server is used to host RSA Identity Governance and Lifecycle. WebSphere can be configured to operate in FIPS mode. RSA Identity Governance and Lifecycle is configured to run with RSA BSAFE Crypto J which is FIPS validated, certificate#2468 A physical system comprised of SUSE Linux Enterprise Server 11 SP3 64 bit with latest LTSS patches, IBM WebSphere, and OpenJDK 1.7. In all cases for RSA Identity Governance and Lifecycle, the encryption is provided by the following FIPS certified cryptographic module: RSA BSAFE Crypto J JSAFE and JCE version 6.2.1, certificate#2468 Used for protected communication Used to store identity and access data for the test environment. This also is used as an

5 Oracle Database 12 (1) Oracle Database 12 (2) Identity and credential attributes authentication source. Used by RSA Identity Governance and Lifecycle as the data store for configuration, operational data, and audit data for the TOE. Used to store identity and access data that might supplement or is in addition to enterprise data stored in Active Directory. An administrator can configure the attributes available based on their business in RSA Identity Governance and Lifecycle. Please refer to the section Creating and Managing Attributes for RSA Identity Governance and Lifecycle Object found in the Online Help [8]. For the evaluation, credential lifetime, credential status (that is, Active Status (Active or terminated)), name (first and last), User ID, Title, Job Status, Supervisors, Department and Business Unit, First Seen On, Last Seen On, Is Deleted, Is Terminated, Termination Date, Unique Id, Account, Group, Role and Entitlement attributes were defined. Active Directory was configured as an authentication source. Note that the attribute storing the password is not managed by RSA Identity Governance and Lifecycle and only resides on the Active Directory endpoint. Installation and Configuration The RSA Identity Governance and Lifecycle Installation Guide [1] includes detailed step by step instructions on how to install and configure the product in numerous environments including the TOE. A key step in the configuration of the Encryption Key directory (see Confirm the Setting for the Encryption Key Directory section [1]). This directory is the file system location where a unique KEK is stored and is used for any cryptographic operations. The install guide includes specific sections for configuring SSL to ensure secure communications between RSA Identity Governance and Lifecycle components and similarly for external communications. Security The install guide includes a security best practices section that administrators should review to ensure the TLS settings are configured properly, secure cookies are enabled on the application server, and the security settings found on the Admin >System >Security tab of the RSA Identity Governance and Lifecycle user interface are locked down. The default settings comply with the security best practices.

6 The system defines several roles that can be granted to users to act as administrator and owners of operations. These roles as well as individual entitlements can be found under the Aveksa application. A request to grant the role or entitlement to a user is done like any other access request by creating a request and adding the application role from the Aveksa application to the appropriate user(s). A system installed and configured in a CC environment defines the following default roles to perform the necessary management functions: System Administrator Password Management role Role Administrator Access Request Administrator As part of following security best practice, RSA recommends the AveksaAdmin account is used just for setup and then disabled or password changed. Everyday system administrator rights should be granted to real users that can be properly audited. For testing of the TOE an authentication source against Active Directory was defined in RSA Identity Governance and Lifecycle so all authentication was done against the Active Directory endpoint. See more details in the Managing Log On Authentication Sources found in the online help [8].

7 Auditing In order to be compliant with Common Criteria, RSA Identity Governance and Lifecycle must audit the events listed below for the Protection Profile for Enterprise Security Management Identity and Credential Management, version 2.1 ( ccevs.org/profile/info.cfm?id=346 ). All management functions made will produce an audit event. Some activities may also produce some additional audit artifacts which are called out. Administrators can configure the events that are audited by the following steps: 1. Login as someone with the AuditLogManagement::Admin entitlement (by default AveksaAdmin) 2. Navigate to the Admin >System >Audit menu 3. This screen lists the available audit events and allows the administrator to enable/disable the audit events to log. This screen also provides settings to control if audit events are cleaned up automatically and how long audit events are retained. By default, all audit events are enabled. The column includes a list of audit information required to be provided in the event s audit record addition to: date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event. The Viewing Audit column provides details on the audit location(s) for the audit event. Lastly, the column shows an example of the audit event that RSA Identity Governance and Lifecycle produces. ESM_EAU.2 Any use of an authentication mechanism. Viewing Audit All necessary details are captured in the audit events and can be viewed in the out of the box audit report. Unsuccessful Login Web GUI (Bad Credentials) 12/21/16 9:05 AM user LOGIN AuthSource ActiveDirectory FAIL 12/21/16 9:05 AM user LOGIN LoginFailureAttempt user1 FAIL 12/21/16 9:05 AM user LOGIN LoginSessionId HSHA007(c6698acbe64e2e14a58745d035cb80fee6cf6e a2a9e877c5c5af416761df47be) FAIL 12/21/16 9:05 AM user LOGIN LoginUserId user15 FAIL Unsuccessful Login Web Services (Bad Credentials) The audit records are the same except an additional audit is produced: 12/23/ : user

8 WEBSERVICES_COMMAND WebServiceCommandExecution The WebService command 'loginuser' execution is failed FAIL Successful Login Web GUI user1 User One 12/21/16 9:47 AM user LOGIN LoginSessionId HSHA007(db3f0d6237d6d ba fa9e98 ca93491e026d1f22fc27e2fae45) SUCCESS user1 User One 12/21/16 9:47 AM user LOGIN LoginUserId user1 SUCCESS user1 User One 12/21/16 9:47 AM user LOGIN AuthSource ActiveDirectory SUCCESS Successful Login Web Services (The audit records are the same except an additional audit is produced) 10: user WEBSERVICES_COMMAND WebServiceCommandExecution The WebService command 'loginuser' is executed successfully SUCCESS ESM_ICD.1 Creation or modification of identity and credential data. The attribute(s) modified Viewing Audit An audit is produced in the Audit report containing the change request id. The change request can be viewed within the user interface to see additional levels of detail (approvals and fulfillment history). Password Reset User1 User One 9/28/16 9:07 AM user REQUEST_FORM Run Request Form The Request Form Default Reset Password Form is executed Request Submitted user1 User One 9/28/16 9:08 AM user REQUEST_FORM RequestWorkItem Action performed for CR succeeded : MODIFY Enrollment or modification of subject Viewing Audit The subject The user can use the Run ID in a Collection of Users from External Business Source

9 created or modified, the attribute(s) modified (if applicable) MONITORING_DATA_RUNS audit event and view more information on the Monitoring page (Admin >Monitoring >Data Runs). An audit is produced in the Audit report containing the change request id. The change request can be viewed within the user interface to see additional levels of detail (approvals and fulfillment history). User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS AccountLoad Run id = 1082, Monitoring data run is in running state MODIFY User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS IdentityLoad Run id = 1081, Monitoring data run Completed, Run start time= :21:14, Run end time= :21:23, Elapsed run time=0: SUCCESS User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS EntitlementLoad Run id = 1069, Monitoring data run Completed, Run start time= :27:40, Run end time= :27:53, Elapsed run time=0: SUCCESS Modification of Subjects Status (Termination) User1 User One user1@aveksaus.com 9/26/16 10:41 AM user REQUEST_FORM Run Request Form The Request Form Default Termination Form is executed user1 User One user1@aveksaus.com 9/26/16 10:42 AM user REQUEST_FORM RequestWorkItem Action performed for CR succeeded : MODIFY Definition of identity and credential data that can be associated with users (activate, suspend, revoke credential, etc.) Viewing Audit An audit is produced in the Audit report containing the change request id. The change request can be viewed within the user interface to see additional levels of detail (approvals and fulfillment history). Password Reset User1 User One user1@aveksaus.com 9/28/16 9:07 AM user REQUEST_FORM Run Request Form The Request Form Default Reset Password Form is executed user1 User One user1@aveksaus.com 9/28/16 9:08 AM user REQUEST_FORM RequestWorkItem Action performed for CR succeeded : MODIFY Management of credential status

10 Viewing Audit This action usually starts from the Terminate button found on a user s detail screens. An audit is produced in the Audit report containing the change request id. The change request can be viewed within the user interface to see additional levels of detail (approvals and fulfillment history). Modification of Credential Status (Termination) User1 User One user1@aveksaus.com 9/26/16 10:41 AM user REQUEST_FORM Run Request Form The Request Form Default Termination Form is executed user1 User One user1@aveksaus.com 9/26/16 10:42 AM user REQUEST_FORM RequestWorkItem Action performed for CR succeeded : MODIFY Enrollment of users into repository Viewing Audit This action usually starts from a request button to register a user or a new user is collected. The user can use the Run ID in a MONITORING_DATA_RUNS audit event and view more information on the Monitoring page (Admin >Monitoring >Data Runs) for a collection. An audit is produced in the Audit report containing the change request id when registering a new user. The change request can be viewed within the user interface to see additional levels of detail (approvals and fulfillment history). Collection of Users from External Business Source User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS AccountLoad Run id = 1082, Monitoring data run is in running state MODIFY User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS IdentityLoad Run id = 1081, Monitoring data run Completed, Run start time= :21:14, Run end time= :21:23, Elapsed run time=0: SUCCESS User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS EntitlementLoad Run id = 1069, Monitoring data run Completed, Run start time= :27:40, Run end time= :27:53, Elapsed run time=0: SUCCESS ESM_ICT.1 All attempts to transmit information

11 The destination to which the transmission was attempted Viewing Audit The user can use the Run ID in a MONITORING_DATA_RUNS audit event and view more information on the Monitoring page (Admin >Monitoring >Data Runs). An audit is produced in the Audit report containing the change request id. The change request can be viewed within the user interface to see additional levels of detail (approvals and fulfillment history). Lastly, AFX logs are available for the endpoint where any requests are sent. Collector User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS AccountLoad Run id = 1082, Monitoring data run is in running state MODIFY User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS IdentityLoad Run id = 1081, Monitoring data run Completed, Run start time= :21:14, Run end time= :21:23, Elapsed run time=0: SUCCESS User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS EntitlementLoad Run id = 1069, Monitoring data run Completed, Run start time= :27:40, Run end time= :27:53, Elapsed run time=0: SUCCESS AFX Connector User1 User One user1@aveksaus.com 9/26/16 10:41 AM user REQUEST_FORM Run Request Form The Request Form Default Termination Form is executed user1 User One user1@aveksaus.com 9/26/16 10:42 AM user REQUEST_FORM RequestWorkItem Action performed for CR succeeded : MODIFY Configuration of circumstances in which transmission of identity and credential data is performed Viewing Audit The user can create, modify, or delete a connector or collector. All necessary details are captured in the audit events and can be viewed in the out of the box audit report. Create Collector User1 User One user1@aveksaus.com 1/30/2017 9: user ACCOUNT_COLLECTOR Create Account Collector Created Account Collector Active Directory 2 ADC CREATE User1 User One user1@aveksaus.com 1/30/2017 9: user IDENTITY_COLLECTOR Create Identity Collector Created Identity Collector Active Directory 2 IDC CREATE Modify Collector

12 User1 User One 1/30/2017 9: user ACCOUNT_COLLECTOR Modify Account Collector Modified Account Collector Active Directory 2 ADC MODIFY User1 User One user1@aveksaus.com 1/30/ : user IDENTITY_COLLECTOR Modify Identity Collector Modified Identity Collector Active Directory 2 IDC MODIFY Delete Collector User1 User One user1@aveksaus.com 1/30/ : user ACCOUNT_COLLECTOR Delete Account Collector Deleted Create Connector User1 User One user1@aveksaus.com 2/13/2017 3: user CONNECTOR Create Connector Created the connector Demo- Connector CREATE Modify Connector User1 User One user1@aveksaus.com 2/13/2017 3: user CONNECTOR Modify Connector Modified the connector Democonnector MODIFY Delete Connector User1 User One user1@aveksaus.com 2/13/2017 3: user CONNECTOR Delete Connector Deleted the connector Demo-Connector DELETE FAU_GEN.1 Start up of the audit functions Viewing Audit Shut down of the audit functions All necessary details are captured in the audit events and can be viewed in the out of the box audit report. user1 11/21/16 9:21 AM user AUDIT_SETTINGS AuditLoggingEnabled true MODIFY Viewing Audit All necessary details are captured in the audit events and can be viewed user1 11/21/16 9:20 AM user AUDIT_SETTINGS AuditLoggingEnabled

13 in the out of the box audit report. false MODIFY FAU_STG_EXT.1 Establishment of communications with audit server. Identification of audit server Viewing Audit Audit events show when the audit engine is started and stopped. Disestablishment of communications with audit server. Note: All events are logged to an internal source (database). The server must always be able to communicate with the database in order to operate. Therefore, this communication cannot be established/ disestablished through the application. Identification of audit server Viewing Audit Audit events show when the audit engine is started and stopped. Note: All events are logged to an internal source (database). The server must always be able to communicate with the database in order to operate. Therefore, this communication cannot be established/ disestablished through the application. FTA_SSL.3 All session termination events. Viewing Audit Audit events show when a session ends. Similar events can also be seen for system sessions. These are identified with attributes like LoginSystemId Server Log (termination due to timeouts): rsa INFO 1/11/17 7:57 AM Session timeout logging out user LoginID=user1 Audit Events: user1 User One user1@aveksaus.com 1/11/2017 7: user LOGOUT LogoutUserId 129 SUCCESS user1 User One user1@aveksaus.com 1/11/2017 7: user LOGOUT LogoutSessionId HSHA007(44db9ff07533deca73a18454f3de5aeb64c9f 02d45c5c4a347a3ded344e5ced1) SUCCESS FTA_SSL.4 All session termination events (from all sources).

14 Viewing Audit Audit events show when a session ends. Similar events can also be seen for system sessions. These are identified with attributes like LoginSystemId Logout Web GUI User1 User One user1@aveksaus.com 12/21/16 9:58 AM user LOGOUT LogoutUserId 129 SUCCESS User1 User One user1@aveksaus.com 12/21/16 9:58 AM user LOGOUT LogoutSessionId HSHA007(cece81ff3bbad3b7fe9b7de8a9507a8dcfdc5d fb197aa0f830c4c8ab7c354c2b) SUCCESS Logout Web Services The audit records are the same except an additional audit is produced: 10: user WEBSERVICES_COMMAND WebServiceCommandExecution The WebService command 'logoutuser' is executed successfully SUCCESS FTA_SSL_EXT.1 All session locking and unlocking events. Viewing Audit Audit events show when a session ends. Similar events can also be seen for system sessions. These are identified with attributes like LoginSystemId. Same as FTA_SSL.3 Server Log (termination due to timeouts): rsa INFO 1/11/17 7:57 AM Session timeout logging out user LoginID=user1 Audit Events: user1 User One user1@aveksaus.com 1/11/2017 7: user LOGOUT LogoutUserId 129 SUCCESS user1 User One user1@aveksaus.com 1/11/2017 7: user LOGOUT LogoutSessionId HSHA007(44db9ff07533deca73a18454f3de5aeb64c9f 02d45c5c4a347a3ded344e5ced1) SUCCESS FTP_ITC.1 All use of trusted channel functions

15 Identity of the initiator and target of the trusted channel Viewing Audit See ESM_ICD.1 The user can use the Run ID in a MONITORING_DATA_RUNS audit event and view more information on the Monitoring page (Admin >Monitoring >Data Runs). An audit is produced in the Audit report containing the change request id. The change request can be viewed within the user interface to see additional levels of detail (approvals and fulfillment history). Collector User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS AccountLoad Run id = 1082, Monitoring data run is in running state MODIFY User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS IdentityLoad Run id = 1081, Monitoring data run Completed, Run start time= :21:14, Run end time= :21:23, Elapsed run time=0: SUCCESS User1 User One 12/21/16 9:21 AM user MONITORING_DATA_RUNS EntitlementLoad Run id = 1069, Monitoring data run Completed, Run start time= :27:40, Run end time= :27:53, Elapsed run time=0: SUCCESS AFX Connector User1 User One user1@aveksaus.com 9/26/16 10:41 AM user REQUEST_FORM Run Request Form The Request Form Default Termination Form is executed Configuration of actions that require trusted channel (if applicable) Viewing Audit These events occur when particular objects are created, modified, or deleted (collectors, connectors, authentication sources). All of these actions produce audit events. Create Collector User1 User One user1@aveksaus.com 1/30/2017 9: user ACCOUNT_COLLECTOR Create Account Collector Created Account Collector Active Directory 2 ADC CREATE User1 User One user1@aveksaus.com 1/30/2017 9: user IDENTITY_COLLECTOR Create Identity Collector Created Identity Collector Active Directory 2 IDC CREATE Modify Collector User1 User One user1@aveksaus.com 1/30/2017 9: user ACCOUNT_COLLECTOR Modify Account Collector Modified Account Collector Active Directory 2 ADC

16 MODIFY User1 User One 1/30/ : user IDENTITY_COLLECTOR Modify Identity Collector Modified Identity Collector Active Directory 2 IDC MODIFY Delete Collector User1 User One user1@aveksaus.com 1/30/ : user ACCOUNT_COLLECTOR Delete Account Collector Deleted Account Collector Active Directory 2 ADC DELETE User1 User One user1@aveksaus.com 1/30/ : user IDENTITY_COLLECTOR Delete Identity Collector Deleted Identity Collector Active Directory 2 IDC DELETE Create Connector User1 User One user1@aveksaus.com 2/13/2017 3: user CONNECTOR Create Connector Created the connector Demo- Connector CREATE Modify Connector User1 User One user1@aveksaus.com 2/13/2017 3: user CONNECTOR Modify Connector Modified the connector Democonnector MODIFY Delete Connector User1 User One user1@aveksaus.com 2/13/2017 3: user CONNECTOR Delete Connector Deleted the connector Demo-Connector DELETE Create Authentication Source 13: user AUTH_SOURCE CollectorId 49 CREATE 13: user AUTH_SOURCE CollectorType I CREATE 13: user AUTH_SOURCE ProviderType ActiveDirectoryCollector CREATE

17 13: user AUTH_SOURCE ProviderName ActiveDirectory2 CREATE Modify Authentication Source User1 User One 1/12/2017 9: user AUTH_SOURCE ProviderType ActiveDirectoryCollector MODIFY User1 User One 1/12/2017 9: user AUTH_SOURCE ProviderName ActiveDirectory2 MODIFY User1 User One 1/12/2017 9: user AUTH_SOURCE CollectorType I MODIFY Delete Authentication Source 13: user AUTH_SOURCE ProviderName ActiveDirectory2 DELETE FTP_TRP.1 All attempted uses of the trusted path functions Identification of user associated with all trusted path functions, if available Viewing Audit All necessary details are captured in the audit events and can be viewed in the out of the box audit report. Web GUI user1 User One user1@aveksaus.com 12/21/16 9:47 AM user LOGIN LoginSessionId HSHA007(db3f0d6237d6d ba fa9e9 8ca93491e026d1f22fc27e2fae45) SUCCESS user1 User One user1@aveksaus.com 12/21/16 9:47 AM user LOGIN LoginUserId user1 SUCCESS user1 User One user1@aveksaus.com 12/21/16 9:47 AM user LOGIN AuthSource ActiveDirectory SUCCESS Web Services The audit records are the same except an additional audit is produced: 10: user WEBSERVICES_COMMAND WebServiceCommandExecution The WebService

18 command 'loginuser' is executed successfully SUCCESS Configuration of actions that require trusted path (if applicable). Identification of user associated with all trusted path functions, if available Viewing Audit The configuration of the Web GUI over TLS/HTTPS occurs during the installation process and therefor is not audited by the TOE. Enabling/disabling web services is recorded as an audit event. Enable Secure Web Services User1 11/21/16 1:35 PM User SECURITY_SETTINGS WebServicesRequireSecurity true MODIFY Disable Secure Web Services User1 11/21/16 1:37 PM User SECURITY_SETTINGS WebServicesRequireSecurity false MODIFY FTA_TAB.1 Maintenance of the banner Identification of user associated with all trusted path functions, if available Viewing Audit All necessary details are captured in the audit events and can be viewed in the out of the box audit report. This event occurs when the banner is modified under Admin >System >Security User1 User One 12/23/16 7:52 AM user AUTH_SOURCE LoginPagePasswordText password MODIFY User1 User One 12/23/16 7:52 AM user AUTH_SOURCE LoginPageNameText UserName MODIFY User1 User One 12/23/16 7:51 AM user AUTH_SOURCE LoginPageMessage Warning! This device is for CC Authorized Users only! Test MODIFY FTA_SSL.3 & FTA_SSL_ESXT.1 Configuration of the inactivity period for session termination Viewing Audit All necessary details are captured in the audit events and can be viewed in the out of the box audit report. This event occurs when the session timeout is modified under Admin >System >Security Web GUI User1 User One 12/21/16 11:37 AM user SYSTEM_SETTING SessionTimeoutWarning 60 MODIFY User1 User One 12/21/16 11:37 AM user SYSTEM_SETTING SessionTimeout 999 MODIFY

19 Web Services User1 User One 12/23/16 6:54 AM user SECURITY_SETTINGS TokenInactivityTimeout 5 MODIFY User1 User One 12/23/16 6:54 AM user SECURITY_SETTINGS TokenLifetimeTimeout 5 MODIFY ESM_EAU.2 & ESM_EID.2 Management of authentication data for both interactive users and authorized IT entities (if managed by the TSF) Viewing Audit All necessary details are captured in the audit events and can be viewed in the out of the box audit report. These events occur when authentication sources are created, modified, or deleted from the Admin >System >Authentication screen. Create Authentication Source 13: user AUTH_SOURCE CollectorId 49 CREATE 13: user AUTH_SOURCE CollectorType I CREATE 13: user AUTH_SOURCE ProviderType ActiveDirectoryCollector CREATE 13: user AUTH_SOURCE ProviderName ActiveDirectory2 CREATE Modify Authentication Source User1 User One user1@aveksaus.com 1/12/2017 9: user AUTH_SOURCE ProviderType ActiveDirectoryCollector MODIFY User1 User One user1@aveksaus.com 1/12/2017 9: user AUTH_SOURCE ProviderName ActiveDirectory2 MODIFY User1 User One user1@aveksaus.com 1/12/2017 9: user AUTH_SOURCE CollectorType I MODIFY Delete Authentication Source 13: user AUTH_SOURCE ProviderName ActiveDirectory2 DELETE

20 FTM_MOF.1 Management of sets of users that can interact with security functions Viewing Audit An audit is produced in the Audit report containing the change request id. The change request can be viewed within the user interface to see additional levels of detail (approvals and fulfillment history). Add User to Role user1 User One 1/30/17 11:20 AM user REQUEST_FORM RequestWorkItem Action performed for CR succeeded : MODIFY Remove User from Role user1 User One user1@aveksaus.com 1/30/17 11:32 AM user REQUEST_FORM RequestWorkItem Action performed for CR succeeded : MODIFY FMT_SMR.1 Management of the users that belong to a particular role. Viewing Audit An audit is produced in the Audit report containing the change request id. The change request can be viewed within the user interface to see additional levels of detail (approvals and fulfillment history). Add User to Role user1 User One user1@aveksaus.com 1/30/17 11:20 AM user REQUEST_FORM RequestWorkItem Action performed for CR succeeded : MODIFY Remove User from Role user1 User One user1@aveksaus.com 1/30/17 11:32 AM user REQUEST_FORM RequestWorkItem Action performed for CR succeeded : MODIFY FIA_USB.1 Definition of default subject security attributes, modification of subject security attributes Viewing Audit All necessary details are captured in the audit events and can be viewed in the out of the box audit report. See example audits from ESM_ICD.1 This is like the management

21 functions for ESM_ICD.1.

22 Audit Locations There are several locations in RSA Identity Governance and Lifecycle where audit information is captured: Audit events Monitoring information collections, reviews, rules Change requests Access Certification (reviews) Rule remediation Server side logs Audit Events Events that are captured as part of the audit component in RSA Identity Governance and Lifecycle are configured on the Admin >System >Audit screen. Audit events are persisted in the internal database that ships with the product. An out of the box report is provided to view the audit events for the last 30 days. Please refer to the Audit Events section and for Events found in the Online Help [8]. Monitoring In addition to capturing the audit event, administrators can view what collections, reviews, and rules have run in the system from the Admin >Monitoring >Data Runs. The details including steps and access to logs for each run can be found by clicking on the Run ID. Please refer to the Viewing Running and Completed Processing Runs section found in the Online Help [8]. Change Requests Audit events for submitted request forms show the id for the change request. In addition to this, any submitted request can be viewed from the Requests >Requests screen. An administrator can see details related to what was requested, who approved it, and what endpoints were involved in fulfilling the request. Any details related to delegation, escalations, or rejections to the request are also captured in these screens. Please refer to the section Working with Change Requests found in the Online Help [8]. Access Certification Access Certification (Reviews) is an important part of the governance lifecycle. Reviews are run based on the business requirements. Some businesses may run quarterly reviews to look at what access users have. Other businesses may run monthly reviews based on any access that is detected as violations by defined rules. Regardless of the frequency of the review, a review captures all the audit data about what was reviewed, who was responsible for reviewing, and any decisions made. Any actions to reassign work are also captured as review history. Please refer to the sections Performing Reviews and View and Enter Review Comments and View Review Item History found in the Online Help [8]. Out of the box report templates are also available to look at review related data. The templates can be found when creating a report under the Reports >Tabular screen.

23 Rule Remediation Businesses can define rules to detect conditions and react to them. In particular, user access rules are useful for detecting if users have access they shouldn t have. Similarly, unauthorized change detection rules are used to detect any access granted outside of RSA Identity Governance and Lifecycle. For more information on the types of rules available, please refer to Rule Types found in the Online Help [8]. When rules are evaluated, violations are created for any conditions found. Automatic actions like generating a change request or creating a review may occur or a remediator may be assigned to look closer at the violation. Like change requests, the violation history can be viewed along with actions taken like a decision made but a remediator. Please refer to the section Working with Rule Violations found in the Online Help [8] for more details. Server Side Logs logs can be seen for the server(s) from the Admin >System >Server Nodes screen. Administrators have access to the aveksaserver.log file among other files. Similarly, the logs for an AFX Server can be accessed from the AFX >Servers screen by clicking on the name of the server and going to the Logs tab. Individual connectors deployed on the AFX Server(s) also have log files that are viewable by navigating to AFX >Connectors and clicking on a connector name. The Logs tab shows the details for that connector.