Hitachi ID Management Suite Version 3.2 Security Target (EAL2) Version 1.98

Transcription

1 Hitachi ID Management Suite Version 3.2 Security Target (EAL2) Version Hitachi ID Systems, Inc. All rights reserved.

2 Hitachi ID Systems, Inc. Document name: Version 3.2 Security Target (EAL2) Submitted to: DOMUS IT Security Laboratory Attn: Submitted by: Hitachi ID Systems, Inc. Document date: April 21, 2008 Document path: PRCS:qa/ccc/doc/st-new.tex 2008 Hitachi ID Systems, Inc. All rights reserved. i

3 Revision History Rev. # Description By Date of Issue 1.0 Initial draft Enzo Bertorelli 26-Aug Update SFR list Enzo Bertorelli 31-Aug Update Functional Characteristics Enzo Bertorelli 13-Sep Update Detailed description Enzo Bertorelli 15-Sep Minors updates to all sections as per DOMUS review Enzo Bertorelli 27-Oct Updates to diagrams in section 1. Updates to the SFR descriptions. Updates to correlations section. Enzo Bertorelli 15-Nov Corrections from Hitachi ID feedback Enzo Bertorelli 25-Nov Changes made as result of CSE suggestions Enzo Bertorelli 07-Jan General Revision Luc D. Cousineau 18-Apr Changes to address DOMUS OR 01 Enzo Bertorelli, Luc D. Cousineau 16-Sep Changes to address CB OR 01 Luc D. Cousineau 27-Nov Final Draft Stacey Kaluta 23-June Minor revision to Final Draft Stacey Kaluta 16-Aug Minor revision to Final Draft to address OR8 Stacey Kaluta 14-Feb Updated conventions and terminology Stacey Kaluta 27-Mar Further updates to acronyms and abbreviations Stacey Kaluta 03-Apr Removed confidential information and associated text from control page Stacey Kaluta 04-Apr Rebranding from M-Tech to Hitachi ID Stacey Kaluta 08-APR Hitachi ID Systems, Inc. All rights reserved. ii

4 Table of Contents 1 Introduction Identification Security target overview CC conformance claim TOE Description ID-Synch Primitive operations Core features P-Synch Primitive operations Core features Shared architecture Security Interaction with target systems Web access TOE boundary TOE Security Environment Secure usage assumptions Threats to security Organizational security policies Security Objectives Security objectives for the TOE Security objectives for the IT environment IT Security Requirements Hitachi ID Systems, Inc. All rights reserved. iii

5 5.1 TOE security functional requirements Security audit (FAU) User data protection (FDP) Identification and authentication (FIA) Security management (FMT) Protection of the TOE security functions (FPT) TOE security assurance requirements Configuration management (ACM) Delivery and operation (ADO) Development (ADV) Guidance documents (AGD) Tests (ATE) Vulnerability assessment (AVA) Security requirements for the IT environment Protection of the TOE security functions (FPT) Statement of strength of TOE security function TOE Summary Specification Statement of TOE IT security functions Assurance measures PP Claims 34 8 Rationale Introduction Security objectives rationale Security functional requirements rationale Assurance security requirements rationale Dependencies rationale Hitachi ID Systems, Inc. All rights reserved. iv

6 List of Tables 5-2 Auditable Events Assurance Requirements for EAL Assurance Measures Mapping the TOE Security Environment to Security Objectives Mapping Security Objectives to Security Functional Requirements Mapping TOE IT Security Functions to Security Function Requirements Functional and Assurance Requirements Dependencies Hitachi ID Systems, Inc. All rights reserved. v

7 List of Figures 1 Integration With Target Systems Web access architecture diagram TOE Boundary Hitachi ID Systems, Inc. All rights reserved. vi

8 Conventions and Terminology Through this document, operations performed in Common Criteria requirements are highlighted like this. Acronyms and abbreviations CC CCCS CEM COTS EAL PP SARs SFP SFRs ST TBD TOE TSC TSF TSP Common Criteria Canadian Common Criteria Scheme Common Methodology for Information Technology Security Commercial-Off-The-Shelf Evaluation Assurance Level Protection Profile Security Assurance Requirements Security Function Policy Security Functional Requirements Security Target To Be Determined Target of Evaluation TSF Scope of Control TOE Security Function TOE Security Policy 2008 Hitachi ID Systems, Inc. All rights reserved. 1

