WIXLIB

CACA Access Control r8 for WindowsSecurity TargetVersion 2.0Debra BakerDan DePrezMichelle RuppelJune 7, 2007Suite 5200 7925 Jones Branch Drive McLean, VA 22102 703 848-0883 Fax 703 848-0960

TABLE OF CONTENTSSECTIONPAGET1 Security Target Introduction. 121.1Security Target Identification.11.2Security Target Overview .11.3Common Criteria Conformance.21.4Document Organization .2TOE Description . 32.1Product Type .32.2The CA Access Control approach to Security .32.3CA Access Control sical Boundary and Scope of the Evaluation.6Included in TOE .7Excluded from TOE.82.5Logical Boundary.92.6TOE Security Environment .10TOE Security Environment. 113.1Assumptions.113.2Threats .11Security Objectives. 124.1Security Objectives for the TOE.124.2Security Objectives for the Environment .124.2.14.2.25CA Access Control Database.3CA Access Control Request Management Software .4CA Access Control Services.4CA Access Control Administrator Interfaces .6Security Objectives for the IT Environment .12Non-IT Security Objectives .13IT Security Requirements. 145.1Formatting Conventions.145.2TOE Security Functional Requirements.155.2.15.2.25.2.35.2.4Class FAU: Security Audit .16Class FDP: User Data Protection.18Class FIA: Identification and Authentication .26Class FMT: Security Management .26ii

5.2.55.2.6Class FPT: Protection of the TOE Security Functions.35Class FTA: TOE session establishment .365.3Strength of Function .365.4Security requirements for the IT Environment .36T5.5TOE Security Assurance Requirements .376TOE Summary Specification. 396.1IT Security Functions .396.1.16.1.2Overview .39CA Access Control Security Functions .396.2SOF Claims.436.3Assurance Measures .437PP Claims. 458Rationale . 468.1Security Objectives Rationale .468.1.18.1.28.2Security Requirements Rationale unctional Requirements .49Dependencies.51Strength of Function Rationale .53Assurance Rationale .53Rationale that the IT Security Requirements are Internally Consistent .53Requirements for the IT Environment .53Protection of the TOE Rationale.55Explicitly Stated Security Requirements Rationale .55TOE Summary Specification Rationale .568.3.18.3.28.4Threats to Security .46Assumptions .48IT Security Functions.56Assurance Measures .57PP Claims Rationale .59Acronyms. 60References . 61iii

Table of Tables and FiguresTable or FigurePageFigure 2-1 eTrustTM Access Control TOE Boundary.7Table 3-1 AssumptionsTable 3-2 ThreatsTable 4-1 Security Objectives for TOETable 4-2 Security Objectives for IT EnvironmentTable 4-3 Security Objectives for Non-IT Security ObjectivesTable 5-1 TOE Functional RequirementTable 5-2 eTrustTM Access Control Auditable EventsTable 5-3 eTrustTM Access Control Policy (Objects and Operations)Table 5-4 eTrustTM Access Control Policy (Security Attributes)Table 5-5 eTrustTM Access Control Policy (Controlled Operation Access Rules)Table 5-6 eTrustTM Access Control Policy (Label Access Rules)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)Table 5-10 TSF Data (Resource Class Security Attributes)Table 5-11 TOE Security FunctionsTable 5-12 TSF Security RolesTable 5-13 Functional Requirement for the IT environmentTable 5-14 Assurance Requirements: EAL3Table 6-1 Security Functional Requirements mapped to Security FunctionsTable 6-2 Security Audit FunctionTable 6-3 Manage User Access FunctionTable 6-4 User Identification FunctionTable 6-5 Security Management FunctionTable 6-6 TSF Protection FunctionTable 6-7 TOE Session Establishment FunctionTable 6-8 Assurance Measures and How SatisfiedTable 8-1 All Threats to Security CounteredTable 8-2 All Assumptions AddressedTable 8-3 Mapping of Security Objectives for the Environment to Threats and AssumptionsTable 8-4 All Objectives Met by Functional ComponentsTable 8-5 TOE Dependencies SatisfiedTable 8-6 IT Environment Dependencies are SatisfiedTable 8-7 All Objectives for the IT Environment Met by RequirementsTable 8-8 Mapping of Functional Requirements to TOE Summary SpecificationTable 8-9 Assurance Measures 940414142434344464848495252545657

