RSA, The Security Division of EMC RSA Access Manager v6.1. Security Target

Transcription

1 RSA, The Security Division of EMC RSA Access Manager v6.1 Security Target Evaluation Assurance Level: EAL3+ Augmented with ALC_FLR.2 Document Version: 0.8 Prepared for: Prepared by: RSA, The Security Division of EMC Corsec Security, Inc. 174 Middlesex Turnpike Bedford, MA Democracy Lane, Suite 201 Fairfax, VA Phone: (877) RSA-4900 Phone: (703)

2 Table of Contents TABLE OF CONTENTS... 2 TABLE OF FIGURES... 3 TABLE OF TABLES SECURITY TARGET INTRODUCTION PURPOSE SECURITY TARGET AND TOE REFERENCES TOE OVERVIEW TOE Components Excluded Components TOE Environment TOE DESCRIPTION Physical Scope Logical Scope CONFORMANCE CLAIMS SECURITY PROBLEM DEFINITION THREATS TO SECURITY ORGANIZATIONAL SECURITY POLICIES ASSUMPTIONS SECURITY OBJECTIVES SECURITY OBJECTIVES FOR THE TOE SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT IT Security Objectives Non-IT Security Objectives EXTENDED COMPONENTS DEFINITION EXTENDED TOE SECURITY FUNCTIONAL COMPONENTS Class FDP: User Data Protection Class FPT: Protection of the Toe Security Functions EXTENDED TOE SECURITY ASSURANCE COMPONENTS SECURITY REQUIREMENTS CONVENTIONS SECURITY FUNCTIONAL REQUIREMENTS Class FAU: Security Audit Class FDP: User Data Protection Class FIA: Identification and Authentication Class FMT: Security Management Class FPT: Protection of the TSF Class FTA: TOE Access SECURITY ASSURANCE REQUIREMENTS TOE SUMMARY SPECIFICATION TOE SECURITY FUNCTIONS Security Audit User Data Protection Identification and Authentication Security Management Protection of the TSF TOE Access RATIONALE CONFORMANCE CLAIMS RATIONALE RSA Access Manager v6.1 Page 2 of 81

3 8.2 SECURITY OBJECTIVES RATIONALE Security Objectives Rationale Relating to Threats Security Objectives Rationale Relating to Policies Security Objectives Rationale Relating to Assumptions RATIONALE FOR EXTENDED SECURITY FUNCTIONAL REQUIREMENTS RATIONALE FOR EXTENDED TOE SECURITY ASSURANCE REQUIREMENTS SECURITY REQUIREMENTS RATIONALE Rationale for Security Functional Requirements of the TOE Objectives Security Assurance Requirements Rationale Dependency Rationale TERMINOLOGY AND ACRONYMS Terminology Acronyms Table of Figures FIGURE 1 TYPICAL DEPLOYMENT CONFIGURATION OF THE TOE... 6 FIGURE 2 FDP_ACF_(EXT) FAMILY DECOMPOSITION FIGURE 3 FDP_ACF_(EXT) FAMILY DECOMPOSITION FIGURE 4 FPT_TST_(EXT) FAMILY DECOMPOSITION FIGURE 5 FPT_TST_(EXT) FAMILY DECOMPOSITION Table of Tables TABLE 1 ST AND TOE REFERENCES... 4 TABLE 2 TOE MINIMUM REQUIREMENTS TABLE 3 CC AND PP CONFORMANCE TABLE 4 THREATS TABLE 5 ORGANIZATIONAL SECURITY POLICIES TABLE 6 ASSUMPTIONS TABLE 7 SECURITY OBJECTIVES FOR THE TOE TABLE 8 IT SECURITY OBJECTIVES TABLE 9 NON-IT SECURITY OBJECTIVES TABLE 10 EXTENDED TOE SECURITY FUNCTIONAL REQUIREMENTS TABLE 11 TOE SECURITY FUNCTIONAL REQUIREMENTS TABLE 12 AUDITABLE EVENTS TABLE 13 ASSURANCE REQUIREMENTS TABLE 14 MAPPING OF TOE SECURITY FUNCTIONS TO SECURITY FUNCTIONAL REQUIREMENTS TABLE 15 AUDIT RECORD CONTENTS TABLE 16 MAPPING OF TOE SECURITY OBJECTIVES TO THREATS AND POLICIES TABLE 17 THREATS:OBJECTIVES MAPPING TABLE 18 POLICIES:OBJECTIVES MAPPING TABLE 19 ASSUMPTIONS:OBJECTIVES MAPPING TABLE 20 MAPPING OF SFRS TO TOE SECURITY OBJECTIVES TABLE 21 OBJECTIVES:SFRS MAPPING TABLE 22 FUNCTIONAL REQUIREMENTS DEPENDENCIES RSA Access Manager v6.1 Page 3 of 81