9 Document Organization Section 1 provides the introductory material for the Security Target. Section 2 provides general purpose and TOE description. Section 3 provides a discussion of the expected environment for the TOE. This section also defines the set of threats that are to be addressed by either the technical countermeasures implemented in the TOE hardware or software or through the environmental controls. Section 4 defines the security objectives for both the TOE and the TOE environment. Section 5 contains the functional and assurance requirements derived from the Common Criteria Parts 2 and 3, respectively, that must be satisfied by the TOE. Section 6 describes the details specific to the TOE implementation of the security measures described in this document. Section 7 contains the claims of Protection Profile conformance for this Security Target. Section 8 provides a rationale to explicitly demonstrate that the information technology security objectives satisfy the policies and threats. Arguments are provided for the coverage of each policy and threat. The section then explains how the set of requirements are complete relative to the objectives, and that each security objective is addressed by one or more component requirements. Arguments are provided for the coverage of each objective Hitachi ID Systems, Inc. All rights reserved. 2

10 1 Introduction This section identifies the Security Target and Target of Evaluation (TOE) identification, ST conventions, and ST conformance claims. This ST describes a set of security requirements and specifications to be used as the basis for evaluation of an identified Information Technology (IT) product. The IT product described in this ST is the Hitachi ID Management Suite Version 3.2 software, developed by Hitachi ID Systems, Inc. Throughout this document, the TOE will be referred to as the ID Management Suite. The ID Management Suite is composed of 2 components: P-Synch and ID-Synch. The ID Management Suite software components are the subject of the evaluation and are called the Target of Evaluation (TOE). Note: The Hitachi ID Management Suite was previously known as the M-Tech Identity Management Suite. Hitachi ID Systems, Inc. was previously known as M-Tech Information Technology, Inc. M-Tech was acquired by Hitachi, Ltd. In April of Identification Title: Hitachi ID Management Suite Version 3.2 Security Target (EAL2) ST Version: 1.98 TOE Identification: Hitachi ID Management Suite Version 3.2 Authors: Enzo Bertorelli, Luc D. Cousineau, Stacey Kaluta CC Version: 2.2 Keywords: Commercial-off-the-shelf (COTS), identity management, password management, identification, authentication, networked information systems. 1.2 Security target overview Hitachi ID s ID Management Suite is made up of 2 major components: ID-Synch which provides identity management across multiple platforms, both current and legacy. P-Synch which provides automated Enterprise password management on a self serve basis. These can include password synchronization and password reset. This framework provides a uniform password policy throughout the Enterprise and provides strong data encryption. These two components make up the entire TOE for this security Target (ST). Its security characteristics are described below as is the boundary of this evaluation Hitachi ID Systems, Inc. All rights reserved. 3

11 The Common Criteria (CC) Evaluation Assurance Level 2 evaluation documented herein describes the assumptions, threats, security objectives that pertain to the product in its normal use and presents findings that establish its functional properties at that level. This documentation presents the rationale that the evaluation criteria presented are consistent and complete, and that the functional and assurance requirements cited are fulfilled. Throughout this document, we will refer to P-Synch Protected User Record Access Control to refer to the access control policy enforced by the P-Synch component of the ID Management Suite and ID-Synch Protected User Record Access Control to refer to the access control policy enforced by the ID-Synch component of the ID Management Suite. Wherever we refer to Protected User Record Access Control, we will be referring to the combination of the P-Synch protected User Record Access Control and ID-Synch protected User Record Access Control policies. 1.3 CC conformance claim The ID Management Suite is conformant to Common Criteria for Information Technology Security Evaluation Part 2: Security functional requirements (Version 2.2, January 2004) Extended (with FAU_ADG.1). All International Common Criteria Interpretations through September, 2004 have been applied. The ID Management Suite is conformant to Common Criteria for Information Technology Security Evaluation Part 3: Security assurance requirements (Version 2.2, January 2004). All International Common Criteria Interpretations through September, 2004 have been applied. The ID Management Suite is being evaluated to Evaluation Assurance Level 2 (EAL2) under the Canadian Common Criteria Scheme (CCCS) using the Common Methodology for Information Technology Security Evaluation, Evaluation methodology, Version 2.2, January All International Common Criteria Interpretations through September, 2004 have been applied Hitachi ID Systems, Inc. All rights reserved. 4

12 2 TOE Description The ID Management Suite is a complete identity management solution enabling organizations to securely organize and manage user identities across enterprise applications and systems. The ID Management Suite combines the power of Hitachi ID s flagship technologies, ID-Synch for user provisioning and P-Synch for password management. The following sections describe the ID Management Suite and its components. 2.1 ID-Synch ID-Synch is a complete user provisioning solution that automates and simplifies the routine tasks of managing users across multiple systems. Enterprise-scale organizations depend on ID-Synch to ensure that their employees and contractors are securely and efficiently connected to vital systems and information. ID-Synch strengthens security by: Providing consolidated reports on user access to systems that can be used to review compliance with security policy Enforcing authorization rules over change requests Implementing standards over the setup of new login IDs Applying access controls to security administrators Providing an audit log of all provisioning / deprovisioning events Primitive operations ID-Synch primitive operations, which create or modify user objects on managed systems, may be any of the following: Create new and delete existing accounts for a user Check enabled / disabled status of existing accounts Set enabled / disabled status of existing accounts Read attributes of existing user accounts Set attributes of existing user accounts Modify the membership of existing accounts in security groups Change the context of a user in a structured directory 2008 Hitachi ID Systems, Inc. All rights reserved. 5