1 Security Target Introduction1.1Security Target IdentificationTOE Identification:CA Access Control for Windows 1 r8 with patch NT – 0604CUMULATIVE RELEASEST Title:CA Access Control r8 for WindowsSecurity TargetST Version:Version 2.0ST Authors:Debra Baker, Dan DePrez, Michelle RuppelST Date:June 7, 2007Assurance Level:EAL3Strength of Function:Not applicableVendor:CAVendor Address:6150 Oak Tree Blvd, Suite 100Park Center Plaza IIIndependence, OH 44131Registration: To be filled in upon registration Keywords:Access Control, Identification, Authentication, Authorization, SecurityTarget, and Security Management1.2Security Target OverviewThis Security Target (ST) defines the Information Technology (IT) security requirements for CAAccess Control for Windows version r8 with patch NT – 0604 CUMULATIVE RELEASE 2 . CAAccess Control is a security management application that regulates access to business assets byproviding 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 andsupports deployment of security policies to control access to selected resources on native operatingsystems.This document describes security aspects of the Windows version of CA Access Control only. TheUNIX version of CA Access Control is the subject of a separate evaluation.1Previously known as eTrust Access Control (eAC) for Windows.2For brevity, this product will be called the “eTrustTM Access Control for Windows version r8” in the remainderof the document.1

1.3Common Criteria ConformanceThe TOE is Part 2 extended, Part 3 conformant, and meets the requirements of EvaluationAssurance Level (EAL) 3 from the Common Criteria (CC) Version 2.2.1.4Document OrganizationThe main sections of an ST are the ST Introduction, Target of Evaluation (TOE) Description, TOESecurity 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 theTOE.Section 3, TOE Security Environment, identifies assumptions about the TOE’s intended usage andenvironment 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 AssuranceMeasures.Section 7, Protection Profile (PP) Claims, is not applicable, as this product does not claimconformance to any PP.Section 8, Rationale presents evidence that the ST is a complete and cohesive set of requirementsand that a conformant TOE would provide an effective set of IT security countermeasures within thesecurity environment. The Rationale has three main parts: Security Objectives Rationale, SecurityRequirements Rationale, and TOE Summary Specification Rationale.Sections 9 and 10 provide the acronym definitions and references.2

2 TOE DescriptionThis section describes the Windows version of CA Access Control only. The UNIX version of CAAccess Control is the subject of a separate evaluation.2.1Product TypeCA Access Control is a security management application that regulates access to business assetsby providing policy-based control of who can access specific systems and resources, what they cando within them, and when they are allowed access. Policies can be created, managed, anddistributed on an enterprise-wide basis, or customized to meet the security requirements of specificapplications.2.2The CA Access Control approach to SecurityThe main security service provided by CA Access Control (ACW) is the enforcement of accesscontrols. CA Access Control maintains information on users and the resources they can access. Itprovides a single interface for administrators to grant, manage, and revoke user access privileges.Security AttributesRecords defining accessors (users of ACW controlled resources) and resources in the AccessControl database can be assigned a security level, a security label and/or a security category.Access Control ListAn Access Control List (ACL) is a specific list of the accessors authorized to access a protectedresource and the exact access they can have. An ACL can be used to define the access rulesfor a particular resource.CA Access Control allows authorized administrators 3 to define a security policy that uses thesecurity attributes, access control lists, and access rules to grant or deny access to selectedresources for each accessor.2.3CA Access Control ComponentsCA Access Control is comprised of a database, request management software, a number ofservices, and an administrator interface.2.3.1CA Access Control DatabaseThe ACW Database contains definitions of:3The term “authorized administrator” in this ST includes multiple roles defined in the product. (See Table 5-12TSF Security Roles for more detail.) Refer to Section 5.2.4 for details on roles and separation of duty.3

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 resources2.3.2CA Access Control Request Management SoftwareThe 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 theEngine whether the request should be granted or denied. Forwards the decision to the original system call of the operating system, which thencontinues its processing based on the answer it received from the ACW kernel extension. .2.3.3CA Access Control ServicesWatchdogThe Watchdog service performs two functions: one to keep other services running and anotherto perform sensitive file integrity monitoring.The Watchdog constantly checks that the other CA Access Control services are running. If theWatchdog discovers that another service has stopped, it immediately starts it again.The sensitive file integrity monitoring performed by Watchdog checks the signature of trustedfiles, which includes secured files (SECFILE class) and programs (PROGRAM class). When adifference in one of the trusted files is discovered, the Watchdog updates the ACWAuthorization seos 4 Engine, marking the files as untrusted, and sends an audit record.Untrusted program files are not allowed to execute. This sensitive file integrity monitoringfunction is not in the evaluated configuration.AgentThe Agent service is responsible for: Communicating with CA Access Control clientsT 5 through a proprietary applicationprotocol above TCP/IP. Managing native security for the ACW user.Authorization Engine (seosdT 6 )4seos is the previous name of the product.CA Access Control clients refer to the Policy Manager, selang, or any other 3rd party application that usesthe LCA/seadmapi APIs for administration. Note that only selang is included in the TOE.54