Professional Documents
Culture Documents
Version 1.d
8 October 1999
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
8 October 1999
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
Foreword
This publication, Controlled Access Protection Prole, is issued by the Information Systems Security Organization (ISSO) as part of its program to promulgate security standards for information systems. This protection prole is based on the C2 class of the Department of Defense Trusted Computer System Evaluation Criteria (DOD 5200.28STD), and supersede that class for use in evaluations. The base set of requirements used in this protection prole are taken from the Common Criteria for Information Technology Security Evaluations, Version 2.0. Further information, including the status and updates, of both this protection prole and the Common Criteria can be found on the internet at http://www.radium.ncsc.mil/tpep. Comments on this document should be directed to: Protection Prole Registry (V13) National Security Agency 9800 Savage Road, Suite 6740 Ft. George G. Meade, MD 20755-6740
or
PPRegistry@gibraltar.ncsc.mil
or
(410) 854-4458
____________________________________________ Keith Brewster 8 October 1999 Chief Information Assurance Criteria Support
Version 1.d
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
Revision History
CAPP 1.0 - Based on version 1.0 of the Common Criteria. Also known as the C2 Protection Prole. CAPP 1.a - Completely revised version based on version 2.0 of the Common Criteria. CAPP 1.b - Major updates to the policy and objective sections. Also both pre and post selection of audit events were included. LSPP 1.0 - Baseline version, derived from CAPP 1.b. CAPP 1.c - Changes based on comments from external review of the document. Changes include: Reformatting the list of audit events into a table; FAU_STG.2 was changed to FAU_STG.1; Security-relevant authorizations were moved to roles section. The O.ENFORCEMENT objective was claried.
LSPP 1.a - Updates include all those made for CAPP 1.c, plus the following: Management of MAC related attributes added.
8 October 1999
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
Table of Contents
Foreword Table of Contents 1.0 1.1 1.2 1.3 1.4 1.5 2.0 3.0 3.1 3.2 3.3
3.3.1 3.3.2 3.3.3
3 5 9 9 9 9 9 10 13 15 15 15 15
15 16 16
Introduction Identication Overview Strength of Environment Conventions Terms TOE Description Security Environment Threats Organizational Security Policies Security Usage Assumptions
Physical Assumptions Personnel Assumptions Connectivity Assumptions
Security Objectives IT Security Objectives Non-IT Security Objectives Functional Requirements Security Audit (FAU)
Audit Data Generation (FAU_GEN.1) User Identity Association (FAU_GEN.2) Audit Review (FAU_SAR.1) Restricted Audit Review (FAU_SAR.2) Selectable Audit Review (FAU_SAR.3) Selective Audit (FAU_SEL.1) Guarantees of Audit Data Availability (FAU_STG.1) Action in Case of Possible Audit Data Loss (FAU_STG.3) Prevention of Audit Data Loss (FAU_STG.4)
17 17 17 19 19
19 21 21 22 22 22 22 23 23
5.2
5.2.1 5.2.2 5.2.3 5.2.4
23
23 24 25 25
5.3
5.3.1 Version 1.d
25
25 8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 Information Systems Security Organization 26 26 27 27 27
Strength of Authentication Data (FIA_SOS.1) Authentication (FIA_UAU.1) Protected Authentication Feedback (FIA_UAU.7) Identication (FIA_UID.1) User-Subject Binding (FIA_USB.1)
5.4
5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6 5.4.7 5.4.8 5.4.9
28
28 29 29 29 30 30 30 31 31
5.5
5.5.1 5.5.2 5.5.3 5.5.4
32
32 32 32 33
6.0 6.1
6.1.1 6.1.2
35 35
35 35
6.2
6.2.1 6.2.2
36
36 36
6.3
6.3.1 6.3.2 6.3.3
Development (ADV)
Functional Specication (ADV_FSP.1) High-Level Design (ADV_HLD.2) Correspondence Demonstration (ADV_RCR.1)
37
37 37 38
6.4
6.4.1 6.4.2
38
38 39
6.5
6.5.1
40
40
6.6
6.6.1 6.6.2 6.6.3 6.6.4
40
40 40 41 41
8 October 1999
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
6.7
6.7.1 6.7.2 6.7.3
41
41 42 42
7.0 7.1
7.1.1 7.1.2 7.1.3
45 45
45 45 46
7.2
7.2.1 7.2.2
46
46 46
Dependencies Rationale for Assurance Rating Rational for SOF Rating Notes on Deviations
49 50 50 51
Version 1.d
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
8 October 1999
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
1.0
Introduction
This section contains document management and overview information necessary to allow a Protection Prole (PP) to be registered through a Protection Prole Registry. The PP identication provides the labelling and descriptive information necessary to identify, catalogue, register, and cross-reference a PP. The PP overview summarizes the prole in narrative form and provides sufcient information for a potential user to determine whether the PP is of interest. The overview can also be used as a standalone abstract for PP catalogues and registers. The conventions section provides an explanation of how this document is organized and the terms section gives a basic denition of terms which are specic to this PP.
1.1
Identication
Title: Controlled Access Protection Prole (CAPP) Registration: Information Systems Security Organization (ISSO) Keywords: access control, discretionary access control, general-purpose operating system, information protection
1.2
Overview
The Common Criteria (CC) Controlled Access Protection Prole, hereafter called CAPP, species a set of security functional and assurance requirements for Information Technology (IT) products. CAPPconformant products support access controls that are capable of enforcing access limitations on individual users and data objects. CAPP-conformant products also provide an audit capability which records the security-relevant events which occur within the system. The CAPP provides for a level of protection which is appropriate for an assumed non-hostile and wellmanaged user community requiring protection against threats of inadvertent or casual attempts to breach the system security. The prole is not intended to be applicable to circumstances in which protection is required against determined attempts by hostile and well funded attackers to breach system security. The CAPP does not fully address the threats posed by malicious system development or administrative personnel. CAPP-conformant products are suitable for use in both commercial and government environments. The CAPP was derived from the requirements of the C2 class of the U.S. Department of Defense (DoD) Trusted Computer System Evaluation Criteria (TCSEC), dated December, 1985, and the material upon which those requirements are based. This protection prole provides security functions and assurances which are equivalent to those provided by the TCSEC and replaces the requirements used for C2 trusted product evaluations. The CAPP is generally applicable to distributed systems but does not address the security requirements which arise specically out of the need to distribute the resources within a network.
1.3
Strength of Environment
The CAPP is for a generalized environment with a moderate level of risk to the assets. The assurance requirements and the minimum strength of function were chosen to be consistent with that level of risk. The assurance level is EAL 3 and the minimum strength of function is SOF-medium.
1.4
Conventions
This document is organized based on Annex B of Part 1 of the Common Criteria. There are several deviations in the organization of this prole. First, rather than being a separate section, the application notes have been integrated with requirements and indicated as notes. Likewise, the rationale has been Version 1.d 9 8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile integrated where appropriate. For each component, an application note may appear. Application notes document guidance for how the requirement is expected to be applied. For additional guidance, the CC itself should be consulted. Following the application note is rationale for the inclusion of the component in the requirement set. In the requirement sections, each section which represents a requirement family or component, there is a mnemonic in parenthesis. These refer to the requirement section in the CC from which it was derived. Requirement elements have these references includes as superscripted text at the end of the element. In some places these references indicate a note instead. These notes represent components or elements which do not appear in the CC, and an explanation can be found in section 8.0 of this prole. The superscripted text which appears in the audit event list in 5.1.1.1 is cross referenced to the functional requirement component in this prole upon which that event was derived. Information Systems Security Organization
1.5
Terms
This prole uses the following terms which are described in this section to aid in the application of the requirements: User Authorized User Authorized Administrator Discretionary Access Control (DAC) Policy Mediation Access Authorization
A user is an individual who attempts to invoke a service offered by the TOE. An authorized user is a user who has been properly identied and authenticated. These users are considered to be legitimate users of the TOE. An authorized administrator is an authorized user who has been granted the authority to manage the TOE. These users are expected to use this authority only in the manner prescribed by the guidance given them. The Discretionary Access Control Policy, also referred to as DAC, is the basic policy that a CAPP conformant TOE enforces over users and resources. Whether a user is granted a requested action is determined by the TOE Security Policy (TSP) which is specied in this prole in the context of Discretionary Access Control (DAC). The DAC policy is the set of rules used to mediate user access to TOE protected objects and can be generally characterized as a policy which requires the TOE to allow authorized users and authorized administrators to control access to objects based on individual user identication. When the DAC policy rules are invoked, the TOE is said to be mediating access to TOE protected objects. However, there may be instances when the DAC policy is not invoked meaning that there may be objects residing in the TOE which are not protected by the TSP. In these instances the TOE is said to not be mediating access to a set of objects even though the TOE is executing a (possibly unauthorized) user request. The DAC policy consists of two types of rules: those which apply to the behavior of authorized users (termed access rules) and those which apply to the behavior of authorized administrators (termed authorization rules). If an authorized user is granted a request to operate on an object, the user is said to have access to that object. There are numerous types of access; typical ones include read access and write access which allow the reading and writing of objects respectively. If an authorized administrator is granted a requested service, the user is said to have authorization to the requested service or object. As for access, there are numerous possible authorizations. Typical authorizations include auditor authorization which allows an administrator to view audit records and execute audit tools and DAC override authorization which allows an administrator to override object access controls 8 October 1999 10 Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization to administer the system. Controlled Access Protection Profile
Version 1.d
11
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
8 October 1999
12
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
2.0
TOE Description
The CAPP denes a set of security requirements to be levied on Targets of Evaluation (TOEs). These TOEs include information systems which contain general-purpose operating systems, such as workstations, mainframes, or personal computers. These systems can be comprised of a single host or a set of cooperating hosts in a distributed system. Such systems permit one or more processors along with peripherals and storage devices to be used by multiple users to perform a variety of functions requiring controlled, shared access to the information stored on the system. Such installations are typical of personal, work group, or enterprise computing systems accessed by users local to, or with otherwise protected access to, the computer systems. The CAPP is applicable to TOEs that provide facilities for on-line interaction with users, as well as TOEs that provide for batch processing. The protection prole is also generally applicable to TOEs incorporating network functions but contains no network specic requirements. Networking is covered only to the extent to which the TOE can be considered to be part of a centrally-managed system that meets a common set of security requirements. The CAPP assumes that responsibility for the safeguarding of the data protected by the TOEs security functions (TSF) can be delegated to the TOE users. All data is under the control of the TOE. The data are stored in objects, and the TSF can associate with each controlled object a description of the access rights to that object. All individual users are assigned a unique identier. This identier supports individual accountability. The TSF authenticates the claimed identity of the user before allowing the user to perform any actions that require TSF mediation, other than actions which aid an authorized user in gaining access to the TOE.
Version 1.d
13
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
8 October 1999
14
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
3.0
3.1
Security Environment
Threats
The CAPP has derived all security objectives from the statement of Organizational Security Policy found in the following section. Therefore, there is no statement of the explicit threats countered by the CAPP.
3.2
An Organizational Security Policy is a set of rules or procedures imposed by an organization upon its operations to protect its sensitive data. Although the organizational security policies described below is drawn from DoD Manual 5200.28-M (Techniques and procedures for Implementing, Deactivating and Evaluating Resource Sharing ADP Systems) it applies to many non-DoD environments. P.AUTHORIZED_USERS Only those users who have been authorized to access the information within the system may access the system. P.NEED_TO_KNOW The system must limit the access to, modication of, and destruction of the information in protected resources to those authorized users which have a need to know for that information. P.ACCOUNTABILITY The users of the system shall be held accountable for their actions within the system.
3.3
This section describes the security aspects of the environment in which the TOE will be, or is intended to be used. This includes information about the physical, personnel, and connectivity aspects of the environment. A CAPP-conformant TOE is assured to provide effective security measures in a cooperative non-hostile environment only if it is installed, managed, and used correctly. The operational environment must be managed in accordance with assurance requirements documentation for delivery, operation, and user/administrator guidance. The following specic conditions are assumed to exist in an environment where CAPP-conformant TOEs are employed.
3.3.1
Physical Assumptions
CAPP-conformant TOEs are intended for application in user areas that have physical control and monitoring. It is assumed that the following physical conditions will exist: A.LOCATE The processing resources of the TOE will be located within controlled access facilities which will prevent unauthorized physical access. A.PROTECT The TOE hardware and software critical to security policy enforcement will be protected from unauthorized physical modication.
Version 1.d
15
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
3.3.2
Personnel Assumptions
It is assumed that the following personnel conditions will exist: A.MANAGE There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains. A.NO_EVIL_ADM The system administrative personnel are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the administrator documentation. A.COOP Authorized users possess the necessary authorization to access at least some of the information managed by the TOE and are expected to act in a cooperating manner in a benign environment.
3.3.3
Connectivity Assumptions
The CAPP contains no explicit network or distributed system requirements. However, it is assumed that the following connectivity conditions exist: A.PEER Any other systems with which the TOE communicates are assumed to be under the same management control and operate under the same security policy constraints. CAPP-conformant TOEs are applicable to networked or distributed environments only if the entire network operates under the same constraints and resides within a single management domain. There are no security requirements which address the need to trust external systems or the communications links to such systems. A.CONNECT All connections to peripheral devices reside within the controlled access facilities. CAPP-conformant TOEs only address security concerns related to the manipulation of the TOE through its authorized access points. Internal communication paths to access points such as terminals are assumed to be adequately protected.
8 October 1999
16
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
4.0
Security Objectives
This section denes the security objectives of the TSF and its supporting environment. Security objectives, categorized as either IT security objectives or non-IT security objectives, reect the stated intent to counter identied threats and/or comply with any organizational security policies identied. All of the identied threats and organizational policies are addressed under one of the categories below.
4.1
IT Security Objectives
The following are the CAPP IT security objectives: O.AUTHORIZATION The TSF must ensure that only authorized users gain access to the TOE and its resources. O.DISCRETIONARY_ACCESS The TSF must control accessed to resources based on identity of users. The TSF must allow authorized users to specify which resources may be accessed by which users. O.AUDITING The TSF must record the security relevant actions of users of the TOE. The TSF must present this information to authorized administrators. O.RESIDUAL_INFORMATION The TSF must ensure that any information contained in a protected resource is not released when the resource is recycled. O.MANAGE The TSF must provide all the functions and facilities necessary to support the authorized administrators that are responsible for the management of TOE security. O.ENFORCEMENT The TSF must be designed and implemented in a manner which ensures that the organizational policies are enforced in the target environment.
4.2
A CAPP-conformant TOE is assumed to be complete and self-contained and, as such, is not dependent upon any other products to perform properly. However, certain objectives with respect to the general operating environment must be met. The following are the CAPP non-IT security objectives: O.INSTALL Those responsible for the TOE must ensure that the TOE is delivered, installed, managed, and operated in a manner which maintains IT security objectives. O.PHYSICAL Those responsible for the TOE must ensure that those parts of the TOE critical to security policy are protected from physical attack which might compromise IT security objectives. O.CREDEN Those responsible for the TOE must ensure that all access credentials, such as passwords or other authentication information, are protected by the users in a manner which maintains IT security objecVersion 1.d 17 8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile tives. Information Systems Security Organization
8 October 1999
18
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
5.0
Functional Requirements
This chapter denes the functional requirements for the TOE. Functional requirements components in this prole were drawn from Part 2 of the CC. Some functional requirements are extensions to those found in the CC. CC dened operations for assignment, selection, and renement were used to tailor the requirements to the level of detail necessary to meet the stated security objectives. These operations are indicated through the use of underlined (assignments and selections) and italicized (renements) text. All required operations not performed within this prole are clearly identied and described such that they can be correctly performed upon instantiation of the PP into a Security Target (ST) specication.
5.1
5.1.1
5.1.1.1
5.1.1.2
a)
Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event;
b)
The additional information specied in the Details column of Table 1 (Auditable Events).
Application Note: For some situations it is possible that some events cannot be automatically generated. This is usually due to the audit functions not being operational at the time these events occur. Such events need to be documented in the Administrative Guidance, along with recommendation on how manual auditing should be established to cover these events. Rationale: This component supports O.AUDITING by specifying the detailed, securityrelevant events and data that the audit mechanism must be capable of generating and recording. The basic level of auditing was selected as best representing the mainstream of contemporary audit practices used in the target environments.
Component
FAU_GEN.1 FAU_GEN.2 FAU_SAR.1 FAU_SAR.2 FAU_SAR.3
Event
Start-up and shutdown of the audit functions. None Reading of information from the audit records. Unsuccessful attempts to read information from the audit records. None
Details
Version 1.d
19
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
Component
FAU_SEL.1
Event
All modications to the audit conguration that occur while the audit collection functions are operating. None Actions taken due to exceeding of a threshold. Actions taken due to the audit storage failure. None All requests to perform an operation on an object covered by the SFP. None None None Rejection or acceptance by the TSF of any tested secret. All use of the authentication mechanism. None All use of the user identication mechanism, including the identity provided during successful attempts. Success and failure of binding user security attributes to a subject (e.g. success and failure to create a subject). All modications of the values of security attributes. Modications of the default setting of permissive or restrictive rules. All modications of the initial value of security attributes. All modications to the values of TSF data. All modications to the values of TSF data. All modications to the values of TSF data. All modications to the values of TSF data. All attempts to revoke security attributes. All modications to the values of TSF data. Modications to the group of users that are part of a role.
Details
5.1.7 5.1.8 5.1.9 5.2.1 5.2.2 5.2.3 5.2.4 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5
FAU_STG.2 FAU_STG.3 FAU_STG.4 FDP_ACC.1 FDP_ACF.1 FDP_RIP.2 Note 1 FIA_ATD.1 FIA_SOS.1 FIA_UAU.1 FIA_UAU.7 FIA_UID.1
5.3.6
FIA_USB.1
5.4.1 5.4.2
FMT_MSA.1 FMT_MSA.3
The new value of the TSF data. The new value of the TSF data.
8 October 1999
20
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
Component
FMT_SMR.1 FPT_AMT.1 FPT_RVM.1 FPT_SEP.1 FPT_STM.1
Event
Every use of the rights of a role. (Additional / Detailed) Execution of the tests of the underlying machine and the results of the test. None None Changes to the time.
Details
The role and the origin of the request.
5.1.2
5.1.2.1
5.1.3
5.1.3.1 5.1.3.2
Version 1.d
21
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
5.1.4
5.1.4.1
5.1.5
5.1.5.1
5.1.6
5.1.6.1
5.1.7
5.1.7.1 5.1.7.2
8 October 1999
22
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
Rationale: This component supports the O.AUDITING objective by protecting the audit trail from tampering, via deletion or modification of records in it. Further it ensures that it is as complete as possible.
5.1.8
5.1.8.1
5.1.9
5.1.9.1
5.2
5.2.1
5.2.1.1
Version 1.d
23
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
Rationale: This component supports the O.DISCRETIONARY_ACCESS objective by specifying the scope of control for the DAC policy.
5.2.2
5.2.2.1
5.2.2.2
The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: FDP_ACF.1.2 [assignment: a set of rules specifying the Discretionary Access Control policy, where: i) For each operation there shall be a rule, or rules, that use the permission attributes where the user identity of the subject matches a user identity specied in the access control attributes of the object; ii) For each operation there shall be a rule, or rules, that use the permission attributes where the group membership of the subject matches a group identity specied in the access control attributes of the object; and iii) For each operation there shall be a rule, or rules, that use the default permission attributes specied in the access control attributes of the object when neither a user identity or group identity matches.]
5.2.2.3
The TSF shall explicitly authorize access of subjects to objects based in the following additional rules: [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]. FDP_ACF.1.3 The TSF shall explicitly deny access of subjects to objects based on the [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]. FDP_ACF.1.4
Application Note: A CAPP conformant TOE is required to implement a DAC policy, but the rules which govern the policy may vary between TOEs; those rules need to be specified in the ST. In completing the rule assignment above, the resulting mechanism must be able to specify access rules which apply to at least any single user. This single user may have a special status such as the owner of the object. The mechanism must also support specifying access to the membership of at least any single group. Conformant implementations include self/group/public controls and access control lists. A DAC policy may cover rules on accessing public objects; i.e., objects which are readable to all authorized users, but which can only be altered by the TSF or authorized
5.2.2.4
8 October 1999
24
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
administrators. Specification of these rules should be covered under 5.2.2.3 and 5.2.2.4. A DAC policy may include exceptions to the basic policy for access by authorized administrators or other forms of special authorization. These rules should be covered under 5.2.2.3. The ST must list the attributes which are used by the DAC policy for access decisions. These attributes may include permission bits, access control lists, and object ownership. A single set of access control attributes may be associated with multiple objects, such as all objects stored on a single floppy disk. The association may also be indirectly bound to the object, such as access control attributes being associated with the name of the object rather than directly to the object itself. Rationale: This component supports the O.DISCRETIONARY_ACCESS objective by defining the rules which will be enforced by the TSF.
5.2.3
5.2.3.1
5.2.4
5.2.4.1
5.3
5.3.1
5.3.1.1
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
c) d) e)
Authentication Data; Security-relevant Roles; and [assignment: other user security attributes].
Application Note: The specified attributes are those that are required by the TSF to enforce the DAC policy, the generation of audit records, and proper identification and authentication of users. The user identity must be uniquely associated with a single individual user. Group membership may be expressed in a number of ways: a list per user specifying to which groups the user belongs, a list per group which includes which users are members, or implicit association between certain user identities and certain groups. A TOE may have two forms of user and group identities, a text form and a numeric form. In these cases there must be unique mapping between the representations. Rationale: This component supports the O.AUTHORIZATION and O.DISCRETIONARY_ACCESS objectives by providing the TSF with the information about users needed to enforce the TSP.
5.3.2
5.3.2.1
c)
5.3.3
5.3.3.1 5.3.3.2
Authentication (FIA_UAU.1)
The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on the behalf of that user. FIA_UAU.1.2
Application Note: The ST must specify the actions which are allowed by an unauthenticated user. The allowed actions should be limited to those things which aid an authorized
8 October 1999
26
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
user in gaining access to the TOE. This could include help facilities or the ability to send a message to authorized administrators. Rationale: This component supports the O.AUTHORIZATION objective by specifying what actions unauthenticated users may perform.
5.3.4
5.3.4.1
5.3.5
5.3.5.1 5.3.5.2
Identication (FIA_UID.1)
The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed before the user is identied. FIA_UID.1.1 The TSF shall require each user to be successfully identied before allowing any other TSF-mediated actions on the behalf of that user. FIA_UID.1.2
Application Note: The ST must specify the actions which are allowed to an unidentified user. The allowed actions should be limited to those things which aid an authorized user in gaining access to the TOE. This could include help facilities or the ability to send messages to authorized administrators. The method of identification is unspecified by this PP, but should be specified in a ST and it should specify how this relates to user identifiers maintained by the TSF. Rationale: This component supports the O.AUTHORIZATION objective by specifying what actions unidentified users may perform.
5.3.6
5.3.6.1
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
5.3.6.2
The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of a user: NOTE 2 a) [assignment: initial association rules].
5.3.6.3
The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of a user: NOTE 2 a) [assignment: changing of attributes rules].
Application Note: The DAC policy and audit generation require that each subject acting on the behalf of users have a user identity associated with the subject. This identity is normally the one used at the time of identification to the system. The DAC policy enforced by the TSF may include provisions for making access decisions based on a user identity which differs from the one used during identification. The ST must state, in 5.3.6.3, how this alternate identity is associated with a subject and justify why the individual user associated with this alternate identity is not compromised by the mechanism used to implement it. Depending on the TSFs implementation of group membership, the associations between a subject and groups may be explicit at the time of identification or implicit in a relationship between user and group identifiers. The ST must specify this association. Like user identification, an alternate group mechanism may exist, and parallel requirements apply. Rationale: This component supports the O.DISCRETIONARY_ACCESS and O.AUDITING objectives by binding user identities to subjects acting on their behalf.
5.4
5.4.1
5.4.1.1
8 October 1999
28
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
5.4.2
5.4.2.1
5.4.2.2
5.4.3
5.4.3.1
5.4.4
5.4.4.1
Version 1.d
29
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
5.4.5
5.4.5.1
5.4.6
5.4.6.1 5.4.6.2
a) b)
authorized administrators; and users authorized to modify their own authentication data
Application Note: User authentication data refers to information that users must provide to authenticate themselves to the TSF. Examples include passwords, personal identification numbers, and fingerprint profiles. User authentication data does not include the users identity. The ST must specify the authentication mechanism that makes use of the user authentication data to verify a users identity. This component does not require that any user be authorized to modify their own authentication information; it only states that it is permissible. It is not necessary that requests to modify authentication data require reauthentication of the requesters identity at the time of the request. Rationale: This component supports the O.AUTHORIZATION and O.MANAGE objectives by ensuring integrity and confidentiality of authentication data.
5.4.7
5.4.7.1 5.4.7.2
8 October 1999
30
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
Rationale: This component supports the O.MANAGE objective by controlling access to data and functions which are not generally available to all users.
5.4.8
5.4.8.1
The TSF shall enforce the rules: FMT_REV. a) b) The access rights associated with an object shall be enforced when an access check is made; and [assignment: list of other revocation rules concerning objects].
Application Note: The DAC policy may include immediate revocation (e.g., Multics immediately revokes access to segments) or delayed revocation (e.g., most UNIX systems do not revoke access to already opened files). The DAC access rights are considered to have been revoked when all subsequent access control decisions by the TSF use the new access control information. It is not required that every operation on an object make an explicit access control decision as long as a previous access control decision was made to permit that operation. It is sufficient that the developer clearly documents in guidance documentation how revocation is enforced. Rationale: This component supports the O.DISCRETIONARY_ACCESS objective by providing that specified access control attributes are enforced at some fixed point in time.
5.4.9
5.4.9.1
5.4.9.2
Version 1.d
31
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
5.5
5.5.1
5.5.1.1
5.5.2
5.5.2.1
5.5.3
5.5.3.1 5.5.3.2
8 October 1999
32
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
5.5.4
5.5.4.1
Version 1.d
33
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
8 October 1999
34
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
6.0
Assurance Requirements
This chapter denes the assurance requirements for the TOE. Assurance requirement components are Evaluation Assurance Level (EAL) 3, with no augmentation, from part 3 of the CC.
6.1
6.1.1
6.1.1.1D 6.1.1.2D 6.1.1.3D 6.1.1.1C 6.1.1.2C 6.1.1.3C 6.1.1.4C 6.1.1.5C 6.1.1.6C 6.1.1.7C 6.1.1.8C 6.1.1.9C
The CM documentation shall describe the method used to uniquely identify the conguration items. ACM_CAP.3.5C The CM system shall uniquely identify all conguration items. ACM_CAP.3.6C The CM plan shall describe how the CM system is used. ACM_CAP.3.7C The evidence shall demonstrate that the CM system is operating in accordance with the CM plan. ACM_CAP.3.8C The CM documentation shall provide evidence that all conguration items have been and are being effectively maintained under the CM system. ACM_CAP.3.9C
6.1.1.10C The CM system shall provide measures such that only authorized changes are made to the conguration items. ACM_CAP.3.10C 6.1.1.1E The evaluator shall conrm that the information provided meets all requirements for content and presentation of evidence. ACM_CAP.3.1E
Application Note: This component provides for three things. First it requires that the TOE is identifiable by a customer, using things such as version and part numbers, to ensure that the proper thing has been installed. Second it requires that the pieces used to produce the TOE are identified; the scope required is covered in 6.1.2. And third it requires that the production of the TOE be done in a controlled manner.
6.1.2
6.1.2.1D
Coverage (ACM_SCP.1)
The developer shall provide CM documentation. ACM_SCP.1.1D
Version 1.d
35
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
6.1.2.1C
The CM documentation shall show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, and CM documentation. ACM_SCP.1.1C The CM documentation shall describe how conguration items are tracked by the CM system. ACM_SCP.1.2C The evaluator shall conrm that the information provided meets all requirements for content and presentation of evidence. ACM_SCP.1.1E
6.1.2.2C 6.1.2.1E
6.2
6.2.1
6.2.1.1D 6.2.1.2D 6.2.1.1C 6.2.1.1E
6.2.2
6.2.2.1D 6.2.2.1C 6.2.2.1E 6.2.2.2E
8 October 1999
36
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
6.3
6.3.1
6.3.1.1D 6.3.1.1C 6.3.1.2C 6.3.1.3C
Development (ADV)
Functional Specication (ADV_FSP.1)
The developer shall provide a functional specication. ADV_FSP.1.1D The functional specication shall describe the TSF and its external interfaces using an informal style. ADV_FSP.1.1C The functional specication shall be internally consistent. ADV_FSP.1.2C The functional specication shall describe the purpose and method of use of all external TSF interfaces, providing details of effects, exceptions and error messages, as appropriate. ADV_FSP.1.3C The functional specication shall completely represent the TSF. ADV_FSP.1.4C The evaluator shall conrm that the information provided meets all requirements for content and presentation of evidence. ADV_FSP.1.1E The evaluator shall determine that the functional specication is an accurate and complete instantiation of the TOE security functional requirements. ADV_FSP.1.2E
Application Note: This components requires that the design documentation includes a complete external description of the TSF. In particular it needs to address the mechanisms which are used to meet the functional requirements of the CAPP. Other areas need to be addressed to the degree that they affect the functional requirements.
6.3.2
6.3.2.1D 6.3.2.1C 6.3.2.2C 6.3.2.3C 6.3.2.4C 6.3.2.5C
The high-level design shall describe the security functionality provided by each subsystem of the TSF. ADV_HLD.2.4C The high-level design shall identify any underlying hardware, rmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, rmware, or software. ADV_HLD.2.5C The high-level design shall identify all interfaces to the subsystems of the TSF.
ADV_HLD.2.6C
The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible. ADV_HLD.2.7C The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing details of effects, exceptions and error messages, as appropriate. ADV_HLD.2.8C
37 8 October 1999
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
The high-level design shall describe the separation of the TSF into TSP-enforcing and other subsystems. ADV_HLD.2.9C The evaluator shall conrm that the information provided meets all requirements for content and presentation of evidence. ADV_HLD.2.1E The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements. ADV_HLD.2.2E
Application Note: This component requires that the design documentation include a breakdown of the TSF at a very coarse grain. Both the developer and evaluator need to carefully choose how a subsystem is defined for a particular TOE. There must be a balance between subsystems being too large that it is difficult to understand the functions of any single subsystem and subsystems that are so small that how they fit into the system as a whole is difficult to understand. If different pieces of the TSF are developed or maintained by different groups of developers, that can aid in making those choices. Furthermore, it must be noted that the presentation need only be informal. This means that the interfaces between subsystems need to be presented in general terms of how they interact, not to the level of presenting a programming interface specification between them.
6.3.3
6.3.3.1D 6.3.3.1C
6.3.3.1E
6.4
6.4.1
6.4.1.1D 6.4.1.1C 6.4.1.2C 6.4.1.3C
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
The administrator guidance shall describe all assumptions regarding user behavior that are relevant to secure operation of the TOE. AGD_ADM.1.4C The administrator guidance shall describe all security parameters under the control of the administrator, indicating secure values as appropriate. AGD_ADM.1.5C The administrator guidance shall describe each type of security-relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. AGD_ADM.1.6C The administrator guidance shall be consistent with all other documents supplied for evaluation. AGD_ADM.1.7C The administrator guidance shall describe all security requirements on the IT environment that are relevant to the administrator. AGD_ADM.1.8C The evaluator shall conrm that the information provided meets all requirements for content and presentation of evidence. AGD_ADM.1.1E
Application Note: The content required by this component is quite comprehensive and broadly stated; in particular the content needs to address any of the mechanisms and functions provided to an administrator to meet the functional requirements of the CAPP. It should also contain warnings about actions that may typically be done by administrators which should not be done on this specific TOE. This may include activating certain features or installing certain software which would compromise the TSF.
6.4.2
6.4.2.1D 6.4.2.1C 6.4.2.2C 6.4.2.3C 6.4.2.4C
Version 1.d
39
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
6.5
6.5.1
6.5.1.1D 6.5.1.1C
6.5.1.2C
6.5.1.1E 6.5.1.2E
The evaluator shall conrm that the information provided meets all requirements for content and presentation of evidence. ALC_DVS.1.1E The evaluator shall conrm that the security measures are being applied. ALC_DVS.1.2E
Application Note: For the CAPP, this is really an extension of the configuration management system requirements to reduce the chance that the TSF is subverted by outsiders during development.
6.6
6.6.1
6.6.1.1D 6.6.1.1C
6.6.1.2C
6.6.1.1E
6.6.2
6.6.2.1D 6.6.2.1C
Depth (ATE_DPT.1)
The developer shall provide the analysis of the depth of testing. ATE_DPT.1.1D The depth analysis shall demonstrate that the tests identied in the test documentation are sufcient to demonstrate that the TSF operates in accordance with its high-level design. ATE_DPT.1.1C The evaluator shall conrm that the information provided meets all requirements for content and presentation of evidence. ATE_DPT.1.1E
Application Note: While the high-level design is to be used as the basis for testing, it is not required that internal interfaces between subsystems be tested.
6.6.2.1E
8 October 1999
40
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
6.6.3
6.6.3.1D 6.6.3.2D 6.6.3.1C 6.6.3.2C 6.6.3.3C
6.6.4
6.6.4.1D 6.6.4.1C 6.6.4.2C 6.6.4.1E 6.6.4.2E 6.6.4.3E
6.7
6.7.1
6.7.1.1D 6.7.1.1C
Version 1.d
41
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
The guidance documentation shall list all assumptions about the intended environment. AVA_MSU.1.3C The guidance documentation shall list all requirements for external security measures (including external procedural, physical and personnel controls). AVA_MSU.1.4C The evaluator shall conrm that the information provided meets all requirements for content and presentation of evidence. AVA_MSU.1.1E The evaluator shall repeat all conguration and installation procedures to conrm that the TOE can be congured and used securely using only the supplied guidance documentation. AVA_MSU.1.2E The evaluator shall determine that the use of the guidance documentation allows all insecure states to be detected. AVA_MSU.1.3E
Application Note: This requirement is can be approached as testing by the evaluator to ensure that the guidance documents are correct. The content elements primarily reinforce the guidance requirements themselves.
6.7.1.3E
6.7.2
6.7.2.1D
6.7.2.1C
For each mechanism with a strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the minimum strength level dened in the PP/ST. AVA_SOF.1.1C For each mechanism with a specic strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the specic strength of function metric dened in the PP/ST. AVA_SOF.1.2C The evaluator shall conrm that the information provided meets all requirements for content and presentation of evidence. AVA_SOF.1.1E The evaluator shall conrm that the strength claims are correct. AVA_SOF.1.2E
Application Note: For the CAPP, the requirement applies to the authentication mechanism which is used as described in 5.3.2.
6.7.2.2C
6.7.2.1E 6.7.2.2E
6.7.3
6.7.3.1D 6.7.3.2D 6.7.3.1C
8 October 1999
42
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
6.7.3.1E 6.7.3.2E
The evaluator shall conrm that the information provided meets all requirements for content and presentation of evidence. AVA_VLA.1.1E The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure obvious vulnerabilities have been addressed.
AVA_VLA.1.2E
Application Note: The evaluator should consider the following with respect to the search for obvious flaws: a) Dependencies among functional components and potential inconsistencies in strength of function among interdependent functions; b) Potential inconsistencies between the TSP and the functional specification; c) Potential gaps or inconsistencies in the HLD, and potentially invalid assumptions about supporting hardware, firmware, and/or software required by the TSF; d) Potential gaps in the administrator guidance that enable the administrator to fail (a) to make effective use of TSF functions, (b) to understand or take actions that need to be performed, (c) to avoid unintended interactions among security functions, and (d) to install and/or configure the TOE correctly. In particular, failure to describe all the security parameters under the administrators control and the effects of settings of (interacting combinations of) those parameters; e) Potential gaps in the user guidance that enable the user to fail to control functions and privileges as required to maintain a secure processing environment. Potential presence in the user guidance of information that facilitates exploitation of vulnerabilities; f) Open literature (e.g., CERT advisories, bug-traq mailing list) which may contain information on vulnerabilities on the TSF should be consulted.
Version 1.d
43
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
8 October 1999
44
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
7.0
Rationale
This chapter provides the rationale for the selection, creation, and use of the security policies, objectives, and components. Section 7.1 provides the rationale for the existence of the security objectives based upon the stated security policies while Section 7.2 provides the lower-level rationale for the existence of functional and assurance components based upon the stated security objectives. Section 7.2 provides an analysis that maps given security objectives to components as well as mapping given components to security objectives. In providing a mapping in both directions for the components and objectives, assurance is gained that the objectives were entirely met. This is further detailed in Section 7.2. In addition to providing a complete rationale, chapters 5 and 6 also provide the necessary application notes needed to understand how a TOE must meet the stated security objectives. These application notes provide additional information about a particular family/component/element that a developer or evaluator may need in order to fully understand how the component is to be applied.
7.1
This section provides a rationale for the existence of each threat, policy statement, security objective, and component that comprise the protection prole.
7.1.1
The TOE security objectives have been derived exclusively from statements of organizational security policy, and therefore, there are no explicitly dened threats countered by this prole.
7.1.2
This section provides evidence demonstrating coverage of the Organizational Security Policy by both the IT and Non-IT security objectives. The following table shows this objective to policy mapping, and the table is followed by a discussion of the coverage for each Security Policy. Organizational Security Policy P.AUTHORIZED_USERS Security Objectives O.AUTHORIZATION O.MANAGE O.ENFORCEMENT O.DISCRETIONARY_ACCESS O.RESIDUAL_INFORMATION O.MANAGE O.ENFORCEMENT O.AUDITING O.MANAGE O.ENFORCEMENT
P.NEED_TO_KNOW
P.ACCOUNTABILITY
The following discussion provides detailed evidence of coverage for each statement of organizational security policy: P.AUTHORIZED_USERS
Only those users who have been authorized to access the information within the system may access the system.
This policy is implemented by the O.AUTHORIZATION objective. The O.MANAGE supports this policy by requiring authorized administrators to be able to manage the functions and O.ENFORCEMENT ensures that functions are invoked and operate correctly. Version 1.d 45 8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile P.NEED_TO_KNOW Information Systems Security Organization
The system must limit the access to, modication of, and destruction of the information in protected resources to those authorized users which have a need to know for that information.
This policy is implemented by the O.DISCRETIONARY_ACCESS objective. The O.RESIDUAL_INFORMATION objective ensures that information will not given to users which do not have a need to know, when resources are reused. The O.MANAGE supports this policy by requiring authorized administrator be able to manage the functions and O.ENFORCEMENT ensures that functions are invoked and operate correctly. P.ACCOUNTABILITY
The users of the system shall be held accountable for their actions within the system.
This policy is implemented by the O.AUDITING objective by requiring that actions are recorded in an audit trail. The O.MANAGE supports this policy by requiring authorized administrator be able to manage the functions and O.ENFORCEMENT ensures that functions are invoked and operate correctly.
7.1.3
This section provides evidence demonstrating coverage of the Non-IT security objectives by the environmental assumptions. The following table shows this assumption to objective mapping. Non IT Security Objectives O.INSTALL Environmental Assumptions A.MANAGE A.NO_EVIL_ADM A.PEER A.LOCATE A.PROTECT A.CONNECT A.COOP
O.PHYSICAL
O.CREDEN
7.2
This section provides evidence supporting the combined internal consistency and completeness of the functional components that comprise the CAPP.
7.2.1
This section describes the mutual support and internal consistency of the components selected for this prole. These properties are discussed for both functional and assurance components. The functional components were selected from pre-dened CC components. The use of component renement was accomplished in accordance with CC guidelines. An additional component was included to clarify the relationship of objects and security attributes. Assignment, selection, and renement operations were carried out among components using consistent computer security terminology. This helps to avoid the ambiguity associated with interpretations of meanings of terms between related components. Multiple instantiation of identical or hierarchically-related components was used to clearly state the required functionality that must exist in a TOE conformant with this prole.
7.2.2
This section demonstrates that the functional components selected for this prole provide complete coverage of the dened security objectives. The mapping of components to security objectives is 8 October 1999 46 Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization depicted in the following table. Security Objective O.AUTHORIZATION Functional Component 5.3.1 User Attribute Denition (FIA_ATD.1) 5.3.2 Strength of Authentication Data (FIA_SOS.1) 5.3.3 Authentication (FIA_UAU.1) 5.3.4 Protected Authentication Feedback (FIA_UAU.7) 5.3.5 Identication (FIA_UID.1) 5.4.6 Management of Authentication Data (FMT_MTD.1) 5.2.1 Discretionary Access Control Policy (FDP_ACC.1) 5.2.2 Discretionary Access Control Functions (FDP_ACF.1) 5.3.1 User Attribute Denition (FIA_ATD.1) 5.3.6 User-Subject Binding (FIA_USB.1) 5.4.1 Management of Object Security Attributes (FMT_MSA.1) 5.4.2 Static Attribute Initialization (FMT_MSA.3) 5.4.8 Revocation of Object Attributes (FMT_REV.1) 5.1.1 Audit Data Generation (FAU_GEN.1) 5.1.2 User Identity Association (FAU_GEN.2) 5.1.3 Audit Review (FAU_SAR.1) 5.1.4 Restricted Audit Review (FAU_SAR.2) 5.1.5 Selectable Audit Review (FAU_SAR.3) 5.1.6 Selective Audit (FAU_SEL.1) 5.1.7 Guarantees of Audit Data Availability (FAU_STG.1) 5.1.8 Action in Case of Possible Audit Data Loss (FAU_STG.3) 5.1.9 Prevention of Audit Data Loss (FAU_STG.4) 5.3.6 User-Subject Binding (FIA_USB.1) 5.4.3 Management of the Audit Trail (FMT_MTD.1) 5.4.4 Management of Audited Events (FMT_MTD.1) 5.5.4 Reliable Time Stamps (FPT_STM.1) 5.2.3 Object Residual Information Protection (FDP_RIP.2) 5.2.4 Subject Residual Information Protection (Note 1) 5.1.3 Audit Review (FAU_SAR.1) 5.1.5 Selectable Audit Review (FAU_SAR.3) 5.1.6 Selective Audit (FAU_SEL.1) 5.1.8 Action in Case of Possible Audit Data Loss (FAU_STG.3) 5.1.9 Prevention of Audit Data Loss (FAU_STG.4) 5.4.3 Management of the Audit Trail (FMT_MTD.1) 5.4.4 Management of Audited Events (FMT_MTD.1) 5.4.5 Management of User Attributes (FMT_MTD.1) 5.4.6 Management of Authentication Data (FMT_MTD.1) 5.4.7 Revocation of User Attributes (FMT_REV.1) 5.4.9 Security Management Roles (FMT_SMR.1) 5.5.1 Abstract Machine Testing (FPT_AMT.1) 5.5.2 Reference Mediation (FPT_RVM.1) 5.5.3 Domain Separation (FPT_SEP.1) Controlled Access Protection Profile
O.DISCRETIONARY_ACCESS
O.AUDITING
O.RESIDUAL_INFORMATION O.MANAGE
O.ENFORCEMENT
The following discussion provides detailed evidence of coverage for each security objective:
Version 1.d
47
8 October 1999
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile O.AUTHORIZATION Information Systems Security Organization
The TSF must ensure that only authorized users gain access to the TOE and its resources.
Users authorized to access the TOE are dened using an identication and authentication process [5.3.5, 5.3.3]. To ensure authorized access to the TOE, authentication data is protected [5.3.1, 5.3.4, 5.4.6]. The strength of the authentication mechanism must be sufcient to ensure unauthorized users to easily pose as authorized users [5.3.2]. O.DISCRETIONARY_ACCESS
The TSF must control accessed to resources based on identity of users. The TSF must allow authorized users to specify which resources may be accessed by which users.
Discretionary access control must have a dened scope of control [5.2.1]. The rules of the DAC policy must be dened [5.2.2]. The security attributes of objects used to enforce the DAC policy must be dened. The security attributes of subjects used to enforce the DAC policy must be dened [5.3.1, 5.3.6]. Authorized users must be able to control who has access to objects [5.4.1] and be able to revoke that access [5.4.8]. Protection of named objects must be continuous, starting from object creation [5.4.2]. O.AUDITING
The TSF must record the security relevant actions of users of the TOE. The TSF must present this information to authorized administrators.
Security-relevant actions must be dened, auditable [5.1.1], and capable of being associated with individual users [5.1.2, 5.3.6]. The audit trail must be protected so that only authorized users may access it [5.1.4]. The TSF must provide the capability to audit the actions of an individual user [5.1.5, 5.1.6, 5.3.6]. The audit trail must be complete [5.1.7, 5.1.9]. The time stamp associated must be reliable [5.5.4]. An authorized administrator must be able to review [5.1.3] and manage [5.1.8, 5.4.4, 5.4.4] the audit trail. O.RESIDUAL_INFORMATION
The TSF must ensure that any information contained in a protected resource is not released when the resource is recycled.
Residual information associated with dened objects in the TOE must be purged prior to the reuse of the object containing the residual information [5.2.3]. O.MANAGE
The TSF must provide all the functions and facilities necessary to support the authorized administrators that are responsible for the management of TOE security.
The TSF must provide for an authorized administrator to manage the TOE [5.4.9]. The administrator must be able to administer user accounts [5.4.5, 5.4.6, 5.4.7]. The administrator must be able to review manage the audit trail [5.1.3, 5.1.5, 5.1.6, 5.1.8, 5.1.9, 5.4.3, 5.4.4]. O.ENFORCEMENT
The TSF must be designed and implemented in a manner which ensures that the organizational policies are enforced in the target environment.
The TSF must make and enforce the decisions of the TSP [5.5.2]. It must be protected from interference that would prevent it from performing its functions [5.5.3]. Additionally, the TOE must provide the capability to demonstrate correct operation of the TSFs underlying abstract machine [5.5.1]. The correctness of this objective is further met through the assurance requirements dened in this PP. This objective provides global support to other security objectives for the TOE by protecting the parts 8 October 1999 48 Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
of the TOE which implement policies and ensures that policies are enforced.
7.3
Dependencies
The following table shows the dependencies which exist. A box with an X in it indicates a dependency which has been satised. A box with an O in it indicates an optional dependency where one of the options has been satised. FMT_SMR.1 X X X X X X 49 8 October 1999 FMT_MSA.1 FMT_MSA.3 FMT_MTD.1 FDP_ACC.1 FAU_GEN.1 FPT_STM.1 X X X X X X X X X X X X X FAU_SAR.1 FAU_STG.1 FDP_ACF.1 FDP_IFC.1 FIA_UAU.1 X FIA_ATD.1 FDP_IFF.1 FIA_UID.1 X
Section
CC Identier
5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 5.1.7 5.1.8 5.1.9 5.2.1 5.2.2 5.2.3 5.2.4 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 Version 1.d
FAU_GEN.1 FAU_GEN.2 FAU_SAR.1 FAU_SAR.2 FAU_SAR.3 FAU_SEL.1 FAU_STG.1 FAU_STG.3 FAU_STG.4 FAU_ACC.1 FAU_ACF.1 FDP_RIP.2 Note 1 FIA_ATD.1 FIA_SOS.1 FIA_UAU.1 FIA_UAU.7 FIA_UID.1 FIA_USB.1 FMT_MSA.1 FMT_MSA.3 FMT_MTD.1 FMT_MTD.1 FMT_MTD.1 O O X
UNCLASSIFIED
UNCLASSIFIED
Controlled Access Protection Profile Information Systems Security Organization
FMT_SMR.1 X X X
FMT_MSA.1
FMT_MSA.3
FMT_MTD.1
FDP_ACC.1
FAU_GEN.1
Section
CC Identier
7.4
This protection prole has been developed for a generalized environment with a moderate level of risk to the assets. It is intended that products used in these environments will be generally available, without modication to meet the security needs of the environment. As such it was determined the Evaluation Assurance Level 3 was the most appropriate.
7.5
The strength of function rating of SOF-medium is consistent with the SFR FIA_SOS.1 by providing a one off probability of guessing the password in 1,000,000. This SFR is in turn consistent with the security objectives described in section 7.2.
8 October 1999
50
FPT_STM.1
FAU_SAR.1
FAU_STG.1
FDP_ACF.1
FDP_IFC.1
FIA_UAU.1
FIA_ATD.1
FDP_IFF.1
FIA_UID.1
Version 1.d
UNCLASSIFIED
UNCLASSIFIED
Information Systems Security Organization Controlled Access Protection Profile
8.0
Notes on Deviations
This section contains notes on places where this protection prole deviated from version 2 of the Common Criteria. Each of these notes has been submitted as Common Criteria Request for Interpretations (CCRI) for inclusion in future versions of the Common Criteria.
Note 1
The CCs FDP_RIP components only specify resources being allocated to objects and does not address resources used directly by subjects, such as memory or registers. This explicit requirement was added to ensure coverage of these resources. The words are identical to FDP_RIP.2 except subject replaces object. The CCs FIA_USB component used the term appropriate security attributes, which is really too vague. The word appropriate was replaced with the word following and an assignment list was added. This allows the PP/ST to specify what attributes are needed to enforce the TSP. In addition, elements were added to cover any rules that were required to be enforced on attribute binding or changes. The word take was removed from FAU_STG.3 in order to make a grammatically correct sentence. The format of using sub-elements which appeared in the CCs FAU_GEN.1 was difcult to represent all the information in a clear fashion. The sub-elements were replaced by the use of a table, as the wording of the element adjusted to refer to the table, rather than the sub-elements. The CCs FAU_STG.4 did not provide a selection which only required that this capability be available. The words be able to were added in order to allow the option to make this a congurable feature.
Note 2
Note 3 Note 4
Note 5
Version 1.d
51
8 October 1999
UNCLASSIFIED