13 2.1.2 Core features ID-Synch core features include: Consolidated user administration Security administrators can log into an ID-Synch web user interface, from which they can: create new accounts; delete, enable, disable, or update existing accounts; and manage the membership of users in security groups and distribution lists. Simplified management of users across systems reduces the workload for security administrators. Self-service user administration workflow Users are empowered to submit requests for new, changed or terminated systems access or to change their personal profile information. For example, a manager may submit a request for new accounts for a new hire or contractors may request additional system access for themselves. Requests are automatically validated, filled out with extra attributes such as login ID or directory OU and routed to the appropriate authorizers. Authorizers are assigned based on the resources requested or the identity of the requester. Authorizers review open requests and may approve or reject them. Approved requests are automatically applied to managed systems by ID-Synch. In many organizations, most of the cost and delay of access management is due to entry, routing and approvals of change requests. ID-Synch streamlines requests with easy input and parallel routing, to significantly reduce the delay between first input of a request and its fulfillment. Rapid access provisioning improves user productivity: new hires no longer spend days or weeks waiting for access before they can start work. Managers spend less time filling in and tracking paper requests. 2.2 P-Synch P-Synch helps organizations manage passwords and other forms of authentication more effectively to reduce IT support costs, increase productivity and enhance corporate security. P-Synch strengthens security by providing: A strong enterprise-wide password policy enforcement facility Effective user authentication, especially for self-service and assisted password resets Password synchronization to help users remember, rather than write down, their passwords The ability to securely delegate the right to reset passwords to front-line support staff Accountability for password resets Encryption of all transmitted passwords 2008 Hitachi ID Systems, Inc. All rights reserved. 6

14 2.2.1 Primitive operations P-Synch primitive operations may be any of the following: Set / reset passwords Clear intruder lockout flags on systems that support intruder lockout Set account enabled status on systems that support enable / disable Update password expiry information Core features P-Synch core features include: Assisted password reset Authorized support analysts can log into a P-Synch web user interface, look up a caller s profile, authenticate the caller by keying in answers to personal questions, and reset one or more passwords. A closed ticket can be automatically written to the call tracking system. Support staff do not require any privileges to systems on which P-Synch allows them to reset passwords. Self-service password reset A user who has forgotten his password or triggered an intruder lockout can log into P-Synch, from his own computers or that of a neighbor, with another form of authentication to perform self-service password reset. Supported authentication factors include answering personal questions in the form of Q&A, using a hardware token (SecurID, SafeWord), using a biometric sample, and smart cards. Automated password reset allows locked out users to reset their own passwords, effectively addressing the problem of forgotten passwords. P-Synch creates a secure and efficient process for users to reset their passwords, thus minimizing the help desk call volume and time spent with the help desk resetting the passwords. Once authenticated, users can reset their own passwords without calling the help desk. Tickets can be automatically created on a call tracking system. Web-based password synchronization Users can synchronize some or all of their passwords by using a P-Synch web interface to make routine password changes. The password policy is clearly stated on the screen and enforced immediately. Each system where the user has a login ID is represented by a name and a check box. Transparent password synchronization When users change their Windows NT, Active Directory, LDAP (Sun, IBM), Unix, OS/390, and OS/400 password, the new password is subjected to a global password policy in addition to the native policy. If the password is acceptable, the new password is changed both on the initial system and, automatically, on every other system where the user has a login ID Hitachi ID Systems, Inc. All rights reserved. 7

15 Password policy enforcement P-Synch enforces a uniform, global policy in addition to the various password policies enforced natively on each managed system. The built-in password policy engine includes over 50 standard rules, plus a regular expression engine and plug-in system, allowing organizations to define new rules. Open-ended password history and dictionary checks are included. 2.3 Shared architecture P-Synch and ID-Synch use the same product architecture for: Security The ID Management Suite offers multi-layered security. This includes running on a hardened OS, using file system ACLs, providing strong application-level user authentication, encrypting sensitive data, enforcing application-level ACLs, and storing log data indefinitely Interaction with target systems The ID Management Suite server interacts with target systems (managed systems) using native communication protocols wherever possible. This minimizes the amount of software that must be installed on managed systems. For those systems where a secure remote administration facility is not available, a combination of server-side software and scripting technologies are used. This is illustrated in Figure 1. Some of the supported target systems include: Active Directory, LDAP directories, Windows NT servers / domains, Novell NDS, Unix (various flavors), OS/400, OS/390, DB2 database, Oracle database, Sybase database, MSSQL database, SAP, PeopleSoft, Exchange, GroupWise, Notes / Domino, Telnet sessions, Windows command-line integration, web forms, web services (SOAP, XML), and SecurID tokens Hitachi ID Systems, Inc. All rights reserved. 8

