CA CA Access Control r8 for Windows Security Target Version 2.0 Debra Baker Dan DePrez Michelle Ruppel June 7, 2007 Suite 5200♦7925 Jones Branch Drive♦McLean, VA 22102♦703 848-0883♦Fax 703 848-0960 ii TABLE OF CONTENTS SECTION PAGE T1 Security Target Introduction........................................................................................................ 1 1.1 Security Target Identification...........................................................................................................1 1.2 Security Target Overview .................................................................................................................1 1.3 Common Criteria Conformance.......................................................................................................2 1.4 Document Organization ....................................................................................................................2 2 TOE Description........................................................................................................................... 3 2.1 Product Type ......................................................................................................................................3 2.2 The CA Access Control approach to Security.................................................................................3 2.3 CA Access Control Components.......................................................................................................3 2.3.1 CA Access Control Database..........................................................................................................................3 2.3.2 CA Access Control Request Management Software ......................................................................................4 2.3.3 CA Access Control Services...........................................................................................................................4 2.3.4 CA Access Control Administrator Interfaces .................................................................................................6 2.4 Physical Boundary and Scope of the Evaluation.............................................................................6 2.4.1 Included in TOE .............................................................................................................................................7 2.4.2 Excluded from TOE........................................................................................................................................8 2.5 Logical Boundary...............................................................................................................................9 2.6 TOE Security Environment ............................................................................................................10 3 TOE Security Environment........................................................................................................ 11 3.1 Assumptions......................................................................................................................................11 3.2 Threats ..............................................................................................................................................11 4 Security Objectives...................................................................................................................... 12 4.1 Security Objectives for the TOE.....................................................................................................12 4.2 Security Objectives for the Environment ......................................................................................12 4.2.1 Security Objectives for the IT Environment.................................................................................................12 4.2.2 Non-IT Security Objectives..........................................................................................................................13 5 IT Security Requirements........................................................................................................... 14 5.1 Formatting Conventions..................................................................................................................14 5.2 TOE Security Functional Requirements........................................................................................15 5.2.1 Class FAU: Security Audit ...........................................................................................................................16 5.2.2 Class FDP: User Data Protection..................................................................................................................18 5.2.3 Class FIA: Identification and Authentication ...............................................................................................26 5.2.4 Class FMT: Security Management ...............................................................................................................26 iii 5.2.5 Class FPT: Protection of the TOE Security Functions..................................................................................35 5.2.6 Class FTA: TOE session establishment........................................................................................................36 5.3 Strength of Function........................................................................................................................36 5.4 Security requirements for the IT Environment ............................................................................36 T5.5 TOE Security Assurance Requirements ........................................................................................37 6 TOE Summary Specification...................................................................................................... 39 6.1 IT Security Functions ......................................................................................................................39 6.1.1 Overview ......................................................................................................................................................39 6.1.2 CA Access Control Security Functions ........................................................................................................39 6.2 SOF Claims.......................................................................................................................................43 6.3 Assurance Measures ........................................................................................................................43 7 PP Claims.................................................................................................................................... 45 8 Rationale ..................................................................................................................................... 46 8.1 Security Objectives Rationale.........................................................................................................46 8.1.1 Threats to Security........................................................................................................................................46 8.1.2 Assumptions .................................................................................................................................................48 8.2 Security Requirements Rationale...................................................................................................49 8.2.1 Functional Requirements..............................................................................................................................49 8.2.2 Dependencies................................................................................................................................................51 8.2.3 Strength of Function Rationale.....................................................................................................................53 8.2.4 Assurance Rationale .....................................................................................................................................53 8.2.5 Rationale that the IT Security Requirements are Internally Consistent........................................................53 8.2.6 Requirements for the IT Environment ..........................................................................................................53 8.2.7 Protection of the TOE Rationale...................................................................................................................55 8.2.8 Explicitly Stated Security Requirements Rationale......................................................................................55 8.3 TOE Summary Specification Rationale.........................................................................................56 8.3.1 IT Security Functions....................................................................................................................................56 8.3.2 Assurance Measures .....................................................................................................................................57 8.4 PP Claims Rationale ........................................................................................................................59 9 Acronyms..................................................................................................................................... 60 10 References ............................................................................................................................... 61 iv Table of Tables and Figures Table or Figure Page Figure 2-1 eTrustTM Access Control TOE Boundary............................................................................................................7 Table 3-1 Assumptions 11 Table 3-2 Threats 11 Table 4-1 Security Objectives for TOE 12 Table 4-2 Security Objectives for IT Environment 12 Table 4-3 Security Objectives for Non-IT Security Objectives 13 Table 5-1 TOE Functional Requirement 15 Table 5-2 eTrustTM Access Control Auditable Events 16 Table 5-3 eTrustTM Access Control Policy (Objects and Operations) 18 Table 5-4 eTrustTM Access Control Policy (Security Attributes) 21 Table 5-5 eTrustTM Access Control Policy (Controlled Operation Access Rules) 22 Table 5-6 eTrustTM Access Control Policy (Label Access Rules) 24 Table 5-7 TSF Data (User Class Security Attributes) 26 Table 5-8 TSF Data (Group Class Security Attributes) 27 Table 5-9 TSF Data (Resource Classes) 28 Table 5-10 TSF Data (Resource Class Security Attributes) 29 Table 5-11 TOE Security Functions 29 Table 5-12 TSF Security Roles 34 Table 5-13 Functional Requirement for the IT environment 36 Table 5-14 Assurance Requirements: EAL3 38 Table 6-1 Security Functional Requirements mapped to Security Functions 39 Table 6-2 Security Audit Function 40 Table 6-3 Manage User Access Function 41 Table 6-4 User Identification Function 41 Table 6-5 Security Management Function 42 Table 6-6 TSF Protection Function 43 Table 6-7 TOE Session Establishment Function 43 Table 6-8 Assurance Measures and How Satisfied 44 Table 8-1 All Threats to Security Countered 46 Table 8-2 All Assumptions Addressed 48 Table 8-3 Mapping of Security Objectives for the Environment to Threats and Assumptions 48 Table 8-4 All Objectives Met by Functional Components 49 Table 8-5 TOE Dependencies Satisfied 52 Table 8-6 IT Environment Dependencies are Satisfied 52 Table 8-7 All Objectives for the IT Environment Met by Requirements 54 Table 8-8 Mapping of Functional Requirements to TOE Summary Specification 56 Table 8-9 Assurance Measures Rationale 57 1 1 Security Target Introduction 1.1 Security Target Identification TOE Identification: CA Access Control for Windows1 r8 with patch NT – 0604 CUMULATIVE RELEASE ST Title: CA Access Control r8 for Windows Security Target ST Version: Version 2.0 ST Authors: Debra Baker, Dan DePrez, Michelle Ruppel ST Date: June 7, 2007 Assurance Level: EAL3 Strength of Function: Not applicable Vendor: CA Vendor Address: 6150 Oak Tree Blvd, Suite 100 Park Center Plaza II Independence, OH 44131 Registration: Keywords: Access Control, Identification, Authentication, Authorization, Security Target, and Security Management 1.2 Security Target Overview This Security Target (ST) defines the Information Technology (IT) security requirements for CA Access Control for Windows version r8 with patch NT – 0604 CUMULATIVE RELEASE2 . CA Access Control is a security management application that regulates access to business assets by providing policy-based control of who can access specific systems, what they can do within them, and when they are allowed access. Access Control allows management of user privileges and supports deployment of security policies to control access to selected resources on native operating systems. This document describes security aspects of the Windows version of CA Access Control only. The UNIX version of CA Access Control is the subject of a separate evaluation. 1 Previously known as eTrust™ Access Control (eAC) for Windows. 2 For brevity, this product will be called the “eTrustTM Access Control for Windows version r8” in the remainder of the document. 2 1.3 Common Criteria Conformance The TOE is Part 2 extended, Part 3 conformant, and meets the requirements of Evaluation Assurance Level (EAL) 3 from the Common Criteria (CC) Version 2.2. 1.4 Document Organization The main sections of an ST are the ST Introduction, Target of Evaluation (TOE) Description, TOE Security Environment, Security Objectives, IT Security Requirements, TOE Summary Specification, and Rationale. Section 2, the TOE Description, describes the product type and the scope and boundaries of the TOE. Section 3, TOE Security Environment, identifies assumptions about the TOE’s intended usage and environment and threats relevant to secure TOE operation. Section 4, Security Objectives, defines the security objectives for the TOE and its environment. Section 5, IT Security Requirements, specifies the TOE Security Functional Requirements (SFR), Security Requirements for the IT Environment, and the Security Assurance Requirements. Section 6, TOE Summary Specification, describes the IT Security Functions and Assurance Measures. Section 7, Protection Profile (PP) Claims, is not applicable, as this product does not claim conformance to any PP. Section 8, Rationale presents evidence that the ST is a complete and cohesive set of requirements and that a conformant TOE would provide an effective set of IT security countermeasures within the security environment. The Rationale has three main parts: Security Objectives Rationale, Security Requirements Rationale, and TOE Summary Specification Rationale. Sections 9 and 10 provide the acronym definitions and references. 3 2 TOE Description This section describes the Windows version of CA Access Control only. The UNIX version of CA Access Control is the subject of a separate evaluation. 2.1 Product Type CA Access Control is a security management application that regulates access to business assets by providing policy-based control of who can access specific systems and resources, what they can do within them, and when they are allowed access. Policies can be created, managed, and distributed on an enterprise-wide basis, or customized to meet the security requirements of specific applications. 2.2 The CA Access Control approach to Security The main security service provided by CA Access Control (ACW) is the enforcement of access controls. CA Access Control maintains information on users and the resources they can access. It provides a single interface for administrators to grant, manage, and revoke user access privileges. Security Attributes Records defining accessors (users of ACW controlled resources) and resources in the Access Control database can be assigned a security level, a security label and/or a security category. Access Control List An Access Control List (ACL) is a specific list of the accessors authorized to access a protected resource and the exact access they can have. An ACL can be used to define the access rules for a particular resource. CA Access Control allows authorized administrators3 to define a security policy that uses the security attributes, access control lists, and access rules to grant or deny access to selected resources for each accessor. 2.3 CA Access Control Components CA Access Control is comprised of a database, request management software, a number of services, and an administrator interface. 2.3.1 CA Access Control Database The ACW Database contains definitions of: 3 The term “authorized administrator” in this ST includes multiple roles defined in the product. (See Table 5-12 TSF Security Roles for more detail.) Refer to Section 5.2.4 for details on roles and separation of duty. 4 • Users and groups of users in an organization • System resources to be protected • Logical resources to be protected • Rules governing user and group access to system resources 2.3.2 CA Access Control Request Management Software The Request Management software performs the following: • Intercepts every request to perform a critical operating system command (such as: open/close a file, access a registry key, execute a program or terminate a process). • Passes these requests to the ACW Authorization Engine and receives the decision of the Engine whether the request should be granted or denied. • Forwards the decision to the original system call of the operating system, which then continues its processing based on the answer it received from the ACW kernel extension. . 2.3.3 CA Access Control Services Watchdog The Watchdog service performs two functions: one to keep other services running and another to perform sensitive file integrity monitoring. The Watchdog constantly checks that the other CA Access Control services are running. If the Watchdog discovers that another service has stopped, it immediately starts it again. The sensitive file integrity monitoring performed by Watchdog checks the signature of trusted files, which includes secured files (SECFILE class) and programs (PROGRAM class). When a difference in one of the trusted files is discovered, the Watchdog updates the ACW Authorization seos4 Engine, marking the files as untrusted, and sends an audit record. Untrusted program files are not allowed to execute. This sensitive file integrity monitoring function is not in the evaluated configuration. Agent The Agent service is responsible for: • Communicating with CA Access Control clientsT5 through a proprietary application protocol above TCP/IP. • Managing native security for the ACW user. Authorization Engine (seosdT6 ) 4 seos is the previous name of the product. 5 CA Access Control clients refer to the Policy Manager, selang, or any other 3rd party application that uses the LCA/seadmapi APIs for administration. Note that only selang is included in the TOE. 5 The Engine performs the following tasks: • Manages the ACW database, including controlling all database updates. • Decides whether to grant access requests that it has received from the Request Management software and the Agent. • Checks that the Watchdog is running, and restarts the Watchdog if it discovers that the Watchdog has stopped running. The Engine handles both database access requests and the decision-making function. Therefore, inter-process communication is reduced to a minimum, and maximum efficiency is achieved. Policy Model The Policy Model tool simplifies administration at large sites. The Policy Model allows management of many computers from one computer. The Policy Model is used with a policy model database (PMDB). Like other CA Access Control databases, the PMDB contains users, groups, protected resources, and rules governing access to the resources. In addition, the PMDB contains a list of subscriber stations. A subscriber station is one linked to the parent PMDB so that any change to the parent PMDB is automatically sent to the subscriber’s database. Using the PMDB, a baseline security policy can be created. The subscribers can include both Windows and UNIX stations, thereby ensuring uniform rules with minimal administrative efforts. The system or security administrator updates the policy model database. The PMDB then propagates all updates from the parent policy model database to its subscribers in batch mode. A policy model database can have two types of subscribers: • Stations that contain a PMDB o The subscriber, in its role as a PMDB, also contains a list of subscribers to which it propagates database updates. This feature allows a hierarchy of PMDBs to be built. • Stations that contain a local ACW database o The local ACW database can be used to protect the users, groups, and resources defined on the station on which it is located. The local database can also subscribe to a PMDB. Note: The policy model is not in the evaluated configuration. Task Delegation (Windows Only) The Task Delegation service allows an administrator to grant general users the right to execute utilities and commands that require administrative privileges without being members of the 6 seosd is the name of the on-disk executable that implements the authorization engine. seosd is a daemon which is named after the previous product name (seos). 6 Administrators group. The Task Delegation service is responsible for executing these privileged tasks and informing the user of the tasks outcome. (The Task Delegation service that runs on Windows is similar to UNIX ACW utility sesudo.) Note: The Task Delegation service is not in the evaluated configuration. 2.3.4 CA Access Control Administrator Interfaces GUI Interface CA Access Control has a graphical user interface through which all ACW functions are managed. This GUI is used to define users, groups, and access rules. It can also be used to monitor audit events. Note: The GUI Interface, also known as Policy Manager, is not in the evaluated configuration. Command Line Interface CA Access Control can be fully managed via a command line language called selang. 2.4 Physical Boundary and Scope of the Evaluation The evaluated configuration includes the following: • Host Platform: CA Access Control running on Microsoft Windows 2000 Server SP4 or on Microsoft Windows XP Professional Version 2002 SP2 with a locally connected monitor/terminal ; KEY: eTrust Access Control TOE Host Platform eTrust Access Control Database OS users and groups Repository Task Delegation Service Policy Model Service Command Line Interface Local Terminal Remote Non- administrative User (requesting access to resources) Authorization Engine Service Watchdog Service Agent Service GUI Administrator Interface (TCP/IP encrypted protocol) Operating System Kernel Request Management Software Figure 2-1 CA Access Control TOE Boundary 2.4.1 Included in TOE The TOE encompasses the following components of the CA Access Control product: • The ACW database (Section 2.3.1) • The Request Management software (Section 2.3.2) • The ACW services: (Section 2.3.3) o Watchdog o Agent o Authorization Engine • The Command Line Interface for the CA environment (Section 2.3.4) • Database classes that are stored for use of other CA applications (such as CA Single Sign- On): AGENT, AGENT_TYPE, APPL, AUTHHOST, CALENDAR, GAPPL, GAUTHHOST, RESOURCE_DESC, RESPONSE_TAB, USER_ATTR, USER_DIR, and Unicenter TNG User-Defined Classes. These classes, however, will not be tested in the evaluation and there are no security claims made about these classes. • Language Client API (LCA) • Administration API (seadmapi) • eAC IR API. This library supplies an interface to the ACW log files. 7 8 • The accumulated group rights option must always be set in the evaluated configuration 2.4.2 Excluded from TOE This section defines the components that are not part of the TOE. The administrator guidance informs the administrator of these exclusions. The components and features listed below require authorization to use. The administrator is trusted to not use these features in the evaluated configuration. The following interfaces are only accessible by the administrator and the administrator is trusted to follow guidance and not use them. o The Policy Model Tool (Section 2.3.3) o The GUI Administrator Interface (Section 2.3.4) o dbmgr utility (This is a maintenance utility) o eacpg_gen utility o Authorization and Authentication API o Exits API o Command Line Interface for the native Windows Environment, and Policy Model environment Because the scope of the evaluated configuration is a standalone system, the following features are excluded. o Concurrent logins (allowing the user login to the terminal from different machines) o Resource Protection for TCP/IP services o Domain based login enforcement o Use of the _network and _interactive pre-defined groups o Database classes that apply to this feature: CONNECT, DOMAIN, GHOST, HOST, HOSTNET, HOSTNP, MFTERMINAL, TCP. The native operating system is not part of the CA Access Control product. CA Access Control provides methods for enhancing some of the security features of the native OS. The enforcement of these security features does not strengthen the security of the features provided by the TOE itself. Instead, it strengthens the security features implemented by the native OS. In addition, these security features require the integration of features from both CA Access Control and the native OS to provide a complete implementation o The native Operating System of the host platform o Native Windows Environment database classes and properties (NT environment database) o Database classes that apply to the native operating system: ADMIN, DICTIONARY, PWPOLICY. The following product features were not tested and are not included in the TSF: 9 o Sensitive File Integrity Monitoring (Section 2.3.3) o The Task Delegation Service (Section 2.3.3) o Use of the _abspath pre-defined group o The ability to not set the accumulated group rights option in the evaluated configuration o Database classes that apply to features not included in the TOE (such as Task Delegation) or not included in the Evaluated Configuration (such as multiple hosts): GSUDO, LOGINAPPL, PROGRAM, SECFILE, SPECIALPGM, SUDO, SURROGATE, UACC, and User Defined Classes. 2.5 Logical Boundary CA Access Control provides the following security features: • Resource Protection – CA Access Control provides the ability to assign a security level for the protection of resources that include: o Files o Executables o Server Access o Privileged system commands and data o Terminals o User Accounts • Security Attributes - There are several different types of security administration privileges in Access Control that allow a user the right to access a resource. Privileges are granted by: o Global authorization o User/Group authorization attributes o Ownership o Security Level o Access Rules • Security Audit - CA Access Control (ACW) provides the ability to audit selected events. ACW also provides for the ability to search and view audit records. • Security Management - CA Access Control provides security management through the use of the Administrator Interface. Through the enforcement of the CA Access Control Policy, the ability to manage various security attributes is controlled. The TOE includes three roles: Authorized Administrator, Server and User. The authorized administrator is a user with the OPERATOR, AUDITOR, or ADMIN authority. The SFRs in Section 5.2 define the capabilities of the authorized administrators. 10 • TSF Protection - ACW provides non-bypassability of the TSP and domain separation functionality. 2.6 TOE Security Environment CA Access Control relies upon the underlying operating system platforms to provide user identification and authentication and to provide reliable time stamps. 11 3 TOE Security Environment This section identifies secure usage assumptions and threats to security. There are no organizational security policies. 3.1 Assumptions This section contains assumptions regarding the security environment and the intended usage of the TOE. Table 3-1 Assumptions Item Assumption Description 1 A.Admin The administrator is trusted to correctly install, configure and operate the TOE according to the instructions provided by the TOE documentation and procedures developed by the organization deploying the TOE. These administrators will be trained to manage and operate the system in a secure manner. 2 A.Physical The processing resources of the TOE will be located within controlled access facilities, which will prevent unauthorized physical access. 3.2 Threats The TOE itself has threats and the TOE is also responsible for addressing threats to the environment in which it resides. The assumed level of expertise of the attacker for all threats is unsophisticated, with access to specialized equipment and public information about the product. The TOE must counter the threats to security described below. Table 3-2 Threats Item Threat Description 1 T.Access An authorized user of the TOE may access information or resources without having permission from the person who owns, or is responsible for, the information or resource. 2 T.Bypass An attacker may attempt to bypass TSF security functions to gain unauthorized access to TSF. 3 T.Mismanage Administrators may make errors in the management of security functions and TSF data, if administrator tools are not provided thus allowing attackers to gain unauthorized access to resources protected by the TOE. 4 T.Undetect Attempts by an attacker to violate the CA Access Control Policy may go undetected. If the attacker is successful, TSF data may be lost or altered. 12 4 Security Objectives 4.1 Security Objectives for the TOE The security objectives for the TOE are as shown below. Table 4-1 Security Objectives for TOE Item Objective Description 1 O.AccessControl The TOE must control user access to selected resources in accordance with the set of rules defined by the CA Access Control Policy. 2 O.Admin The TOE must provide the functionality to enable an authorized administrator to effectively manage the TOE and its security functions. 3 O.Audit The TOE must record audit records for data accesses and use of the system functions. 4 O.NonBypass The TOE must ensure the security enforcing functions are invoked and succeed before allowing a TOE function to proceed. 5 O.PartialDomainSep 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. 6 O.Roles The TOE must support multiple user roles. 7 O.SecurityAttr The TOE must be able to assign, store and maintain security attributes for users and selected resources. 4.2 Security Objectives for the Environment 4.2.1 Security Objectives for the IT Environment The security objectives for the IT environment are shown below. Table 4-2 Security Objectives for IT Environment Item Objective Description 1E OE.IDAuth The IT environment must be able to identify and authenticate users prior to allowing access to the operating system of the host platform. 2E OE.Time The IT environment must provide reliable time stamps. 3E OE.NonBypassSupport The IT environment must ensure that the TOE security mechanisms cannot be bypassed in order to gain access to TOE security functions and data. 4E OE.DomainSepSupport The IT environment must provide an isolated domain for the execution of the TOE. 13 4.2.2 Non-IT Security Objectives The Non-IT security objectives are shown below. Table 4-3 Security Objectives for Non-IT Security Objectives Item Objective Description 1N ON.Install Those responsible for the TOE must ensure that the TOE is delivered, installed, and configured in a manner that maintains IT security. 2N ON.Operations There must be procedures in place in order to ensure that the TOE will be managed and operated in a secure manner. 3N ON.Person Personnel working as authorized administrators shall be carefully selected and trained for proper operation of the system. 4N ON.Physical Those responsible for the TOE must ensure that those parts of the TOE critical to the security policy are protected from any physical attack. 14 5 IT Security Requirements This section provides the TOE security functional and assurance requirements. In addition, the IT environment security functional requirements on which the TOE relies are described. These requirements consist of functional components from Part 2 of the CC, assurance components from Part 3 of the CC, and CCIMB Final Interpretations. 5.1 Formatting Conventions The notation, formatting, and conventions used in this security target (ST) are consistent with version 2.2 of the Common Criteria for Information Technology Security Evaluation. Font style and clarifying information conventions were developed to aid the reader. The CC permits four functional component operations: assignment, iteration, refinement, and selection to be performed on functional requirements. These operations are defined in Common Criteria, Part 1, Section 4.4.1.3.2 as: • assignment: allows the specification of an identified parameter; • refinement: allows the addition of details or the narrowing of requirements; • selection: allows the specification of one or more elements from a list; and • iteration: allows a component to be used more than once with varying operations. This ST indicates which text is affected by each of these operations in the following manner: • Assignments and Selections specified by the ST author are in [italicized bold text]. • Refinements are identified with "Refinement:" right after the short name. Additions to the CC text are specified in italicized bold and underlined text. • Iterations are identified with a dash number "-#". These follow the short family name and allow components to be used more than once with varying operations. “*” refers to all iterations of a component. • Application notes provide additional information for the reader, but do not specify requirements. Application notes are denoted by italicized text. • NIAP Interpretations will not be included in this ST due to Labgram 21, but CCIMB Interpretations will be included in the ST. CCIMB interpretations are not identified in the component name, but rather the CC text is modified to include the interpretation. The original CC text modified by the interpretation is not denoted nor explained. • Comments are provided as an aid to the ST author and evaluation team. These items will be deleted in the final version of the ST. All References are to the Windows Administrator Guide unless otherwise noted. 15 The explicitly stated requirements claimed in this ST are denoted by an additional “_XXX” extension in the unique short name for the explicit security requirement. 5.2 TOE Security Functional Requirements The TOE security functional requirements are listed in Table 5-1 below. The FPT_RVM_EXP.1, and FPT_SEP_EXP.1 security functional requirements are explicitly stated (based on FPT_RVM.1 and FPT_SEP.1, respectively from CC Part 2). The remaining security functional requirements are taken from Part 2 of the Common Criteria. Table 5-1 TOE Functional Requirement No. Requirement Requirement Name 1 FAU_GEN.1 Audit data generation 2 FAU_GEN.2 User identity association 3 FAU_SAR.1 Audit review 4 FAU_SAR.2 Restricted audit review 5 FAU_SAR.3 Selectable audit review 6 FAU_SEL.1 Selective audit 7 FAU_STG.1 Protected audit trail storage 8 FDP_ACC.1 Subset access control 9 FDP_ACF.1 Security attribute based access control 10 FIA_ATD.1 User attribute definition 11 FMT_MOF.1 Management of security functions behavior 12 FMT_MSA.1 Management of security attributes 13 FMT_MSA.3-1 Static attribute initialization - restrictive 14 FMT_MTD.1 Management of TSF data 15 FMT_SMF.1 Specification of Management Functions 16 FMT_SMR.1 Security roles 17 FPT_RVM_EXP.1 Partial Non-bypassability of the TSP 18 FPT_SEP_EXP.1 Partial TSF domain separation 19 FTA_TSE.1 TOE session establishment 20 FMT_MSA.3-2 Static attribute initialization - permissive 16 5.2.1 Class FAU: Security Audit Table 5-2 CA Access Control Auditable Events Database Class Type Audit Attribute Value Auditable Event Description all All user login attempts and resource access attempts; same as including: failure, loginfail, loginsuccess, and success failure Failed access attempt of ACW protected resource loginfail Failed user login attempt (ACW denied the login attempt; the attempt never got to the OS) loginsuccess Successful user login (ACW allowed the login attempt; the OS portion of the login is not reflected in the audit record so the OS may still deny the login attempt even though loginsuccess is audited in ACW) none No user activities logged Accessor success Successful access of ACW protected resource all All access requests for the resource; same as including: allow and deny allow Authorized access request for the resource deny Unauthorized access request for the resource Resource none No access requests for the resource logged FAU_GEN.1 Audit data generation Hierarchical to: No other components. FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shutdown of the audit functions; b) All auditable events for the [not specified] level of audit; and c) [auditable events listed in Table 5-2 CA Access Control Auditable Events]. FAU_GEN.1.2 The TSF shall record within each audit record at least 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 PP/ST: [no other information]. Dependencies: FPT_STM.1 Reliable time stamps FAU_GEN.2 User identity association Hierarchical to: No other components. 17 FAU_GEN.2.1 The TSF shall be able to associate each auditable event with the identity of the user that caused the event. Dependencies: FAU_GEN.1 Audit data generation FIA_UID.1 Timing of identification FAU_SAR.1 Audit review Hierarchical to: No other components. FAU_SAR.1.1 The TSF shall provide [Authorized Administrator with AUDITOR authorization] with the capability to read [all audit information] from the audit records. FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. Dependencies: FAU_GEN.1 Audit data generation FAU_SAR.2 Restricted audit review Hierarchical to: No other components. FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access. Dependencies: FAU_SAR.1 Audit review FAU_SAR.3 Selectable audit review Hierarchical to: No other components. FAU_SAR.3.1 The TSF shall provide the ability to perform [searches] of audit data based on [date, time, object identity, user identity, resource class, event type]. Dependencies: FAU_SAR.1 Audit review Application Note: • object identity = RESOURCENAME attribute of resource record; • user identity = USERNAME or GROUPNAME attribute of accessor record. FAU_SEL.1 Selective audit Hierarchical to: No other components. FAU_SEL.1.1 The TSF shall be able to include or exclude auditable events from the set of audited events based on the following attributes: 18 [object identity, user identity, event type] [resource group membership, user group membership]. Dependencies: FAU_GEN.1 Audit data generation FMT_MTD.1 Management of TSF data Application Note: • object identity =RESOURCENAME attribute of resource record • user identity = USERNAME or GROUPNAME attribute of accessor record • resource group membership = RESOURCENAME attribute of CONTAINER, GFILE, or GTERMINAL record that the resource belongs to • user group membership = GROUPNAME attribute of the group record the accessor belongs to FAU_STG.1 Protected audit trail storage Hierarchical to: No other components. FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion. FAU_STG.1.2 The TSF shall be able to [prevent] unauthorized modifications to the audit records in the audit trail. Dependencies: FAU_GEN.1 Audit data generation 5.2.2 Class FDP: User Data Protection FDP_ACC.1 Subset access control Hierarchical to: No other components. FDP_ACC.1.1 The TSF shall enforce the [CA Access Control Policy] on [Accessors and Resource Objects and Operations as listed in Table 5-3]. Dependencies: FDP_ACF.1 Security attribute based access control Table 5-3 CA Access Control Policy (Objects and Operations) Resource Object Operations (Permitted Access Rights Values for ACL, NACL and PACL attributes) all Allows accessors to perform all operations permissible for the class. FILE a specific: chdir Allows accessors to access the directory with the equivalent of read and execute permissions. 19 Resource Object Operations (Permitted Access Rights Values for ACL, NACL and PACL attributes) chown Allows accessors to change the owner of the file. control Allows accessors all accesses except delete and rename. create Allows accessors to create a file. delete Allows accessors to delete a file. (ACL and PACL only) execute Allows accessors to execute a program. To use this access type, the accessor must also have read access. none Does not allow the accessor to perform any operations. read Allows accessors to use a file or directory without changing it. rename Allows an accessor to rename a file. sec Allows an accessor to change the ACL of a file. update Allows accessors the combination of read, write, and execute permissions. ƒ file ƒ directory ƒ files that match a file- name pattern write Allows an accessor to change the file or directory. none Does not allow the accessor to perform any operations. read Allows accessors to use any file or directory in the group without changing it. GFILE a group of: ƒ specific files ƒ specific directories ƒ files that match a file- name pattern write Allows an accessor to change the file or directory in the group. none Does not allow the accessor to perform any operations. read Allows accessors to log in from any terminal in the group. GTERMINAL a group of: ƒ terminals write Allows an accessor to administer CA Access Control from any terminal in the group none Does not allow the accessor to perform any operations. HOLIDAY Defines one or more periods when users need extra permission to log in read Allows accessors to log in during the holiday specified in the record. none Does not allow the accessor to perform any operations PROCESS a program – executable file that runs in its own address space & needs to be protected from being killed read Allows accessors to kill the process all Allows accessors to perform all operations permissible for the class. delete Allows accessors to delete a Windows registry key none Does not allow the accessor to perform any operations. read Allows accessors to list the contents of the Windows registry key REGKEY a key in the registry write Allows an accessor to change the Windows registry key 20 Resource Object Operations (Permitted Access Rights Values for ACL, NACL and PACL attributes) none Does not allow the accessor to perform any operations. read Allows accessors to log in from the terminal . TERMINAL a terminal of the local host write Allows an accessor to administer CA Access Control from the terminal. FDP_ACF.1 Security attribute based access control Hierarchical to: No other components. FDP_ACF.1.1 The TSF shall enforce the [CA Access Control Policy] to objects based on the following: [Objects with attributes listed in ]. Table 5-4 CA Access Control Policy (Security Attributes) 21 Table 5-4 CA Access Control Policy (Security Attributes) Object Security Attribute ACW Database Record Attribute Object Identity RESOURCENAME Resource Class CLASSNAME Resource Group Membership GROUPS Resource Owner OWNER Day and Time Restrictions DAYTIME Access Control List ACL Negative Access Control List NACL Program Access Control List PACL Default Access UACC Security Category * CATEGORY Security Label * SECLABEL Resource Record (The File, Process, Regkey, and Terminal classes have _default object records. The use of the _default object records is included in Table 5-5. _default object records are managed the same as other resource records.) Security Level * SECLEVEL User Identity USERNAME User Group Membership GROUPS Security Category CATEGORY Security Label SECLABEL Accessor Record Security Level SECLEVEL * The REGKEY class does not support the Security Category, Security Label or Security Level security attributes. 22 FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [rules listed in Table 5-5 CA Access Control Policy (Controlled Operation Access Rules)) and Table 5-6 CA Access Control Policy (Label Access Rules)]. Table 5-5 CA Access Control Policy (Controlled Operation Access Rules) Controlled Operation Access Rules The following process will be followed to determine if a user is allowed to perform an operation on a resource. Access rights will be checked in the following order: 23 If a record with the exact resource name is found in database: 1. Grant access if user has the OPERATOR authorization, the resource is a FILE class, and the requested access is “read”. 2. Label Access Check as described in Table 5-6 If access is denied, stop processing. Otherwise, continue. 3. Check Resource day-time restriction If access is denied, stop processing. Otherwise, continue. 4. Grant access if user is owner of named resource record 5. Access Lists Check for user name in the named resource record If a match is found, abide by the matching permitted access rights, else continue processing. 6. Access Lists Check for user name in any of the named resource’s group records If a match is found, abide by the matching permitted access rights, else continue processing. 7. Access Lists Check for any of the user’s group names in the named resource record If a match is found, abide by the matching permitted access rights, else continue processing. 8. Access Lists Check for any of the user’s group names in any of the named resource’s group records: If a match is found, abide by the matching permitted access rights, else continue processing. 9. Access Lists Check for general user7 in the named resource record: If a match is found, abide by the matching permitted access rights, else continue processing. 10. Access Lists Check for general user in any of the named resource’s group records If a match is found, abide by the matching permitted access rights, else continue processing. 11. If ACCPACL is active : a. Program Access Lists check for user name/program pair in the named resource. If a match is found, abide by the matching permitted access rights, else continue processing. b. Program Access Lists check for access NONE in one of the user’s groups in the PACL. If a match is found, abide by the matching permitted access rights, else continue processing. c. Program Access Lists check for access for the user’s groups in the PACL. If a match is found, abide by the matching permitted access rights, else continue processing. d. Program Access Lists check for general user access in the PACL. If a match is found, abide by the matching permitted access rights, else continue processing. e. Program Access Lists check for user name/generic program8 pair in the named resource. If a match is found, abide by the matching permitted access rights, else continue processing. f. Program Access Lists check for access NONE for the user’s group/generic program pair in the named resource. If a match is found, abide by the matching permitted access rights, else continue processing. g. Program Access Lists check for access for the user’s group/generic program pair in the named resource. If a match is found, abide by the matching permitted access rights, else continue processing. h. Program Access Lists check for access for the general user/generic program pair in the named resource. If a match is found, abide by the matching permitted access rights, else continue processing. i. Repeat a-h, checking for the Program Access List in the named resource’s group, instead of the name resource. If a match is found, abide by the matching permitted access rights, else continue processing. 12. Default record access check (‘defaccess’ property) 24 Else if generic record9 matching the resource name is found in database: 1. Same checks as for an exact resource name, except with the generic record used in place of named resource record. Else if the resource is in the FILE or REGKEY class and a match is not found in the database and the user is in the _restricted group: Same checks as for an exact resource name, except with the _default record for FILE or REGKEY class used in place of named resource record. Else if the resource is in the TERMINAL class and if the _default object for the resource's class is found in the database: Same checks as for an exact resource name, except #1 is skipped and _default object record for the class is used in place of the named resource record. Else Grant access The Access Lists Check will be performed in the following order: 1. Check resource record for access rights for accessor name in NACL 2. Check resource record for access rights for accessor name in ACL If a user is a member of more than one group in an access control list: 1. If any of the access values is NONE, CA Access Control denies the user access to the resource. 2. The access control list right of a user belonging to more than one group is equal to the sum of all the access rights of the groups to which the user belongs. (NOTE: The accumulated group rights option is always set in the evaluated configuration.) Table 5-6 CA Access Control Policy (Label Access Rules) CA Access Label Access Rules If CATEGORY, SECLABEL, and/or SECLEVEL classes have been activated the following rules will be applied in order: 7 The term general user in the access rules is used to refer to an ACL entry for all users who are defined in eAC, as specified by entering an asterisk (*) for the username. 8 The term generic program in the access rules is used to refer to program entry with wildcard patterns in the program name. 9 The term generic record in the access rules is used to refer to a resource record with wildcard patterns in the resource name. 25 Security Label Check When a USER record includes a security label, the user is granted access to a resource only if both of the following are true: o The user security level specified in the security label is equal to or greater than the resource security level. o All categories specified in the resource record are included in the security category list of the user security label. If a resource has one or more security categories assigned to it, a user is granted access to the resource only if the user security category list contains all the security categories assigned to the resource. Security Category Check When a user requests access to a resource that has been assigned one or more security categories ACW compares the list of security categories in the user record with the list of security categories in the resource record. If any security category in the resource record is not in the user record, ACW denies access to the resource. If the user record contains all the security categories specified in the resource record, ACW continues with other authorization checking. Security Level Check If a resource has a security level assigned to it, the user is granted access to the resource only if the security level of the user is equal to or greater than the security level of the resource. FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [no additional rules]. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the [no additional rules]. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation 26 5.2.3 Class FIA: Identification and Authentication FIA_ATD.1 User attribute definition Hierarchical to: No other components. FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [attributes of the USER class listed in Table 5-7 ]. Dependencies: No dependencies. Table 5-7 TSF Data (User Class Security Attributes) User Security Attribute Attribute Definition AUDIT_MODE Specifies the type of activities that Access Control records in the audit log for the user. (event type) CATEGORY One or more security categories assigned to a user. DAYTIME The day and time restrictions that govern when a user can access resources. GROUPS The list of user groups a user belongs to. This property also contains any group authorities, such as group administration authority (GROUP-ADMIN), assigned to the user for each group the user belongs to. (user group membership) USERNAME Name entered by the user when logging into the system. (user identity) NOTIFY The user notified when a resource generates an audit event. OBJ_TYPE Specifies the authority attributes (authorizations) of the user (ADMIN, AUDITOR, IGN_HOL, OPERATOR, SERVER). OWNER The user or group that is the owner of the record. PROFILE The profile group for the user. When the user belongs to a profile group, properties not explicitly assigned in the USER record are inherited from the profile GROUP record: SECLABEL The security label of a user. A security label associates a security level with security categories. SECLEVEL The security level of the user. The security level is a positive integer between 0 and 255. 5.2.4 Class FMT: Security Management The CA Access Control Policy is defined by the use of the TOE security functions and the TSF data. The TSF data are the records in the CA Access Control database that define the classes and objects that enforce the TOE’s purpose of providing resource protection and access control. The classes and their attributes that are included in the evaluated configuration of the TOE are listed in Table 5-7 TSF Data (User Class Security Attributes), Table 5-8 TSF Data (Group Class Security Attributes), Table 5-9 TSF Data (Resource Classes) and Table 5-10 TSF Data (Resource Class Security Attributes). The TOE security functions are those functions available to authorized users through the CA Access Control command language to act on the TSF data stored in the CA Access 27 Control database. The functions included in the evaluated configuration of the TOE are listed in Table 5-11 TOE Security Functions. Table 5-8 TSF Data (Group Class Security Attributes) Group Security Attribute Attribute Definition AUDIT_MODE Specifies the type of activities that ACW records in the audit log for the group. (event type) GROUP_MEMBER The groups that are members of this group. MEMBER_OF The groups that this group is a member of. (user group membership) GROUPNAME Name of the group. (user group identity) OWNER The user or group that is the owner of the record. SUPGROUP The name of the parent group (“superior” group). USERLIST The list of users that belong to the group. 28 Table 5-9 TSF Data (Resource Classes) Class Class Attributes Name Description ACL CATEGORY DAYTIME GROUPS NACL NOTIFY OWNER PACL RAUDIT SECLABEL SECLEVEL UACC WARNING OTHER CATEGORY Defines a security category in the database. X CONTAINER Defines a group of resource classe objects. X X X X X X X X MEMBERS FILE Defines the access allowed to a specific file or directory, or to files that match a file name pattern. X X X X X X X X X X X X X GFILE Defines the access allowed to a group of specific files, specific directories, or files that match a name pattern. X X X X X X X X MEMBERS GTERMINAL Defines a group of terminals. X X X X X X MEMBERS HOLIDAY Defines one or more periods when users need extra permission to log in. X X X X X X X X X X X HOL_DATE PROCESS Defines a program that needs to be protected from being killed. X X X X X X X X X X X X X REGKEY Defines the tree structure of a key in the registry where Windows configuration information is saved. X X X X X X X X X X SECLABEL Associates a security level with security categories. X X X SEOS The class contains only one record, called SEOS, which specifies general security and authorization options. See Note TERMINAL Defines a terminal of the local host, another host on the network, or an X terminal from which a login session can be made. X X X X X X X X X X X X X Application Note: The SEOS class is only used with the setoptions command to set the following SEOS modifiable attributes: 1. CATEGORY, FILE, HOLIDAY, PROCESS, REGKEY, SECLABEL and SECLEVEL which activates or deactivates the classes of the same name. 2. ACCPACL which determines the order in which the attributes PACL and UACC in a resource are checked for user access. 3. GRACCL which determines if the accumulated group rights of users are checked. It must always be set in the evaluated configuration. 29 Table 5-10 TSF Data (Resource Class Security Attributes) Resource Security Attribute Attribute Definition ACL The list of accessors (users and groups) permitted to access the resource and their access types. CATEGORY One or more security categories assigned to a resource. CLASSNAME Name of the class the resource belongs to. (resource class) DAYTIME The day and time restrictions that govern when a user can access the resource. GROUPS The list of GFILE, GTERMINAL or CONTAINER records a resource record belongs to. (resource group membership) HOL_DATE Specifies the period during which users cannot log in. MEMBERS The list of objects that are members of the group. NACL The list of accessors (users and groups) that are denied access to the resource and the type of access denied. RESOURCENAME Name of the resource. (object identity) NOTIFY The user notified when a resource generates an audit event. OWNER The user or group that is the owner of the record. PACL The program access control list—an ACL that applies to accessors when the access request is made by a specific program or a program that matches a program-name pattern. RAUDIT The types of access events that CA Access Control records in the audit log. SECLABEL The security label of a resource. A security label associates a security level with security categories. SECLEVEL The security level of the user or resource. The security level is a positive integer between 0 and 255. UACC The default access for the resource, which indicates the access granted to accessors who are not defined to ACW or who do not appear in the ACL of the resource. WARNING Indicates whether warning mode is enabled. When warning mode is enabled, all access requests are granted. If an access request violates an access rule, a record is written to the audit log. Table 5-11 TOE Security Functions Function Function Definition Role(s) that may use the function selang command authorize Adds or Removes accessors to a resource access control list. rmgrp Deletes records belonging to the GROUP class from the database. o Authorized Administrator with ADMIN authorization o User with GROUP-ADMIN authorization for the group that owns the record o User specified in the OWNER attribute of the record 30 Function Function Definition Role(s) that may use the function selang command rmfile Deletes resource records belonging to the FILE class from the database. rmres Deletes resource records from the database. rmusr Deletes records belonging to the USER class from the database. check Determines if a user has access to a resource. checklogin Determines user login privileges, whether a password check is needed, and whether a terminal access check is needed. o Authorized Administrator with ADMIN authorization o Process with SERVER authorization chfile Modifies one or more records in the FILE class. chgrp Modifies one or more records in the GROUP class. chres Modifies one or more records in a resource class. Modify all attributes except audit: o Authorized Administrator with ADMIN authorization o User with GROUP-ADMIN authorization for the group that owns the record o User specified in the OWNER attribute of the record Modify audit attribute only: o Authorized Administrator with AUDITOR authorization o User with GROUP-AUDITOR authorization for the group that owns the record 31 Function Function Definition Role(s) that may use the function selang command chusr Modifies a record in the USER class. Modify all attributes except audit: o Authorized Administrator with ADMIN authorization Modify audit attribute only: o Authorized Administrator with AUDITOR authorization o User with GROUP-AUDITOR authorization for the group that owns the record Modify all attributes except audit and authorization: o User specified in OWNER attribute of the record o User with GROUP-ADMIN authorization for the group that owns the record • To assign a security category to the user record, the security category must appear in the owner’s user record. • To assign a security label to the user record, the security label must be assigned in the owner’s user record. • The owner of the user record can assign any security level that is less than or equal to the security level assigned in the owner’s user record. editfile Creates or modifies one or more records in the FILE class. See chfile and newfile editgrp Creates or modifies one or more records in the GROUP class. See chgrp and newgrp editres Creates or modifies one or more records in a resource class. See chres and newres editusr Creates or modifies one or more records in the USER class. See chusr and newusr find list search Displays classes and objects in the ACW database. ruler Sets the attributes that Access Control displays for a particular class. o Authorized Administrator with ADMIN, AUDITOR or OPERATOR authorization join Adds users to one or more groups, or changes their set of properties with respect to the groups. newfile Creates a new FILE record. newgrp Creates a new GROUP record. o Authorized Administrator with ADMIN authorization 32 Function Function Definition Role(s) that may use the function selang command newres Defines a new resource. newusr Defines a new user record. rename Changes a resource name in the CA Access Control database. o Authorized Administrator with ADMIN authorization setoptions Sets system-wide options related to resource protection and lists the current settings of the options. List and Set options: o Authorized Administrator with ADMIN authorization List option only: o Authorized Administrator with AUDITOR or OPERATOR authorization showfile Displays the attributes of a FILE record. showgrp Displays the attributes of a GROUP record. showres Displays the attributes of a resource record. showusr Displays the attributes of a USER record. o Authorized Administrator with ADMIN, AUDITOR or OPERATOR authorization o User with GROUP-ADMIN, GROUP-AUDITOR, GROUP-OPERATOR authorization for the group that owns the record or that is a parent of the group that owns the record/resource o User specified in the OWNER attribute of the record Utilities (non-selang commands) seaudit Displays the CA Access Control audit log. o Authorized Administrator with AUDITOR authority attribute secons Provides a control console to the CA Access Control engine. Operations include control tracing of the CA Access Control authorization engine, display run- time statistics, shutdown the CA Access Control engine and all other CA Access Control services o –h, –m, and -refIP options are available to all users o -file, -i, -s, -t+, -t-, -tc, -ts, -tt, -tv options are available to authorized administrators with the ADMIN or OPERATOR authority attribute o –d+, -d-, -ds, -l+, -l-, -ls, –u+, -u-, -us options are not included in the scope of the evaluation. FMT_MOF.1 Management of Security Functions Behavior Hierarchical to: No other components. FMT_MOF.1.1 The TSF shall restrict the ability to [determine the behavior of, disable, enable, and modify the behavior of] the functions [audit functions (see Table 5-2 CA Access Control Auditable Events)] to [Authorized Administrators with AUDITOR authorization, User with GROUP-AUDITOR authorization]. Dependencies: FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles 33 FMT_MSA.1 Management of security attributes Hierarchical to: No other components. FMT_MSA.1.1 The TSF shall enforce the [CA Access Control Policy] to restrict the ability to [[function as specified in column 1 of Table 5-11]] the security attributes [attributes of the classes as specified in Table 5-4] to [roles as specified in column 3 of Table 5-11]. Dependencies: [FDP_ACC.1 Subset access control] FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles FMT_MSA.3-1 Static attribute initialization - restrictive Hierarchical to: No other components. FMT_MSA.3.1-1 The TSF shall enforce the [discretionary access control portion of the CA Access Control Policy10 ] to provide [restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2-1 The TSF shall allow the [Authorized Administrator with ADMIN authorization] to specify alternative initial values to override the default values when an object or information is created. Dependencies: FMT_MSA.1 Management of security attributes, FMT_SMR.1 Security roles. FMT_MSA.3-2 Static attribute initialization - permissive Hierarchical to: No other components. FMT_MSA.3.1-2 The TSF shall enforce the [daytime restrictions and label access portion of the CA Access Control Policy11 ] to provide [permissive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2-2 The TSF shall allow the [Authorized Administrator with ADMIN authorization] to specify alternative initial values to override the default values when an object or information is created. Dependencies: FMT_MSA.1 Management of security attributes, 10 The discretionary access control portion refers to the OWNER, GROUPS, ACL, NACL, PACL, and UACC record attributes. 11 The daytime restrictions portion refers to the the DAYTIME record attribute. The label access portion refers to the CATEGORY, SECLABEL, and SECLEVEL record attribute. 34 FMT_SMR.1 Security roles. FMT_MTD.1 Management of TSF data Hierarchical to: No other components. FMT_MTD.1.1 The TSF shall restrict the ability to [[functions specified in column 1 of Table 5-11]] the [TSF Data as specified in Table 5-7, Table 5-8, Table 5-9 and Table 5-10] to [roles as specified in column 3 of Table 5-11]. Dependencies: FMT_SMF.1 Specification of Management Functions, FMT_SMR.1 Security roles. FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components. FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions: [ [read and search the audit records], [determine the behavior of, disable, enable, and modify the behavior of the audit functions], and [functions specified in Table 5-11]]. Dependencies: No Dependencies. FMT_SMR.1 Security roles Hierarchical to: No other components. FMT_SMR.1.1 The TSF shall maintain the roles [Authorized Administrator, Server, User]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. Dependencies: FIA_UID.1 Timing of identification. Table 5-12 TSF Security Roles Security Role Role Definition Authorized Administrator User with one or more of the following authority attribute values assigned in the OBJ_TYPE attribute of the corresponding USER record: o ADMIN o AUDITOR o OPERATOR 35 Security Role Role Definition Server Process with the SERVER authority attribute value. A Server can: o determine if a user has access to a resource o determine user login privileges o determine whether a password check is needed o determine whether a terminal access check is needed User User with only the IGN_HOL authority attribute or with no authority attribute values assigned in the OBJ_TYPE attribute of the corresponding USER record. o A user may be designated in the OWNER attribute of an CA Access Control database record. The OWNER of an accessor or resource record may display or modify attributes (except for the audit attributes) of the owned record or delete the owned record. o A user may be designated as a group administrator with GROUP- ADMIN authorization. If a database record is owner by a group, the group administrator of that group has the same privileges as the owner of a record. o A user may be designated as a group auditor with GROUP-AUDITOR authorization. If a database record is owned by a group, the group auditor of that group may modify the audit attribute of that record. o A user may be designated as a group operator with GROUP- OPERATOR authorization. If a database records is owned by a group, the group operator of that group may list the attributes of that record. 5.2.5 Class FPT: Protection of the TOE Security Functions FPT_RVM_EXP.1 Partial Non-bypassability of the TSP Hierarchical to: No other components. FPT_RVM_EXP.1.1 The TSF, when invoked shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed. Dependencies: No dependencies. FPT_SEP_EXP.1 Partial TSF domain separation Hierarchical to: No other components. FPT_SEP_EXP.1.1 The TSF shall maintain a security domain that protects it from interference and tampering by untrusted subjects initiating actions through its own TSFI. FPT_SEP_EXP.1.2 The TSF shall enforce separation between the security domains of subjects in the TSC. Dependencies: No dependencies. 36 5.2.6 Class FTA: TOE session establishment FTA_TSE.1 TOE session establishment Hierarchical to: No other components. FTA_TSE.1.1 The TSF shall be able to deny session establishment based on [date and time]. Dependencies: No dependencies. Application Note: Users can be restricted from creating a logon session by date and time with use of the DAYTIME attribute of the USER record and further restricted by use of the HOLIDAY class. 5.3 Strength of Function There are no SOF Claims, since there are no probabilistic or permutational mechanisms included in the TOE. 5.4 Security requirements for the IT Environment The security functional requirements are listed in Table 5-13. They are all taken from Part 2 of the Common Criteria. Table 5-13 Functional Requirement for the IT environment No. Component Requirement Requirement Component Name 1E FIA_UAU.2 User authentication before any action 2E FIA_UID.2 User identification before any action 3E FPT_STM.1 Reliable time stamps 4E FPT_RVM_ENV.1 Environment Non-bypassability of the TSP 5E FPT_SEP_ENV.1 Environment TSF Domain Separation FIA_UAU.2 User authentication before any action Hierarchical to: FIA_UAU.1 FIA_UAU.2.1 Refinement: The IT environment shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Dependencies: FIA_UID.1 Timing of identification. 37 FIA_UID.2 User identification before any action Hierarchical to: FIA_UID.1 FIA_UID.2.1 Refinement: The IT environment shall require each user to identify itself before allowing any other TSF-mediated actions on behalf of that user. Dependencies: No dependencies. FPT_RVM_ENV.1 Environment Non-bypassability of the TSP Hierarchical to: No other components. FPT_RVM_ENV.1.1 The IT Environment shall ensure that IT Environment security policy enforcement functions are invoked and succeed before each function within the IT environment scope of control is allowed to proceed. Dependencies: No dependencies. FPT_SEP_ENV.1 Environment TSF Domain Separation Hierarchical to: No other components. FPT_SEP_ENV.1.1 The IT Environment shall maintain a security domain for the TOE’s execution that protects the TOE from interference and tampering by untrusted subjects. FPT_SEP_ENV.1.2 The IT Environment shall enforce separation between the security domains of subjects in the TSC. Dependencies: No dependencies. FPT_STM.1 Reliable time stamps Hierarchical to: No other components. FPT_STM.1.1 Refinement: The IT environment shall be able to provide reliable time stamps for its own use. Dependencies: No dependencies. 5.5 TOE Security Assurance Requirements The Security Assurance Requirements for the TOE are the assurance components of Evaluation Assurance Level 3 (EAL3) taken from Part 3 of the Common Criteria. None of the assurance components is refined. The assurance components are listed in the table below. 38 Table 5-14 Assurance Requirements: EAL3 Assurance Class Item Assurance Requirement 1 ACM_CAP.3 Authorization controls Configuration management 2 ACM_SCP.1 TOE CM coverage 3 ADO_DEL.1 Delivery procedures Delivery and operation 4 ADO_IGS.1 Installation, generation, and start-up procedures 5 ADV_FSP.1 Informal functional specification 6 ADV_HLD.2 Security enforcing high-level design Development 7 ADV_RCR.1 Informal correspondence demonstration 8 AGD_ADM.1 Administrator guidance Guidance documents 9 AGD_USR.1 User guidance Life cycle support 10 ALC_DVS.1 Identification of security measures 11 ATE_COV.2 Analysis of coverage 12 ATE_DPT.1 Testing: high-level design 13 ATE_FUN.1 Functional testing Tests 14 ATE_IND.2 Independent testing - sample 15 AVA_MSU.1 Examination of guidance 16 AVA_SOF.1 Strength of TOE security function evaluation Vulnerability assessment 17 AVA_VLA.1 Developer vulnerability analysis Further information on these assurance requirements can be found in the Common Criteria for Information Technology Security Evaluation (CCITSE) Part 3. 39 6 TOE Summary Specification 6.1 IT Security Functions 6.1.1 Overview The following sections describe the IT Security Functions of the CA Access Control TOE components. This section includes a bi-directional mapping between functions and requirements that clearly shows which functions satisfy which requirements and that all requirements are met. In this document, all CA Access Control TOE components will be mutually referred to as CA Access Control. 6.1.2 CA Access Control Security Functions Table 6-1 Security Functional Requirements mapped to Security Functions No. SFR Security Class Security Functions Sub-functions 1 FAU_GEN.1 Security Audit Security Audit AI-SA-1 AI-SA-2 2 FAU_GEN.2 Security audit Security Audit AI-SA-3 3 FAU_SAR.1 Security audit Security Audit AI-SA-4 4 FAU_SAR.2 Security audit Security Audit AI-SA-5 5 FAU_SAR.3 Security audit Security Audit AI-SA-6 6 FAU_SEL.1 Security audit Security Audit AI-SA-7 7 FAU_STG.1 Security audit Security Audit AI-SA-8 8 FDP_ACC.1 User data protection Manage User Access AI-MUA-1 9 FDP_ACF.1 User data protection Manage User Access AI-MUA-2 10 FIA_ATD.1 Identification and authentication User Identification AI-UI-1 11 FMT_MOF.1 Security management Security Management AI-SM-1 12 FMT_MSA.1 Security management Security Management AI-SM-2 13 FMT_MSA.3-1 Security management Security Management AI-SM-3 14 FMT_MTD.1 Security management Security Management AI-SM-4 15 FMT_SMF.1 Security management Security Management AI-SM-5 16 FMT_SMR.1 Security management Security Management AI-SM-6 17 FPT_RVM_EXP.1 Protection of the TSF TSF Protection AI-TP-1 18 FPT_SEP_EXP.1 Protection of the TSF TSF Protection AI-TP-2 19 FTA_TSE.1 TOE access TOE Session Establishment AI-TSE-1 20 FMT_MSA.3-2 Security management Security Management AI-SM-7 40 Table 6-2 Security Audit Function Security Functions: Security Audit Function Sub-function ID Sub-function description AI-SA-1 CA Access Control will generate the following types of audit events: • Startup and shutdown of audit functions that are included with the startup and shutdown of CA Access Control • Events listed in Table 5-2 CA Access Control Auditable Events (FAU_GEN.1.1) AI-SA-2 CA Access Control will record the following information for all audit events: • Date and Time of event • Event Type • User Identity • Return Code which indicates the success or failure of event • Audit Record Code that indicates the reason for the result (FAU_GEN.1.2) AI-SA-3 CA Access Control will associate each auditable event with the identity of the user that caused the event. (FAU_GEN.2) AI-SA-4 CA Access Control will provide the Authorized Administrator with AUDITOR authority with the capability to read all audit information in the audit records. The records will be presented in a manner suitable to interpret the information. These capabilities are provided through the use of the seaudit utility. (FAU_SAR.1) AI-SA-5 CA Access Control will prohibit all users read access to the audit records, except those users that have been granted explicit read-access (Authorized administrators with AUDITOR authorization). (FAU_SAR.2) AI-SA-6 CA Access Control will provide the ability to perform searches of the audit data based on: o Date and Time o User Identity (accessor record name) o Object Identity (resource record name) o Resource Class o Event Type The seaudit utility provides searching of the audit data. (FAU_SAR.3) 41 Security Functions: Security Audit Function Sub-function ID Sub-function description AI-SA-7 CA Access Control will be able to include or exclude auditable events from the set of audited events based on the attributes: o Object Identity (resource record name) o User Identity (accessor record name) o Event Type o Resource Group Membership o User Group Membership Audit events for resource class objects and groups of resource class objects can be included or excluded by setting the value of the RAUDIT attribute. Audit events for user class objects and groups of user class objects can be included or excluded by setting the values of the AUDIT_MODE attribute. (FAU_SEL.1) AI-SA-8 CA Access Control will protect the stored audit records in the audit trail from unauthorized deletion and modification. The audit file is protected by the seos Engine. The audit log is a binary file and cannot be edited or changed. (FAU_STG.1) Table 6-3 Manage User Access Function Security Functions: Manage User Access Function Sub-function ID Sub-function description AI-MUA-1 The TSF will enforce the CA Access Control Policy on users and the resources and operations listed in Table 5-3 CA Access Control Policy (Objects and Operations). (FDP_ACC.1) AI_MUA-2 The TSF will use the rules listed in Table 5-5 CA Access Control Policy (Controlled Operation Access Rules) and Table 5-6 CA Access Control Policy (Label Access Rules) to enforce the CA Access Control Policy. The _restricted group is a pre-defined group with special meaning in the access rules. This group is managed the same as the other groups. (FDP_ACF.1) Table 6-4 User Identification Function Security Functions: User Identification Function Sub-function ID Sub-function description AI-UI-1 For each user, CA Access Control will maintain the security attributes listed in Table 5-7 TSF Data (User Class Security Attributes). (FIA_ATD.1) 42 Table 6-5 Security Management Function Security Functions: Security Management Function Sub-function ID Sub-function description AI-SM-1 CA Access Control will restrict the ability to modify and control the auditing functions to Authorized Administrators with AUDITOR authorization or users with GROUP-AUDITOR authorization. (See Table 5-2 CA Access Control Auditable Events.) (FMT_MOF.1) AI-SM-2 CA Access Control will restrict the ability to add, display, modify and delete the security attributes of users and resources in the ACW database records. See Table 5-7 TSF Data (User Class Security Attributes), Table 5-8 TSF Data (Group Class Security Attributes), Table 5-9 TSF Data (Resource Classes), and Table 5-10 TSF Data (Resource Class Security Attributes) for a list of the ACW database classes and their security attributes. See Table 5-11 TOE Security Functions for a description of the functions and the roles that may use them. (FMT_MSA.1) AI-SM-3 CA Access Control will provide restrictive default values for the discretionary access control security attributes listed in Table 5-4 CA Access Control Policy (Security Attributes). The default initial values of the ACL, NACL, PACL attributes are null which restricts access to resources to the owner. The default initial values of the UACC attribute are none which assigns a default access value of none. The default initial value of the GROUPS attribute is empty. The default initial value of the OWNER attribute is the user creating the resource. The Authorized Administrator with ADMIN authorization can override UACC and OWNER values when creating a new resource or user. The ACL, NACL, PACL, and GROUPS attribute initial default values cannot be changed. (FMT_MSA.3-1) AI-SM-4 CA Access Control will restrict the ability use the command line interface functions that add, delete, modify and display the TSF Data as described in Table 5-11 TOE Security Functions. (FMT_MTD.1) AI-SM-5 CA Access Control will provide the security management functions as defined in Table 5-11 TOE Security Functions, the ability to modify the audit functions, and the ability to read and search the audit records with the seaudit utility. (FMT_SMF.1) AI-SM-6 CA Access Control will maintain the roles: Authorized Administrator, Server and User as defined in Table 5-12 TSF Security Roles. (FMT_SMR.1) AI-SM-7 CA Access Control will provide permissive default values for the daytime restsrictions and label access security attributes listed in Table 5-4 CA Access Control Policy (Security Attributes). The default initial value of the daytime attribute is none which allows access to the resource at any day and time. The CATEGORY, SECLABEL, and SECLEVEL attributes are globally not activated in the TOE by default. The default initial value of the CATEGORY, SECLABEL, and SECLEVEL attributes are permissive because to restrict access they must first be connected to the resource. The Authorized Administrator with ADMIN authorization can override the values when creating a new resource or user. NOTE: Since the access control policy rules check discretionary access in addition to daytime and before label access checks, the overall resulting object access is by default restrictive. (FMT_MSA.3-2) 43 Table 6-6 TSF Protection Function Security Functions: TSF Protection Function Sub-function ID Sub-function description AI-TP-1 CA Access Control will ensure that TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed. (FPT_RVM_EXP.1) AI-TP-2 CA Access Control will maintain a security domain that protects it from interference and tampering by untrusted subjects initiating actions through its own TSFI. (FPT_SEP_EXP.1) Table 6-7 TOE Session Establishment Function Security Functions: TOE Session Establishment Function Sub-function ID Sub-function description AI-TSE-1 CA Access Control will be able to deny session establishment based on date and time through use of the DAYTIME attribute of a USER record and/or the HOLIDAY class. The IGN_HOL authority attribute of the USER record allows the user to login during the time defined in the HOLIDAY record. (FTA_TSE.1) 6.2 SOF Claims There are no SOF Claims, since there are no probabilistic or permutational mechanisms included in the TOE. The AVA_SOF is vacuously satisfied when there are no applicable mechanisms and no strength is implied. 6.3 Assurance Measures CA Access Control satisfies the assurance requirements for Evaluation Assurance Level EAL3. The following items are provided as evaluation evidence to satisfy the EAL3 assurance requirements: 44 Table 6-8 Assurance Measures and How Satisfied Item Component Evidence Requirements How Satisfied 1 ACM_CAP.3 CM Plan eTrust TM Access Control r8 CM Plan 2 ACM_SCP.1 CM coverage Configuration Item List 3 ADO_DEL.1 Delivery Procedures Distribution Centers Procedures Manual United States and Canada Preservation of Product 4 ADO_IGS.1 Installation and Start-Up Procedures eTrustTM Access Control for Windows Administrator Guide r8 eTrustTM Access Control for Windows Getting Started r8 CA eTrustTM Access Control for Windows r8 Common Criteria Supplement to the Guidance Documentation 5 ADV_FSP.1 Informal Functional Specification EAL3 Design Documentation CA eTrustTM Access Control r8 for Windows DrvEng Engine detailed functions description 6 ADV_HLD.2 High-Level Design EAL3 Design Documentation CA eTrustTM Access Control r8 for Windows DrvEng Engine detailed functions description 7 ADV_RCR.1 Representation Correspondence EAL3 Design Documentation CA eTrustTM Access Control r8 for Windows DrvEng Engine detailed functions description 8 AGD_ADM.1 Administrator Guidance eTrust TM Access Control for Windows Administrator Guide r8 eTrustTM Access Control for Windows Reference Guide r8 CA eTrust TM Access Control for Windows r8 Common Criteria Supplement to the Guidance Documentation 9 AGD_USR.1 N/A Vacuously satisifed. All users of the TOE perform an administrative function.12 10 ALC_DVS.1 Development Security Documentation CA Development Security Procedures Manual 11 ATE_COV.2 Test Coverage Analysis eTrust Access Control (AC) for Windows Test Cases EAL3 12 ATE_DPT.1 Depth of Testing analysis eTrust Access Control (AC) for Windows Test Cases EAL3 13 ATE_FUN.1 Test Documentation eTrust Access Control (AC) for Windows Test Cases EAL3 CA QA test plan documents 14 ATE_IND.2 TOE for Testing TOE for Testing 15 AVA_MSU.1 Misuse Analysis eTrust TM Access Control for Windows Administrator Guide r8 eTrustTM Access Control for Windows Reference Guide r8 CA eTrust TM Access Control for Windows r8 Common Criteria Supplement to the Guidance Documentation 16 AVA_SOF.1 SOF Analysis This ST Section 6.2 17 AVA_VLA.1 Vulnerability Analysis eTrust TM Access Control r8 Vulnerability Analysis 12 Per PD0106, AGD_USR.1 is vacuously satisfied. 45 7 PP Claims The CA Access Control Security Target was not written to address any existing Protection Profile. 46 8 Rationale 8.1 Security Objectives Rationale 8.1.1 Threats to Security Table 8-1 shows that all the identified threats to security are countered by Security Objectives for the TOE. Table 8-1 All Threats to Security Countered Item Threat Name Threat Description Security Objective 1 T.Access An authorized user of the TOE may access information or resources without having permission from the person who owns, or is responsible for, the information or resource. O.AccessControl O.SecurityAttr OE.IDAuth 2 T.Bypass An attacker may attempt to bypass TSF security functions to gain unauthorized access to TSF. O.NonBypass O.PartialDomainSep OE.NonBypassSupport OE.DomainSepSupport 3 T.Mismanage Administrators may make errors in the management of security functions and TSF data, if administrator tools are not provided thus allowing attackers to gain unauthorized access to resources protected by the TOE. O.Admin O.Roles 4 T.Undetect Attempts by an attacker to violate the CA Access Control Policy may go undetected. If the attacker is successful, TSF data may be lost or altered. O.Audit OE.Time T.Access: An authorized user of the TOE may access information or resources without having permission from the person who owns, or is responsible for, the information or resource. T.Access is countered by: o O.AccessControl: The TOE must control user access to selected resources in accordance with the set of rules defined by the CA Access Control Policy. This objective counters the threat by providing access controls that limit the actions an individual is authorized to perform. o O.SecurityAttr: The TOE must be able to assign, store and maintain security attributes for users and selected resources. This objective counters the threat by providing for the attributes that associate accessors and resources with the access privileges on which the CA Access Control Policy is based. o OE.IDAuth: The IT environment must be able to identify and authenticate users prior to allowing access to the operating system of the host platform. This objective counters the threat by providing for the identification and authentication of users prior to any user data access or TSF data access so that the CA Access Control Policy can be enforced. 47 T.Bypass: An attacker may attempt to bypass TSF security functions to gain unauthorized access to TSF. T.Bypass is countered by: o O.NonBypass: The TOE must ensure the security enforcing functions are invoked and succeed before allowing a TOE function to proceed. This objective counters this threat by ensuring the TOE’s protection mechanisms cannot be bypassed, which requires that TSF security functions not be bypassable. o O.PartialDomainSep: 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. This objective addresses this threat by providing TOE self- protection and separation between users. The TOE will maintain separation between code executing on behalf of different users. o OE.NonBypassSupport: The IT environment will provide an isolated domain for execution of the TOE and will ensure that the TOE security mechanisms cannot be bypassed in order to gain access to TOE security functions and data. o OE.DomainSepSupport: The IT environment will provide an isolated domain for execution of the TOE. T.Mismanage: Administrators may make errors in the management of security functions and TSF data, if administrator tools are not provided thus allowing attackers to gain unauthorized access to resources protected by the TOE. T.Mismanage is countered by: o O.Admin: The TOE must provide the functionality to enable an authorized administrator to effectively manage the TOE and its security functions. This objective counters the threat by providing the administrative tools which make it easier for administrators to correctly manage the TOE. o O.Roles: The TOE must support multiple user roles. This objective counters the threat by providing for multiple roles which can be used to enforce separation of duty depending on the level of training and trust of the user. T.Undetect: Attempts by an attacker to violate the CQ Access Control Policy may go undetected. If the attacker is successful, TSF data may be lost or altered. T.Undetect is countered by: o O.Audit: The TOE must record audit records for data accesses and use of the system functions. This objective counters the threat by ensuring the recording of all security significant events, so that counter measures may be taken if there is evidence of an attack. o OE.Time: The IT environment must provide reliable time stamps. This objective counters the threat by providing for a reliable way to correlate audit records to reconstruct a potential compromise. 48 8.1.2 Assumptions Table 8-2 shows that all of the secure usage assumptions are addressed by either security objectives for the IT environment or Non-IT security objectives. Table 8-2 All Assumptions Addressed Item Name Assumption Objective 1 A.Admin The administrator is trusted to correctly install, configure and operate the TOE according to the instructions provided by the TOE documentation and procedures developed by the organization deploying the TOE. These administrators will be trained to manage and operate the system in a secure manner. ON.Install ON.Person ON.Operations 2 A.Physical The processing resources of the TOE will be located within controlled access facilities, which will prevent unauthorized physical access. ON.Physical A.Admin: The administrator is trusted to correctly install, configure, and operate the TOE according to the instructions provided by the TOE documentation. A.Admin is covered by: o ON.Install: Those responsible for the TOE must ensure that the TOE is delivered, installed, and configured in a manner that maintains IT security. Installing the TOE in a manner that maintains IT security includes correctly configuring the TOE. This objective provides for secure installation and configuration of the TOE. o ON.Person: Personnel working as authorized administrators shall be carefully selected and trained for proper operation of the system. This objective ensures that trusted personnel will be responsible for maintaining the security of the system. o ON.Operations: There must be procedures in place in order to ensure that the TOE will be managed and operated in a secure manner. The procedures will provide guidance to the administrator on how to securely operate the TOE. This objective provides for operation procedures to be in place. A.Physical: The processing resources of the TOE will be located within controlled access facilities, which will prevent unauthorized physical access. A.Physical is covered by: o ON.Physical: Those responsible for the TOE must ensure that those parts of the TOE critical to enforcing the CA Access Control Policy are protected from any physical attack. This objective provides physical security for the TOE. Table 8-3 Mapping of Security Objectives for the Environment to Threats and Assumptions Item Objective Name Threat/Policy/Assumption 1E OE.IDAuth T.Access 2E OE.Time T.Undetect 3E OE.NonBypassSupport T.Bypass 4E OE.DomainSepSupport T.Bypass 49 Item Objective Name Threat/Policy/Assumption 1N ON.Install A.Admin 2N ON.Operations A.Admin 3N ON.Physical A.Physical 4N ON.Person A.Admin 8.2 Security Requirements Rationale 8.2.1 Functional Requirements The table below shows that all of the security objectives of the TOE are satisfied. Table 8-4 All Objectives Met by Functional Components Item Objective Objective Description SFR 1 O.AccessControl The TOE must control user access to selected resources in accordance with the set of rules defined by the CA Access Control Policy. FAU_SAR.2 FAU_STG.1 FDP_ACC.1 FDP_ACF.1 FMT_MOF.1 FTA_TSE.1 2 O.Admin The TOE must provide the functionality to enable an authorized administrator to effectively manage the TOE and its security functions. FAU_SAR.1 FAU_SAR.3 FMT_MTD.1 FMT_SMF.1 3 O.Audit The TOE must record audit records for data accesses and use of the system functions. FAU_GEN.1 FAU_GEN.2 FAU_SEL.1 4 O.NonBypass The TOE must ensure the security enforcing functions are invoked and succeed before allowing a TOE function to proceed. FPT_RVM_EXP.1 5 O.PartialDomainSep 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. FPT_SEP_EXP.1 6 O.Roles The TOE must support multiple user roles. FMT_SMR.1 7 O.SecurityAttr The TOE must be able to assign, store and maintain security attributes for users and selected resources. FIA_ATD.1 FMT_MSA.1 FMT_MSA.3-1 FMT_MSA.3-2 O.AccessControl: The TOE must control user access to selected resources in accordance with the set of rules defined by the CA Access Control Policy. O.AccessControl is addressed by: 50 • FAU_SAR.2: Restricted audit review, which requires that access to the audit data be restricted to authorized users. • FAU_STG.1: Protected audit trail storage, which requires that the audit log be protected from unauthorized deletion and modifications. • FDP_ACC.1: Subset access control, which requires that the TSF enforce access controls on operations between subjects and objects covered by the access control SFP. • FDP_ACF.1: Security attribute based access control, which requires the TSF enforce access controls based on specified security attributes. In addition, the TSF can explicitly authorize and deny access to specified subjects. • FMT_MOF.1: Management of security functions behavior, which restricts the ability to disable, enable, and modify the audit functions to authorized users. • FTA_TSE.1: TOE session establishment, which restricts the ability of users to gain access to the TOE and TOE protected resources based on date and time. O.Admin: The TOE must provide the functionality to enable an authorized administrator to effectively manage the TOE and its security functions. O.Admin is addressed by: • FAU_SAR.1: Audit review, which requires that the auditor be able to read and interpret the audit records. • FAU_SAR.3: Selectable audit review, which requires that the TSF will provide the ability to search the audit data. • FMT_MTD.1: Management of TSF data, which specifies the management of TSF Data according to assigned roles. • FMT_SMF.1: Specification of management functions, which requires the TSF be capable of performing the specified security management functions. O.Audit: The TOE must record audit records for data accesses and use of the system functions. O.Audit is addressed by: • FAU_GEN.1: Audit data generation, which requires the ability to audit specified events. • FAU_GEN.2: User identity association, which requires the ability to associate an auditable event with a specific user. • FAU_SEL.1: Selective audit, which requires that the TSF provide the ability to include or exclude events from the audit data depending on administrator selected attributes. O.NonBypass: The TOE must ensure the security enforcing functions are invoked and succeed before allowing a TOE function to proceed. O.NonBypass is addressed by: • FPT_RVM_EXP.1: Non-bypassability of the TSP, which requires that TSP enforcement functions are invoked and succeed before a security-relevant function is allowed to proceed. 51 O.PartialDomainSep: 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.PartialDomainSep is addressed by: • FPT_SEP_EXP.1: TSF domain separation, which requires that the TSF protect itself from interference and tampering by attackers who gain access to the TOE through its own security interface and also requires that the TSF must protect users and processes from each other. O.Roles: The TOE must support multiple user roles. O.Roles is addressed by: • FMT_SMR.1 Security roles, which defines the user roles that the TSF maintains. O.SecurityAttr: The TOE must be able to assign, store and maintain security attributes for users and selected resources. O.SecurityAttr is addressed by: • FIA_ATD.1 User attribute definition, which defines the user attributes that the TSF maintains. • FMT_MSA.1 Management of security attributes, which defines the security attributes of users and resources in the TOE, the functions that can operate on them and the user roles that may use those functions. • FMT_MSA.3-1 Static attribute initialization - restrictive, which requires the TSF enforce discretionary access control for specified default values of security attributes. • FMT_MSA.3-2 Static attribute initialization - permissive, which requires the TSF enforce daytime restrictions and label access control for specified default values of security attributes. 8.2.2 Dependencies The following tables show the dependencies between the functional requirements. All dependencies are satisfied. Dependencies that are satisfied by a hierarchical component are denoted by an (H) following the dependency reference. 52 Table 8-5 TOE Dependencies Satisfied No. Component Component Name Dependencies Reference 1 FAU_GEN.1 Audit data generation FPT_STM.1 3E 2 FAU_GEN.2 User identity association FAU_GEN.1 FIA_UID.1 1 2E (H) 3 FAU_SAR.1 Audit review FAU_GEN.1 1 4 FAU_SAR.2 Restricted audit review FAU_SAR.1 3 5 FAU_SAR.3 Selectable audit review FAU_SAR.1 3 6 FAU_SEL.1 Selective audit FAU_GEN.1 FMT_MTD.1 1 14 7 FAU_STG.1 Protected audit trail storage FAU_GEN.1 1 8 FDP_ACC.1 Subset access control FDP_ACF.1 9 9 FDP_ACF.1 Security attribute based access control FDP_ACC.1 FMT_MSA.3 8 13, 20 10 FIA_ATD.1 User attribute definition None None 11 FMT_MOF.1 Management of security functions behavior FMT_SMR.1 FMT_SMF.1 16 15 12 FMT_MSA.1 Management of security attributes FDP_ACC.1 FMT_SMR.1 FMT_SMF.1 8 16 15 13 FMT_MSA.3-1 Static attribute initialization - restrictive FMT_MSA.1 FMT_SMR.1 12 16 14 FMT_MTD.1 Management of TSF data FMT_SMR.1 FMT_SMF.1 16 15 15 FMT_SMF.1 Specification of management functions None None 16 FMT_SMR.1 Security roles FIA_UID.1 2E (H) 17 FPT_RVM_EXP.1 Partial Non-bypassability of the TSP None None 18 FPT_SEP_EXP.1 Partial TSF domain separation None None 19 FTA_TSE.1 TOE session establishment None None 20 FMT_MSA.3-2 Static attribute initialization - permissive FMT_MSA.1 FMT_SMR.1 12 16 Table 8-6 IT Environment Dependencies are Satisfied No. Component Component Name Dependencies Reference 1E FIA_UAU.2 User authentication before any action FIA_UID.1 2E (H) 2E FIA_UID.2 User identification before any action None None 3E FPT_STM.1 Reliable time stamps None None 4E FPT_RVM_ENV.1 Environment Non-bypassability of the TSP None None 5E FPT_SEP_ENV.1 Environment TSF domain separation None None 53 8.2.3 Strength of Function Rationale There are no SOF Claims, since there are no probabilistic or permutational mechanisms included in the TOE. 8.2.4 Assurance Rationale Evaluation Assurance Level (EAL) 3 was chosen because it provides appropriate assurance measures for the expected application of the product. EAL3 was selected because the TOE requires a moderate level of independently assured security and requires a thorough investigation of the TOE and its development without substantial re-engineering. 8.2.5 Rationale that the IT Security Requirements are Internally Consistent The IT Security Requirements are internally consistent. There are no requirements that conflict with one another. When different IT security requirements apply to the same event, operation, or data there is no conflict between the security requirements. The requirements mutually support each other to apply to the event, operation, or data. For auditing, each of the SFRs build on the others. For example, FAU_SAR.1 states that the TSF shall provide authorized personnel with the capability to read all audit information from the audit records. FAU_SAR.2 builds on FAU_SAR.1 by stating the TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access. FAU_SAR.3 allows for easier interpretation of the audit data. FAU_STG.1 further protects the audit data from unauthorized deletion or modification. FAU_GEN.1 and FAU_GEN.2 specifies the information that will be recorded, while FAU_SEL.1 allows for the recording of only the events that are considered the most significant. Together FDP_ACC.2 and FDP_ACF.1 provide User Data Protection by defining the CA Access Control Policy. They specify that the TSF controls user access to controlled resources based upon rules and security attributes. These requirements are supported by FIA_ATD.1 which specifies the user attributes needed to enforce the policy. User data protection is further enhanced by FTA_TSE.1 which can be used to limit when a user may log on to a TOE protected system. The management requirements (FMT_) are related to many of the mechanisms involved with other requirements. FMT_MSA.1 enforces the CA Access Control Policy (FDP_ACC.2). These management requirements specify the security functions (FMT_SMF.1), the behavior of those functions (FMT_MOF.1), how they operate on TSF data (FMT_MTD.1, FMT_MSA.1, and FMT_MSA.2) and who may use the functions (FMT_SMR.1). In many cases, the other mechanisms will enforce the settings made through management functions. Installation mechanisms (see ADO_IGS.1) rely on management functions. The administrator guidance (see AGD_ADM) documents the management functions. Rationale for the protection of the TOE security functional requirements is given in Section 8.2.7. 8.2.6 Requirements for the IT Environment The following table shows that all of the security objectives for the IT environment are satisfied. 54 Table 8-7 All Objectives for the IT Environment Met by Requirements ItemObjective Objective Description Item IT Environment Requirement Component Title 1E OE.IDAuth The IT environment must be able to identify and authenticate users prior to allowing access to the operating system of the host platform. 1E 2E FIA_UAU.2 FIA_UID.2 User authentication before any action. User identification before any action. 2E OE.Time The underlying operating system must provide reliable time stamps. 3E FPT_STM.1 Reliable time stamps 3E OE.NonBypassSupport The IT environment must ensure that the TOE security mechanisms cannot be bypassed in order to gain access to TOE security functions and data. 4E FPT_RVM_ENV.1 Environment Non- bypassability of the TSP 4E OE.DomainSepSupport The IT environment must provide an isolated domain for the execution of the TOE. 5E FPT_SEP_ENV.1 Environment TSF Domain Separation OE.Time: The underlying operating system must provide reliable time stamps. OE.Time is addressed by: • FPT_STM.1: Reliable time stamps, which requires that time stamps be provided by the IT environment. OE.IDAuth: The IT environment must be able to identify and authenticate users prior to allowing access to the operating system of the host platform. OE.IDAuth is addressed by: • FIA_UAU.2: User authentication before any action, which requires that the IT environment authenticate users before allowing them access to the TOE. • FIA_UID.2: User identification before any action, which requires that the IT environment identify users before allowing them access to the TOE. OE.DomainSepSupport: The IT environment must provide an isolated domain for the execution of the TOE. OE.DomainSepSupport is addressed by: • FPT_SEP_ENV.1: Environment TSF Domain Separation, which requires that the IT environment provide an isolated domain for the TOE to execute within . 55 OE.NonBypassSupport: The IT environment must ensure that the TOE security mechanisms cannot be bypassed in order to gain access to TOE security functions and data. OE.NonBypassSupport is addressed by: • FPT_RVM_ENV.1: Environment Non-bypassability of the TSP, which requires that the IT environment ensures that the TOE will not be bypassed. 8.2.7 Protection of the TOE Rationale Protection of the TOE is provided by the FPT_RVM_EXP (partial non-bypassability of the TSP) and FPT_SEP_EXP (partial TSF domain separation) requirements. CA Access Control relies upon the same functionality it uses to protect user data to protect its own program executables, files, and data structures. For example, the ACW database REGISTRY class is used to protect critical entries in the Windows Registry from unauthorized modification. Vital TSF and system services can be prevented from being killed by use of the PROCESS class. In addition, the Watchdog, Engine and Agent services provide continuous protection of the ACW services. The CA Access Control security functions start automatically and cannot be bypassed. The security attributes of a user are checked upon session establishment. CA Access Control intercepts Windows system calls before they are processed and performs the appropriate security functionality based checks. Every request to perform a critical operating system command is intercepted and not acted upon until the CA Access Control Policy security checks have been performed and passed. 8.2.8 Explicitly Stated Security Requirements Rationale The ST includes four explicitly stated security requirements. FPT_SEP_EXP.1 was explicitly stated because the FPT_SEP SFR from CC Part 2 cannot be completely satisfied by an application TOE. FPT_SEP_EXP.1 defines the separation that can be performed by the TOE (applications). FPT_RVM_EXP.1 was explicitly stated because the FPT_RVM SFR from CC Part 2 is not completely satisfied by the TOE. FPT_RVM_EXP.1 defines the non-bypassability that is performed by the TOE. FPT_SEP_ENV.1 was explicitly stated because the FPT_SEP SFR from CC Part 2 cannot be completely satisfied by an application TOE. FPT_SEP_ENV.1 defines the separation that is performed by the IT environment. FPT_RVM_ENV.1 was explicitly stated because the FPT_RVM SFR from CC Part 2 is not completely satisfied by the TOE. FPT_RVM_ENV.1 defines the non-bypassability that is performed by the IT environment. 56 8.3 TOE Summary Specification Rationale 8.3.1 IT Security Functions The following table shows that the IT Security Functions in the TOE Summary Specification (TSS) address all of the TOE Security Functional Requirements. Table 8-8 Mapping of Functional Requirements to TOE Summary Specification Item Functional Component Functional Requirement Security Function Rationale 1 FAU_GEN.1 Audit data generation AI-SA-1 AI-SA-2 Specifies the types of events to be audited. Specifies the information to be recorded in an audit record. 2 FAU_GEN.2 User identity association AI-SA-3 Specifies that each auditable event is associated with the identity of the user that caused the event. 3 FAU_SAR.1 Audit review AI-SA-4 Specifies that the audit records can be read and understood. 4 FAU_SAR.2 Restricted audit review AI-SA-5 Specifies that only specific users have read access to the audit records. 5 FAU_SAR.3 Selectable audit review AI-SA-6 Specifies CA Access Control provides the ability to perform searches of the audit data, based on various criteria. 6 FAU_SEL.1 Selective audit AI-SA-7 Specifies CA Access Control is able to include or exclude auditable events from the set of audited events based on designated attributes. 7 FAU_STG.1 Protected audit trail storage AI-SA-8 Specifies that CA Access Control is able to protect the stored audit records from unauthorized deletion and prevent modifications to the audit records. 8 FDP_ACC.1 Subset access control AI-MUA-1 Specifies the subjects, objects and operations controlled under the CA Access Control User Access Policy. 9 FDP_ACF.1 Security attribute based access control AI-MUA-2 Specifies rules and attributes used to define the CA Access Control User Access Policy. 10 FIA_ATD.1 User attribute definition AI-UI-1 Specifies the security attributes maintained for each user. 11 FMT_MOF.1 Management of security functions behavior AI-SM-1 Specifies that CA Access Control restricts the ability to modify the audit functions. 12 FMT_MSA.1 Management of security attributes AI-SM-2 Specifies that CA Access Control restricts the ability to add, delete, modify and display security attributes. 13 FMT_MSA.3-1 Static attribute initialization - restrictive AI-SM-3 Specifies that CA Access Control provides restrictive default values for discretionary security attributes that can be overridden by authorized administrators. 14 FMT_MTD.1 Management of TSF data AI-SM-4 Specifies that CA Access Control restricts the ability to access TSF data. 15 FMT_SMF.1 Specification of management functions AI-SM-5 Specifies the security management functions provided by CA Access Control. 57 Item Functional Component Functional Requirement Security Function Rationale 16 FMT_SMR.1 Security roles AI-SM-6 Specifies the user roles maintained by CA Access Control. 17 FPT_RVM_EXP.1 Partial Non-bypassability of the TSP AI-TP-1 Specifies that CA Access Control ensures the CA Access Control Policy is invoked and succeeds before each function is allowed to proceed. 18 FPT_SEP_EXP.1 Partial Domain separation AI-TP-2 Specifies CA Access Control maintains a security domain for its own execution and enforces separation between security domains of users. 19 FTA_TSE.1 TOE session establishment AI-TSE-1 Specifies that users can be restricted from accessing the TOE by date and time. 20 FMT_MSA.3-2 Static attribute initialization – permissive AI-SM-7 Specifies that eTrustTM Access Control provides permissive default values for daytime restrictions and label security attributes that can be overridden by authorized administrators. 8.3.2 Assurance Measures The assurance measures rationale shows how all assurance requirements are satisfied. The rationale is provided in the table below. Table 8-9 Assurance Measures Rationale Item Component Evidence Requirements How Satisfied Rationale 1 ACM_CAP.3 CM Plan eTrust TM Access Control r8 CM Plan Describes the access controls used to control access to configuration items. Describes the roles of individuals authorized to make changes to source code configuration items. 2 ACM_SCP.1 TOE CM coverage Configuration Item List Lists: o source code files and version numbers o design documents with version numbers o test documents with version numbers o user and administrator documentation with version numbers 3 ADO_DEL.1 Delivery Procedures Distribution Centers Procedures Manual United States and Canada Preservation of Product Provides a description of all procedures that are necessary to maintain security when distributing Access Control software to the user’s site. Applicable across all phases of delivery from packaging, storage, distribution. 58 Item Component Evidence Requirements How Satisfied Rationale 4 ADO_IGS.1 Installation, generation, and start-up procedures eTrustTM Access Control for Windows Administrator Guide r8 eTrustTM Access Control for Windows Getting Started r8 CA eTrustTM Access Control for Windows r8 Common Criteria Supplement to the Guidance Documentation Provides detailed instructions on how to configure and install eTrustTM Access Control. 5 ADV_FSP.1 Informal Functional Specification EAL3 Design Documentation CA eTrustTM Access Control r8 for Windows DrvEng Engine detailed functions description Provides rationale that TSF is fully represented. Describes the TSF interfaces and TOE functionality. 6 ADV_HLD.2 High-Level Design EAL3 Design Documentation CA eTrustTM Access Control r8 for Windows DrvEng Engine detailed functions description Describes the TOE subsystems and their associated security functionality. 7 ADV_RCR.1 Representation Correspondence EAL3 Design Documentation CA eTrust TM Access Control r8 for Windows v1.0 DrvEng Engine detailed functions description Provides the following two dimensional mappings: o TSS and functional specification; o Functional specification and high-level design. 8 AGD_ADM.1 Administrator Guidance eTrustTM Access Control for Windows Administrator Guide r8 eTrustTM Access Control for Windows Reference Guide r8 CA eTrustTM Access Control for Windows r8 Common Criteria Supplement to the Guidance Documentation Describes how to administer the TOE securely. 9 AGD_USR.1 User Guidance N/A Vacuously satisified. All users of the TOE perform an administrative function 10 ALC_DVS.1 Development Security Documentation CA Development Security Procedures Manual Describes the physical, procedural, personnel, and other security measures necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment. 11 ATE_COV.2 Test Coverage Analysis eTrust Access Control (AC) for Windows Test Cases EAL3 Shows correspondence between the tests identified in the test documentation and the TSF as described in the functional specification. 12 ATE_DPT.1 Depth of Testing analysis eTrust Access Control (AC) for Windows Test Cases EAL3 Demonstrates that the TSF operates in accordance with its High-Level Design. 59 Item Component Evidence Requirements How Satisfied Rationale 13 ATE_FUN.1 Test Documentation eTrust Access Control (AC) for Windows Test Cases EAL3 CA QA test plan documents Test documentation includes test plans and procedures and expected and actual results. 14 ATE_IND.2 TOE for Testing TOE for Testing The TOE will be provided for testing. 15 AVA_MSU.1 Misuse Analysis eTrustTM Access Control for Windows Administrator Guide r8 eTrustTM Access Control for Windows Reference Guide r8 CA eTrustTM Access Control for Windows r8 Common Criteria Supplement to the Guidance Documentation The guidance documentation shall be analyzed and demonstrated to be complete. 16 AVA_SOF.1 SOF Analysis This ST Section 6.2 Provides a rationale that each mechanism identified in the ST as having an SOF meets or exceeds the minimum strength level specified there. 17 AVA_VLA.1 Vulnerability Analysis eTrustTM Access Control r8 Vulnerability Analysis Provide an analysis of the TOE deliverables for obvious ways in which a user can violate the TSP, including the disposition of obvious vulnerabilities. 8.4 PP Claims Rationale There are no PP claims; therefore this section is not applicable. 60 9 Acronyms ACL Access Control List CC Common Criteria [for IT Security Evaluation] EAL Evaluation Assurance Level GUI Graphical User Interface ID Identifier IT Information Technology NACL Negative Access Control List PACL Program Access Control List PMDB Policy Model Database PP Protection Profile SAR Security Assurance Requirement SF Security Function SFP Security Function Policy SFR Security Functional Requirement SOF Strength of Function ST Security Target TOE Target of Evaluation TSC TSF Scope of Control TSF TOE Security Functions TSFI TOE Security Functions Interface TSP TOE Security Policy 61 10 References CCITSE Common Criteria for Information Technology Security Evaluation, CCIMB- 2004-01-002, Version 2.2, January 2004. G006581E.pdf eTrustTM Access Control for Windows Administrator Guide r8 G006591E.pdf eTrustTM Access Control for Windows Getting Started r8 G006611E.pdf eTrustTM Access Control for Windows Reference Guide r8 G006621E.pdf eTrustTM Access Control for Windows Release Summary r8