4 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 Access Manager, v6.1 and will hereafter be referred to as the TOE throughout this document. The TOE (Access Manager) is a software product designed to fulfill identity management needs. The TOE provides a central management interface which allows efficient administration of the security policy being enforced, and the users upon which the policy is enforced. 1.1 Purpose This ST provides mapping 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), ST 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 new components (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 Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) met by the TOE and by the TOE s environment. 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. Terminology and Acronyms (Section 9) Defines the acronyms and terminology used within this ST. 1.2 Security Target and TOE References Table 1 ST and TOE References ST Title ST Version ST Author RSA, The Security Division of EMC RSA Access Manager v6.1 Security Target Version 0.8 Corsec Security, Inc. ST Publication Date November 5, 2009 TOE Reference RSA Access Manager v6.1 build Note: The U.S. Government Protection Profile Authorization Server for Basic Robustness Environments, Version 1.1 dated 25 July 2007 contains IT Environment Security Functional Requirements requiring that the IT Environment be RSA Access Manager v6.1 Page 4 of 81

5 compliant with the Controlled Access Protection Profile or an Operating System Protection Profile at the Basic Level of Robustness or Greater. As v3.1 of the Common Criteria Standard does not require Environmental SFRs, these SFRs have been removed, but the associated Environmental Objectives remain. 1.3 TOE Overview The TOE Overview summarizes the usage and major security features of the TOE. The TOE Overview provides a context for the TOE evaluation by identifying the TOE type, describing the product, and defining the specific evaluated configuration. RSA Access Manager (the TOE) is a software product designed to fulfill identity management needs. The TOE has a central management interface which allows efficient administration of the security policy being enforced, and the users the policy is being enforced upon. The TOE manages user accounts and determines whether or not users have the correct permissions to view protected resources. In its typical deployment scenario, an Access Manager Agent is installed on a server that hosts a protected resource. Each time a user attempts to access the protected resource, the server will redirect the user to the TOE server to authenticate himself. If the user is successfully authenticated, and if the user has the permissions required allowing the user to view the resource, then the user will be granted access to the protected resource. The TOE has the following features: Resource Access Management The TOE controls access to protected resources over the web. If a user attempts to view a protected resource, the user must successfully authenticate himself before Access Manager will grant or deny him access to the resource based on his privilege profile. Interoperability The TOE is capable of being successfully deployed throughout multi-vendor environments. The TOE additionally provides native support for user LDAP (Lightweight Directory Access Protocol) data stores. Single Sign-On With Single Sign-On, users are able to seamlessly access protected resources deployed on various servers throughout the network without having to re-authenticate their identities. Identity Management and User Privilege Management Identities can be centrally managed, and trust in each identity is established through user authentication. Additionally, privileges are centrally managed and can be mapped to user identities statically (for example: each department can have its own set of privileges) or dynamically (e.g. each account has privileges specific only to that account). SNMP (Simple Network Management Protocol) Support Access Manager provides support for a thirdparty Network Management System (NMS) using SNMP. An NMS reveals how the Access Manager Servers are functioning in a production environment, making it easier to configure them for optimal performance. Auditing and Reporting Logs are recorded, and reports can be generated based on logs that capture the actions of users, administrators, and system processes. Protection The TOE uses the RSA BSAFE module in the TOE s operational environment to obfuscate all traffic over the network (via TLS (Transport Layer Security). Additionally, the TOE can optionally obfuscate component configuration files on-disk. Authentication Support - Authentication methods are configured on each non-toe Agent. Access Manager can work with Oracle and iplanet data stores, and supports the following authentication methods 1 : o Basic. This is the default authentication method. At logon, users enter their user names and passwords, which are authenticated with the user account information in the Access Manager data store. o RSA SecurID. Access Manager supports RSA SecurID two-factor authentication. At logon, a user name and password are authenticated against the credentials stored in the Authentication Manager. 1 Note that only the Basic authentication method is included in the evaluated configuration of the TOE. RSA Access Manager v6.1 Page 5 of 81

6 o X.509 Certificates. Access Manager supports X.509 certificates. The web server must be configured to accept browser certificates for authentication. o Windows. Access Manager can use several methods to authenticate users against the Windows environment. These include NT, NT LAN (Local Area Network) Manager (NTLM), and Integrated Windows Authentication (IWA). o Custom. Developers can use an Access Manager Web Agent Extension (WAX) or the Access Manager Runtime API (Application Programming Interface) to create their own custom authentication methods, with custom error messages and logging. They can also create WAX programs that integrate with existing legacy authentication methods. Each authentication method prompts the user to provide the appropriate identification credentials. For added security, administrators can combine different authentication methods. For example, one could require that a user first authenticate by Basic authentication and then by Windows NT authentication. Figure 1 shows the typical deployment configuration of the TOE: Log Server Figure 1 Typical Deployment Configuration of the TOE RSA Access Manager v6.1 Page 6 of 81

7 1.3.1 TOE Components The TOE comprises multiple components which work together to perform identity and access management services. The following components compose the TOE Entitlements Server The Entitlements Server provides Administrative API clients (including the Administrative Console) with read/write access to the Access Manager data store. This allows the Administrator to establish security policies, or modify existing policies. The Entitlements Server can be configured to selectively update the cached data on the Authorization Servers. By doing so, changes made to the Access Manager data store, such as entitling a user to access a resource, take effect immediately. The Entitlements Server provides auditing to track administrator actions on the server Authorization Server The Authorization Server performs the authentication and authorization checks for users at runtime. As a user attempts to access a protected resource, the Authorization Server determines whether the authentication method validated the user and if the user is allowed to access the resource. The Authorization Server reads the user and policy information directly from the data store. The Authorization Server can be configured to cache a variety of data. When properly configured, the Authorization Server does not have to access the data store to check access privileges for users who have already been allowed or denied access to a resource. The Authorization Server provides auditing to track administrator actions on the server Dispatcher/Key Server The Dispatcher/Key Server has two functions. The Dispatcher keeps track of all available Authorization Servers. By default, Agents are configured to query the Dispatcher at startup for available Authorization Servers. Agents then connect to the Authorization Servers that are available. The Key Server generates single sign-on (SSO) token encryption keys (or secret keys) via a cryptographic module in the TOE s operational environment, which carry a limited lifetime. When a user authenticates to the Access Manager system, the Authorization Server issues a token, encrypted with one of these keys via the environmental cryptographic module, which encapsulates the user's session state. The Agent returns this token to the user's browser in the form of a cookie. On subsequent requests, the token is sent back to the Authorization Server for decryption by the environmental cryptographic module as needed. The Dispatcher/Key Server provides auditing to track administrator actions on the server RSA Access Manager Data Adapters Access Manager uses the Data Abstraction Layer (DAL) to access user data in data stores, such as an LDAP directory or an SQL database. The user data store contains all information about TOE users and their access privileges. Access Manager adds additional policy, resource, and administration data schemas to the directory server or database, which can be managed separately from the user data store. This allows the administrator to consolidate users and security policies into one central location, making administration of the enterprise security less time-consuming. Access Manager policy, resource, and administrative data can also be kept in separate data stores from user and group data. The Administrator can configure the Data Adapter to control the location and setup of the user and policy data stores. Keep in mind that data stores must all be of the same type. For example, Administrators cannot store some users in an LDAP directory, and other users in an SQL database. Changes to the Access Manager data stores are made through the Administrative Console (or through the Administrative API, which has larger capabilities than those provided by the Administrative Console). Both the Entitlements Server and Authorization Server use the Data Abstraction Layer (DAL) drivers to connect directly to data servers. A single Data Adapter is needed for each of the data stores. RSA Access Manager v6.1 Page 7 of 81

8 RSA Access Manager Administrative Console The access Manager Administrative Console is used to administer the system. The Administrative Console is a web-based, Java Server Page (JSP) application installed on any supported application server or servlet engine. For a list of supported application servers and servlet engines, see the Servers Installation and Configuration Guide. The Administrative Console can be accessed from any computer with a web browser. From the Administrative Console, administrative groups and roles can be set up, resources added, and security policies defined. The Administrative Console can be used to add and edit users and groups, and store the information in its data store Excluded Components The following product components can be implemented, depending on an Enterprise s security needs, system load, existing network architecture, and logging plans. However, they are not part of the TOE Web Server and Application Server Agents An Agent must be installed on each of the servers Administrators want to protect. There are two types of Agents: Web Server Agents and Applications Server Agents. These are described below: Web Server RSA Access Manager Web Server Agents supplement the native security mechanisms of a web server. They run in the same process as the web server itself and are invoked whenever the web server needs to determine access rights for a particular Uniform Resource Locator (URL). The Agents forward access requests to an Authorization Server, which passes the answers it receives back to the web server Application Server RSA Access Manager Application Server Agents supplement the native security on application servers with Access Manager, and extend single sign-on to the web application environment. This allows Administrators to protect web resources, such as servlets, Enterprise Java Beans (EJBs), and Java Server Pages (JSPs) with Access Manager Redundant RSA Access Manager Servers and LDAP Directories Additional Access Manager Servers and LDAP directories can be deployed to increase runtime performance, stability, and to eliminate single points of failure in the Access Manager system RSA Access Manager Log Server The Access Manager Log Server allows the administrator to configure the system so that all servers write to a single log file, regardless of where the servers are physically located RSA Access Manager Instrumentation Server The Instrumentation Server provides Simple Network Management Protocol (SNMP) support for a third-party Network Management System (NMS). Using an NMS, a system administrator can query the Instrumentation Server for information about the Access Manager Servers that are running in a production environment. This allows for real-time monitoring of Server activity and performance RSA Access Manager Secure Proxy Server The Access Manager Secure Proxy Server (SPS) is a self-contained reverse proxy and access control solution that consists of these components: Secure Apache-based HTTP server RSA Access Manager v6.1 Page 8 of 81

9 Fully integrated RSA Access Manager Agent Proxy engine The SPS can be used as a proxy-based gateway to secure web servers. This allows the protection of web servers not currently supported by an Access Manager Web Server Agent. The Access Manager SPS can be placed in the Demilitarized Zone (DMZ) of the network to ensure that non-authenticated users cannot access the web resources, even though the web servers where these resources reside are not protected by an RSA Access Manager Agent. The SPS provides rapid, out-of-the-box access control in a robust and scalable fashion. The proxy engine can be configured to dynamically route incoming requests to the appropriate web server RSA Security Certificate Manager The Security Certificate Manager creates keystores that can be used by Access Manager for inter-component security. RSA Access Manager Software Development Kit Access Manager is a highly customizable solution. The following Access Manager Application Programming Interfaces (APIs) and Service Provider Interfaces (SPIs) can be used to create custom applications that work with the Access Manager components Administrative APIs (Java and DCOM) The Java and DCOM versions of the Administrative API allow Administrators to develop applications that interact with the Entitlements Server to create user accounts and the security policies that protect resources. A security policy identifies protected resources, defines the entitlements and Smart Rules that control access to these resources, and identifies the administrative groups and administrative roles in these groups that manage the security policy itself. In addition, if Access Manager is configured for write access to the user data store, then the Administrative API applications can create and update users and user groups. This allows Administrators to write custom programs to perform various administrative functions. For example: Load a large quantity of data from another source directly into the Access Manager data store. Develop custom web applications to perform self-registration and self-service account management for Access Manager. Develop custom policy administration applications that enhance the functionality provided by the Administrative Console. Note: The C Administrative API was deprecated in RSA ClearTrust and is not included with Access Manager 6.0. It is still available to developers who download an older version of the Software Development Kit (SDK) Runtime APIs (Java, C, and DCOM) The Java, C, and DCOM versions of the Runtime API allow Administrators to develop custom programs that use or extend the runtime functionality of the Authorization Server. The Runtime API provides efficient and scalable readonly access to certain Access Manager objects and security policy settings. Administrators can use the Runtime API to: Authenticate users. Control user access to protected resources. Personalize a user s online experience. Allow SSO tokens created by the Runtime API to be passed to application servers and web servers. 2 RSA Access Manager was formerly known as RSA ClearTrust. RSA Access Manager v6.1 Page 9 of 81

10 Web Agent Extension (WAX) API The WAX API, implemented in C, extends the functionality of RSA s Access Manager Web Server Agents. This allows Administrators to customize or control the behavior of the Agent during the authentication and authorization processing. For example, Administrators can: Create an extension to do custom logging. Create an extension to do custom authentication of users without connecting to an Access Manager Authorization Server. Create an extension to direct the web server to custom HTML pages based on the return codes returned from the Authorization Server Service Provider Interfaces The Service Provider Interfaces (SPIs) allow Administrators to extend the Access Manager Servers in various ways by implementing code that is run in-process as part of the Servers. This code is registered with the Servers to be invoked at certain points during client request processing. This allows Administrators to: Alter or override default Administrative and Runtime API call behavior, or to perform arbitrary operations (for example, sending notifications to remote systems) when such calls are executed. Retrieve user properties from third-party data sources for use in Smart Rule evaluation and by RSA Access Manager Agents. Make additional Runtime API calls within the context of a client call execution within the Authorization Server. This makes it possible to have more complex combinations of authentication and authorization logic TOE Environment The necessary hardware and software for the TOE to operate is described in Table 2 below. Enforcement of RSA Access Manager s access control decisions on principals are enforced by servers and programs in the TOE Environment. The host computer will need to have a network connection. Additionally, the operating system must be in a secure location, operate in a secure state, and run a FIPS validated version of RSA BSAFE. 1.4 TOE Description This section will primarily address the physical and logical components of the TOE included in the evaluation Physical Scope Figure 1 above 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. The TOE is a software-only TOE designed to fulfill identity management needs. The server software components which make up the TOE are typically installed on a single host computer that is compliant with the minimum requirements as listed in Table 2. The non-toe servers hosting resources requiring protection will typically also host a non-toe Access Manager Agent which will refer the principal (any user or application) to the Access Manager Server when the principal attempts to access a protected resource, as depicted in Figure 1 above. There are no hardware components that come with the TOE. RSA Access Manager v6.1 Page 10 of 81

11 TOE Software The TOE is a software product designed to fulfill identity management needs. The software that makes up the TOE is typically installed on a single host computer Guidance Documentation The following guides are required reading and part of the TOE: RSA Access Manager 6.1 Getting Started RSA Access Manager 6.1 Common Criteria Installation and Configuration Guide RSA Access Manager 6.1 Servers Installation and Configuration Guide RSA Access Manager 6.1 Administrator s Guide RSA Access Manager 6.1 Planning Guide RSA Access Manager 6.1 Upgrade Guide (if upgrading from a previous version of Access Manager (which was formerly called ClearTrust)) Logical Scope The security functional requirements implemented by the TOE are usefully grouped under the following Security Function Classes: Security Audit User Data Protection Identification and Authentication Security Management Protection of the TOE Security Functions TOE Access Security Audit The Security Audit function provides the TOE with the functionality for generation of audit records. As administrators manage and configure the TOE, their activities are automatically logged. All security-relevant configuration settings and changes are recorded to ensure accountability of the administrator s actions User Data Protection The User Data Protection function implements functionality for TOE security functions and TOE security function policies related to protecting user data. The user data that the TOE is protecting is any resource(s) that the TOE is assigned by the administrator to protect. The TOE uses its Authorization Server Access Control Policy to provide an access decision and enforce the decision on principals, protected resources, and all operations between the two. An access decision is provided and enforced by the TOE through the comparison of user attributes with the Authorization Server Access Control Policy, which is composed of Entitlements and/or Smart Rules implemented by the administrator Identification and Authentication The Identification and Authentication function identifies and authenticates users to the TOE. End users must identify and authenticate themselves to the TOE anytime they wish to access a resource protected by the TOE. Access Manager provides its own internal authentication mechanism for identifying and authenticating users to the TOE. It does this by validating the user s username and password against the Access Manager Data store. The TOE can integrate with several external authentication types such as Microsoft NT Primary Domain Controller (PDC). Additionally, each administrator must identify and authenticate himself before he can administer the TOE. RSA Access Manager v6.1 Page 11 of 81

12 Security Management The Security Management features provide management and administration functions of the TOE for its administrators. The TSF is capable of associating users with roles. The TOE uses customizable user roles. The Security Administrator is the only user who can configure or modify the Authorization Server Access Control Policy settings. Additionally, only the Security Administrator is authorized to modify security attributes, for principals or protected resources, used by the Authorization Server Access Control Policy to make access decisions Protection of the TOE Security Functions The Security Administrator is the sole role capable of modifying and verifying the integrity of the TOE system configuration files. Additionally, only the Security Administrator is capable of verifying the integrity of the stored TSF executable code TOE Access When an administrator initiates an administrative user session, the TOE displays an advisory message warning about unauthorized use of the TOE Security Considerations in the TOE Environment: The TOE s underlying operating system must be maintained in a secure state and physical access to the computers hosting the Access Manager components must be kept secure. Table 2 specifies the minimum system requirements for the proper operation of the TOE. Table 2 TOE Minimum Requirements Category Windows Solaris Operating System Operating System: Microsoft Windows Server 2003 SP2 including R2 (64 bit) x86 Architecture: x86/x86-64/em64t, 500 MHz (Megahertz) or faster Disk Space: 200 MB Operating System: Solaris 10 on SPARC 64 bit Architecture: UltraSPARC, 500 MHz or faster Disk Space: 200 MB Administrative Console BEA WebLogic Server 10 BEA WebLogic Server 10 Data Store Oracle 10g Release 2 (10.2) iplanet 6.3 RSA Access Manager Agents IIS Web Agent 4.8 on Win2k3 R2 SP2 64 bit Apache2.x.x Agent 4.8 on Solaris 10 Sparc Browser IE 6 IE 6 RSA Access Manager v6.1 Page 12 of 81

13 2 Conformance Claims This section provides the identification for any CC, Protection Profile (PP), 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 3 CC and PP Conformance Common Criteria (CC) Identification and Conformance PP Identification Evaluation Assurance Level Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 2, September 2007; CC Part 2 extended; CC Part 3 conformant; PP claim. US Government Protection Profile Authorization Server for Basic Robustness Environments, version 1.1 EAL3+ Augmented with Flaw Remediation (ALC_FLR.2) RSA Access Manager v6.1 Page 13 of 81

14 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 4 Threats Name Description T.ACCIDENTAL_ADMIN_ERROR An administrator may incorrectly install or configure the TOE resulting in ineffective security mechanisms. T.ACCIDENTAL_AUDIT_COMPR OMISE An administrative user or process may view audit records, cause audit records to be lost or modified, or prevent future audit records from being recorded, thus masking a user's action. T.ACCIDENTAL_CRYPTO_COM PROMISE An administrative user or process may cause key, data or executable code associated with the cryptographic functionality to be inappropriately accessed (viewed, modified, or deleted), thus compromising the cryptographic mechanisms and the data protected by those mechanisms. T.LOW_PRIORITY A low priority process may exhaust resources required by the TOE. T.MASQUERADE A user or process may masquerade as another entity in order to gain unauthorized access to data or TOE resources. RSA Access Manager v6.1 Page 14 of 81

15 Name Description T.POOR_DESIGN Unintentional errors in requirements specification or design of the TOE may occur, leading to flaws that may be exploited by a casually mischievous user or program. T.POOR_IMPLEMENTATION Unintentional errors in implementation of the TOE design may occur, leading to flaws that may be exploited by a casually mischievous user or program. T.POOR_TEST Developers or test engineers may implement tests that are insufficient to demonstrate that all TOE security functions operate correctly (including in a fielded TOE) may result in incorrect TOE behavior being discovered thereby causing potential security vulnerabilities. T.RESIDUAL_DATA A user or process may gain unauthorized access to data through reallocation of TOE resources from one user or process to another. T.TSF_COMPROMISE An attacking user or process may cause, through an unsophisticated attack, TSF data, or executable code to be inappropriately accessed (viewed, modified, or deleted). T.UNATTENDED_SESSION A user may gain unauthorized access to an unattended session. T.UNAUTHORIZED_ACCESS A user or application may gain access to the data for which they are not authorized according to the TOE security policy. T.UNIDENTIFIED_ACTIONS The administrator may not have the ability to notice potential security violations, this limiting the administrator's ability to identify and take action against a possible security breach, 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 operational environment of the TOE. The following OSPs are presumed to be imposed upon the TOE or its operational environment by any organization implementing the TOE in the CC evaluated configuration: Table 5 Organizational Security Policies Name Description P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by access the system. P.ACCOUNTABILITY The TOE shall log all actions by authorized users such that the authorized RSA Access Manager v6.1 Page 15 of 81

16 Name Description users can be held accountable for their actions within the TOE. P.BASIC_ROBUSTNESS The TOE must be developed in accordance with the Basic Robustness guidelines. P.CAPP_OS The operating system the TOE operates on top of must be evaluated to be compliant with the Controlled Access Protection Profile. P.COMMS Communications exist between the TOE components (internally) and between the TOE components and the IT components. P.CRYPTOGRAPHY Only NIST FIPS validated cryptography (methods and implementations) are acceptable for key management (i.e.; generation, access, distribution, destruction, handling, and storage of keys) and cryptographic services (i.e., encryption, decryption, signature, hashing, key exchange, and random number generation services). P.HIGH_AVAILABILITY The TOE shall include providing resource allocations to support priority of service and fault tolerance. P.NO_GENERAL_PURPOSE There will be no general-purpose computing or storage repository capabilities (e.g., compilers, editors, or user applications) available on the hardware platforms that the TOE administrative and authorization policy engine software are installed. If Authorization Server "Agent" software is part of the TOE, then the system on which the Agent operates is exempt from the assumption. P.TOE_ENVIRONMENT_ACCESS The TOE environment will provide mechanisms that control a user's logical access to the TOE environment components. P.WEB_BROWSER_PP If administrators use a web browser to access the TOE for remote administration, they must use software that has been evaluated to the Web Browser Protection Profile. Note to Consumer: The Authorization Server Protection Profile states If the TOE supports remote administration via web browser, then the guidance documents shall instruct administrators to use a web browser that has been evaluated to be compliant with the Web Server Protection Profile (if any such web browsers exist at the time of the TOE evaluation). No web browsers have been evaluated against the Web Browser Protection Profile because the Web Browser Protection Profile is still a draft. Therefore, any of the web browsers defined in Table 2 above are acceptable for remote administration of the TOE. 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. RSA Access Manager v6.1 Page 16 of 81

17 Table 6 Assumptions Name Description A.IT_ACCESS The TOE has access to all the IT System data it needs to perform its functions. A.LOWEXP The threat of malicious attacks aimed at discovering exploitable vulnerabilities is considered low. A.MANAGE There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains. A.NO_EVIL Administrators are non-hostile, appropriately trained and follow all administrator guidance. A.NO_TOE_BYPASS Principals cannot gain access to resources protected by the TOE without passing through the TOE access control mechanisms. A.PHYSICAL The IT environment provides the TOE with appropriate physical security, commensurate with the value of the IT assets protected by the TOE. A.SCALABLE The TOE environment is appropriately scalable to provide support to the IT Systems in the organization it is deployed. RSA Access Manager v6.1 Page 17 of 81

18 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 part-wise solutions: 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, as well as providing a mapping of the objectives to the threats, OSPs, and assumptions included in the security problem definition. 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 7 Security Objectives for the TOE Name Description O.ADMIN_GUIDANCE The TOE will provide administrators with the necessary information for secure management. O.AUDIT_GENERATION The TOE will provide the capability to detect and create records of securityrelevant events associated with users. O.CORRECT_TSF_OPERATION The TOE will provide the capability to test the TSF to ensure the correct operation of the TSF at a customer's site. O.DISPLAY_BANNER The TOE will display an advisory warning regarding use of the TOE to the administrative users. O.MANAGE The TOE will provide all the functions and facilities necessary to support the administrators in their management of the security of the TOE, and restrict these functions and facilities from unauthorized use. O.MEDIATE The TOE must protect user data in accordance with its security policy. O.PARTIAL_SELF_PROTECTION The TSF will maintain a domain for its own execution that protects itself and its resources from external interference, tampering, or unauthorized disclosure through its own interfaces. O.RESIDUAL_INFORMATION The TOE will ensure that any information contained in a protected resource is not released when the resource is reallocated. O.TOE_ACCESS The TOE will provide mechanisms that control a user's logical access to the TOE. RSA Access Manager v6.1 Page 18 of 81

19 4.2 Security Objectives for the Operational Environment IT Security Objectives The following IT security objectives are to be satisfied by the environment: Table 8 IT Security Objectives Name Description OE.AUDIT_PROTECTION The IT Environment will provide the capability to protect audit information. OE.CAPP_OS Operating systems the TOE operates on top of must be compliant with the Controlled Access Protection Profile. The operating system will therefore provide all the capabilities outlined in the CAPP security function requirements and will have been evaluated against the CAPP assurance requirements. OE.COMMS Sites deploying the TOE will ensure that adequate communications exist between the TOE components (internally) and between the TOE components and the IT components. OE.CRYPTOGRAPHY The IT environment components shall use NIST FIPS validated cryptographic modules if they provide cryptographic services. OE.DISPLAY_BANNER The underlying operating system of the TOE will display an advisory warning regarding use of the TOE to administrative users logging on the platform where the TOE software is installed. OE.IT_ACCESS Sites deploying the TOE will ensure the TOE has access to all the IT System data it needs to perform its functions. OE.FAULT_TOLERANCE The IT environment will provided limited capabilities to support degraded fault tolerance and fail over for some TOE components. OE.LOWEXP Site deploying the TOE will establish a protective environment where the threat of malicious attacks aimed at discovering exploitable vulnerabilities is considered low. OE.NO_GENERAL_PURPOSE There will be no general-purpose computing or storage repository capabilities (e.g., compilers, editors, or user applications) available on the hardware platforms that the TOE administrative and authorization policy engine software are installed. This objective does not apply to agent software that might reside on a web server. OE.PRIORITY The IT Environment will provide prioritization of resources to support the TOE. OE.RESIDUAL_INFORMATION The IT Environment will ensure that any information contained in a protected resource is not released when the resource is reallocated. RSA Access Manager v6.1 Page 19 of 81

20 Name Description OE.SCALABLE Sites using the TOE will deploy the appropriate hardware and software environment to ensure the TOE system is scalable to provide support to the IT Systems in the organization it is deployed. OE.WEB_BROWSER_PP If administrators use a web browser to access the TOE for remote administration, they must to use software that has been evaluated to the Web Browser Protection Profile. OE.NO_TOE_BYPASS Principals cannot gain access to resources protected by the TOE without passing through the TOE access control mechanisms 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 9 Non-IT Security Objectives Name Description OD.BASIC_ROBUSTNESS The TOE shall be developed in accordance with the Basic Robustness requirements. OD.CONFIGURATION_IDENTIFICATION The configuration of the TOE is fully identified in a manner that will allow implementation errors to be identified, corrected with the TOE being redistributed promptly. OD.DOCUMENTED_DESIGN The design of the TOE is adequately and accurately documented. OD.PARTIAL_FUNCTIONAL_TESTING The TOE will undergo some security functional testing that demonstrates the TSF satisfies its security functional requirements. OD.VULNERABILITY_ANALYSIS The TOE will undergo vulnerability analysis demonstrate the design and implementation of the TOE does not contain any obvious flaws. OE.NO_EVIL Sites using the TOE shall ensure that administrators are non-hostile, appropriately trained and follow all administrator guidance. OE.PHYSICAL Physical security will be provided within the domain for the value of the IT assets protected by the operating system and the value of the stored, processed, and transmitted information. RSA Access Manager v6.1 Page 20 of 81

21 Name Description OE.MANAGE The TOE environmental components will provide all the functions, facilities and competent individuals necessary to support the administrators in their management of the security of the environment, and restrict these functions and facilities from unauthorized use. OE.TOE_ENVIRONMENT_ACCESS The TOE environment will provide mechanisms that control a user s logical access to the environmental components. RSA Access Manager v6.1 Page 21 of 81

22 5 Extended Components Definition This section defines the extended Security Functional Requirements (SFRs) and extended Security Assurance Requirements (SARs) met by the TOE. These requirements are presented following the conventions identified in Section Extended TOE Security Functional Components This section specifies the extended SFRs for the TOE. The extended SFRs are organized by class. Table 10 identifies all extended SFRs implemented by the TOE Table 10 Extended TOE Security Functional Requirements Name FDP_ACF_(EXT).1 Description Security Attribute Based Access Control FPT_TST_(EXT).1 TSF Testing RSA Access Manager v6.1 Page 22 of 81

23 5.1.1 Class FDP: User Data Protection User data protection functions involve functionality for TOE security functions and TOE security function policies related to protecting user data. User data protection function class was modeled after the CC FDP: user data protection. The extended component FDP_ACF_(EXT).1: Security Attribute Based Access Control was modeled after the CC component FDP_ACF.1: Security Attribute Based Access Control. Figure 2 FDP_ACF_(EXT) Family Decomposition RSA Access Manager v6.1 Page 23 of 81

24 Security Attribute Based Access Control (FDP_ACF_(EXT)) Family Behavior This family describes the rules for the specific functions that can implement an access control policy named in Access control policy (FDP_ACC). Access control policy (FDP_ACC) specifies the scope of the policy. Component Leveling Figure 3 FDP_ACF_(EXT) Family Decomposition This family addresses security attribute usage and characteristics of policies. The component within this family is meant to be used to describe the rules for the function that implements the SFP as identified in Access control policy (FDP_ACC). The PP/ST author may also iterate this component to address multiple policies in the TOE. Management: FDP_ACF_(EXT).1 The following actions could be considered for the management functions in FMT: Managing the attributes used to make explicit access or denial based decisions. Audit: FDP_ACF_(EXT).1 The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Minimal: Successful requests to perform an operation on an object covered by the SFP Basic: All requests to perform an operation on an object covered by the SFP. Detailed: The specific security attributes used in making an access check. FDP_ACF_(EXT).1 Security Attribute Based Access Control Hierarchical to: Dependencies: [No other components] FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF_(EXT).1.1 The TSF shall perform an access control decision and [selection of one or more by ST Author: enforce the decision, provide the decision] based on the [assignment: Access Control Policy] to objects based on the following: [assignment: list of subjects and objects controlled under the Authorization Server Access Control Policy, and for each, the relevant security attributes]. FDP_ACF_(EXT).1.2 RSA Access Manager v6.1 Page 24 of 81

25 The TSF shall [selection of one by ST Author: enforce, provide an access control decision based on] the following rules to determine if an operation among controlled subjects and controlled objects is allowed [assignment by ST Author: rules governing access among controlled subject and controlled objects using controlled operations on controlled objects]. FDP_ACF_(EXT).1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [selection: [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects], "no additional rules"] FDP_ACF_(EXT).1.4 The TSF shall explicitly deny access of subjects to objects based on the [selection: [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects], "no additional explicit denial rules"]. Application Note: This requirement (FDP_ACF_(EXT).1) is applicable only if the TOE enforces or provides an access control decision. If the TOE acts only as attribute authority, then this requirement is not applicable. RSA Access Manager v6.1 Page 25 of 81