16 Local Agent: OS/390, Unix, RSA ACE Master, Slave Target System: Remote Agent Proxy Servers Remote Site Physical security P-Synch, ID-Synch Servers TCP/IP bit Crypto Various Protocols Secure Native Protocol System Ticket System HR System, Directory Figure 1: Integration With Target Systems 2008 Hitachi ID Systems, Inc. All rights reserved. 9

17 2.3.3 Web access Most ID Management Suite functions are accessed using a web browser. The ID Management Suite user interface is primarily HTML and works with most web browsers. In particular, since the web interface does not require active content (ActiveX), it works with older browsers, locked down browsers, and through filtering firewalls. Local Agent: OS/390, Unix, RSA ACE Target System: Remote Agent Proxy Servers Remote Site User HTTPS Load Balancer Master, Slave P-Synch, ID-Synch Servers Physical security TCP/IP bit Crypto Various Protocols Secure Native Protocol System Ticket System HR System, Directory Figure 2: Web access architecture diagram For added security, the web server software on the ID Management Suite server can be configured to use HTTPS. To enable encryption between users web browsers and the ID Management Suite interface, an organization purchases (from a certificate authority) or generates its own digital server certificate and installs it for the web site. This is no different from any other secure web application (web banking, e- Commerce) Hitachi ID Systems, Inc. All rights reserved. 10

18 2.4 TOE boundary For the purposes of this security target, the TOE boundary includes Hitachi ID s ID Management Suite software, as well as P-Synch/390 a proprietary started task and security exit to be used as local agent installed on the IBM OS/390 operating system. Note: Although other platforms exist (see subsubsection on Page 8) they are not within the TOE boundary as their interface functions are handled by native methods (APIs or the underlying OS). The following diagram describes the relationships within the TOE: IDM Server Self-service P-Synch self-serve UI (CGIs) Requests Service infrastructure (idauth) ID-Synch self-serve UI (CGIs) P-Synch service (pushpass) Verify/ reset passwords Consolidated administration P-Synch user admin (CGIs) Make updates/ reset passwords Web browsers HTTPS Web server (IIS, Apache, etc) Make updates ID-Synch user admin (CGIs) Remote agent ID-Synch DB service Synchronize passwords Identity cache Hitachi ID encrypted TPC/IP OS/390 Server OS/390 local agent P-Synch/390 started task P-Synch/390 security exit Target of evaluation Scope of Control (TSC) Figure 3: TOE Boundary 2008 Hitachi ID Systems, Inc. All rights reserved. 11

19 Note: The TOE is constituted of the modules within the highlighted (gold) area. The name of the physical processes providing the services is indicated in brackets after the service description. There are no hardware or firmware components within the TOE boundary. 3 TOE Security Environment The TOE security environment consists of the threats to security, organizational security policies, and usage assumptions as they relate to the TOE. The ID Management Suite provides for a level of protection that is appropriate for IT environments that require a harmonized password policy across an enterprise. The software is not designed to withstand physical attacks directed at disabling or bypassing its security features, however it is designed to withstand some logical attacks originating from its attached network. Threats are undesirable events and are characterized in terms of a threat agent, a presumed attack method, vulnerabilities that are the foundation for the attack, and identification of the asset under attack. Threat agents are subjects which have not been granted authorized access to the assets. Assets comprise the TOE and the authentication data held by the TOE on behalf of authorized users. For this evaluation, the threat agents are assumed to have an attack potential of low. As a result, the TOE has been developed with the assumption that a potential attacker would have a proficient level of expertise, access to public knowledge of the TOE, restricted access to the TOE, and have access to standard equipment. 3.1 Secure usage assumptions A.Competent_Admin Competent system administrators System administrators are competent to manage the TOE and the security of the information it contains. The administrators will not compromise the security of the TOE or its data either willfully or by neglect. A.Coop_User Cooperative users Users cooperate with those responsible for managing the TOE to maintain TOE security and will follow all directives and prescriptions imposed by the administrators and / or guidance provided with the TOE. A.Environment Secure Environment The environment is secure and the administrators have a good working knowledge and know how to manage the OS underlying the TOE. A.Network Secure Network Network connected to the TOE is protected from active attacks (i.e. data mode intrusion) Hitachi ID Systems, Inc. All rights reserved. 12

