© 2009 RSA®, The Security Division of EMC RSA®, The Security Division of EMC RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Security Target Evaluation Assurance Level: EAL2 Augmented with ALC_FLR.1 Document Version: 1.0 Prepared for: Prepared by: RSA®, The Security Division of EMC Corsec Security, Inc. 7 Shenkar Street, 4 th floor Herzlia, IL 46733 10340 Democracy Lane, Suite 201 Fairfax, VA 22030 Phone: (972) 972-8100 Phone: (703) 267-6050 http://www.rsa.com http://www.corsec.com Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 2 of 72 © 2009 RSA®, The Security Division of EMC Revision History Version Modification Date Modified By Description of Changes 0.1 2008-03-31 Darryl H. Johnson Initial draft (for informal review). 0.2 2008-04-11 Darryl H. Johnson Second draft (for formal review) 0.3 2008-05-27 Nathan Lee Updates based on RSA feedback. 0.4 2008-06-12 Nathan Lee Updates based on ORs. 0.5 2008-08-12 Nathan Lee Updates based on ORs. 0.6 2008-11-14 Chris Truncer Updates based on ORs. 0.7 2008-12-18 Christopher Truncer Updates based on ORs. 1.0 2009-02-04 Nathan Lee Finalized for release. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 3 of 72 © 2009 RSA®, The Security Division of EMC Table of Contents 1 SECURITY TARGET INTRODUCTION........................................................................................................5 1.1 PURPOSE ......................................................................................................................................................5 1.2 SECURITY TARGET AND TOE REFERENCES..................................................................................................6 1.3 TOE OVERVIEW...........................................................................................................................................6 1.3.1 Brief Description of the Components of the TOE............................................................................6 1.3.2 TOE Environment ...........................................................................................................................8 1.3.3 TOE Guidance Documentation .......................................................................................................8 1.4 TOE DESCRIPTION .....................................................................................................................................10 1.4.1 Physical Scope ..............................................................................................................................10 1.4.2 Logical Scope................................................................................................................................11 1.4.3 Physical/Logical Features and Functionality Excluded from the Evaluated Configuration of the TOE.....................................................................................................................................12 2 CONFORMANCE CLAIMS............................................................................................................................13 3 SECURITY PROBLEM DEFINITION ..........................................................................................................14 3.1 THREATS TO SECURITY ..............................................................................................................................14 3.2 ORGANIZATIONAL SECURITY POLICIES......................................................................................................15 3.3 ASSUMPTIONS ............................................................................................................................................15 4 SECURITY OBJECTIVES ..............................................................................................................................17 4.1 SECURITY OBJECTIVES FOR THE TOE ........................................................................................................17 4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT.................................................................17 4.2.1 IT Security Objectives ...................................................................................................................17 4.2.2 Non-IT Security Objectives ...........................................................................................................18 5 EXTENDED COMPONENTS DEFINITION ................................................................................................19 5.1 EXTENDED TOE SECURITY FUNCTIONAL COMPONENTS............................................................................19 5.1.1 Class FCR: Case Recording and Review......................................................................................19 5.2 EXTENDED TOE SECURITY ASSURANCE COMPONENTS .............................................................................25 6 SECURITY REQUIREMENTS.......................................................................................................................26 6.1 CONVENTIONS............................................................................................................................................26 6.2 SECURITY FUNCTIONAL REQUIREMENTS....................................................................................................26 6.2.1 Class FDP: User Data Protection ................................................................................................29 6.2.2 Class FIA: Identification and Authentication ...............................................................................35 6.2.3 Class FMT: Security Management................................................................................................39 6.2.4 Class FPT: Protection of the TSF.................................................................................................42 6.2.5 Class FCR: Case Recording and Review......................................................................................43 6.3 SECURITY ASSURANCE REQUIREMENTS.....................................................................................................45 7 TOE SUMMARY SPECIFICATION..............................................................................................................46 7.1 TOE SECURITY FUNCTIONS .......................................................................................................................46 7.1.1 User Data Protection....................................................................................................................47 7.1.2 Identification and Authentication..................................................................................................48 7.1.3 Security Management....................................................................................................................49 7.1.4 Protection of the TSF ....................................................................................................................50 7.1.5 Case Recording and Review..........................................................................................................50 8 RATIONALE.....................................................................................................................................................51 8.1 CONFORMANCE CLAIMS RATIONALE .........................................................................................................51 8.2 SECURITY OBJECTIVES RATIONALE ...........................................................................................................51 8.2.1 Security Objectives Rationale Relating to Threats........................................................................53 8.2.2 Security Objectives Rationale Relating to Policies.......................................................................55 8.2.3 Security Objectives Rationale Relating to Assumptions................................................................56 8.3 RATIONALE FOR EXTENDED SECURITY FUNCTIONAL REQUIREMENTS.......................................................58 Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 4 of 72 © 2009 RSA®, The Security Division of EMC 8.4 RATIONALE FOR EXTENDED TOE SECURITY ASSURANCE REQUIREMENTS................................................58 8.5 SECURITY REQUIREMENTS RATIONALE......................................................................................................58 8.5.1 Rationale for Security Functional Requirements of the TOE Objectives ......................................61 8.5.2 Security Assurance Requirements Rationale.................................................................................67 8.5.3 Dependency Rationale ..................................................................................................................67 9 ACRONYMS......................................................................................................................................................71 Table of Figures FIGURE 1 – DETAILED DECOMPOSITION OF THE RSA AA SYSTEM.................................................................................7 FIGURE 2 – PHYSICAL TOE BOUNDARY.......................................................................................................................10 FIGURE 3 – EXT_FCR: CASE RECORDING AND REVIEW FUNCTION CLASS DECOMPOSITION ......................................20 FIGURE 4 – EXT_FCR_ARP COMPONENT LEVELING..................................................................................................21 FIGURE 5 – EXT_FCR_GEN COMPONENT LEVELING .................................................................................................22 FIGURE 6 – EXT_FCR_CDA COMPONENT LEVELING .................................................................................................23 List of Tables TABLE 1 – ST AND TOE REFERENCES............................................................................................................................6 TABLE 2 – THREATS .....................................................................................................................................................14 TABLE 3 – ORGANIZATIONAL SECURITY POLICIES .......................................................................................................15 TABLE 4 – ASSUMPTIONS .............................................................................................................................................15 TABLE 5 – SECURITY OBJECTIVES FOR THE TOE .........................................................................................................17 TABLE 6 – IT SECURITY OBJECTIVES ...........................................................................................................................17 TABLE 7 – NON-IT SECURITY OBJECTIVES...................................................................................................................18 TABLE 8 – EXTENDED TOE SECURITY FUNCTIONAL REQUIREMENTS..........................................................................19 TABLE 9 – EXTENDED TOE SECURITY FUNCTIONAL REQUIREMENTS..........................................................................19 TABLE 10 – TOE SECURITY FUNCTIONAL REQUIREMENTS ..........................................................................................26 TABLE 11 – ASSURANCE REQUIREMENTS.....................................................................................................................45 TABLE 12 – MAPPING OF TOE SECURITY FUNCTIONS TO SECURITY FUNCTIONAL REQUIREMENTS.............................46 TABLE 13 – MAPPING OF TOE SECURITY OBJECTIVES TO THREATS AND POLICIES .....................................................52 TABLE 14 – THREATS/OBJECTIVES MAPPING...............................................................................................................53 TABLE 15 – POLICIES/OBJECTIVES MAPPING ...............................................................................................................55 TABLE 16 – ASSUMPTIONS/OBJECTIVES MAPPING .......................................................................................................56 TABLE 17 – MAPPING OF SFRS TO TOE SECURITY OBJECTIVES ..................................................................................59 TABLE 18 – OBJECTIVES/SFRS MAPPING.....................................................................................................................61 TABLE 19 – FUNCTIONAL REQUIREMENTS DEPENDENCIES ..........................................................................................67 TABLE 20 – ACRONYMS ...............................................................................................................................................71 Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 5 of 72 © 2009 RSA®, The Security Division of EMC 1 Security Target Introduction This section identifies the Security Target (ST), Target of Evaluation (TOE), and the ST organization. The Target of Evaluation is the RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1, and will hereafter be referred to as the TOE throughout this document. The TOE is a risk-based authentication system that provides additional layers of security to organizations with a web presence . The TOE provides additional authentication measures using user credentials, positive device identification, and risk analysis during login and continuously during transaction processing. 1.1 Purpose This ST provides mappings of the Security Environment to the Security Requirements that the TOE meets in order to remove, diminish, or mitigate the defined threats in the following sections: Security Target Introduction (Section 1) – Provides a brief summary of the ST contents and describes the organization of other sections within this document. It also provides an overview of the TOE security functions and describes the physical and logical scope for the TOE. Conformance Claims (Section 2) – Provides the identification of any Common Criteria (CC), Protection Profile, and Evaluation Assurance Level (EAL) package claims. Security Problem Definition (Section 3) – Describes the threats, policies, and assumptions that pertain to the TOE and its environment. Security Objectives (Section 4) – Identifies the security objectives that are satisfied by the TOE and its environment. Extended Components Definition (Section 5) – Identifies extended Security Functional Requirements (SFRs) and extended Security Assurance Requirements (SARs) that are not included in CC Part 2 or CC Part 3. Security Requirements (Section 6) – Presents the SFRs and SARs met by the TOE. TOE Summary Specification (Section 7) – Describes the security functions provided by the TOE that satisfy the security functional requirements and objectives. Rationale (Section 8) – Presents the rationale for the security objectives, requirements, and SFR dependencies as to their consistency, completeness, and suitability. Acronyms (Section 9) – Defines the acronyms used within this ST. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 6 of 72 © 2009 RSA®, The Security Division of EMC 1.2 Security Target and TOE References Table 1 – ST and TOE References ST Title RSA®, The Security Division of EMC RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Security Target ST Version Version 1.0 ST Author Corsec Security, Inc. Darryl H. Johnson and Nathan Lee ST Publication Date February 4, 2009 TOE Reference RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Keywords RSA, EMC, Adaptive Authentication 1.3 TOE Overview The RSA Adaptive Authentication (AA) System is a risk-based authentication platform that provides additional layers of security to companies with an online presence. The RSA AA System uses positive device identification and risk analysis to ensure that only genuine online customers can access their accounts. The RSA AA System provides additional authentication measures during login and continuous monitoring of each transaction. If a single transaction (or series of transactions) increases the perceived risk level, the online customer may be challenged to provide additional authentication, or the transaction can be flagged for later review. RSA AA System v6.0.2.1 with Service Pack 1 (build # 1831) is the evaluated version of the product. 1.3.1 Brief Description of the Components of the TOE The RSA AA System is composed of several parts that are primarily written in Java. The product can be distributed across several servers or deployed with all the product components installed on a single server. Figure 1 below shows a detailed decomposition of the RSA AA System. The product can be divided into several major components: Core Components Back Office Applications Adaptive Authentication Utilities Data and Configuration Databases External Network Interfaces Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 7 of 72 © 2009 RSA®, The Security Division of EMC Figure 1 – Detailed Decomposition of the RSA AA System The Core Components provide the fundamental functionality of transaction risk assessment, authentication processing based on risk, and transaction policies enforcement. The Risk Engine, Policy Manager, and Multi- credential Framework make up the Core Components. An online website that relies on the RSA AA System will send individual transactions to the product via SOAP messages conveyed using Hypertext Transfer Protocol over Secure Sockets Layer (https). Transactions can be initial authentication requests or other specific transaction events from the online application. All transactions enter the product over the Adaptive Authentication Web Services Interface, a well-defined application programming interface (API) for Web Services using Web Services Description Language (WSDL). The Risk Engine takes information from a variety of sources, including the online application, and performs a risk analysis to determine how much risk a transaction presents. The risk score from the Risk Engine is used as an input to the Policy Manager. The Policy Manager enforces the transaction handling policies that are defined by the system administrators. The policy decision trees will result in a decision of Allow, Deny, Challenge, or Review for each transaction the RSA AA System processes. If a policy decision of Challenge is reached, the RSA AA System can provide several additional authentication mechanisms to authenticate the online customer. The product can provide challenge questions or require an out-of-band action such as a response to an e-mail or phone call to authenticate the customer. This product supports two types of users. There are Back Office Users who are the administrators of the product. Back Office Users will configure and maintain the system and enter the policies that the product will enforce. There are also End Users who are the online customers that will be subjected to the authentication policies. Administrators of the RSA AA System administer the device using a set of Back Office Applications. The Access Management, Admin Tool, Report Viewer, Customer Service Representative (CSR) Tool, Policy Editor, and Case Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 8 of 72 © 2009 RSA®, The Security Division of EMC Management applications make up the Back Office Applications. The Access Management tool provides a single interface for access to the Back Office applications. It allows administrators to create Back Office Users and manage roles and permissions for the different Back Office applications. The Admin Tool can be used to add, remove, and save elements from security risk lists such as country or Internet Protocol (IP) blacklists, watch lists, and white lists. The Report Viewer allows administrators to view daily, weekly, or monthly reports created by the RSA Data Center; the Report Viewer does not generate reports. The CSR Tool is designed to help Customer Service Representatives (CSRs) look up and modify user account information as the user interacts with the RSA AA System. The Policy Editor allows Back Office Users to configure and customize the necessary policies by which the RSA AA System detects and challenges potentially risky End Users, marks transactions for review by Fraud Analysts, allows valid End Users, or denies fraudulent End Users. The Case Management tool is used to review any events that have been flagged as risky by the RSA AA System, and requires review by a Fraud Analyst. There are a number Adaptive Authentication Utilities that run in the background or provide specific configuration tools for the RSA AA System. These utilities can be used by administrators to help manage the RSA AA System and troubleshoot any problems. The following utilities are included in the Adaptive Authentication Utilities: Health Check Servlet Simple Mail Transfer Protocol (SMTP) and HTTP to Voice Extensible Markup Language (VXML) or Telephony Aggregator Token Generator Log Manager Policy Simulator Billing Utility GeoIP Admin Tool GeoIP Inspector Utility Risk Engine Offline Task Utility Orgs & Groups Config Tool The RSA AA System utilizes three primary data stores: Tools Database, Case Management Database, and the AA Database. The Tools Database stores the authentication credentials and privileges for the administrators that authenticate and use the Back Office Applications. The Case Management Database contains events that have been flagged as risky by the RSA AA System, and requires review by a Fraud Analyst. The AA Database is the primary data store for the Core Components. It contains the policy table information for the Policy Manager and the End User credentials other than user name and password, including secret questions and responses. 1.3.2 TOE Environment The TOE is intended to be deployed on a general purpose computer in a physically secured room or data center with the appropriate level of physical access control and physical protection (e.g. fire control, locks, alarms, etc.). The TOE is intended to be managed by administrators operating under a consistent security policy. 1.3.3 TOE Guidance Documentation The following is a list of the guidance documentation that comes with the TOE to help with the installation, configuration, and use of the TOE: Access Management User’s Guide v6.0.2.1. rev 1.2, published October 30, 2007 & Doc Number CUS-029- 007-ENG Admin Tool User’s Guide v6.0.2.1. rev 1.4, published October 29, 2007 & Doc Number CUS-020-001- ENG Architectural Overview v6.0.2.1. rev 1.5, published October 29, 2007 & Doc Number CUS-021-010-ENG Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 9 of 72 © 2009 RSA®, The Security Division of EMC Best Practices for Choosing Challenge Questions v6.0.2.1. rev 1.8, published November 1, 2007 & Doc Number CUS-032-001-PDM Case Management User’s Guide v6.0.2.1. rev 1.7, published October 30, 2007 & Doc Number CUS-029- 006-ENG Configuration Framework User’s Guide v6.0.2.1. rev 2.5, published October 25, 2007 & Doc Number CUS- 022-017-ENG CSR Tool User’s Guide v6.0.2.1. rev 1.5, published September 7, 2007 & Doc Number CUS-029-001-ENG Authentify ACSP Developer’s Guide v6.0.2.1. rev 1.0, published November 8, 2007 & Doc Number WSI- 023-009-ENG Integration Guide v6.0.2.1. rev 1.4, published October 31, 2007 & Doc Number CUS-023-005-ENG Operations Handbook v6.0.2.1. rev 2.5, published November 1, 2007 & Doc Number CUS-024-002-ENG Policy Editor User’s Guide v6.0.2.1. rev 1.6, published October 30, 2007 & Doc Number CUS-029-002- FOR Policy Simulator User’s Guide v6.0.2.1. rev 1.2, published October 30, 2007 & Doc Number CUS-029-007- ENG Web Service Reference Guide v6.0.2.1. rev 1.2, published October 30, 2007 & Doc Number CUS-029-007- ENG AdminService & ImageService Reference Guide v6.0.2.1. rev 2.2, published August 29, 2007 & Doc Number WSI-023-004-ENG Release Notes v6.0.2.1. rev 1.2, published November 2, 2007 & Doc Number ENG-028-026-ENG Reporting & Logging v6.0.2.1. rev 1.6, published October 26, 2007 & Doc Number CUS-027-008-ENG Report Viewer User’s Guide v6.0.2.1. rev 1.5, published September 7, 2007 & Doc Number CUS-029-004- ENG The RSA Risk Engine Upgrade Guide v6.0.2.1. rev 1.5, published October 26, 2007 & Doc Number FOR- 021-003-FOR Workflows & Processes v6.0.2.1. rev 1.2, published October 26, 2007 & Doc Number CUS-032-003-PDM Authentify ACSP Developer’s Guide v6.0.2.1. rev 1.0, published November 8, 2007 & Doc Number WSI- 023-009-ENG eFraudNetwork™ Agent Installation & Admin Guide v6.0.2.1. rev 1.2, published October 2, 2007 & Doc Number CUS-022-016-ENG Back Office Tools Installation Guide v6.0.2.1. rev 2.0, published October 30, 2007 & Doc Number CUS- 022-018-ENG Back Office Database Installation Guide v6.0.2.1. rev 2.0, published October 30, 2007 & Doc Number CUS-022-020-ENG Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 10 of 72 © 2009 RSA®, The Security Division of EMC Database Installation Guide v6.0.2.1. rev 1.0, published October 30, 2007 & Doc Number CUS-022-009- ENG 1.4 TOE Description This section will primarily address the physical and logical components of the TOE included in the evaluation. Figure 2 illustrates the physical scope and the physical boundary of the overall solution and ties together all of the components of the TOE and the constituents of the TOE Environment. Operating System (Microsoft Windows or Sun Solaris) Application Server (IBM Websphere or Apache Tomcat) Back Office Apps Adaptive Authentication Utilities External Network Interfaces Core Components Multi-credential Framework Risk Engine Policy Manager TOE Boundary * - Databases can be installed locally or on a remote server Operating System (Microsoft Windows or Sun Solaris) Databases* TOE Security Functional Interface Figure 2 – Physical TOE Boundary 1.4.1 Physical Scope The RSA AA System is a risk-based authentication application that executes on a general purpose computer (GPC). The essential physical components for the proper operation of the TOE in the evaluated configuration consist of the GPC hardware. The GPC (in particular, the resident operating system and networking components) provides the basic operating system functions, such as system resource management and communications between the hardware and software, plus other core functionality, such as object store, network stack, etc. 1.4.1.1 TOE Software The RSA AA System is a software TOE that requires an application server to run. The product will run with IBM Websphere, Apache Tomcat, or BEA Weblogic application servers. With an application server providing a Java runtime environment, the product can be installed on numerous versions of IBM AIX, Microsoft Windows, Linux, Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 11 of 72 © 2009 RSA®, The Security Division of EMC and Sun Solaris operating systems. The product can be distributed across several servers or deployed with all the product components installed on a single server. The RSA AA System relies on the presence of a database application to store data and configurations. The RSA AA product supports the use of Microsoft SQL Server, Oracle (Windows or Linux versions), and IBM DB2 (Windows, Linux, or AIX versions). For this evaluation, the TOE will be installed on a single server, with databases resident on a separate machine. The TOE testing platforms will consist of the following external environmental components: Operating systems: Microsoft Windows 2003; SUN Solaris 10 Application servers: IBM Websphere 6.1; Apache Tomcat 5.5 Database applications: Oracle 10g; Microsoft SQL Server 2005 1.4.2 Logical Scope The security functional requirements implemented by the TOE are usefully grouped under the following Security Function Classes: User Data Protection Identification and Authentication Security Management Protection of the TSF Case Recording and Review 1.4.2.1 User Data Protection The TOE provides authorized administrators with the ability to set up security policies using the Policy Manager. The Policy Manager provides for the creation of rules that define certain actions the TOE should take based on a set of conditions. These policies define the conditions under which End Users are required to provide additional authentication credentials. 1.4.2.2 Identification and Authentication The TOE provides the ability for administrators to manage the security functions of the TOE and user access to TOE functionality. The identification and authentication security function ensures that access to configuration and management functionality available via the Back Office Tools component of the TOE is restricted to authorized TOE users and access is protected by the entry of credentials. Administrators are assigned a role to determine what aspects of the TOE they are allowed to manage. End User authentication is supported by the RSA AA System’s layered security approach. While initial logins are validated by the front-end application, the RSA AA System provides additional validation using information collected from each enrolled End User. Risk analysis is performed on logins (and other requested transactions) and recommendations are made regarding how to proceed. End Users who have not previously used the RSA AA System’s services can be required by the front-end application to enroll in the RSA AA System, providing challenge questions to be used by the system to verify their identity later, and choosing a personal image and text phrase by which the End User can authenticate that they are connected to the correct front-end application. 1.4.2.3 Security Management Upon installation, the TOE includes a default set of roles that have associated permissions. The roles and permissions define which administrators have access to which information. Authorized administrators can also create new roles and permission sets as required. The Security Management function also provides administrators with the ability to properly manage and configure the TOE. TOE administrators can use the Policy Editor tool to create rules that control the flow of end user information. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 12 of 72 © 2009 RSA®, The Security Division of EMC 1.4.2.4 Protection of the TSF The TOE provides reliable timestamp information for its own use. The TOE software retrieves the timestamp from the operating system of the host hardware platform. The timestamps are used in the generation of case records. 1.4.2.5 Case Recording and Review The TOE provides the means to monitor End User transactions for potentially fraudulent activities. Information from logins and transactions that are deemed potentially fraudulent can be generated and saved to a case log for later review by a Fraud Analyst. 1.4.3 Physical/Logical Features and Functionality Excluded from the Evaluated Configuration of the TOE This evaluation includes all the physical/logical features and functionality available in the listed configuration(s) of the TOE, except for the eFraudNetwork Agent, which is disabled in the CC-evaluated configuration. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 13 of 72 © 2009 RSA®, The Security Division of EMC 2 Conformance Claims This section provides the identification for any CC, Protection Profile, and EAL package conformance claims. Rationale is provided for any extensions or augmentations to the conformance claims. Rationale for CC and PP conformance claims can be found in Section 8.1. Table 2 – CC and PP Conformance Common Criteria (CC) Identification and Conformance Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 2, September 2007; CC Part 2 extended; CC Part 3 conformant; PP claim (none). PP Identification None Evaluation Assurance Level EAL2 (Augmented with ALC_FLR.1) Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 14 of 72 © 2009 RSA®, The Security Division of EMC 3 Security Problem Definition This section describes the security aspects of the environment in which the TOE will be used and the manner in which the TOE is expected to be employed. It provides the statement of the TOE security environment, which identifies and explains all: Known and presumed threats countered by either the TOE or by the security environment Organizational security policies with which the TOE must comply Assumptions about the secure usage of the TOE, including physical, personnel, and connectivity aspects 3.1 Threats to Security This section identifies the threats to the IT assets against which protection is required by the TOE or by the security environment. The threat agents are divided into two categories: Attackers who are not TOE users: They have public knowledge of how the TOE operates and are assumed to possess a low skill level, limited resources to alter TOE configuration settings/parameters and no physical access to the TOE. TOE users: They have extensive knowledge of how the TOE operates and are assumed to possess a high skill level, moderate resources to alter TOE configuration settings/parameters and physical access to the TOE. (TOE users are, however, assumed not to be willfully hostile to the TOE.) Both are assumed to have a low level of motivation. The IT assets requiring protection are the user data saved on or transitioning through the TOE and the hosts on the protected network. Removal, diminution, and mitigation of the threats are through the objectives identified in Section 4 – Security Objectives. The following threats are applicable: Table 2 – Threats Name Description T.DOS An attacker may attempt to flood the TOE with network traffic, rendering the TOE’s services inaccessible to authorized users. T.FRAUD An attacker may take advantage of weak authentication mechanisms to commit fraudulent activities against the host application employing the TOE. T.MASQUERADE An attacker may masquerade as another entity in order to gain unauthorized access to data or TOE resources. T.TAMPERING An attacker may be able to bypass the TOE’s security mechanisms by tampering with the TOE or TOE environment. T.UNAUTH An attacker may gain access to security data on the TOE, even though the user is not authorized in accordance with the TOE security policy. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 15 of 72 © 2009 RSA®, The Security Division of EMC 3.2 Organizational Security Policies An organizational security policy (OSP) is a set of security rules, procedures, or guidelines imposed by an organization on the TOE or the operational environment of the TOE. The following OSPs are presumed to be imposed by any organization implementing the TOE in the CC-evaluated configuration: Table 3 – Organizational Security Policies Name Description P.ADMIN The TOE shall provide a set of tools for the secure management of TOE data and functions. P.CASELOG The TOE shall have the capability to record “high-risk” events and activities in a case log for later review. P.INTEGRITY Data collected and produced by the TOE shall be protected from unauthorized deletion or modification. P.MANAGE The TOE shall only be managed by authorized users. P.RECOMMEND The TOE shall make recommendations regarding the submission of authentication credentials based on a calculated risk associated with the login attempt or transaction. P.RISK The TOE shall have the capability to compute a “risk factor” for a given end user login attempt or transaction. 3.3 Assumptions This section describes the security aspects of the intended environment for the evaluated TOE. The operational environment must be managed in accordance with assurance requirement documentation for delivery, operation, and user guidance. The following specific conditions are required to ensure the security of the TOE and are assumed to exist in an environment where this TOE is employed. Table 4 – Assumptions Name Description A.AUDIT The operating system, that the TOE is installed on, is correctly configured by the administrator to audit all administrative actions that the administrator deems necessary. A.INSTALL The TOE is properly installed on a hardware and operating system capable of supporting all of its required functionality. A.LOCATE The TOE is located within a controlled access facility. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 16 of 72 © 2009 RSA®, The Security Division of EMC Name Description A.MANAGE There are one or more competent individuals assigned to manage the TOE and the security of the information it contains. A.NETCON The TOE environment provides a private network which allows the TOE to provide its security functions to TOE components, the database server, front-end applications, and the RSA Data Center. A.NOEVIL The users who manage the TOE are non-hostile, appropriately trained, and follow all guidance. A.PROTECT The TOE software will be protected from unauthorized modification. A.TIMESTAMP The IT environment provides the TOE with the current time, which is used by the TOE to generate reliable time stamps. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 17 of 72 © 2009 RSA®, The Security Division of EMC 4 Security Objectives Security objectives are concise, abstract statements of the intended solution to the problem defined by the security problem definition (see Section 3). The set of security objectives for a TOE form a high-level solution to the security problem. This high-level solution is divided into two parts: the security objectives for the TOE and the security objectives for the TOE’s operational environment. This section identifies the security objectives for the TOE and its supporting environment. A mapping of the objectives to the threats, OSPs, and assumptions included in the security problem definition is provided in Section 8. This mapping also provides rationale for how the threats, OSPs, and assumptions are effectively and fully addressed by the security objectives. 4.1 Security Objectives for the TOE The specific security objectives for the TOE are as follows: Table 5 – Security Objectives for the TOE Name Description O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data, ensuring that TOE users with the appropriate privileges, and only those TOE users, may exercise such management control. O.ADMIN_AUTH The TOE must be able to identify and authenticate administrative users prior to allowing access to TOE administrative functions and data. O.ENDUSER_AUTH The TOE must be able to identify and authenticate end users prior to allowing access to end user functions and data and high-risk transactions. O.MONITOR The TOE must provide a mechanism to continuously monitor end user transactions, and to record potentially risky transactions for later review. O.RECOMMEND The TOE must be able to make recommendations regarding the submission of authentication credentials based on a calculated risk associated with the login attempt or transaction. O.RISK_FACTOR The TOE must provide a mechanism for determining a “risk factor” of allowing a given login or transaction to be performed. 4.2 Security Objectives for the Operational Environment 4.2.1 IT Security Objectives The following IT security objectives are to be satisfied by the environment: Table 6 – IT Security Objectives Name Description OE.AUDIT The TOE environment will be configured to audit all administrative actions. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 18 of 72 © 2009 RSA®, The Security Division of EMC Name Description OE.NETWORK The TOE environment must be implemented such that the TOE is appropriately located within the network to perform its intended function. OE.PLATFORM The TOE hardware and OS must support all required TOE functions. OE.PROTECT The TOE environment must protect itself and the TOE from external interference or tampering. OE.SECURE_COMMS The TOE environment must ensure that communications between the TOE components, the database server, front-end applications, and the RSA Data Center are protected via a secure channel. OE.TIME The TOE environment must provide reliable time stamps to the TOE. 4.2.2 Non-IT Security Objectives The following non-IT environment security objectives are to be satisfied without imposing technical requirements on the TOE. That is, they will not require the implementation of functions in the TOE hardware and/or software. Thus, they will be satisfied largely through application of procedural or administrative measures. Table 7 – Non-IT Security Objectives Name Description NOE.MANAGE Sites deploying the TOE will provide competent, non-hostile TOE administrators who are appropriately trained and follow all administrator guidance. TOE administrators will ensure the system is used securely. NOE.PHYSICAL The physical environment must be suitable for supporting a computing device in a secure setting. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 19 of 72 © 2009 RSA®, The Security Division of EMC 5 Extended Components Definition This section defines the extended SFRs and SARs met by the TOE. These requirements are presented following the conventions identified in Section 6.1. 5.1 Extended TOE Security Functional Components This section specifies the extended SFRs for the TOE. The extended SFRs are organized by class. Table 8 identifies all extended SFRs implemented by the TOE. Table 8 – Extended TOE Security Functional Requirements Extended SFR Name Description EXT_FCR_ARP.1 Security alarms EXT_FCR_GEN.1 Case data generation EXT_FCR_ CDA.1 Potential violation analysis EXT_FCR_ CDA.2 Simple attack heuristics 5.1.1 Class FCR: Case Recording and Review Case Recording and Review involves recognizing, recording, storing, and analyzing records of users committing potentially fraudulent activities against a TOE-protected system. The EXT_FCR: Case Recording and Review function class was modeled after the CC FAU: Security audit class. Table 9 – Extended TOE Security Functional Requirements Extended Family CC Family EXT_FCR_ARP.1: Security alarms FAU_ARP.1: Security alarms EXT_FCR_GEN.1: Case data generation FAU_GEN.1: Audit data generation EXT_FCR_CDA.1: Potential violation analysis FAU_SAA.1: Potential violation analysis EXT_FCR_CDA.2: Simple attack heuristics FAU_SAA.3: Simple attack heuristics Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 20 of 72 © 2009 RSA®, The Security Division of EMC Figure 3 – EXT_FCR: Case Recording and Review Function Class Decomposition EXT_FCR_ARP: Transaction automatic response 1 EXT_FCR_GEN: Case data generation 1 EXT_FCR_CDA: Case data analysis 1 2 Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 21 of 72 © 2009 RSA®, The Security Division of EMC 5.1.1.1 Transaction automatic response (EXT_FCR_ARP) Family Behaviour This family defines the response to be taken in case of detected transactions indicative of potentially fraudulent activity. Component Leveling Figure 4 – EXT_FCR_ARP Component Leveling EXT_FCR_ARP.1 Security alarms shall take actions in case a potentially fraudulent activity is detected. Management: EXT_FCR_ARP.1 The following actions could be considered for the management functions in FMT: The management (addition, removal, or modification) of actions. Audit: EXT_FCR_ARP.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Minimal: Actions taken due to potential fraudulent activity. EXT_FCR_ARP.1 Security alarms Hierarchical to: No other components. Dependencies: EXT_FCR_CDA.1 Potential violation analysis EXT_FCR_ARP.1.1 The TSF shall make the recommendation [assignment: list of recommendations that can be made] upon determination of a heightened potential of risk for a given transaction. 5.1.1.2 Case generation (EXT_FCR_GEN) Family Behaviour This family defines the requirements for recording the occurrence of potentially fraudulent activities that take place against a TOE-protected system. This family enumerates the types of activities that shall be recorded by the TSF, and identifies the minimum set of transaction-related information that should be provided within various case record types. Component Leveling 1 EXT_FCR_ARP: Transaction automatic response Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 22 of 72 © 2009 RSA®, The Security Division of EMC Figure 5 – EXT_FCR_GEN Component Leveling EXT_FCR_GEN.1 Case data generation specifies the list of data that shall be monitored during transactions and recorded in the generation of a case. Management: EXT_FCR_GEN.1 There are no management activities foreseen. Audit: EXT_FCR_GEN.1 There are no auditable events foreseen. EXT_FCR_GEN.1 Case data generation Hierarchical to: No other components. Dependencies: FPT_STM.1 Reliable time stamps EXT_FCR_GEN.1.1 The TSF shall be able to generate case data of the following monitored activities: [assignment: list of activities that can be monitored]. EXT_FCR_GEN.1.2 The TSF shall record within each record at least the following information: [assignment: list of information stored in every generated case data record]. 1 EXT_FCR_GEN: Case data generation Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 23 of 72 © 2009 RSA®, The Security Division of EMC 5.1.1.3 Case data analysis (EXT_FCR_CDA) Family Behaviour This family defines requirements for automated means that analyze system activity and case data, looking for possible or real fraudulent activities. This analysis may work in support of intrusion detection or automatic response to a potentially fraudulent activity. Component Leveling Figure 6 – EXT_FCR_CDA Component Leveling EXT_FCR_CDA.1 Potential violation analysis defines the basic threshold detection on the basis of a fixed rule set. Management: EXT_FCR_CDA.1 The following actions could be considered for the management functions in FMT: The maintenance of the rules by (adding, modifying, or deletion) of rules from the set of rules. Audit: EXT_FCR_CDA.1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Minimal: enabling and disabling of any of the analysis mechanisms; Minimal: automated responses performed by the tool. EXT_FCR_CDA.1 Potential violation analysis Hierarchical to: No other components. Dependencies: EXT_FCR_GEN.1 Case data generation EXT_FCR_CDA.1.1 The TSF shall be able to apply a set of rules in monitoring on-going transactions and, based upon these rules, indicate a potentially fraudulent activity against the TOE-protected system. EXT_FCR_CDA.1.2 The TSF shall enforce the following rules for monitoring on-going transactions: a) Risk factor calculation based on user, device, and transaction data; EXT_FCR_CDA: Case data analysis 1 2 Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 24 of 72 © 2009 RSA®, The Security Division of EMC b) No other rules. EXT_FCR_CDA.2 Simple attack heuristics shall be able to detect the occurrence of signature events that represent a potential threat against the TOE-protected system. Management: EXT_FCR_CDA.2 The following actions could be considered for the management functions in FMT: Maintenance (deletion, modification, or addition) of the subset of system events. Audit: EXT_FCR_CDA.2 The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Minimal: enabling and disabling of any of the analysis mechanisms; Minimal: automated responses performed by the tool. EXT_FCR_CDA.2 Simple attack heuristics Hierarchical to: EXT_FCR_CDA.1 Potential violation analysis Dependencies: No dependencies EXT_FCR_CDA.2.1 The TSF shall be able to maintain an internal representation of the following risk information [assignment: list of risk information used in determining risk level for a transaction] that help in determining a level of risk for a given transaction. EXT_FCR_CDA.2.2 The TSF shall be able to compare the stored risk information against information about the current transaction discernible from an examination of [assignment: list of data gathered from the current transaction]. EXT_FCR_CDA.2.3 The TSF shall be able to indicate an appropriate course of action for a given transaction when the level of risk for a transaction indicates a potentially fraudulent use of a TOE-protected system. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 25 of 72 © 2009 RSA®, The Security Division of EMC 5.2 Extended TOE Security Assurance Components There are no extended TOE Security Assurance components associated with this evaluation. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 26 of 72 © 2009 RSA®, The Security Division of EMC 6 Security Requirements This section defines the SFRs and SARs met by the TOE. These requirements are presented following the conventions identified in Section 6.1. 6.1 Conventions There are several font variations used within this section of the ST. Selected presentation choices are discussed here to aid the Security Target reader. The CC allows for assignment, refinement, selection and iteration operations to be performed on security functional requirements. All of these operations are used within this ST. These operations are performed as described in Parts 2 and 3 of the CC, and are shown as follows: Completed assignment statements are identified using [italicized text within brackets]. Completed selection statements are identified using [underlined italicized text within brackets]. Refinements are identified using bold text. Any text removed is stricken (Example: TSF Data) and should be considered as a refinement. Extended Functional and Assurance Requirements are identified using “EXT_” at the beginning of the short name. Iterations are identified by appending a letter in parentheses following the component title. For example, FDP_ACC.1(a) Subset access control would be the first iteration and FDP_ACC.1(b) Subset access control would be the second iteration. 6.2 Security Functional Requirements This section specifies the SFRs for the TOE. This section organizes the SFRs by CC class. Table 10 identifies all SFRs implemented by the TOE and indicates the ST operations performed on each requirement. Table 10 – TOE Security Functional Requirements Name Description S A R I FDP_ACC.1(a) Subset access control     FDP_ACC.1(b) Subset access control     FDP_ACF.1(a) Security attribute based access control     FDP_ACF.1(b) Security attribute based access control     FDP_ETC.1 Export of user data without security attributes    FDP_IFC.1 Subset information flow control    FDP_IFF.1 Simple security attributes    FDP_ITC.1 Import of user data without security attributes     Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 27 of 72 © 2009 RSA®, The Security Division of EMC Name Description S A R I FIA_ATD.1(a) User attribute definition     FIA_ATD.1(b) User attribute definition     FIA_SOS.1 Verification of secrets    FIA_UAU.1 Timing of authentication     FIA_UAU.2 User authentication before any action     FIA_UAU.5 Multiple authentication mechanisms    FIA_UAU.6 Re-authenticating    FIA_UAU.7 Protected authentication feedback    FIA_UID.1 Timing of identification     FIA_UID.2 User identification before any action     FMT_MOF.1(a) Management of security functions behaviour     FMT_MOF.1(b) Management of security functions behaviour     FMT_MSA.1(a) Management of security attributes     FMT_MSA.1(b) Management of security attributes     FMT_MSA.1(c) Management of security attributes     FMT_MSA.3 Static attribute initialisation     FMT_MTD.1(a) Management of security attributes     FMT_MTD.1(b) Management of security attributes     FMT_MTD.1(c) Management of security attributes     FMT_SMF.1 Specification of management functions     FMT_SMR.1 Security roles     FPT_STM.1 Reliable time stamps     Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 28 of 72 © 2009 RSA®, The Security Division of EMC Name Description S A R I EXT_FCR_ARP.1 Security alarms     EXT_FCR_GEN.1 Case data generation     EXT_FCR_CDA.1 Potential violation analysis     EXT_FCR_CDA.2 Simple attack heuristics     Note: S=Selection; A=Assignment; R=Refinement; I=Iteration Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 29 of 72 © 2009 RSA®, The Security Division of EMC 6.2.1 Class FDP: User Data Protection FDP_ACC.1(a) Subset access control Hierarchical to: No other components. FDP_ACC.1.1(a) The TSF shall enforce the [Back Office User Access SFP] on [TOE users accessing the Back Office Tools component of the TOE]. Dependencies: FDP_ACF.1(a) Security attribute based access control FDP_ACC.1(b) Subset access control FDP_ACC.1.1(b) The TSF shall enforce the [End User Access SFP] on [users authenticating to a front-end application employing the TOE]. Dependencies: FDP_ACF.1(b) Security attribute based access control FDP_ACF.1(a) Security attribute based access control Hierarchical to: No other components. FDP_ACF.1.1(a) The TSF shall enforce the [Back Office User Access SFP] to objects based on the following: [ Back Office user (subject) attributes: a. user name b. password c. assigned Back Office Tool(s) d. assigned role(s) e. assigned operation(s) (create, read, update, delete) Back Office Tool (object) attributes: a. none ]. FDP_ACF.1.2(a) Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 30 of 72 © 2009 RSA®, The Security Division of EMC The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [ a. The user must have a valid user name and password. b. The user must have permissions assigned by an administrator allowing access to the desired Back Office Tool (the “controlled objects”). c. The user’s assigned role must support the operation they wish to perform. ]. FDP_ACF.1.3(a) The TSF shall explicitly authorise access of subjects to objects based on the following no additional rules. FDP_ACF.1.4(a) The TSF shall explicitly deny access of subjects to objects based on the no additional rules. Dependencies: FDP_ACC.1(a) Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1(b) Security attribute based access control Hierarchical to: No other components. FDP_ACF.1.1(b) The TSF shall enforce the [End User Access SFP] to objects based on the following: [ End User (subject) attributes: a. User name b. Password c. Challenge questions and answers d. Out-of-Band authentication information e. Network information f. Device information Transaction (object and operation) attributes: a. Level of risk, as determined by the TOE Risk and Policy Engine ]. FDP_ACF.1.2(b) Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 31 of 72 © 2009 RSA®, The Security Division of EMC The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [ 1. (In “Signin with Risk-Based Authentication” deployment) The End User is allowed to perform an operation if: a. The TOE Risk and Policy Engine determines that the End User’s characteristics (user name, password, challenge response, out-of-band response, network information, and device information) and the level of risk posed by the operation (i.e. transaction) are deemed acceptable (according to the current policy); or b. The End User’s characteristics are deemed acceptable (according to the current policy) and an authentication challenge (due to a high level of risk) is successfully passed. 2. (In “Signin with Positive Device Identification Only” deployment) ) The End User is allowed to perform an operation if: a. The End User is authenticating from a device that is deemed acceptable (according to the current policy) through positive identification; or b. The End User is authenticating from an unknown device, but successfully passes an authentication challenge. 3. (In “Signin Monitoring” deployment) No rules. ].1 Application Note: The term “acceptable” in this SFR means that the End User’s characteristics and/or the operation’s level of risk meet the requirements of the current policy set by the TOE Administrator. FDP_ACF.1.3(b) The TSF shall explicitly authorise access of subjects to objects based on no additional rules the following rules [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]. FDP_ACF.1.4(b) The TSF shall explicitly deny access of subjects to objects based on no additional rules the following rules [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]. Dependencies: FDP_ACC.1(b) Subset access control FMT_MSA.3 Static attribute initialization FDP_ETC.1 Export of user data without security attributes Hierarchical to: No other components. 1 These deployments are defined in Section 7.1.2.2. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 32 of 72 © 2009 RSA®, The Security Division of EMC FDP_ETC.1.1 The TSF shall enforce the [Back Office User Access SFP, and End User Access SFP] when exporting user data, controlled under the SFP, outside of the TOE. FDP_ETC.1.2 The TSF shall export the user data without the user data’s associated security attributes. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FDP_IFC.1 Subset information flow control Hierarchical to: No other components. FDP_IFC.1.1 The TSF enforce the [Transactional SFP] on [ a. (subjects) End Users attempting to perform policy-controlled transactions b. (information) End User authentication status c. (operations) policy-controlled transactions ]. Dependencies: FDP_IFF.1 Simple security attributes FDP_IFF.1 Simple security attributes Hierarchical to: No other components. FDP_IFF.1.1 The TSF shall enforce the [Transactional SFP] based on the following types of subject and information security attributes: [ End user (subject) attributes: a. User name b. Personal security image and caption c. Challenge questions/answers d. Out-of-Band authentication information e. Network information Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 33 of 72 © 2009 RSA®, The Security Division of EMC f. Device information Transaction (information) attributes: a. Risk factor ]. FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [ a. (In “Transactional Authentication” deployment) The End User is deemed valid, and risk analysis by the TOE Risk and Policy Engine has determined that the transaction can proceed. b. (In “Transactional Monitoring” deployment) No rules. ].2 FDP_IFF.1.3 The TSF shall enforce no additional information flow control SFP rules the [assignment: additional information flow control SFP rules]. FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on no additional information flow control SFP rules. provide no additional SFP capabilities the following [assignment: list of additional SFP capabilities]. FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on no additional information flow control SFP rules. the following rules: [assignment: rules, based on security attributes, that explicitly authorise information flows]. Dependencies: FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation FDP_ITC.1 Import of user data without security attributes Hierarchical to: No other components. FDP_ITC.1.1 The TSF shall enforce the [Back Office User Access SFP and End User Access SFP] when importing user data, controlled under the SFP, from outside of the TOE. 2 These deployments are defined in Section 7.1.2.3. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 34 of 72 © 2009 RSA®, The Security Division of EMC FDP_ITC.1.2 The TSF shall ignore any security attributes associated with the user data when imported from outside the TOE. FDP_ITC.1.3 The TSF shall enforce the following no additional rules when importing user data controlled under the SFP from outside the TOE. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_MSA.3 Static attribute initialisation Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 35 of 72 © 2009 RSA®, The Security Division of EMC 6.2.2 Class FIA: Identification and Authentication FIA_ATD.1(a) User attribute definition Hierarchical to: No other components. FIA_ATD.1.1(a) The TSF shall maintain the following list of security attributes belonging to individual Back Office Users users: [ a. User name b. Password c. Assigned Back Office Tool(s) d. Assigned Role(s) e. Assigned Operation(s) ]. Dependencies: No dependencies FIA_ATD.1(b) User attribute definition Hierarchical to: No other components. FIA_ATD.1.1(b) The TSF shall maintain the following list of security attributes belonging to individual End Users users: [ a. User name b. Personal security image c. Challenge question(s) and answer(s) d. Out-of-Band Challenge information e. Network information (IP address, etc.) f. Device information ]. Dependencies: No dependencies Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 36 of 72 © 2009 RSA®, The Security Division of EMC FIA_SOS.1 Verification of secrets Hierarchical to: No other components. FIA_SOS.1.1 The TSF shall provide a mechanism to verify that Back Office User passwords secrets meet [the minimum password length requirement of eight (8) characters]. Dependencies: No dependencies FIA_UAU.1 Timing of authentication Hierarchical to: No other components. FIA_UAU.1.1 The TSF shall allow [ access to the TOE’s Adaptive Authentication Utilities component, which includes the following utilities: a. Aggregator Token Generator b. Billing Utility c. Configuration Framework d. eFraudNetwork Agent and Database Loader e. GeoIP Admin Tool and Inspector Utility f. HealthCheck Servlet g. LogManager Servlet ] on behalf of the Back Office User user to be performed before the Back Office User user is authenticated. FIA_UAU.1.2 The TSF shall require each Back Office User user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that Back Office User user. Dependencies: FIA_UID.1 Timing of identification FIA_UAU.2 User authentication before any action Hierarchical to: FIA_UAU.1 Timing of authentication FIA_UAU.2.1 Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 37 of 72 © 2009 RSA®, The Security Division of EMC The TSF shall require each End User user to be successfully authenticated before allowing any other TSF- mediated actions on behalf of that user. Dependencies: FIA_UID.1 Timing of identification FIA_UAU.5 Multiple authentication mechanisms Hierarchical to: No other components. FIA_UAU.5.1 The TSF shall provide [challenge questions and out-of-band challenges] to support End User user authentication. FIA_UAU.5.2 The TSF shall authenticate any End User’s user’s claimed identity according to the [challenge question and out-of-band challenge rules for responses and timing]. Dependencies: No dependencies FIA_UAU.6 Re-authenticating Hierarchical to: No other components. FIA_UAU.6.1 The TSF shall re-authenticate the End User user under the conditions [the TOE Risk and Policy Engine determines that the risk factor associated with a given transaction is high enough to warrant the submission of additional authentication credentials, based on the End User Access SFP]. Dependencies: No dependencies Application Note: The End User Access SFP is defined in FDP_ACC.1(b) and FDP_ACF.1(b). FIA_UAU.7 Protected authentication feedback Hierarchical to: No other components. FIA_UAU.7.1 The TSF shall provide only [replacement symbols for characters during password entry] to the Back Office User user while the authentication is in progress. Dependencies: FIA_UAU.1 Timing of authentication FIA_UID.1 Timing of identification Hierarchical to: No other components. FIA_UID.1.1 Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 38 of 72 © 2009 RSA®, The Security Division of EMC The TSF shall allow [ access to the TOE’s Adaptive Authentication Utilities component, which includes the following utilities: a. Aggregator Token Generator b. Billing Utility c. Configuration Framework d. eFraudNetwork Agent and Database Loader e. GeoIP Admin Tool and Inspector Utility f. HealthCheck Servlet g. LogManager Servlet ] on behalf of the Back Office User user to be performed before the Back Office User user is identified. FIA_UID.1.2 The TSF shall require each Back Office User user to be successfully identified before allowing any other TSF-mediated actions on behalf of that Back Office User user. Dependencies: No dependencies FIA_UID.2 User identification before any action Hierarchical to: FIA_UID.1 Timing of identification FIA_UID.2.1 The TSF shall require each End User user to be successfully identified before allowing any other TSF- mediated actions on behalf of that user. Dependencies: No dependencies Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 39 of 72 © 2009 RSA®, The Security Division of EMC 6.2.3 Class FMT: Security Management FMT_MOF.1(a) Management of security functions behaviour Hierarchical to: No other components. FMT_MOF.1.1(a) The TSF shall restrict the ability to [determine the behaviour of, disable, enable, modify the behaviour of] the functions [available via the TOE Back Office Tools utilities] to [the “admin” role]. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MOF.1(b) Management of security functions behaviour Hierarchical to: No other components. FMT_MOF.1.1(b) The TSF shall restrict the ability to [determine the behaviour of, disable, enable, modify the behaviour of] the functions [available via the TOE Back Office Tools Policy Editor utility] to [the “editor” role]. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MSA.1(a) Management of security attributes Hierarchical to: No other components. FMT_MSA.1.1(a) The TSF shall enforce the [Back Office User Access SFP] to restrict the ability to [query, modify] the security attributes [associated with Back Office users, Transactional SFP, and cases] to [“admin” role users]. Dependencies: FDP_ACC.1(a) Subset access control FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MSA.1(b) Management of security attributes Hierarchical to: No other components. FMT_MSA.1.1(b) The TSF shall enforce the [Back Office User Access SFP] to restrict the ability to [query, modify] the security attributes [associated with the Transactional SFP] to [“editor” role users]. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 40 of 72 © 2009 RSA®, The Security Division of EMC Dependencies: FDP_ACC.1(a) Subset access control FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MSA.1(c) Management of security attributes Hierarchical to: No other components. FMT_MSA.1.1(c) The TSF shall enforce the [Back Office User Access SFP] to restrict the ability to [query] the security attributes [associated with the Transactional SFP] to [“reviewer” role users]. Dependencies: FDP_ACC.1(a) Subset access control FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MSA.3 Static attribute initialisation Hierarchical to: No other components. FMT_MSA.3.1 The TSF shall enforce the [Back Office User Access SFP] to provide [restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the [“admin” role users] to specify alternative initial values to override the default values when an object or information is created. Dependencies: FMT_MSA.1(a) Management of security attributes FMT_SMR.1 Security roles FMT_MTD.1(a) Management of TSF data Hierarchical to: No other components. FMT_MTD.1.1(a) The TSF shall restrict the ability to [query, modify, delete,[create]] the [Back Office User, Transactional SFP, and case data] to [the “admin” role]. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1(b) Management of TSF data Hierarchical to: No other components. FMT_MTD.1.1(b) Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 41 of 72 © 2009 RSA®, The Security Division of EMC The TSF shall restrict the ability to [query, modify, delete,[create]] the [Transactional SFP data] to [the “editor” role]. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1(c) Management of TSF data Hierarchical to: No other components. FMT_MTD.1.1(c) The TSF shall restrict the ability to [query] the [Transactional SFP data] to [the “reviewer” role]. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components. FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [ a. Management of Back Office User data b. Management of Transactional SFP data c. Management of case (transaction event) data ]. Dependencies: No Dependencies FMT_SMR.1 Security roles Hierarchical to: No other components. FMT_SMR.1.1 The TSF shall maintain the roles [“admin”, “editor”, “reviewer”, and “fraudanalyst”]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. Dependencies: FIA_UID.1(a) Timing of identification Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 42 of 72 © 2009 RSA®, The Security Division of EMC 6.2.4 Class FPT: Protection of the TSF FPT_STM.1 Reliable time stamps Hierarchical to: No other components. FPT_STM.1.1 The TSF shall be able to provide reliable time stamps. Dependencies: No dependencies Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 43 of 72 © 2009 RSA®, The Security Division of EMC 6.2.5 Class FCR: Case Recording and Review EXT_FCR_ARP.1 Security alarms Hierarchical to: No other components. Dependencies: EXT_FCR_CDA.1 Potential violation analysis EXT_FCR_ARP.1.1 The TSF shall make the recommendation [allow, deny, monitor, challenge, review] upon determination of a heightened potential of risk for a given transaction. EXT_FCR_GEN.1 Case data generation Hierarchical to: No other components. Dependencies: FPT_STM.1 Reliable time stamps EXT_FCR_GEN.1.1 The TSF shall be able to generate case data of the following monitored activities: [ a. High-risk user activities in which the recommendation for challenges for additional authentication was made; b. High-risk user activities in which the recommendation for review was made; and c. Manual flagging of an activity by an authorized TOE administrator. ]. EXT_FCR_GEN.1.2 The TSF shall record within each record at least the following information: [ a. User information (including user ID, organization, and authentication status) b. Case information (including case, status resolution, risk score, assigned reviewer) c. Case history d. Recent events ]. EXT_FCR_CDA.1 Potential violation analysis Hierarchical to: No other components. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 44 of 72 © 2009 RSA®, The Security Division of EMC Dependencies: EXT_FCR_GEN.1 Case data generation EXT_FCR_CDA.1.1 The TSF shall be able to apply a set of rules in monitoring on-going transactions and, based upon these rules, indicate a potentially fraudulent activity against the TOE-protected system. EXT_FCR_CDA.1.2 The TSF shall enforce the following rules for monitoring on-going transactions: a) Risk factor calculation based on user, device, and transaction data; b) No other rules. EXT_FCR_CDA.2 Simple attack heuristics Hierarchical to: EXT_FCR_CDA.1 Potential violation analysis Dependencies: No dependencies EXT_FCR_CDA.2.1 The TSF shall be able to maintain an internal representation of the following risk information [country or IP blacklists, watch lists, and “white” lists] that help in determining a level of risk for a given transaction. EXT_FCR_CDA.2.2 The TSF shall be able to compare the stored risk information against information about the current transaction discernible from an examination of [ a. Client machine information b. Browser information c. IP address, IP profile, and geoIP information d. User device history information e. User profile and behavior f. Transaction information ]. EXT_FCR_CDA.2.3 The TSF shall be able to indicate an appropriate course of action for a given transaction when the level of risk for a transaction indicates a potentially fraudulent use of a TOE-protected system. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 45 of 72 © 2009 RSA®, The Security Division of EMC 6.3 Security Assurance Requirements This section defines the assurance requirements for the TOE. Assurance requirements are taken from the CC Part 3 and are EAL2 augmented with ALC_FLR.1. Table 11 – Assurance Requirements summarizes the requirements. Table 11 – Assurance Requirements Assurance Requirements Class ADV: Development ADV_ARC.1 Security Architecture Description ADV_FSP.2 Security-enforcing functional specification ADV_TDS.1 Basic design Class AGD: Guidance documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures Class ALC : Life-cycle support ALC_CMC.2 Use of a CM system ALC_CMS.2 Parts of the TOE CM coverage ALC_DEL.1 Delivery Procedures ALC_FLR.1 Basic Flaw Remediation Class ATE: Tests ATE_COV.1 Evidence of coverage ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample Class AVA: Vulnerability assessment AVA_VAN.2 Vulnerability analysis Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 46 of 72 © 2009 RSA®, The Security Division of EMC 7 TOE Summary Specification This section presents information to detail how the TOE meets the functional and assurance requirements described in previous sections of this ST. 7.1 TOE Security Functions Each of the security requirements and the associated descriptions correspond to the security functions. Hence, each function is described by how it specifically satisfies each of its related requirements. This serves to both describe the security functions and rationalize that the security functions satisfy the necessary requirements. Table 12 – Mapping of TOE Security Functions to Security Functional Requirements TOE Security Function SFR ID Description User Data Protection FDP_ACC.1(a) Subset access control FDP_ACC.1(b) Subset access control FDP_ACF.1(a) Security attribute based access control FDP_ACF.1(b) Security attribute based access control FDP_ETC.1 Import of user data without security attributes FDP_IFC.1 Subset information flow control FDP_IFF.1 Simple security attributes FDP_ITC.1 Export of user data without security attributes Identification and Authentication FIA_ATD.1(a) User attribute definition FIA_ATD.1(b) User attribute definition FIA_SOS.1 Verification of secrets FIA_UAU.1 Timing of authentication FIA_UAU.2 User authentication before any action FIA_UAU.5 Multiple authentication mechanisms FIA_UAU.6 Re-authenticating FIA_UAU.7 Protected authentication feedback Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 47 of 72 © 2009 RSA®, The Security Division of EMC TOE Security Function SFR ID Description FIA_UID.1 Timing of identification FIA_UID.2 User identification before any action Security Management FMT_MOF.1(a) Management of security functions behaviour FMT_MOF.1(b) Management of security functions behaviour FMT_MSA.1(a) Management of security attributes FMT_MSA.1(b) Management of security attributes FMT_MSA.1(c) Management of security attributes FMT_MSA.3 Static attribute initialisation FMT_MTD.1(a) Management of TSF data FMT_MTD.1(b) Management of TSF data FMT_MTD.1(c) Management of TSF data FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles Protection of the TSF FPT_STM.1 Reliable time stamps Case Recording and Review EXT_FCR_ARP.1 Security alarms EXT_FCR_GEN.1 Case data generation EXT_FCR_CDA.1 Potential violation analysis EXT_FCR_CDA.2 Simple attack heuristics 7.1.1 User Data Protection The RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 provides an authentication mechanism for controlling access to Back Office administrative functions of the TOE. This mechanism ensures that access to administrative functions and data is available (but restricted to) authorized administrators only. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 48 of 72 © 2009 RSA®, The Security Division of EMC End Users access to the TOE, while indirect, is primarily controlled by the front-end application. However, the TOE adds another layer of authentication based on additional factors (such as positive device identification). This access control mechanism ensures that access to protected data is granted only as permitted by policy. Further, the TOE also provides for the definition of risk-based policies that require End Users to provide credentials in order to perform transactions under certain policy-controlled conditions. This mechanism ensures that potentially fraudulent transactions on End User data are monitored, the front-end applications are notified, and recommendations for further action are made when appropriate. Back Office User credentials, End User credentials, transaction data, risk data, and other data is stored by the TOE in the external database. This data is stored and retrieved without security attributes and processed by the TOE upon import. 7.1.1.1 Back Office User Access Control The TOE includes a robust set of administrative applications that make up its Back Office Tools set. These tools are used by TOE administrators for configuring and managing cases, reports, and transaction policies. The Access Management tool provides a single interface for access to the other tools in the suite, and allows administrators to create and manage users and user permissions for these applications. Each user is created with the following associated data: Name Organization Assigned Back Office Tool(s) Assigned Role(s) Assigned Operation(s) Within the TOE, the Role defines the operations, or permissions, that the user can exercise within the assigned Back Office Tools. Each Role can be assigned one or more of the following operations: CREATE, READ, UPDATE, and DELETE. Access to the Back Office tools (and the operations allowed while using those tools) requires having the appropriate credentials and permissions. Without them, access is denied. 7.1.1.2 End User Access Control End users do not directly interface with the TOE. Instead, requests are made by a host application on behalf of the user. Authentication requests are made to the host application. Once the host application determines if the user is valid, the host application then ascertains if the user is “enrolled” in the RSA AA System. If not, the user is given the opportunity to enroll at that time. The host application then collects the necessary information and passes it to the TOE. The TOE uses this information to determine a recommended action based on its stored policies. The recommendation will either be ALLOW, CHALLENGE, REVIEW, or DENY. TOE Security Functional Requirements Satisfied: FDP_ACC.1(a), FDP_ACC.1(b), FDP_ACF.1(a), FDP_ACF.1(b), FDP_IFC.1, FDP_IFF.1. 7.1.2 Identification and Authentication 7.1.2.1 Back Office User Authentication TOE administrators (i.e. Back Office users) are identified by a user name, and are authenticated by a password. Back Office users log in to the Access Management interface by entering their user name/password combination. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 49 of 72 © 2009 RSA®, The Security Division of EMC The system creates four users by default: admin, editor, fraudanalyst, and reviewer. These users cannot be removed from the system. 7.1.2.2 End User Authentication End users must authenticate to the host application each time they wish to perform an activity (signin or transaction) that is defined as risky within the host application. For the initial login, the End user must provide whatever information is required by that system, often a user name/password combination. However, once the host application has determined that the credentials are valid, further device and network information is collected and passed to the TOE to determine the risk factor. From this point, the “signin” process can take any one of three paths depending on the TOE deployment mode. Signin with Risk-Based Authentication mode – When deployed in this mode, the TOE will authenticate End Users based on factors such as their network information, user information, positive device identification, and user profiling. All of these factors are fed to the TOE Risk and Policy Engine, which then makes a determination of risk. Users with high risk are challenged (the TOE recommends that the host application require further proof of identity), while users with low risk are allowed to continue. Signin with Positive Device Identification Only mode – When deployed in this mode, the TOE will authenticate End users based primarily on device binding. The TOE checks to see if it recognizes the device from which the user is logging into the host application. It looks at a large number of device characteristics to uniquely identify the user’s device, and determines a risk based on its recognizing of the device. Again, users with high risk are challenged, while users with low risk are allowed to continue. Signin Monitoring mode – When deployed in this mode, the TOE performs a risk analysis just as it does in the other deployment modes. However, no recommendations are made based on that risk; all users are allowed to continue, while potentially risky logins are simply flagged for later review. Challenges take the form of challenge questions or out-of-band (OOB) challenges. Challenge questions require the user to respond to a previously-selected question, and the user response will be compared to their stored answer for correctness. OOB challenges require the user to type a one-time password (presented on their web page) on their phone keypad. 7.1.2.3 Transaction Authentication and Monitoring End user transactions can also result in challenges. A risk factor for each transaction is calculated by the TOE Risk and Policy Engine. If the TOE is deployed in Transactional Authentication mode and if the risk factor for a particular transaction is high, then the End user will be challenged for more credentials. The challenge process for transactions works that same as it does for logins. If the TOE is deployed in Transactional Monitoring mode then all transactions are monitored but no further authentication challenges are issued to the user. TOE Security Functional Requirements Satisfied: FIA_ATD.1(a), FIA_ATD.1(b), FIA_SOS.1, FIA_UAU.1(a), FIA_UAU.1(b) FIA_UAU.5, FIA_UAU.6, FIA_UAU.7, FIA_UID.1(a), FIA_UID(b). 7.1.3 Security Management The TOE is managed by administrators (Back Office Users) who have varying degrees of authority to review and modify the configuration of the security attributes of the TOE. Levels of administrative authority are based on the credentials used to authenticate. Back Office Users have associated modules (accessible Back Office tools) and roles (predefined sets of permissions). While administrators can create roles, the TOE comes pre-populated with the following roles that can perform security management tasks: admin – this role is a “super-user” that can has all permissions (CREATE, READ, UPDATE, DELETE) editor – this role can make changes in the Policy Editor (CREATE, READ, UPDATE, DELETE) reviewer – this role can review policies (READ) Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 50 of 72 © 2009 RSA®, The Security Division of EMC Along with these predefined roles, the TOE has several users predefined as well. For ease of association, the names of the users match their roles. They are “admin”, “editor”, and “reviewer”. There is also a “fraudanalyst” user that can query the TOE database for cases that may have fraudulent activity. These users cannot be deleted, and are configured with default passwords. It is recommended that the passwords be changed. Back Office users with the proper credentials can also administer both users and roles. Using the Access Management tool, administrators can create a user, remove a user (excluding the system-defined default users), and modify user details, including their module(s) and role(s). Administrators can also create, edit, and remove roles. This feature gives administrators the capability to configure roles and users specifically for their own business needs and concerns. While the TOE comes equipped with default policies, administrators can add, delete, or alter policies to fit their specific requirements. Using the Policy Editor, Back Office users can configure and customize the necessary policies by which the TOE detects and challenges potentially risky End users and transactions. Depending on the TOE deployment, events of a sufficient risk level can be recorded in a case log for later evaluation. TOE Security Functional Requirements Satisfied: FMT_MOF.1(a), FMT_MOF.1(b), FMT_MOF.1(c), FMT_MTD.1(a), FMT_MTD.1(b), FMT_MTD.1(c), FMT_SMF.1, FMT_SMR.1. 7.1.4 Protection of the TSF The TOE relies on its operational environment to provide reliable time stamps. Time stamps are used to mark time in the case data records. TOE Security Functional Requirements Satisfied: FPT_STM.1. 7.1.5 Case Recording and Review The TOE’s primary function is to detect and react to potentially fraudulent activities against a system it is configured to protect. This is accomplished via the monitoring of End User transactions as they occur. Each transaction is analyzed for its potential risk, and policy-based recommendations are made to the host application based on the risk value determined by the TOE. The TOE continuously monitors the End User transactions and can record information about questionable logins and transaction request for later review. TOE Security Functional Requirements Satisfied: EXT_FCR_ARP.1, EXT_FCR_GEN.1, EXT_FCR_CDA.1, EXT_FCR_CDA.2. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 51 of 72 © 2009 RSA®, The Security Division of EMC 8 Rationale 8.1 Conformance Claims Rationale There are no Protection Profile conformance claims associated with this Security Target. 8.2 Security Objectives Rationale This section provides a rationale for the existence of each threat, policy statement, and assumption that compose the Security Target. Sections 8.2.1, 8.2.2, and 8.2.3 demonstrate that the mappings between the threats, polices, and assumptions to the security objectives is complete. The following sections provide detailed evidence of coverage for each threat, policy, and assumption. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 52 of 72 © 2009 RSA®, The Security Division of EMC Table 13 – Mapping of TOE Security Objectives to Threats and Policies Security Objectives for the TOE Threats and Policies O.ADMIN O.ADMIN_AUTH O.ENDUSER_AUTH O.MONITOR O.RECOMMEND O.RISK_FACTOR OE.AUDIT OE.NETWORK OE.PLATFORM OE.PROTECT OE.SECURE_COMMS OE.TIME NOE.MANAGE NOE.PHYSICAL Threats T.DOS   T.FRAUD     T.MASQUERADE   T.TAMPERING    T.UNAUTH   Policies P.ADMIN  P.CASELOG  P.INTEGRITY  P.MANAGE  P.RECOMMEND  P.RISK  Assumptions A.AUDIT  A.INSTALL   A.LOCATE  Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 53 of 72 © 2009 RSA®, The Security Division of EMC Security Objectives for the TOE Threats and Policies O.ADMIN O.ADMIN_AUTH O.ENDUSER_AUTH O.MONITOR O.RECOMMEND O.RISK_FACTOR OE.AUDIT OE.NETWORK OE.PLATFORM OE.PROTECT OE.SECURE_COMMS OE.TIME NOE.MANAGE NOE.PHYSICAL A.MANAGE  A.NETCON    A.NOEVIL  A.PROTECT  A.TIMESTAMP  8.2.1 Security Objectives Rationale Relating to Threats Every threat is mapped to one or more objectives in the table below. This complete mapping demonstrates that the defined security objectives address all defined threats. Table 14 – Threats/Objectives Mapping Threats Objectives Rationale T.DOS An attacker may attempt to flood the TOE with network traffic, rendering the TOE’s services inaccessible to authorized users. OE.PROTECT The TOE environment must protect itself and the TOE from external interference or tampering. OE.PROTECT ensures that the environment provides protection for the TOE from outside interference. OE.NETWORK The TOE environment must be implemented such that the TOE is appropriately located within the network to perform its intended function. OE. NETWORK ensures that the environment provides a network configuration capable of protecting against denial-of-service and other network-based attacks, which would prevent the TOE from carrying out its intended functions. T.FRAUD An attacker may take advantage of weak authentication mechanisms to commit fraudulent activities against the host application employing the O.ENDUSER_AUTH The TOE must be able to identify and authenticate end users prior to allowing access to end user functions and data and high-risk transactions. O.ENDUSER_AUTH ensures that access to TOE-protected data is restricted to authenticated users only. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 54 of 72 © 2009 RSA®, The Security Division of EMC Threats Objectives Rationale TOE. O.MONITOR The TOE must provide a mechanism to continuously monitor end user transactions, and to record potentially risky transactions for later review. O. MONITOR ensures that transactions occurring on a TOE-protected host application can be monitored and recorded for later inspection. O.RECOMMEND The TOE must be able to make recommendations regarding the submission of authentication credentials based on a calculated risk associated with the login attempt or transaction. O. RECOMMEND ensures that the TOE is equipped with a mechanism for determining the risk involved with a given transaction, and make a recommendation based on that risk whether the host application should allow a potentially-fraudulent transaction to occur. OE.SECURE_COMMS The TOE environment must ensure that communications between the TOE components, the database server, front-end applications, and the RSA Data Center are protected via a secure channel. OE.SECURE_COMMS ensures that communications between the TOE and non-TOE support systems are protected from tampering and eaves- dropping. T.MASQUERADE An attacker may masquerade as another entity in order to gain unauthorized access to data or TOE resources. O. ADMIN_AUTH The TOE must be able to identify and authenticate administrative users prior to allowing access to TOE administrative functions and data. O. ADMIN_AUTH mitigates this threat by ensuring that the TOE identifies and authenticates users prior to allowing access to TOE administrative functions and data,. O.ENDUSER_AUTH The TOE must be able to identify and authenticate end users prior to allowing access to end user functions and data and high-risk transactions. O.ENDUSER_AUTH ensures that access to TOE-protected data is restricted to authenticated users only. T.TAMPERING An attacker may be able to bypass the TOE’s security mechanisms by tampering with the TOE or TOE environment. O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data, ensuring that TOE users with the appropriate privileges and only those TOE users, may exercise such management control. O.ADMIN supports the mitigation of this threat by ensuring that only authorized users may configure the TOE security mechanisms. OE.PROTECT The TOE environment must protect itself and the TOE from external interference or tampering. OE.PROTECT ensures that the TOE is protected from external interference or tampering. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 55 of 72 © 2009 RSA®, The Security Division of EMC Threats Objectives Rationale OE.SECURE_COMMS The TOE environment must ensure that communications between the TOE components, the database server, front-end applications, and the RSA Data Center are protected via a secure channel. OE.SECURE_COMMS ensures that communications between the TOE and non-TOE support systems are protected from tampering. T.UNAUTH An attacker may gain access to security data on the TOE, even though the user is not authorized in accordance with the TOE security policy. O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data, ensuring that TOE users with the appropriate privileges and only those TOE users, may exercise such control. O.ADMIN ensures that access to TOE security data is limited to those users with access to the management functions of the TOE. O.ADMIN_AUTH The TOE must be able to identify and authenticate administrative users prior to allowing access to TOE administrative functions and data. O.ADMIN_AUTH ensures that administrators are identified and authenticated prior to gaining access to TOE security data. 8.2.2 Security Objectives Rationale Relating to Policies Every policy is mapped to one or more objectives in the table below. This complete mapping demonstrates that the defined security objectives address all defined policies. Table 15 – Policies/Objectives Mapping Policies Objectives Rationale P.ADMIN The TOE shall provide a set of tools for the secure management of TOE data and functions. O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data, ensuring that TOE users with the appropriate privileges, and only those TOE users, may exercise such management control. O.ADMIN ensures that TOE management tools are available for (and restricted for) use by TOE administrators. P.CASELOG The TOE shall have the capability to record “high-risk” events and activities in a case log for later review. O.MONITOR The TOE must provide a mechanism to continuously monitor end user transactions, and to record potentially risky transactions for later review. O.MONITOR provides the ability to monitor and record potentially- fraudulent transactions to a specified location, such that a fraud analyst could review said information. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 56 of 72 © 2009 RSA®, The Security Division of EMC Policies Objectives Rationale P.INTEGRITY Data collected and produced by the TOE shall be protected from unauthorized deletion or modification. OE.PROTECT The TOE environment must protect itself and the TOE from external interference or tampering. OE.PROTECT ensures that the TOE environment provided a mechanism to protect itself from outside tampering and interference, minimizing the threat of tampering with TOE data. P.MANAGE The TOE shall only be managed by authorized users. O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data, ensuring that TOE users with the appropriate privileges, and only those TOE users, may exercise such management control. O.ADMIN ensures that access to TOE security data is limited to those users with access to the management functions of the TOE. P.RECOMMEND The TOE shall make recommendations regarding the submission of authentication credentials based on a calculated risk associated with the login attempt or transaction. O.RECOMMEND The TOE must be able to make recommendations regarding the submission of authentication credentials based on a calculated risk associated with the login attempt or transaction. O.RECOMMEND ensures that the TOE can recommend a course of action based on its risk factor determination and risk analysis. P.RISK The TOE shall have the capability to compute a “risk factor” for a given end user login attempt or transaction. O.RISK_FACTOR The TOE must provide a mechanism for determining a “risk factor” of allowing a given login or transaction to be performed. O. RISK_FACTOR ensures that the TOE has a means for determining and providing a risk factor for a specified end user event. 8.2.3 Security Objectives Rationale Relating to Assumptions Every assumption is mapped to one or more objectives in the table below. This complete mapping demonstrates that the defined security objectives address all defined assumptions. Table 16 – Assumptions/Objectives Mapping Assumptions Objectives Rationale A.AUDIT The operating system, that the TOE is installed on, is correctly configured by the administrator to audit all administrative actions that the administrator deems necessary. OE.AUDIT The TOE environment will be configured to audit all administrative actions. OE.AUDIT ensures that all TOE administrative actions (deemed important by the administrator) are audited by the underlying OS. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 57 of 72 © 2009 RSA®, The Security Division of EMC Assumptions Objectives Rationale A.INSTALL The TOE is properly installed on a hardware and operating system capable of supporting all of its required functionality. OE.PLATFORM The TOE hardware and OS must support all required TOE functions. OE.PLATFORM ensures that the TOE hardware and OS supports the TOE functions. NOE.MANAGE Sites deploying the TOE will provide competent, non-hostile TOE administrators who are appropriately trained and follow all administrator guidance. TOE administrators will ensure the system is used securely. NOE.MANAGE ensures that TOE administrators are capable for performing a TOE installation on the proper platform. A.LOCATE The TOE is located within a controlled access facility. OE.PROTECT The TOE environment must protect itself and the TOE from external interference or tampering. OE.PROTECT ensures that the TOE environment provides protection for the TOE from unauthorized access. NOE.PHYSICAL The physical environment must be suitable for supporting a computing device in a secure setting. NOE.PHYSICAL ensures that the physical security provided by the TOE environment provides appropriate protection to the TOE by controlling access to the facility. A.MANAGE There are one or more competent individuals assigned to manage the TOE and the security of the information it contains. NOE.MANAGE Sites deploying the TOE will provide competent, non-hostile TOE administrators who are appropriately trained and follow all administrator guidance. TOE administrators will ensure the system is used securely. NOE.MANAGE satisfies the assumption that competent individuals are assigned to manage the TOE and the TSF. A.NETCON The TOE environment provides a private network which allows the TOE to provide its security functions to TOE components, the database server, front-end applications, and the RSA Data Center. OE.NETWORK The TOE environment must be implemented such that the TOE is appropriately located within the network to perform its intended function. OE. NETWORK satisfies the assumption that the TOE environment will provide the appropriate connectivity to allow the TOE to perform its function. OE.SECURE_COMMS The TOE environment must ensure that communications between the TOE components, the database server, front-end applications, and the RSA Data Center are protected via a secure channel. OE.SECURE_COMMS ensures that communications between the TOE and non-TOE support systems are protected from tampering and eaves- dropping. OE.PLATFORM The TOE hardware and OS must support all required TOE functions. OE.PLATFORM ensures that the TOE hardware and OS supports the TOE functions. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 58 of 72 © 2009 RSA®, The Security Division of EMC Assumptions Objectives Rationale A.NOEVIL The users who manage the TOE are non-hostile, appropriately trained, and follow all guidance. NOE.MANAGE Sites deploying the TOE will provide competent, non-hostile TOE administrators who are appropriately trained and follow all administrator guidance. TOE administrators will ensure the system is used securely. NOE.MANAGE satisfies the assumption that the users who manage the TOE are non-hostile, appropriately trained and follow all guidance. A.PROTECT The TOE software will be protected from unauthorized modification. OE.PROTECT The TOE environment must protect itself and the TOE from external interference or tampering. OE.PROTECT satisfies this assumption that the TOE environment will provide protection from external interference or tampering. A.TIMESTAMP The IT environment provides the TOE with current time, which is used by the TOE to generate reliable time stamps. OE.TIME The TOE environment must provide reliable time stamps to the TOE. OE.TIME satisfies the assumption that the environment will provide reliable time stamps to the TOE. 8.3 Rationale for Extended Security Functional Requirements A family of EXT_FCR requirements was created to specifically address the capability of the TOE to monitor transactions and record transaction data that represents potentially fraudulent activity against a TOE-protected system. These requirements exhibit functionality that can be easily documented in the ADV assurance evidence and thus do not require any additional Assurance Documentation. 8.4 Rationale for Extended TOE Security Assurance Requirements There are no extended TOE Security Assurance components associated with this evaluation. 8.5 Security Requirements Rationale The following discussion provides detailed evidence of coverage for each security objective. The table below demonstrates that the mapping between the security objectives and SFRs are complete. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 59 of 72 © 2009 RSA®, The Security Division of EMC Table 17 – Mapping of SFRs to TOE Security Objectives Security Objectives for the TOE Security Functional Requirements O.ADMIN O.ADMIN_AUTH O.ENDUSER_AUTH O.MONITOR O.RECOMMEND O.RISK_FACTOR OE.TIME FDP_ACC.1(a)  FDP_ACC.1(b)  FDP_ACF.1(a)  FDP_ACF.1(b)  FDP_ETC.1      FDP_IFC.1  FDP_IFF.1  FDP_ITC.1      FIA_ATD.1(a)  FIA_ATD.1(b)  FIA_SOS.1  FIA_UAU.1  FIA_UAU.2  FIA_UAU.5  FIA_UAU.6  FIA-UAU.7  FIA_UID.1  Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 60 of 72 © 2009 RSA®, The Security Division of EMC Security Objectives for the TOE Security Functional Requirements O.ADMIN O.ADMIN_AUTH O.ENDUSER_AUTH O.MONITOR O.RECOMMEND O.RISK_FACTOR OE.TIME FIA_UID.2  FMT_MOF.1(a)   FMT_MOF.1(b)   FMT_MSA.1(a)   FMT_MSA.1(b)   FMT_MSA.1(c)   FMT_MSA.3   FMT_MTD.1(a)   FMT_MTD.1(b)   FMT_MTD.1(c)   FMT_SMF.1   FMT_SMR.1   FPT_STM.1  EXT_FCR_ARP.1  EXT_FCR_GEN.1  EXT_FCR_CDA.1   EXT_FCR_CDA.2  Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 61 of 72 © 2009 RSA®, The Security Division of EMC 8.5.1 Rationale for Security Functional Requirements of the TOE Objectives Table 18 – Objectives/SFRs Mapping Objective Requirements Addressing the Objective Rationale O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data, ensuring that TOE users with the appropriate privileges, and only those TOE users, may exercise such management control. FMT_MOF.1(a) Management of security functions behaviour This requirement meets the objective O.ADMIN by providing functions to manage TOE security functions, and by ensuring that the management of the functions’ behavior is restricted to authorized users only. FMT_MOF.1(b) Management of security functions behaviour This requirement meets the objective O.ADMIN by providing functions to manage TOE security functions, and by ensuring that the management of the functions’ behavior is restricted to authorized users only. FMT_MSA.1(a) Management of security attributes This requirement meets the objective O.ADMIN by providing functions to manage TOE security attributes, and by ensuring that the management of the attributes is restricted to authorized users only. FMT_MSA.1(b) Management of security attributes This requirement meets the objective O.ADMIN by providing functions to manage TOE security attributes, and by ensuring that the management of the attributes is restricted to authorized users only. FMT_MSA.1(c) Management of security attributes This requirement meets the objective O.ADMIN by providing functions to manage TOE security attributes, and by ensuring that the management of the attributes is restricted to authorized users only. FMT_MSA.3 Static attribute initialisation This requirement meets the objective by providing a function to manage default values for given security attributes, and by restricting that capability to authorized users. FMT_MTD.1(a) Management of TSF data This requirement meets the objective O.ADMIN by providing functions to manage TSF data, and by ensuring that the management of the data is restricted to authorized users only. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 62 of 72 © 2009 RSA®, The Security Division of EMC Objective Requirements Addressing the Objective Rationale FMT_MTD.1(b) Management of TSF data This requirement meets the objective O.ADMIN by providing functions to manage TSF data, and by ensuring that the management of the data is restricted to authorized users only. FMT_MTD.1(c) Management of TSF data This requirement meets the objective O.ADMIN by providing functions to manage TSF data, and by ensuring that the management of the data is restricted to authorized users only. FMT_SMF.1 Specification of Management Functions The requirement meets the objective O.ADMIN by ensuring that the TOE includes administrative functions to facilitate the management of the TSF. FMT_SMR.1 Security roles The requirement meets the objective O.ADMIN by ensuring that the TOE associates users with roles to provide access to TSF management functions and data. O.ADMIN_AUTH The TOE must be able to identify and authenticate administrative users prior to allowing access to TOE administrative functions and data. FDP_ACC.1(a) Subset access control The requirement meets the objective O.ADMIN_AUTH by ensuring that access control is applied to users before they are allowed access to TOE administrative functions and data. FDP_ACF.1(a) Security attribute based access control The requirement meets the objective O.ADMIN_AUTH by ensuring that the TOE enforces access control based on the implemented policy. FDP_ETC.1 Export of user data without security attributes The requirement meets the objective O.ADMIN_AUTH by ensuring that administrative user credentials are stored in the external database. FDP_ITC.1 Import of user data without security attributes The requirement meets the objective O.ADMIN_AUTH by ensuring that administrative user credentials are retrieved from the external database. FIA_ATD.1(a) User attribute definition The requirement meets the objective O.ADMIN_AUTH by maintaining a set of security attributes used for administrators to authenticate. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 63 of 72 © 2009 RSA®, The Security Division of EMC Objective Requirements Addressing the Objective Rationale FIA_SOS.1 Verification of secrets The requirement meets the objective O.ADMIN_AUTH by ensuring that administrator passwords meet a minimum length criterion. FIA_UAU.1 Timing of authentication The requirement meets the objective O.ADMIN_AUTH by ensuring that administrators cannot perform TSF- mediated functions before authenticating to the TOE. FIA-UAU.7 Protected authentication feedback The requirement meets the objective O.ADMIN_AUTH by ensuring that limited feedback is given while administrators authenticate to the TOE. FIA_UID.1 Timing of identification The requirement meets the objective O.ADMIN_AUTH by ensuring that administrators cannot perform TSF- mediated functions before being identified by the TOE. FMT_MOF.1(a) Management of security functions behaviour The requirement meets the objective O.ADMIN_AUTH by ensuring that TOE security functions can be managed only by authorized administrators. FMT_MOF.1(b) Management of security functions behaviour The requirement meets the objective O.ADMIN_AUTH by ensuring that TOE security functions can be managed only by authorized administrators. FMT_MSA.1(a) Management of security attributes The requirement meets the objective O.ADMIN_AUTH by ensuring that security attributes can be managed only by authorized administrators. FMT_MSA.1(b) Management of security attributes The requirement meets the objective O.ADMIN_AUTH by ensuring that security attributes can be managed only by authorized administrators. FMT_MSA.1(c) Management of security attributes The requirement meets the objective O.ADMIN_AUTH by ensuring that security attributes can be managed only by authorized administrators. FMT_MSA.3 Static attribute initialisation This requirement meets the objective by restricting the capability to manage default values for given security attributes to authorized administrators. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 64 of 72 © 2009 RSA®, The Security Division of EMC Objective Requirements Addressing the Objective Rationale FMT_MTD.1(a) Management of TSF data The requirement meets the objective O.ADMIN_AUTH by ensuring that TSF data can be managed only by authorized administrators. FMT_MTD.1(b) Management of TSF data The requirement meets the objective O.ADMIN_AUTH by ensuring that TSF data can be managed only by authorized administrators. FMT_MTD.1(c) Management of TSF data The requirement meets the objective O.ADMIN_AUTH by ensuring that TSF data can be managed only by authorized administrators. FMT_SMF.1 Specification of Management Functions The requirement meets the objective O.ADMIN_AUTH by ensuring that the TOE includes administrative functions to facilitate the management of the TSF. FMT_SMR.1 Security roles The requirement meets the objective O.ADMIN_AUTH by ensuring that the TOE associates users with roles to provide access to TSF management functions and data. O.ENDUSER_AUTH The TOE must be able to identify and authenticate end users prior to allowing access to end user functions and data and high-risk transactions. FDP_ACC.1(b) Subset access control The requirement meets the objective O.ENDUSER _AUTH by ensuring that access control is applied to end users before they are allowed access to user functions and data. FDP_ACF.1(b) Security attribute based access control The requirement meets the objective O.ENDUSER _AUTH by ensuring that the TOE enforces access control based on the implemented policy. FDP_ETC.1 Export of user data without security attributes The requirement meets the objective O.ENDUSER_AUTH by ensuring that end user credentials are stored in the external database. FDP_ITC.1 Import of user data without security attributes The requirement meets the objective O.ENDUSER_AUTH by ensuring that end user credentials are retrieved from the external database. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 65 of 72 © 2009 RSA®, The Security Division of EMC Objective Requirements Addressing the Objective Rationale FDP_IFC.1 Subset information flow control The requirement meets the objective O.ENDUSER _AUTH by requiring that end users authenticate before being given access to transaction-related functions and data. FDP_IFF.1 Simple security attributes The requirement meets the objective O.ENDUSER _AUTH by enforcing information flow control policies based on end user authentication data. FIA_ATD.1(b) User attribute definition The requirement meets the objective O.ENDUSER _AUTH by defining the attributes by which end users are authenticated. FIA_UAU.2 User authentication before any action The requirement meets the objective O.ENDUSER _AUTH by ensuring that end users are authenticated before access to TSF-mediated functions is allowed. FIA_UAU.5 Multiple authentication mechanisms The requirement meets the objective O.ENDUSER _AUTH by providing multiple methods for End Users to provide additional credentials when required. FIA_UAU.6 Re-authenticating The requirement meets the objective O.ENDUSER _AUTH by ensuring that End Users re-authenticate as required by the information flow control policy. FIA_UID.2 User identification before any action The requirement meets the objective O.ENDUSER _AUTH by ensuring that End Users are identified before access to TSF-mediated functions is allowed. O.MONITOR The TOE must provide a mechanism to continuously monitor end user transactions, and to record potentially risky transactions for later review. EXT_FCR_GEN.1 Case data generation This requirement meets the objective O.MONITOR by defining which monitored activities result in case data, as well as what data must be recorded. EXT_FCR_CDA.1 Potential violation analysis This requirement meets the objective O.MONITOR by ensuring that the detection of potentially fraudulent activities relies on the monitoring of on- going transactions. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 66 of 72 © 2009 RSA®, The Security Division of EMC Objective Requirements Addressing the Objective Rationale FDP_ETC.1 Export of user data without security attributes The requirement meets the objective O.MONITOR by ensuring that transaction data is stored in the external database. FDP_ITC.1 Import of user data without security attributes The requirement meets the objective O.MONITOR by ensuring that transaction data is retrieved from the external database. O.RECOMMEND The TOE must be able to make recommendations regarding the submission of authentication credentials based on a calculated risk associated with the login attempt or transaction. EXT_FCR_CDA.2 Simple attack heuristics This requirement meets the objective O.RECOMMEND by providing a mechanism to determine the risk involved with a given transaction, and the ability to recommend a course of action based on that risk factor. FDP_ETC.1 Export of user data without security attributes The requirement meets the objective O.RECOMMEND by ensuring that risk data is stored in the external database. FDP_ITC.1 Import of user data without security attributes The requirement meets the objective O.RECOMMEND by ensuring that risk data is retrieved from the external database. O.RISK_FACTOR The TOE must provide a mechanism for determining a “risk factor” of allowing a given login or transaction to be performed. EXT_FCR_ARP.1 Security alarms This requirements meets the objective O.RISK_FACTOR by requiring that a recommendation for action be made based on a risk factor determined by the TOE EXT_FCR_CDA.1 Potential violation analysis This requirement meets the objective O.RISK_FACTOR by ensuring that the detection of potentially fraudulent activities relies on the calculation of a risk factor. FDP_ETC.1 Export of user data without security attributes The requirement meets the objective O.RISK_FACTOR by ensuring that risk data is stored in the external database. FDP_ITC.1 Import of user data without security attributes The requirement meets the objective O.RISK_FACTOR by ensuring that risk data is retrieved from the external database. Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 67 of 72 © 2009 RSA®, The Security Division of EMC Objective Requirements Addressing the Objective Rationale OE.TIME The TOE environment must provide reliable time stamps to the TOE. FPT_STM.1 Reliable time stamps This requirement meets the objective OE.TIME by ensuring that the TOE environment provides a reliable time stamp for logging. 8.5.2 Security Assurance Requirements Rationale EAL2 was chosen to provide a low to moderate level of assurance that is consistent with good commercial practices. As such, minimal additional tasks are placed upon the vendor assuming the vendor follows reasonable software engineering practices and can provide support to the evaluation for design and testing efforts. The chosen assurance level is appropriate with the threats defined for the environment. While the system may monitor a hostile environment, it is expected to be in a non-hostile position and embedded in or protected by other products designed to address threats that correspond with the intended environment. At EAL2, the system will have incurred a search for obvious flaws to support its introduction into the non-hostile environment. The augmentation of ALC_FLR.1 was chosen to give greater assurance of the developer’s on-going flaw remediation processes. 8.5.3 Dependency Rationale This ST does satisfy all the requirement dependencies of the Common Criteria. Table 19 lists each requirement to which the TOE claims conformance with a dependency and indicates whether the dependent requirement was included. As the table indicates, all dependencies have been met. Table 19 – Functional Requirements Dependencies SFR ID Dependencies Dependency Met Rationale FDP_ACC.1(a) FDP_ACF.1(a)  FDP_ACC.1(b) FDP_ACF.1(b)  FDP_ACF.1(a) FDP_ACC.1(a)  FMT_MSA.3  FDP_ACF.1(b) FDP_ACC.1(b)  FMT_MSA.3  FDP_ETC.1 FDP_ACC.1 or FDP_IFC.1  Both optional dependencies are present and contribute to FDP_ETC.1. FDP_IFC.1 FDP_IFF.1  Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 68 of 72 © 2009 RSA®, The Security Division of EMC SFR ID Dependencies Dependency Met Rationale FDP_IFF.1 FDP_IFC.1  FMT_MSA.3  FDP_ITC.1 FDP_ACC.1 or FDP_IFC.1  Both optional dependencies are present and contribute to FDP_ITC.1. FMT_MSA.3  FIA_ATD.1(a) No dependencies N/A FIA_ATD.1(b) No dependencies N/A FIA_SOS.1 No dependencies N/A FIA_UAU.1 FIA_UID.1  FIA_UAU.2 FIA_UID.1  FIA_UAU.5 No dependencies N/A FIA_UAU.6 No dependencies N/A FIA-UAU.7 FIA_UAU.1  FIA_UID.1 No dependencies N/A FIA_UID.2 No dependencies N/A FMT_MOF.1(a) FMT_SMF.1  FMT_SMR.1  FMT_MOF.1(b) FMT_SMF.1  FMT_SMR.1  FMT_MSA.1(a) FDP_ACC.1(a)  FMT_SMF.1  Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 69 of 72 © 2009 RSA®, The Security Division of EMC SFR ID Dependencies Dependency Met Rationale FMS_SMR.1  FMT_MSA.1(b) FDP_ACC.1(b)  FMT_SMF.1  FMS_SMR.1  FMT_MSA.1(c) FDP_ACC.1(c)  FMT_SMF.1  FMS_SMR.1  FMT_MSA.3 FMT_MSA.1(a)  FMT_MSA.1(b)  FMT_MSA.1(c)  FMT_SMR.1  FMT_MTD.1(a) FMT_SMF.1  FMS_SMR.1  FMT_MTD.1(b) FMT_SMF.1  FMS_SMR.1  FMT_MTD.1(c) FMT_SMF.1  FMS_SMR.1  FMT_SMF.1 No dependencies N/A FMT_SMR.1 FIA_UID.1  FPT_STM.1 No dependencies N/A EXT_FCR_ARP.1 EXT_FCR_CDA.1  Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 70 of 72 © 2009 RSA®, The Security Division of EMC SFR ID Dependencies Dependency Met Rationale EXT_FCR_GEN.1 FPT_STM.1  EXT_FCR_CDA.1 EXT_FCR_GEN.1  EXT_FCR_CDA.2 No dependencies N/A Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 71 of 72 © 2009 RSA®, The Security Division of EMC 9 Acronyms Table 20 – Acronyms Acronym Definition AA Adaptive Authentication API Application Programming Interface CC Common Criteria CM Configuration Management CSR Customer Service Representative EAL Evaluation Assurance Level GPC General Purpose Computer HTTPS Hypertext Transfer Protocol over Secure Sockets Layer IP Internet Protocol IT Information Technology OOB Out-Of-Band OS Operating System OSP Organizational Security Policy RAM Random Access Memory SAR Security Assurance Requirement SFP Security Functional Policy SFR Security Functional Requirement SMTP Simple Mail Transfer Protocol SP1 Service Pack 1 ST Security Target Security Target, Version 1.0 February 4, 2009 RSA Adaptive Authentication System v6.0.2.1 with Service Pack 1 Page 72 of 72 © 2009 RSA®, The Security Division of EMC Acronym Definition TOE Target of Evaluation TSF TOE Security Function VXML Voice Extensible Markup Language WSDL Web Services Description Language