20 A.Physical Physical Security TOE is physically secure. The TOE will be deployed in an environment providing physical security adequate to protect against unauthorized access. A.Ext_Services External Services In cases where external services (e.g. IVR) are used, the services are secure and do not offer unauthorized access to the TOE. A.Back_End_Auth Back End Authentication There is a back-end system handling the authentication of nonadministrative users. A.Time_Source Reliable Time Source The TOE s environment provides a reliable time source for time stamping audit records. A.Reference_Monitor Reference Mediation The TOE s environment provides a properly implemented reference monitor and enforces the domain separation required for the application of the TOE s discretionary access control policy. 3.2 Threats to security T.Disclosure Unauthorized disclosure of user data. An attacker may attempt capture the managed data while it is in transit between remote parts of the TOE. 3.3 Organizational security policies P.Accountability Individual accountability Individuals shall be held accountable for their actions Hitachi ID Systems, Inc. All rights reserved. 13

21 4 Security Objectives 4.1 Security objectives for the TOE O.Audit Auditing Maintain audit records. Provide individual accountability for audited events. Uniquely identify each user so that auditable actions can be traced to a user. O.I&A Identify and authenticate a user to support accountability Provide the basic I&A functions that will support user accountability. O.Secure_Transfer User data is secured from disclosure in transit User data is secured from disclosure in transit between remote parts of the TOE. O.User_Defined_AC User-defined access control Enforce an access control policy whereby company policies determine who may access the data controlled by the TOE. 4.2 Security objectives for the IT environment OE.Audit Audit records with identity The IT environment provides the date and time components of the audit records. OE.AC Environmental access control The IT environment enforces the reference mediation and domain separation required to implement the access controls. OE.Back_End_Auth Back-end Authentication The IT environment provides the back-end authentication services required to authenticate non-administrative users. OE.Competent_Admin Competent system administrators The IT environment ensures that System administrators are competent to manage the TOE and the security of the information it contains and that the administrators will not compromise the security of the TOE or its data either willfully or by neglect. OE.Coop_User Cooperative users 2008 Hitachi ID Systems, Inc. All rights reserved. 14

22 The IT environment ensures that users cooperate with those responsible for managing the TOE to maintain TOE security and will follow all directives and prescriptions imposed by the administrators and / or guidance provided with the TOE. OE.Environment Secure Environment The IT environment must ensure that the TOE is secure and the administrators have a good working knowledge and know how to manage the OS underlying the TOE. OE.Network Secure Network The IT environment must ensure that the network connected to the TOE is protected from active attacks (i.e. data mode intrusion). OE.Physical Physical Security The IT environment must ensure that the TOE is physically secure. OE.Ext_Services External Services In cases where external services (e.g. IVR) are used, the IT environment must ensure that the services are secure and do not offer unauthorized access to the TOE Hitachi ID Systems, Inc. All rights reserved. 15

23 5 IT Security Requirements 5.1 TOE security functional requirements Security audit (FAU) Audit data generation (FAU_ADG.1) The TSF shall be able to generate an audit record of the following auditable event: a) All auditable events for the not specified level of audit; and b) Events listed in Table 5-2. FAU_ADG.1.1 The TSF shall record within each audit record at the following information: a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the ST, no other audit relevant information. FAU_ADG.1.2 Rationale: FAU_ADG.1.1 and FAU_ ADG.1.2 are necessary to specify audit requirements as performed by the TOE. FAU_SAR.1 has a dependency on FAU_GEN.1. FAU_ADG.1.1 which is an extended security requirement based on FAU_GEN.1, generates the audit record and FAU_ADG.1.2 indicates the information contained within the audit record. The dependency is satisfied because a record has to first be generated before it can be read. The TOE audit function does not record start up and shut down of the audit function so the extended requirement is fulfilling the dependency requirement instead of FAU_GEN.1. Table 5-2 Auditable Events Component FDP_ACF.1 FIA_AFL.1 FIA_SOS.1 FIA_UAU.2 Audited Events All requests to perform an operation on an object covered by the SFP, except special cases where the recording of failure is not required. The identity of the object. The reaching of the threshold for the unsuccessful authentication attempts and the actions taken. The restoration to normal state. Rejection or acceptance by the TSF of any tested secret. All use of the authentication mechanism.... continued on the next page 2008 Hitachi ID Systems, Inc. All rights reserved. 16

24 Table 5-2 continued Component FIA_UID.2 FMT_MSA.1 FMT_MSA.3 FMT_SMR.1 Audited Events All use of the user identification mechanism, including the identity provided during successful attempts. All modifications of the values of security attributes. Modifications of the default setting of permissive or restrictive rules. All modifications of the initial value of security attributes. Modifications to the group of users that are part of a role User identity association (FAU_GEN.2) The TSF shall be able to associate each auditable event with the identity of the user that caused the event. FAU_GEN Audit review (FAU_SAR.1) The TSF shall provide Administrative users who are authorized to read audit records with the capability to read all audit information from the audit records. FAU_SAR.1.1 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. FAU_SAR Restricted audit review (FAU_SAR.2) The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access. FAU_SAR Selectable audit review (FAU_SAR.3:P-Synch) The TSF shall provide the ability to perform searches of audit data based on account name, event type, and / or date. FAU_SAR Selectable audit review (FAU_SAR.3:ID-Synch) The TSF shall provide the ability to perform searches of audit data based on operation, target system, and / or date. FAU_SAR Hitachi ID Systems, Inc. All rights reserved. 17

25 Protected audit trail storage (FAU_STG.1) The TSF shall protect the stored audit record from unauthorized deletion. FAU_STG.1.1 The TSF shall be able to prevent unauthorized modifications to the stored audit records in the audit trail. FAU_STG User data protection (FDP) Subset access control (FDP_ACC.1) The TSF shall enforce the Protected User Record Access Control on: a) Subjects: administrative users and regular users of the TOE; b) Objects: global password policy, audit data, user objects, and access control groups; c) Operations: modify global password policy, read TOE audit data, manage (create, update, or delete) user objects, manage (create, update, delete) access control groups, and modify administrative users passwords. FDP_ACC Security attribute based access control (FDP_ACF.1:P-Synch) The TSF shall enforce the P-Synch Protected User Record Access Control to objects based on the following: a) The subject attributes: account name, user role, and user rights associated with subjects: administrative users and regular users. b) The following access control attributes associated with the object: Global password policy: password policy rules Audit data: audit data records User objects: account name, user role, user rights, administrative user password, and user profile data. FDP_ACF.1.1:P-Synch The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: Global password policy: Modification of the global password policy is limited to administrative users with the appropriate right. Audit data: The reading of audit data is limited to administrative users with the appropriate right Hitachi ID Systems, Inc. All rights reserved. 18

26 User objects: The management of administrative user objects is limited to administrative users with the appropriate right. Additionally, an administrative user can only manage administrative user objects that have equal or lesser user rights. An administrative user cannot modify his own user rights. The management of manually added regular user objects is limited to administrative users with the appropriate right. FDP_ACF.1.2:P-Synch Note: Manually added regular users are those added directly to P-Synch by an administrative user. Unlike other regular users, they are not imported from the IT environment. The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: no additional rules. FDP_ACF.1.3:P-Synch The TSF shall explicitly deny access of subjects to objects based on the following additional rules: no additional rules. FDP_ACF.1.4:P-Synch Security attribute based access control (FDP_ACF.1:ID-Synch) The TSF shall enforce the ID-Synch Protected User Record Access Control to objects based on the following: a) The subject attributes: account name, user role, user rights, and access control groups associated with subjects: administrative users and regular users. b) The following access control attributes associated with the object: Global password policy: password policy rules Audit data: audit data records Access control group: group members User objects: account name, user role, user rights, administrative user password, and user profile data. FDP_ACF.1.1:ID-Synch The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: Global password policy: Modification of the global password policy is limited to administrative users with the appropriate right. Audit data: The reading of audit data is limited to administrative users with the appropriate right. Access control groups: The management of access control groups is limited to administrative users with the appropriate rights Hitachi ID Systems, Inc. All rights reserved. 19

27 User objects: The management of administrative user objects is limited to administrative users with the appropriate right. Additionally, an administrative user can only manage administrative user objects that have equal or lesser rights. An administrative user cannot modify his own user rights. The management of manually added regular user objects is limited to administrative users with the appropriate right. Note: Manually added regular users are those added directly to ID-Synch by an administrative user. Unlike other regular users, they are not imported from the IT environment and are not created with accounts on target systems. The management of regular user objects is provided to administrative users with the appropriate right. FDP_ACF.1.2:ID-Synch The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: no additional rules. FDP_ACF.1.3:ID-Synch The TSF shall explicitly deny access of subjects to objects based on the following additional rules: no additional rules. FDP_ACF.1.4:ID-Synch Identification and authentication (FIA) Authentication failure handling (FIA_AFL.1) The TSF shall detect when an administrator configurable positive integer within 1-99 unsuccessful authentication attempts occur related to the unsuccessful authentication attempts since the last successful authentication for the indicated user. FIA_AFL.1.1 When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall disable the user until unlocked by an administrative user. FIA_AFL.1.2 Note: An administrative user can also set the number of minutes after which a locked-out user will automatically be re-enabled (the lockout duration). By default, this setting is off User attribute definition (FIA_ATD.1:P-Synch) The TSF shall maintain the following list of security attributes belonging to individual users: account name, user role, user rights, and administrative user password. FIA_ATD User attribute definition (FIA_ATD.1:ID-Synch) The TSF shall maintain the following list of security attributes belonging to individual users: account name; user role, user rights, access control group, and administrative user password. FIA_ATD Hitachi ID Systems, Inc. All rights reserved. 20

28 Verification of secrets (FIA_SOS.1) The The TSF shall provide a mechanism to verify that secrets meet SOF-high. FIA_SOS User authentication before any action (FIA_UAU.2:Admin) The TSF shall require each user belonging to an administrative role to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FIA_UAU.2.1:Admin Note: Regular users are authenticated using a back-end authentication mechanism Protected authentication feedback (FIA_UAU.7) The TSF shall provide only obscured feedback to the user while the authentication is in progress. FIA_UAU User identification before any action (FIA_UID.2) The TSF shall require each user to identify itself before allowing any other TSF-mediated actions on behalf of that user. FIA_UID User-subject binding (FIA_USB.1:P-Synch) The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: account name, user role, and user rights. FIA_USB.1.1 The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: the user session shall represent the user s access rights predetermined by his role and assigned rights. FIA_USB.1.2 The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: no rules. FIA_USB User-subject binding (FIA_USB.1:ID-Synch) The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: account name, user role, user rights, and access control group. FIA_USB.1.1 The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: the user session shall represent the user s access rights predetermined by his role and assigned rights. FIA_USB.1.2 The TSF shall enforce the following rules governing changes to the user security attributes associated with 2008 Hitachi ID Systems, Inc. All rights reserved. 21

29 subjects acting on the behalf of users: no rules. FIA_USB Security management (FMT) Management of security attributes (FMT_MSA.1:P-Synch) The TSF shall enforce the P-Synch Protected User Record Access Control to restrict the ability to modify the security attributes password policy rules to administrative users with the appropriate right. The TSF shall enforce the P-Synch Protected User Record Access Control to restrict the ability to query the security attributes audit data records to administrative users with the appropriate right. The TSF shall enforce the P-Synch Protected User Record Access Control to restrict the ability to modify the security attributes administrative user password to administrative users authorized to modify their own passwords, and administrative users authorized to modify other administrative users passwords. FMT_MSA.1.1 The TSF shall enforce the P-Synch Protected User Record Access Control to restrict the ability to create the security attributes account name to administrative users authorized to do so. FMT_MSA.1.1 The TSF shall enforce the P-Synch Protected User Record Access Control to restrict the ability to modify the security attributes user rights to administrative users authorized to do so. FMT_MSA.1.1 The TSF shall enforce the P-Synch Protected User Record Access Control to restrict the ability to modify the security attributes user profile data to administrative users authorized to do so. FMT_MSA.1.1 The TSF shall enforce the P-Synch Protected User Record Access Control to restrict the ability to assign the security attributes user role to administrative users authorized to do so. FMT_MSA Management of security attributes (FMT_MSA.1:ID-Synch) The TSF shall enforce the ID-Synch Protected User Record Access Control to restrict the ability to modify the security attributes password policy rules to administrative users with the appropriate right. The TSF shall enforce the ID-Synch Protected User Record Access Control to restrict the ability to query the security attributes audit data records to administrative users with the appropriate right. The TSF shall enforce the ID-Synch Protected User Record Access Control to restrict the ability to modify the security attributes administrative user password to administrative users authorized to modify their own passwords, and administrative users authorized to modify other administrative users passwords. FMT_MSA.1.1 The TSF shall enforce the ID-Synch Protected User Record Access Control to restrict the ability to create the security attributes account name to administrative users and regular users authorized to do so. FMT_MSA.1.1 The TSF shall enforce the ID-Synch Protected User Record Access Control to restrict the ability to modify 2008 Hitachi ID Systems, Inc. All rights reserved. 22

30 the security attributes user rights to administrative users authorized to do so. FMT_MSA.1.1 The TSF shall enforce the ID-Synch Protected User Record Access Control to restrict the ability to modify the security attributes user profile data to administrative users authorized to do so. FMT_MSA.1.1 The TSF shall enforce the ID-Synch Protected User Record Access Control to restrict the ability to manage the security attributes group members to administrative users authorized to do so. FMT_MSA.1.1 The TSF shall enforce the ID-Synch Protected User Record Access Control to restrict the ability to assign the security attributes user role to administrative users authorized to do so. FMT_MSA Static attribute initialization (FMT_MSA.3) The TSF shall enforce the Protected User Record Access Control to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.1 The TSF shall allow the administrative users and regular users with the required rights to specify alternative initial values to override the default values when an object or information is created. FMT_MSA Specification of Management Functions (FMT_SMF.1:P-Synch) The TSF shall be capable of performing the following security management functions: modification of the global password policy, management of user objects, modification of administrative user passwords. FMT_SMF Specification of Management Functions (FMT_SMF.1:ID-Synch) The TSF shall be capable of performing the following security management functions: modification of the global password policy, management of user objects and access control groups, modification of administrative user passwords. FMT_SMF Security roles (FMT_SMR.1:P-Synch) The TSF shall maintain the roles super user, help desk user, and regular user. FMT_SMR Security roles (FMT_SMR.1:P-Synch) The TSF shall maintain the roles super user, console user, and regular user. FMT_SMR.1.1 Note: Collectively, super users, help desk users, and console users are referred to as administrative users. The TSF shall be able to associate users with roles. FMT_SMR Hitachi ID Systems, Inc. All rights reserved. 23

31 5.1.5 Protection of the TOE security functions (FPT) Basic internal TSF data transfer protection (FPT_ITT.1) The TSF shall protect TSF data from disclosure when it is transmitted between separate parts of the TOE. FPT_ITT TOE security assurance requirements The Evaluation Assurance Level chosen for this evaluation is 2 (EAL2). EAL2 was chosen to provide a low to moderate level of independently assured security based on availability of the complete development record from the vendor. The chosen assurance level is consistent with the postulated threat environment. EAL2 was chosen to provide: a low to moderate level of assurance that is consistent with good commercial practices. The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification, selective independent confirmation of the developer test results, strength of function analysis, and evidence of a developer search for obvious vulnerabilities (e.g. those in the public domain). EAL2 also provides assurance through a configuration list for the TOE, and evidence of secure delivery procedures. The TOE s permutational and combinatory mechanisms (passwords) will provide strength of function consistent with corporate password requirements in terms character length and numeric / alphabetic content in accordance with FIA_SOS.1 above Hitachi ID Systems, Inc. All rights reserved. 24

32 Table 5-3 Assurance Requirements for EAL2 Assurance Class ACM ADO Assurance Components ACM_CAP.2 ADO_DEL.1 ADO_IGS.1 ADV AGD ADV_FSP.1 ADV_HLD.1 ADV_RCR.1 AGD_ADM.1 AGD_USR.1 ATE AVA ATE_COV.1 ATE_FUN.1 ATE_IND.2 AVA_SOF.1 AVA_VLA Configuration management (ACM) Configuration items (ACM_CAP.2) The developer shall provide a reference for the TOE. ACM_CAP.2.1D The developer shall use a CM system. ACM_CAP.2.2D The developer shall provide CM documentation. ACM_CAP.2.3D The reference for the TOE shall be unique to each version of the TOE. ACM_CAP.2.1C The TOE shall be labelled with its reference. ACM_CAP.2.2C The CM documentation shall include a configuration list. ACM_CAP.2.3C The configuration list shall describe the configuration items that comprise the TOE. ACM_CAP.2.4C The CM documentation shall describe the method used to uniquely identify the configuration items. ACM_CAP.2.5C The CM system shall uniquely identify all configuration items that comprise the TOE. ACM_CAP.2.6C 2008 Hitachi ID Systems, Inc. All rights reserved. 25

33 5.2.2 Delivery and operation (ADO) Delivery procedures (ADO_DEL.1) The developer shall document procedures for delivery of the TOE or parts of it to the user. ADO_DEL.1.1D The developer shall use the delivery procedures. ADO_DEL.1.2D The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to a user s site. ADO_DEL.1.1C Installation, generation, and start-up procedures (ADO_IGS.1) The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE. ADO_IGS.1.1D The documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE. ADO_IGS.1.1C Development (ADV) Informal functional specification (ADV_FSP.1) The developer shall provide a functional specification. ADV_FSP.1.1D The functional specification shall describe the TSF and its external interfaces using an informal style. ADV_FSP.1.1C The functional specification shall be internally consistent. ADV_FSP.1.2C The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing details of effects, exceptions, and error messages, as appropriate. ADV_FSP.1.3C The functional specification shall completely represent the TSF. ADV_FSP.1.4C Descriptive high-level design (ADV_HLD.1) The developer shall provide the high-level design of the TSF. ADV_HLD.1.1D The presentation of the high-level design shall be informal. ADV_HLD.1.1C The high-level design shall be internally consistent. ADV_HLD.1.2C The high-level design shall describe the structure of the TSF in terms of subsystems. ADV_HLD.1.3C The high-level design shall describe the security functionality provided by each subsystem of the TSF. ADV_HLD.1.4C The high-level design shall identify any underlying hardware, firmware, and / or software required by the 2008 Hitachi ID Systems, Inc. All rights reserved. 26