D R A F T Common Criteria for Information Technology Security Evaluation CCEB-94/086 Example Protection Profiles Version 0.9 94/10/31 D R A F T This document is paginated from i to vi and from 1 to 54 D R A F T CCEB-94/086 Table of contents 94/10/31 Version 0.9 Page iii of vi Table of contents Chapter 0 Foreword ....................................................... 1 0.1 The example Protection Profiles ....................................... 1 0.2 Plans for progress of the Protection Profiles ........................ 1 0.3 Reviewer guidance for example Protection Profiles ..................... 2 Chapter 1 Commercial Security 1 (CS1) Protection Profile .................. 3 1.1 Descriptive elements .................................................. 3 1.1.1 Protection Profile Identifier: ...................................... 3 1.1.2 Protection Profile Description: ..................................... 3 1.1.3 Related Protection Profiles: ....................................... 4 1.2 Top-level security objectives ........................................ 4 1.2.1 Usage assumptions .................................................. 4 1.2.2 Environmental assumptions .......................................... 4 1.2.3 Statement of threat ................................................ 6 1.2.4 CC/CS1 security objectives ......................................... 8 1.3 Requirements ......................................................... 9 1.3.1 Functional requirements ............................................. 9 1.3.2 Assurance requirements ............................................ 16 1.3.3 Rationale for CC/CS1 functional requirements ...................... 17 1.3.4 Rationale for CC/CS1 assurance requirements ........................ 20 1.4 CC/CS1 Application notes ............................................ 21 Chapter 2 Commercial Security 3 (CS3) Protection Profile ................. 23 2.1 Descriptive elements ................................................. 23 2.1.1 Protection Profile Identifier: ..................................... 23 2.1.2 Protection Profile Description: .................................... 23 2.1.3 Related Protection Profiles: ...................................... 24 2.2 Top-level security objectives ....................................... 24 2.2.1 Usage assumptions ................................................. 24 2.2.2 Environmental assumptions ......................................... 24 2.2.3 Statement of threat ............................................... 27 2.2.4 CC/CS3 security objectives ........................................ 30 2.3 Requirements ........................................................ 31 2.3.1 Functional requirements ............................................ 31 2.3.2 Assurance requirements ............................................ 42 2.3.3 Rationale for CC/CS3 functional requirements ...................... 48 2.3.4 Rationale for CC/CS3 assurance requirements ........................ 52 2.4 CC/CS3 Application notes ............................................ 53 D R A F T List of figures CCEB-94/086 Page iv of vi Version 0.9 94/10/31 List of figures D R A F T CCEB-94/086 List of tables 94/10/31 Version 0.9 Page v of vi List of tables D R A F T List of tables CCEB-94/086 Page vi of vi Version 0.9 94/10/31 D R A F T CCEB-94/086 0 - Foreword 94/10/31 Version 0.9 Page 1 of 2 Chapter 0 Foreword 0.1 The example Protection Profiles 1 The Protection Profile (PP) is a Common Criteria (CC) construct which allows users to describe re-usable sets of security requirements of proven utility. All existing criteria contain some sets of standardised requirements for functions and assurance, though they may be separated. The PP brings those two types of requirements together with a statement of the security problem they are intended to solve, so that prospective users can determine their applicability to specific uses. Although the PP concept has been borrowed from the Federal Criteria (FC), it has its conceptual origin in the TCSEC digraphs and its structural origin in the ITSEC security target. 2 Each PP consists of two key parts: a section containing a set of functional and assurance requirements and a section containing the purpose for such requirements expressed as a set of top-level security objectives. Functional requirements are components from Part 2 (modified as necessary to meet specific needs by certain operations described in Part 1 Annex B). Assurance requirements consist of an assurance level from Part 3, augmented as necessary to meet specific needs by addition of assurance components from Part 3. The section containing top-level security objectives is developed from consideration of stated assumptions about intended use, environment of use, and anticipated threats in such an environment. In a general sense, the top- level security objectives express the security problem which the functional and assurance requirements are to solve. An additional part of the PP is the rationale, which demonstrates that relationship between the requirements and objectives exists. 3 Two preliminary draft example PPs, CC/CS1 and CC/CS3 respectively, are furnished for review with the draft CC. These PPs are based for content on the FC CS1 and CS3 respectively, and for structure on the CC Annex F. The example PPs are provided for two purposes: a) To demonstrate at a first approximation that known requirement sets can be replicated by use of the CC approach and contents, and b) To give reviewers the opportunity to review two examples of usage of the CC functional and assurance requirements to form practical requirement sets. 0.2 Plans for progress of the Protection Profiles 4 It is planned that a Part 4 of the CC will be prepared at some point to serve as an initial registry of PPs. Part 4 is to contain a set of PPs reflecting existing criteria. D R A F T 0 - Foreword CCEB-94/086 Page 2 of 2 Version 0.9 94/10/31 (ref. CC Conceptual Framework, para 5.3.1) It has not been decided by the CC Project Sponsors whether that work will be done under the aegis of the Common Criteria Editorial Board (CCEB) or by participating nations. Nor has it been decided whether or at what point highly overlapping sets of requirements from different existing criteria (e.g., TCSEC/C2, FC/CS1, ITSEC/FC2-E2, comparable CTCPEC profile) will be harmonised into single PPs in Part 4 that can replace members of such sets for general use. 5 In the near term, one or more PPs (probably CC/CS1) will be advanced by the CCEB to be used as a basis for trial evaluations under the CC. 0.3 Reviewer guidance for example Protection Profiles 6 The CC Review Guidance document for version 0.9 (CCEB-94/089) contains a section on recommended review approach for the example PPs. In summary, the following issues are brought to the attention of the reviewer for analysis and comment: a) The overall structure of the PP. Does the fundamental notion of requirements supported by objectives make sense for a PP? b) The inclusion of specific elements of the PP: 1) Top-level security objectives (TLSO) contents, including assumed intended use, environment of use and threats. Are those items as used in the example PPs properly developed, addressing the most useful subjects at the appropriate level of detail? See also Editors Notes on threats and objectives in each PP. 2) Functional and assurance requirements sections enumerating the components and their elements from the source material in Parts 2 and 3. Is the PP format for these items useful? 3) Requirements rationale section which show that the requirements meet the objectives. Is this section as a useful addition to the PP structure, or should it be a separate document? 7 It would be less helpful for reviewers to analyse closely the specific contents of the requirements section, i.e., the functional and assurance components and assurance levels, for conformance to the FC CS1 and CS3. As that material is dependent upon Parts 2 and 3 of the CC which are currently under development, a PP derived from them is bound to have some inaccuracies due to their immaturity. D R A F T CCEB-94/086 1 - Commercial Security 1 (CS1) Protection Profile 94/10/31 Version 0.9 Page 3 of 22 Chapter 1 Commercial Security 1 (CS1) Protection Profile Editor Note: Caveat: The material contained in this chapter is a very preliminary draft that has not yet been thoroughly reviewed or evaluated. It has not been approved at this stage for any use, either as a statement of requirements or for any type of evaluation purposes. This draft is provided with the Common Criteria (CC) review draft for two purposes: 1) to demonstrate at a first approximation that known requirement sets can be replicated by use of the CC approach and contents, and 2) to give reviewers the opportunity to review an example of usage of the CC functional and assurance requirements to form practical requirement sets Editor Note: This chapter presents the CS1 Protection Profile in a way that is consistent with the draft CC. CC/CS1 is based on the CS1 Protection Profile in the Federal Criteria, which was itself based on the TCSEC's C2 class. For simplicity of discussion, the term "CC/CS1" will be used to stand for Targets of Evaluation (TOEs) which are compliant with that Protection Profile. 1.1 Descriptive elements 1.1.1 Protection Profile Identifier: 8 Commercial Security 1(CC/CS1) 1.1.2 Protection Profile Description: 9 CC/CS1 is equivalent to Class C2 Controlled Access Protection from the TCSEC. CC/CS1 consists of TCSEC requirements plus those evaluation interpretations that a product must meet before it can be rated at the C2 level. (ref. FC, page CS1-13) 10 CC/CS1 specifies a baseline set of security functions of broad applicability and effectiveness for general purpose, multi-user operating systems (ref. FC, page CS1- 18, para 2.2.3). CC/CS1 compliant products are expected to be used in both commercial and government environments. 11 For government environments, CC/CS1 compliant products are intended to process sensitive-but-unclassified information or single-level classified information. CC/ CS1 compliant products are not intended to process multi- level classified information. (ref. FC, page CS1-18, para 2.2.3) 12 Products that comply with this Commercial Security 1 (CC/CS1) Protection Profile (PP) provide access control capabilities to separate users and data, based on finely grained access controls. D R A F T 1 - Commercial Security 1 (CS1) Protection Profile CCEB-94/086 Page 4 of 22 Version 0.9 94/10/31 13 CC/CS1 incorporates controls capable of enforcing access limitations on an individual basis, i.e., suitable for allowing users to be able to protect sensitive information and to keep other users from reading or destroying their data. 1.1.3 Related Protection Profiles: 14 CC/CS2 Commercial Security 2 (TBD) 15 CC/CS3 Commercial Security 3 1.2 Top-level security objectives 16 These top-level security objectives (TLSO) for CC/CS1 describe assumptions about how the security features of a compliant product are intended to be used, the environment in which it is intended to operate, the threats within that environment, and the objectives to be met to counter these threats. (ref. FC, page CS1-15, para 2.2) 1.2.1 Usage assumptions 17 The product is designed to manage computing, storage, input/output, and to control the sharing of information among multiple users and IT processes. 18 The product provides facilities for on-line interaction with users. 1.2.2 Environmental assumptions 1.2.2.1 Physical assumptions 19 All processing resources of the product, including terminals, are located within controlled access facilities. (ref. FC, page CS1-19, para 2.2.3) 20 The product's hardware, firmware and software will be physically protected from unauthorised modification. 1.2.2.2 Personnel assumptions 21 There are competent persons assigned to manage the product and accurately configure permission sets. 22 Administrative and non-administrative users are uniquely identified. 23 User permissions and system-level access permissions are controlled by system administration. 1.2.2.3 Applicable Laws, Rules or Regulations 24 Due to the general nature of CC/CS1, no specific laws, rules or regulations have been considered in formulating this PP. However, since it is intended to supersede D R A F T CCEB-94/086 1 - Commercial Security 1 (CS1) Protection Profile 94/10/31 Version 0.9 Page 5 of 22 the TCSEC C2 class, any regulation calling for C2 may be demonstrably satisfied by employing products compliant with this PP. 1.2.2.4 Relevant Organisational Considerations 25 CC/CS1 is applicable in environments where the corruption, unauthorized disclosure, or destruction of electronically-maintained resources can have a disruptive effect on an organization's operations as well as serious and immediate financial, legal, and public confidence. (ref. FC, page CS-7, para 1.1) 26 CC/CS1 is intended to satisfy "need-to-know" organisational security policies. 1.2.2.5 Assumed connectivity 27 CC/CS1 contains no explicit network or distributed system requirements. CC/CS1 assumes that input and output interfaces are reliable, non-spoofable and non interceptable. Point-to-point interfaces to peripheral devices (e.g. printers, terminals, disk drives, tape backup) within a controlled space meet the CC/CS1 connectivity assumptions. 28 CC/CS1 is appropriate for homogeneous distributed systems operating under a single administrative domain. 1.2.2.6 Assumed informational assets Availability 29 CC/CS1 has some functional components that can prevent the destruction of data and applications resident on the IT system, although it is not intended to address all potential failure modes. Confidentiality 30 CC/CS1 is intended for environments that operate under the assumption that users can be trusted to share data in a responsible fashion. CC/CS1 employs identity based access controls that rely on users to control data dissemination. Data Integrity 31 CC/CS1 has requirements to limit access of critical data to only certain individuals. CC/CS1 provides the ability to bring under the control of specific qualified individuals data that must be accurate in order for the applications resident on the IT system to function properly. CC/CS1 provides reasonable protection against unauthorised data modification in low threat- intensity environments. 1.2.2.7 Environmental security conditions 32 CC/CS1 assumes that the attack frequency of highly sophisticated threat agents is limited by environmental characteristics, or it is contained by other system elements or physical controls. D R A F T 1 - Commercial Security 1 (CS1) Protection Profile CCEB-94/086 Page 6 of 22 Version 0.9 94/10/31 33 CC/CS1 also assumes that the administration of user access is accurate and procedural safeguards exist to ensure proper system administration. 34 All CC/CS1 functional components are assumed to be complete and self- contained and, as such, are not dependent on any other products to perform as intended. 35 CC/CS1 contains no specific requirements supporting cooperation with other products. It also includes no requirements prohibiting the inclusion of such features or mechanisms. Features such as exportation of audit records that might be useful in a distributed environment are not included in CC/CS1. 1.2.3 Statement of threat Editor Note: The threat information for CC/CS1 is presented here in a manner consistent with the current PP structure in draft Part 1 annex F of the CC. The statement of threat in a PP should be consistent with the usage and environment assumptions, and with those assumptions should form the basis for the security objectives. The characteristics and level of detail of threat information that would be useful in a PP are still under active consideration. Reviewers are invited to comment whether this material adds conceptually to the PP, and as used in this example PP whether the threats are properly developed. 36 CC/CS1 is intended for relatively benign physical and operational environments, those in which the threat of malicious attacks aimed at discovering exploitable vulnerabilities is considered minimal. CC/CS1 is applicable to environments where persons have different needs for access to IT resources, to include no need at all. CC/ CS1 is not intended to prevent users from abusing their authority. Thus, the primary threats countered by CC/CS1 are those of errors or casual attempts to violate the access control policies enforced by the TSF (e.g., "browsing"). 1.2.3.1 Threats not countered 37 Within this context, the following is a list of threat agents that CC/CS1 is not intended to address: a) Careless, wilfully negligent or hostile system administration personnel, b) Hostile insiders who desire to share with others any information resources to which they have been granted access, c) Hostile individuals with physical access, engaged in theft, implantation of devices or alteration of physical configuration of the system. 1.2.3.2 Threats countered 38 In general, CC/CS1 is intended to counter human threat agents who attempt to misuse the system. These threats include the following four specific types. D R A F T CCEB-94/086 1 - Commercial Security 1 (CS1) Protection Profile 94/10/31 Version 0.9 Page 7 of 22 Threat Agent 1: People within the organisation not authorised to use the IT system 39 Opportunity: A person other than a user gaining physical access to a terminal, followed by issuance of commands from keyboard. 40 Expertise: No special knowledge, skills or ability with respect to the TOE are postulated. Accordingly, it is expected that individual attacks of this type may be easily frustrated. 41 Resources: No special hardware or software postulated. Frequency of attack could be high, while individual attacks would tend to be short (minutes to an hour). Amount of effort involved per attack is estimated as low to moderate. 42 Motivation: Assumed non-hostile motivations of curiosity or challenge. Threat Agent 2: Careless or negligent user 43 Opportunity: User issuing inappropriate or incorrect commands from keyboard. 44 Expertise: Low to moderate levels of user knowledge, skills or ability with respect to the TOE are postulated. 45 Resources: No special hardware or software postulated. Frequency of attack could be high, while individual attacks could be lengthy. Amount of effort involved per attack is estimated as low to moderate. 46 Motivation: Assumed non-hostile motivations of poor attitude, job pressure, inadequate training, etc. No overt intent to harm is postulated. Threat Agent 3:Hostile user 47 Opportunity: User performing any intentional actions within the confines of own account, with the intent of harming the system or gaining inappropriate access to resources or information. 48 Expertise: Moderate to high levels of user technical knowledge, skills or ability with respect to the TOE are postulated. D R A F T 1 - Commercial Security 1 (CS1) Protection Profile CCEB-94/086 Page 8 of 22 Version 0.9 94/10/31 49 Resources: Moderate access to special software (e.g., debuggers) is postulated. Frequency of attack is assumed low to moderate in postulated environment for CC/CS1, while individual attacks could be lengthy. Amount of effort involved per attack is estimated as moderate. 50 Motivation: Assumed hostile motivations of any sort, including fraud, revenge, enemy agent, sociopathic behaviour. Clear and strong intent to harm is postulated. Threat Agent 4: Hostile outsider or masquerading hostile insider 51 Opportunity: Outsider or insider masquerading as a user by gaining physical or logical access to input/output device, with the intent of harming the system or gaining inappropriate access to resources or information. 52 Expertise: Moderate to high levels of technical knowledge, skills or ability with respect to the TOE are postulated. 53 Resources: Moderate access to special software (e.g., debuggers) is postulated. Frequency and duration of attack is assumed low in postulated CC/CS1 environment. Amount of effort involved per attack is estimated as high. 54 Motivation: Assumed hostile motivations of any sort, including fraud, revenge, enemy agent, sociopathic behaviour. Clear and strong intent to harm is postulated. 1.2.4 CC/CS1 security objectives Editor Note: The security objectives in a PP should be consistent with and be a logical consequence of the usage and environment assumptions and the statement of threat, and they should form the basis for the functional and assurance requirements. The characteristics and level of detail of the security objectives which would be useful in a PP are still under active consideration. Reviewers are invited to comment whether this material adds conceptually to the PP, and as used in this example PP whether the objectives are properly developed. 55 The following are the CC/CS1 security objectives. a) Prevent unauthorised logical entry into the IT system by providing a terminal log-in procedure to identify and authenticate users. b) Detect repeated unsuccessful log-in attempts via auditing of such events. c) Limit the damage any particular user could cause by providing identity based access controls. D R A F T CCEB-94/086 1 - Commercial Security 1 (CS1) Protection Profile 94/10/31 Version 0.9 Page 9 of 22 d) Detect attempts to misuse system resources or violate security policy by auditing such events. e) Limit the damage of scavenging attacks by clearing volatile and non volatile storage resources such as disk segments, memory segments, and buffers) as those resources are released back into a pool of unused and reallocatable resources. f) Protect against tampering of protection relevant mechanisms by providing a separate execution domain for such mechanisms. g) Counter illicit or errant software or users from bypassing security policy enforcement by providing reference mediation. h) Provide functions that periodically validate the correct operation of protection relevant mechanisms. 1.3 Requirements 56 This section provides functional and assurance requirements that must be satisfied by a Commercial Security 1 (CC/CS1) compliant TOE. These requirements are taken from functional components and packages in Part 2 and an assurance level and assurance components in Part 3 of the CC. (ref. FC, page CS1-23, para 3) 57 The level of functional and assurance components that were chosen for CC/CS1 are equivalent to Class C2 of the TCSEC. They consist of TCSEC requirements plus those evaluation interpretations that a product must meet before it can be evaluated at the C2 level. (ref. FC vol. II, p. CS1-15, para. 2.2) 1.3.1 Functional requirements 58 The security functional requirements for CC/CS1 consist of the following components from Part 2: 1.3.1.1 To satisfy CC/CS1 Access Control: 59 FDP_ACC.2: Resource access control FDP_ACC.2.1: The developer shall define the subset of resources to be controlled by the access control policy such that all operation on those resources are controlled. FDP_ACC.2.2: The TSF shall apply an access control policy to all operations on the controlled set of resources. FDP_ACC.2.3: The access control policy shall define, with respect to each operation an a controlled resource, the control that may be exercised over the operation on a controlled resource, the control that may be exercised over the operation and how that control is specified. D R A F T 1 - Commercial Security 1 (CS1) Protection Profile CCEB-94/086 Page 10 of 22 Version 0.9 94/10/31 FDP_ACC.2.4: The access control policy shall define, with respect to each operation on a controlled resource, the responsible entities (users, subjects) who may exercise the control. 60 FDP_ACC.4: Subset fixed protection FDP_ACC.4.1: The TSF shall apply a fixed protection policy to some defined subset of operations outside the subset of operations to which any access control policy applies. 61 FDP_ACM.1: Single identity-based access control FDP_ACM.1.1: The TSF shall provide an access control mechanism to control the subset of operations governed by the access control policy. FDP_ACM.1.2: The mechanism shall permit or deny access to operations based on the identity of the user performing the operation, or the user on whose behalf the subject is operating. FDP_ACM.1.3: The mechanism shall permit designation of a single user permitted to perform an operation. 62 FDP_ACM.3: Single group-based access control FDP_ACM.3.1: The TSF shall provide an access control mechanism to control the subset of operations governed by the access control policy. FDP_ACM.3.2: The TSF shall provide a mechanism for defining groups of users. FDP_ACM.3.3: The access control mechanism shall permit or deny access to operations based on the group or groups with which the user (or the user on whose behalf a subject is operating) performing the operation is associated. FDP_ACM.3.4: The mechanism shall permit designation of a single group permitted to perform an operation. 63 FDP_SAM.1: Minimal attribute modification FDP_SAM.1.1: The TSF shall limit the ability to modify relevant security attributes of objects, subjects and the users to a security administrator. 64 FDP_SAI.1: Static attribute initialization FDP_SAI.1.1: The TSF shall provide well-defined default values for relevant security attributes that are used to control the data protection mechanisms. D R A F T CCEB-94/086 1 - Commercial Security 1 (CS1) Protection Profile 94/10/31 Version 0.9 Page 11 of 22 FDP_SAI.1.2: In the absence of any overriding initial values, the TSF shall apply these default attributes when an object, user or subject is newly created. FDP_SAI.1.3: Any functions for specifying initial values shall be controlled in accordance with all the TSF's protection policies. 1.3.1.2 To satisfy CC/CS1 Object Reuse: 65 FDP_RIP.2: Full deletion protection FDP_RIP.2.1: The TSF shall ensure that the content of any resource or portion of any resource that is deleted or otherwise released to the TSF's control is protected such that no subject or user may subsequently view it in a way that would violate access control or information flow control policies. 66 FDP_RIP.4: Full creation protection FDP_RIP.4.1: The TSF shall ensure that the entire information content of any resource shall, when the resource is newly created or allocated, be determined from information that is accessible (in accordance with access control and information flow control policies) to the subject creating or allocating the resource. 1.3.1.3 To satisfy CC/CS1 Identification and Authentication: 67 FIA_ATD.2: Basic user attribute definition FIA_ATD.2.1: The TSF shall provide a unique association between each user and the policy attributes necessary to enforce the TSP. 68 FIA_ATA.2: Basic user security attribute administration FIA_ATA.2.1: The TSF shall provide default values for user security attributes to be used when initializing attributes for a user. FIA_ATA.2.2: The TSF shall provide the ability to display user security attributes. FIA_ATA.2.3: The TSF shall provide the ability to modify user security attributes. 69 FIA_ATP.1: Minimal user attribute protection FIA_ATP.1.1: The TSF shall protect user security attributes from unauthorized use, observation, modification, and destruction. 70 FIA_USB.1: Minimal user-subject binding D R A F T 1 - Commercial Security 1 (CS1) Protection Profile CCEB-94/086 Page 12 of 22 Version 0.9 94/10/31 FIA_USB.1.1: The TSF shall associate the appropriate security attributes of the user with subjects acting on behalf of that user in accordance with the TSP. 71 FIA_UID.2: Unique identification of users FIA_UID.2.1: For all users, the TSF shall uniquely identify the user before performing any TSF mediated actions on behalf of that user. 72 FIA_UAU.1: Basic user authentication FIA_UAU.1.1: The TSF shall provide a mechanism to authenticate any user's claimed identity. FIA_UAU.1.2: The TSF shall perform this authentication before performing any other TSF-mediated actions on behalf of the user. 73 FIA_ADP.1: Basic user authentication data protection FIA_ADP.1.1: The TSF shall protect the stored authentication data from unauthorized use, observation, modification and destruction. 74 FIA_AAA.1: Minimal user authentication attribute administration FIA_AAA.1.1: The TSF shall provide functions for displaying and modifying user authentication attributes. FIA_AAA.1.2: The TSF shall restrict use of these functions to security administrators. 75 FDP_SAI.1: Static attribute initialization [for user attributes] FDP_SAI.1.1: The TSF shall provide well-defined default values for relevant security attributes that are used to control the data protection mechanisms. FDP_SAI.1.2: In the absence of any overriding initial values, the TSF shall apply these default attributes when an object, user o subject is newly created. FDP_SAI.1.3: Any functions for specifying initial values shall be controlled in accordance with all the TSF's protection policies. 76 FDP_SAM.1: Minimal attribute modification [for user attributes] FDP_SAM.1.1: The TSF shall limit the ability to modify relevant security attributes of objects, subjects and users to authorised users. 77 FDP_SAQ.1: Minimal attribute query [for user attributes] D R A F T CCEB-94/086 1 - Commercial Security 1 (CS1) Protection Profile 94/10/31 Version 0.9 Page 13 of 22 FDP_SAQ.1.1: The TSF shall provide the ability for authorised users to display relevant security attributes. FDP_SAQ.1.2: The TSF shall provide at least one of the following options: - a) To display all relevant security attributes for an object, user or subject. - b) To display all the objects, users or subjects associated with a relevant security attribute. 1.3.1.4 To satisfy CC/CS1 Audit: 78 FAU_GEN.2: Basic Audit Generation FAU_GEN.2.1: The TSF shall be able to generate a record of the following auditable events: - a) Shutdown of the audit functions. - b) from FIA_ATA.2: - Minimal: Successful use of the user security attribute administration functions. - Basic: All attempted uses of the user security attribute administration functions. - c) from FIA_ATP.1: - Basic: All attempts by unauthorized users to use, observe, modify, or destroy user attributes. - d) from FIA_USB.1: - Minimal: Successful binding of user security attributes to a subject (i.e., creation of a subject). - Basic: Failure of binding of user security attributes to a subject (i.e., creation of a subject). - e) from FIA_UID.2: - Minimal: Successful use of the user identification mechanisms. - Minimal: Identification of the user identity provided. (Note: needs to be included in basic) - Basic: All attempts to use the user identification mechanism. D R A F T 1 - Commercial Security 1 (CS1) Protection Profile CCEB-94/086 Page 14 of 22 Version 0.9 94/10/31 - f) from FIA_UAU.1: - Minimal: Successful use of the authentication mechanism. - Basic: Any use of the authentication mechanism. - g) from FIA_ADP.1: - Minimal: Successful attempts to access user authentication data. - Basic: All attempts by an unauthorized user to access user authentication data. - h) from FIA_AAA.1: - Minimal: Successful use of any TSF authentication attribute management mechanism. - Basic: Any attempts to use the TSF authentication attribute management mechanisms. - Basic: Identification of which user authentication attributes have been modified. - i) from FAU_SEL.2: - All modifications to the audit configuration that occur while the audit collection mechanisms are operating shall be audited. - j) from FPT_TSA.2: - Use of security relevant administrative function. - Explicit requests to assume the security administrative role. FAU_GEN.2.2 The TSF shall record within each audit record the following information: date and time of the event, type of event, user responsible for the event, and success or failure of the event. In addition the TSF shall be able to include the following information: - TBD 79 FAU_PRO.1 Basic Audit Trail Protection FAU_PRO.1.1 The TSF shall limit access to read, modify and destroy the audit trail to authorized administrators. 80 FAU_SEL.2 Selective Audit by Individuals Only D R A F T CCEB-94/086 1 - Commercial Security 1 (CS1) Protection Profile 94/10/31 Version 0.9 Page 15 of 22 FAU_SEL.2.1 The authorized administrator shall be able to selectively audit the actions of one or more users based on individual identity. 81 FAU_STG.2 Prevention of Audit Data Loss FAU_STG.2.1 Conditions under which loss of audit data due to system failure can occur shall be enumerated and the potential number of audit events lost shall be determined. FAU_STG.2.2 In the event of audit storage exhaustion, the TSF shall be capable of preventing auditable actions from occurring. Actions from users authorized to control audit administration may be excluded. 82 FAU_MGT.1 Administration of Audit FAU_MGT.1.1 Administration control over audit mechanisms and access to audit data shall be restricted to authorized administrators and their delegates. 1.3.1.5 To satisfy CC/CS1 System Architecture: 83 FPT_SEP.1: TSF Domain Separation FPT_SEP.1.1: The TSF shall maintain a domain for its own execution that protects it from interference and tampering (e.g., modification or unauthorized observation of the TSF's code and data structures) by subjects external to the TSF. 84 FPT_TSA.2: Separate Security Administrative Role FPT_TSA.2.1: All security-relevant administrative functions shall be identified. FPT_TSA.2.2: The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the TSF; minimally, this set shall include the following services: - a) FDP_SAM.1 - Minimal attribute modification - b) FIA_ATA.2 - Basic user security attribute definition - c) FIA_AAA.1 - Minimal user authentication attribute administration - d) FAU_MGT.1 - Administration of Audit FPT_TSA.2.3: Use of the security-relevant administrative functions shall be restricted to a security administrative role that has clearly-defined boundaries. D R A F T 1 - Commercial Security 1 (CS1) Protection Profile CCEB-94/086 Page 16 of 22 Version 0.9 94/10/31 FPT_TSA.2.4: Only authorized users may be allowed to assume the security administrative role. FPT_TSA.2.5: An explicit request shall be made to the TSF in order for an authorized user to assume the security administrative role. 85 FPT_RVM.1: Mediation of a Defined Set of Objects FPT_RVM.1.1: A defined set of objects (and their associated security attributes) within the scope of the TSP shall be protected by the TSF. FPT_RVM.1.2: The TSF shall mediate all references by subjects external to the TSF to the objects (and their associated security attributes) protected by the TSF. FPT_RVM.1.3: Reference mediation shall ensure that all TSP enforcement functions are invoked before a reference to an object (or an associated security attribute) protected by the TSF is allowed to succeed. 1.3.1.6 To satisfy CC/CS1 System Integrity: 86 FPT_AMT.1: Periodic Abstract Machine Testing FPT_AMT.1.1: The TSF shall provide functions that can be used to periodically validate the correct operation of the protection-relevant functions provided by the TSF's underlying abstract machine. 1.3.2 Assurance requirements 87 This section provides the CC/CS1 assurance requirements, using an assurance level from Part 3. The structure of the assurance level and its components follows that of Part 1 annexes C and E respectively. 88 The assurance requirements for CC/CS1 consist of Assurance Level AL3, Structurally Tested, which is described in Part 3, chapter 3. 89 The assurance components comprising AL3 are the following: ADV_HLD.1- Informal architectural design ADV_TFC.1 - Informal model interpretation ADV_TIS.1 - Informal TSF interface specification ADV_LLD.1 - Informal detailed design ATE_FUN.2 - Minimal testing ATE_DPT.1 - Interface testing D R A F T CCEB-94/086 1 - Commercial Security 1 (CS1) Protection Profile 94/10/31 Version 0.9 Page 17 of 22 ATE_COV.1 - Complete coverage ATE_IND.1 - Third party testing AGD_USR.1 - End-user guidance AGD_ADM.1 - Administration guidance 1.3.3 Rationale for CC/CS1 functional requirements Editor Note: The rationale for requirements in a PP should show that the functional and assurance requirements are suitable to meet the security objectives. The characteristics and level of detail of such a rationale statement which would be useful in a PP are still under active consideration. Reviewers are invited to comment whether this material adds conceptually to the PP, and as used in this example PP whether the rationale statement is properly developed. 1.3.3.1 Access Control: 90 FDP_ACC.2 Resource access control Specifies that the policy must cover all operations on a resource if it covers any, but still permits the set of controlled resources to be chosen arbitrarily. It is then conceivable that a CC/CS1 compliant system need not specify any controlled resource. 91 FDP_ACC.4 Subset fixed protection TBD 92 FDP_ACM.1 Single identity-based access control Specifies that any operation on any controlled resource, as defined by the access control policy, be permitted or denied based on the identity of a single user. 93 FDP_ACM.3 Single group-based access control CC/CS1 also requires that access rights are controlled to the granularity of named individuals or groups of named individuals, or both. CC/CS1 compliant products can, depending on security policy, control which users can read or write certain files, and execute certain programs 94 FDP_SAM.1 Minimal attribute modification CC/CS1 reduces the likelihood that the values of relevant security attributes will be modified by unauthorised users. 95 FDP_SAI.1 Static attribute initialization D R A F T 1 - Commercial Security 1 (CS1) Protection Profile CCEB-94/086 Page 18 of 22 Version 0.9 94/10/31 CC/CS1 reduces the likelihood that relevant security attributes will be set improperly or that newly-created subjects, objects or users will be inadequately or inappropriately protected. 1.3.3.2 Object Reuse 96 FDP_RIP.2 Full deletion protection Full deletion protection reduces the likelihood that deleted information will be visible to unauthorised subjects or users. 1.3.3.3 Identification and Authentication 97 FIA_ATD.2 Basic user attribute definition Basic user attribute definition prevents the incorrect application of the TSP caused by inappropriate definition of user security attributes. 98 FIA_ATA.2 Basic user security attribute administration This requirement addresses incorrect set-up of user security and uncontrolled modification of user security attributes. 99 FIA_ATP.1 Minimal user attribute protection This requirement reduces the likelihood of unauthorized access to the user's security attribute definitions stored in the TOE. 100 FIA_USB.1 Minimal user-subject binding This requirement addresses the misuse of the user's security attributes attached to a subject, (i.e., by unexpected or incorrect association of inappropriate user security attributes). 101 FIA_UID.2 Unique identification of users This requirement reduces the likelihood of unidentified users obtaining access to TOE resources. 102 FIA_UAU.1 Basic user authentication This requirement addresses the unauthorized impersonation of a user's identity. Basic user authentication also reduces the likelihood of replay of authentication data to gain unauthorized access. 103 FIA_ADP.1 Basic user authentication data protection This requirement addresses the unauthorised modification of the user's authentication data and protects the confidentiality of this authentication information. D R A F T CCEB-94/086 1 - Commercial Security 1 (CS1) Protection Profile 94/10/31 Version 0.9 Page 19 of 22 104 FIA_AAA.1 Minimal user authentication attribute administration This requirement addresses unauthorised modification of the authentication policy attributes. 105 FDP_SAI.1 Static attribute initialisation This requirement provides for the correct and complete setup of relevant security attributes. Static attribute initialization also helps newly-created subjects, objects or users to be adequately protected. 106 FDP_SAM.1 Minimal attribute modification This requirement addresses the unauthorised modification of relevant security attributes. 107 FDP_SAQ.1 Minimal attribute query This requirement allows the values of security attributes to be known by authorised users only. 1.3.3.4 Audit 108 FAU_GEN.2 Basic Audit Generation CC/CS1 provides protection from misuse by auditing and imposing limits on which users can use certain resources. CC/CS1 provides individual accountability that, when used in conjunction with non-IT safeguards, can detect and mitigate the damage caused by fraudulent use of computing resources, and help identify the threat agent. 109 FAU_PRO.1 Basic Audit Trail Protection This requirement addresses modification and destruction of audit trail, which could have the result of hindering a subsequent investigation of illicit acts. This requirement also addresses the disclosure of the audit trail to unauthorized user. 110 FAU_SEL.2 Selective Audit by Individuals Only This requirement addresses the problem created by accumulation of audit data that could crash the TOE. This requirement also addresses problems that arise when inflexible audit selection is costly or impacts performance to an intolerable degree. 111 FAU_PRP.1 Symbolic Name Association This requirement addresses inconsistent interpretation of audit events between audit security functions and other security functions. D R A F T 1 - Commercial Security 1 (CS1) Protection Profile CCEB-94/086 Page 20 of 22 Version 0.9 94/10/31 112 FAU_STG.2 Prevention of Audit Data Loss This requirement allows for damage assessment based upon audit activity. 113 FAU_MGT.1 Administration of Audit This requirement addresses (1) inconsistency of setting up security audit parameters or attributes, or incorrect use of the audit tools, (2) uncontrolled modification or access of the security audit attributes, and (3) unauthorized modification or access of the security audit attributes 1.3.3.5 System Architecture 114 FPT_SEP.1 TSF Domain Separation This requirement reduces the likelihood of unauthorized observation and/or modification of the TSF's internal code or data. 115 FPT_TSA.2 Separate Security Administrative Role This requirement counters the potential for abuse of the TSF by those entities external to the TOE upon which the TOE's security depends (e.g., administrators, operators). 116 FPT_RVM.1 Mediation of a Defined Set of Objects This requirement counters illicit or errant software, or unauthorized users attempting to bypass security policy enforcement. Note that the requirements for reference mediation are not directly associated with a specific TOE security policy. It is unclear whether a statement such as this needs to be made explicitly. 1.3.3.6 System Integrity 117 FPT_AMT.1 Periodic Abstract Machine Testing This requirement reduces the likelihood that an internal failure of the underlying abstract machine will go undetected by the TSF and causing some form of TSP violation. 1.3.4 Rationale for CC/CS1 assurance requirements 118 Assurance level AL3 provides commercial quality assurances that the design objectives, captured in the high-level specifications, are implemented in the TOE. This is achieved by showing how the TLSO and security policy requirements are reflected in the first-level design documents (e.g., TSF interface specifications), and then providing evidence of the correspondence between the high-level design and the implementation. D R A F T CCEB-94/086 1 - Commercial Security 1 (CS1) Protection Profile 94/10/31 Version 0.9 Page 21 of 22 119 The intent of the assurances at AL3l is to establish that the external behaviour of the TOE conforms to its user-level and administrative documentation, with minimal analysis of the internal structure of the TSF. 120 Minimal levels of user and administrative guidance and product information are required. That which is required is sufficient for enabling the correct installation of the TOE and correct use of its protection features. 1.4 CC/CS1 Application notes 121 TBD D R A F T 1 - Commercial Security 1 (CS1) Protection Profile CCEB-94/086 Page 22 of 22 Version 0.9 94/10/31 D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 23 of 54 Chapter 2 Commercial Security 3 (CS3) Protection Profile Editor Note: Caveat: The material contained in this chapter is a very preliminary draft that has not yet been thoroughly reviewed or evaluated. It has not been approved at this stage for any use, either as a statement of requirements or for any type of evaluation purposes. This draft is provided with the Common Criteria (CC) review draft for two purposes: 1) to demonstrate at a first approximation that known requirement sets can be replicated by use of the CC approach and contents, and 2) to give reviewers the opportunity to review an example of usage of the CC functional and assurance requirements to form practical requirement sets Editor Note: This chapter presents the CS3 Protection Profile in a way that is consistent with the draft CC. CC/CS3 is based on the CS3 Protection Profile in the Federal Criteria. For simplicity of discussion, the term "CC/CS3" will be used to stand for Targets of Evaluation (TOEs) which are compliant with that Protection Profile. 2.1 Descriptive elements 2.1.1 Protection Profile Identifier: 122 Commercial Security 3 (CC/CS3) 2.1.2 Protection Profile Description: 123 The intent of CC/CS3 is to specify a strong set of features, mechanisms and assurances of broad applicability and effectiveness for general purpose multi-user operating systems (ref. FC, page CS-7, para 1.1 and page CS3-95, para 2.17.3). 124 CC/CS3 compliant products are expected to be used in both commercial and government environments. For government environments, CC/CS3 compliant products are intended to process sensitive-but-unclassified or single-level classified but not multi-level classified. (ref. FC, page CS1-18, para 2.2.3) 125 Products that comply with this Commercial Security 3 (CC/CS3) Protection Profile (PP) provide access control capabilities to separate users and data, based on finely grained access controls. 126 CC/CS3 incorporates centrally administered controls capable of enforcing access limitations on an individual basis, i.e., suitable for allowing an organisation to protect sensitive information and to keep users from reading, writing or destroying data. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 24 of 54 Version 0.9 94/10/31 127 Users are individually accountable for their actions through log-in procedures, auditing of security relevant events, and resource isolation. Through the use of role based access controls, a variety of organisation specific non-discretionary integrity and confidentiality policies can be specified and enforced. In addition, CC/CS3 provides strong authentication mechanisms, administrative tools, and requires an extensive degree of assurance evidence (ref. FC, page CS3-85). 2.1.3 Related Protection Profiles: 128 CC/CS1 Commercial Security 1 129 CC/CS2 Commercial Security 2 (TBD) 2.2 Top-level security objectives 130 These top-level security objectives (TLSO) for CC/CS3 describe assumptions about how the security features of a compliant product are intended to be used, the environment in which it is intended to operate, the threats within that environment, and the objectives to be met to counter these threats. (ref. FC, page CS3-87, para 2.17) 2.2.1 Usage assumptions 131 The CC/CS3 compliant products are used to manage computing, storage, input/ output, and to control the sharing of information among multiple users and IT processes. 132 CC/CS3 is applicable to IT products that provide facilities for on-line interaction with users. 133 CC/CS3 compliant products provide facilities for some or all users to create programs that use an Applications Programming Interface (API) to enable them to protect their objects from unauthorised use. (ref. FC, para 2.17.2) 134 Fail-safe defaults are included for the access control attributes for the defined subject and objects for the product. (ref. FC, para 2.17.2) 2.2.2 Environmental assumptions 2.2.2.1 Physical assumptions 135 Some, but not all, processing resources of the product, including terminals, are located within controlled access facilities. 136 The product's hardware, firmware and software critical to security policy enforcement will be physically protected from unauthorised modification. 137 CC/CS3 is intended for use in user areas that have differing levels of physical control and monitoring. D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 25 of 54 2.2.2.2 Personnel assumptions 138 There are competent persons assigned to manage the product and accurately configure permission sets. 139 Administrative and non-administrative users are uniquely identified. 140 User permissions and system-level access permissions are controlled by system administration. 141 For role based access control, administrators are responsible for interpreting and enforcing organisational policies and protection guidelines that are derived from existing laws, ethics, regulations, or generally accepted practices. (ref. FC, page CS3-94, para 2.17.1.5) 142 System administrators are selectively assigned privileges that are minimally necessary to perform their security related tasks. (ref. FC, page CS3-94, para 2.17.1.5) 143 The operational environment will be managed according to the documentation required by the assurance components. 2.2.2.3 Applicable Laws, Rules or Regulations 144 No specific laws, rules or regulations have been considered in formulating this PP. However, since CC/CS3 is intended to exceed the TCSEC C2 class, any regulation calling for C2 may be demonstrably satisfied by employing products compliant with this protection profile. 2.2.2.4 Relevant Organisational Considerations 145 CC/CS3 is intended for those commercial and government environments where benefit is derived by restricting access to programs, transactions, and information in a manner consistent with the assigned organisational role(s) of users. (ref. FC, page CS3-93, para 2.17.1.5) CC/CS3 provides a sufficient level of trust for law enforcement agencies, nuclear facilities, hospitals or commercial airports. (ref. FC, page CS3-95, para 2.17.3) 2.2.2.5 Assumed Connectivity 146 CC/CS3 contains no explicit network or distributed system requirements. CC/CS3 assumes that input and output interfaces are reliable, non-spoofable and non interceptable. Point-to-point interfaces to peripheral devices (e.g., printers, terminals, disk drives, tape backup) within a controlled space meet the CC/CS3 connectivity assumptions. The specification of resource access control is sufficiently flexible that a product developer could define a policy for dealing with networks at the CC/CS3 level. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 26 of 54 Version 0.9 94/10/31 2.2.2.6 Assumed informational assets Availability 147 CC/CS3 is appropriate for organisations that are intolerant of system failure. CC/ CS3 is intended to address a number of failure modes and has mechanisms that limit destruction and modification of data and applications that could result in rendering the IT system non-functional. Confidentiality 148 CC/CS3 is meant for use in situations where disclosure of sensitive information to another user is not acceptable. CC/CS3 requires IT products to be administered to prevent information from being widely distributed. However, CC/CS3 employs role based access controls that mitigate intentional and unintentional disclosure. Many environments operate under the assumption that organisational roles dictate the scope of a user's authority. CC/CS3 is intended for just such environments. Data Integrity 149 CC/CS3 has features to limit access of critical data to only certain individuals. CC/ CS3 provides the ability to bring under the control of specific qualified individuals data that must be accurate in order for the applications resident on the IT system to function properly and/or the organisation to monitor and control its operations. CC/ CS3 provides reasonable protection against unauthorised data modification in high threat- intensity environments. Protection from Misuse of Resources 150 CC/CS3 provides protection from misuse by auditing and imposing strongly enforced limits on which users can invoke certain processes. CC/CS3 provides individual accountability that, when used in conjunction with non-IT safeguards, can detect and mitigate the damage caused by fraudulent use of computing resources, and help identify the threat agent. 2.2.2.7 Environmental Security Conditions 151 CC/CS3 assumes that the attack frequency of highly sophisticated threat agents may not be limited by environmental characteristics and is not contained by other system elements or physical controls. 152 All CC/CS3 functional components are assumed to be complete and self- contained and, as such, are not dependent on any other products to perform as intended. 153 CC/CS3 supports cooperation with authentication type products. However, features such as exportation of audit records that might be useful in a distributed environment are not included in CC/CS3. D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 27 of 54 2.2.3 Statement of threat Editor Note: The threat information for CC/CS3 is presented here in a manner consistent with the current PP structure in draft Part 1 annex F of the CC. The statement of threat in a PP should be consistent with the usage and environment assumptions, and with those assumptions should form the basis for the security objectives. The characteristics and level of detail of threat information that would be useful in a PP are still under active consideration. Reviewers are invited to comment whether this material adds conceptually to the PP, and as used in this example PP whether the threats are properly developed. 154 CC/CS3 is applicable to environments where persons have different needs for access to IT resources, to include no need at all. CC/CS3 is primarily designed to handle insider threats in that environment and resist penetration from outsider threats. CC/CS3 is not intended to prevent users from abusing their authority. However, CC/CS3 can be used to strongly limit the scope of a user's authority in concert with that user's organisational roles and responsibilities. CC/CS3 is intended to operate in a benign physical environment. 155 CC/CS3 is sufficient for more hostile environments, in particular those in which the threat of malicious attacks aimed at discovering exploitable vulnerabilities is considered to be moderate. Thus, the primary threats addressed by this PP are those posed by someone with minimal skills or motivation, and with limited access to the resources or the detailed information required to discover subtle flaws. 2.2.3.1 Threats not countered 156 Within this context, the following is a list of threat agents that CC/CS3 is not intended to counter: a) Hostile system administration personnel, or b) Hostile individuals with physical access, engaged in theft, implantation of devices or alteration of physical configuration of the system. 2.2.3.2 Threats countered 157 CC/CS3 compliant products are intended for use in physically protected (or at least supervised areas) but may be able to resist prolonged attacks by highly capable hostile insiders or outsiders. 158 In general, CC/CS3 is intended to counter human threat agents who attempt to misuse the system, while it also counters incorrect or careless usage of the system. The following are five specific types of threats that CC/CS3 is intended to counter. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 28 of 54 Version 0.9 94/10/31 Threat Agent 1: People within the organisation not authorised to use the IT system 159 Opportunity: Insider (not a user) gaining physical access to a terminal, followed by issuance of commands from keyboard. 160 Expertise: No special knowledge, skills or ability with respect to the TOE are postulated, as the threat agent is not expected to be a user. Accordingly, it is expected that individual attacks may be easily frustrated. 161 Resources: No special hardware or software postulated. Frequency of attack could be high, while individual attacks would tend to be short (minutes to an hour). Amount of effort involved per attack is estimated as low to moderate. 162 Motivation: Assumed non-hostile motivations of curiosity or challenge. Threat Agent 2: Careless or negligent user 163 Opportunity: A user issuing inappropriate or incorrect commands from keyboard. 164 Expertise: Low to moderate levels of user knowledge, skills or ability with respect to the TOE are postulated. 165 Resources: No special hardware or software postulated. Frequency of attack could be high, while individual attacks could be lengthy. Amount of effort involved per attack is estimated as low to moderate. 166 Motivation: Assumed non-hostile motivations of poor attitude, job pressure, inadequate training, etc. No overt intent to harm is postulated. Threat Agent 3: Hostile user 167 Opportunity: User performing any intentional actions within the confines of own account, with the intent of harming the system or gaining inappropriate access to resources or information. 168 Expertise: Moderate to high levels of user technical knowledge, skills or ability with respect to the TOE are postulated. D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 29 of 54 169 Resources: Moderate access to special software (e.g., debuggers) is postulated. Frequency of attack is assumed moderate to high in postulated environment for CC/CS3, while individual attacks could be lengthy. Amount of effort involved per attack is estimated as high. 170 Motivation: Assumed hostile motivations of any sort, including fraud, revenge, enemy agent, sociopathic behaviour. Clear and strong intent to harm is postulated. Threat Agent 4: Hostile outsider or masquerading hostile insider 171 Opportunity: Outsider or insider masquerading as a user by gaining physical or logical access to input/output device, with the intent of harming the system or gaining inappropriate access to resources or information. 172 Expertise: High levels of technical knowledge, skills or ability with respect to the TOE are postulated. 173 Resources: Good access to special software (e.g., debuggers) is postulated. Frequency and duration of attack is assumed high in postulated CC/CS3 environment. Amount of effort involved per attack is estimated as high. 174 Motivation: Assumed hostile motivations of any sort, including fraud, revenge, enemy agent, sociopathic behaviour. Clear and strong intent to harm is postulated. Threat Agent 5: Careless or negligent system administrator 175 Opportunity: Authorised administrative user issuing inappropriate or incorrect commands from keyboard. 176 Expertise: High levels of user knowledge, skills or ability with respect to the TOE are postulated. 177 Resources: No special hardware or software postulated. Frequency of attack could be high, while individual attacks could be lengthy. Amount of effort involved per attack is estimated as low to moderate. 178 Motivation: Assumed non-hostile motivations of poor attitude, job pressure, inadequate training, etc. No overt intent to harm is postulated. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 30 of 54 Version 0.9 94/10/31 2.2.4 CC/CS3 security objectives Editor Note: The security objectives in a PP should be consistent with and be a logical consequence of the usage and environment assumptions and the statement of threat, and they should form the basis for the functional and assurance requirements. The characteristics and level of detail of the security objectives which would be useful in a PP are still under active consideration. Reviewers are invited to comment whether this material adds conceptually to the PP, and as used in this example PP whether the objectives are properly developed. 179 The following are the CC/CS3 security objectives: a) Prevent unauthorised logical entry into the IT system by providing a terminal log-in procedure to identify and authenticate users. b) Strongly limit hostile penetration by providing a terminal log-in procedure including identification and authentication. Include the capability to use additional authentication mechanisms such as smart cards, tokens or biometrics. c) Prevent log-in spoofing to acquire other users' passwords by providing Trusted Path d) Provide screen clearing and session locking functions to reduce the likelihood that a user will leave a terminal active while physically absent from their station, and which would therefore be vulnerable to a nearby unauthorised person. e) Detect repeated unsuccessful log-in attempts via auditing of such events. f) Detect attempts to misuse system resources or violate security policy by providing System Auditing. g) Limit individual access via identity-based access controls. h) Limit individual access by means of role based access controls. i) Provide role-based access control to permit system administration duties to be divided among a number of system administration personnel, so that no one individual needs to have access to all system software or configuration data. j) Support selective assignment of privileges to system administrators that are minimally necessary to perform their security related tasks. k) Include fail-safe defaults are for access control attributes. l) Provide time-based access control to allow selected operations to be performed during authorised time periods. D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 31 of 54 m) Provide origin-based access controls to limit where selection operation can be initiated. 2.3 Requirements 180 This section provides functional and assurance requirements that must be satisfied by a CC/CS3 compliant TOE. These requirements are taken from functional components and packages in Part 2 and an assurance level and assurance components in Part 3 of the CC. 181 The set of functional and assurance components for CC/CS3, described below, are equivalent to the CS3 Commercial Security 3 PP in the Federal Criteria. 2.3.1 Functional requirements 182 The security functional requirements for CC/CS3 consist of the following components from Part 2: 2.3.1.1 To satisfy CC/CS3 Access Control: 183 FDP_ACC.2 Resource access control FDP_ACC.2.1 The developer shall define the subset of resources to be controlled by the access control policy such that all operations on those resources are controlled. FDP_ACC.2.2 The TSF shall apply an access control policy to all operations on the controlled set of resources. FDP_ACC.2.3 The access control policy shall define, with respect to each operation on a controlled resource, the control that may exercised over the operation and how that control is specified. FDP_ACC.2.4 The access control policy shall define, with respect to each operation on a controlled resource, the responsible entities (users, subjects) who may exercise the control. 184 FDP_ACC.4: Subset fixed protection FDP_ACC.4.1 The TSF shall apply a fixed protection policy to some defined subset of operations outside the subset of operations to which any access control policy applies. 185 FDP_ACM.2: Identity-based access control FDP_ACM.2.1 The TSF shall provide an Identity-based access control mechanism to control the subset of operations governed by the access control policy. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 32 of 54 Version 0.9 94/10/31 FDP_ACM.2.2 The mechanism shall permit or deny access to operations based on the identity of the user performing the operation, or the user on whose behalf a subject is operating. FDP_ACM.2.3 The mechanism shall permit designation of multiple users permitted to perform an operation. FDP_ACM.2.4 The mechanism shall permit designation of multiple users forbidden to perform an operation. FDP_ACM.2.5 The maximum number of users that may be specified using the mechanism shall be defined, and shall be consistent with the intended use of the mechanism and the resources and/or operations it controls. 186 FDP_ACM.6: Role-based access control FDP_ACM.6.1 The TSF shall provide an role-based access control mechanism to control the subset of operations governed by the access control policy. FDP_ACM.6.2 The TSF shall provide a mechanism through which users or subjects may be assigned specific roles. FDP_ACM.6.3 The access control mechanism shall permit or deny operations based on the role in which a user or subject is operating. Editor Note: FDP_ACM.6 must be refined to require multiple roles be provided for access control. 187 FDP_ACM.7 Time-based access control FDP_ACM.7.1 The TSF shall provide a time-based access control mechanism to control the subset of operations governed by the access control policy. FDP_ACM.7.2 The access control mechanism shall permit specification of time intervals during which operations may or may not be performed, and shall permit or deny the operations on that basis. 188 FDP_ACM.8: Origin-based access control FDP_ACM.8.1 The TSF shall provide an origin-based access control mechanism to control the subset of operations governed by the access control policy. FDP_ACM.8.2 The access control mechanism shall permit specification of originating locations from which operations may or may not be performed, and shall permit or deny the operations on that basis. 189 FDP_SAM.1 Minimal attribute modification D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 33 of 54 FDP_SAM.1.1 The TSF shall limit the ability to modify relevant security attributes of objects, subjects and the users to a security administrator. 190 FDP_SAI.1 Static attribute initialization FDP_SAI.1.1 The TSF shall provide well-defined default values for relevant security attributes that are used to control the data protection mechanisms. FDP_SAI.1.2 In the absence of any overriding initial values, the TSF shall apply these default attributes when an object, user or subject is newly created. FDP_SAI.1.3 Any functions for specifying initial values shall be controlled in accordance with all the TSF's protection policies. 2.3.1.2 To satisfy CC/CS3 Object Reuse: 191 FDP_RIP.2 Full deletion protection FDP_RIP.2.1 The TSF shall ensure that the content of any resource or portion of any resource that is deleted or otherwise released to the TSF's control is protected such that no subject or user may subsequently view it in a way that would violate access control or information flow control policies. 192 FDP_RIP.4 Full creation protection FDP_RIP.4.1 The TSF shall ensure that the entire information content of any resource shall, when the resource is newly created or allocated, be determined from information that is accessible (in accordance with access control and information flow control policies) to the subject creating or allocating the resource. 2.3.1.3 To satisfy CC/CS3 Identification and Authentication: 193 FIA_ATD.2 Basic user attribute definition FIA_ATD.2.1 The TSF shall provide a unique association between each user and the policy attributes necessary to enforce the TSP. 194 FIA_ATA.2 Basic user security attribute administration FIA_ATA.2.1 The TSF shall provide default values for user security attributes to be used when initializing attributes for a user. FIA_ATA.2.2 The TSF shall provide the ability to display user security attributes. FIA_ATA.2.3 The TSF shall provide the ability to modify user security attributes. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 34 of 54 Version 0.9 94/10/31 195 FIA_ATP.1 Minimal user attribute protection FIA_ATP.1.1 The TSF shall protect user security attributes from unauthorized use, observation, modification, and destruction. 196 FIA_USB.1 Minimal user-subject binding FIA_USB.1.1 The TSF shall associate the appropriate security attributes of the user with subjects acting on behalf of that user in accordance with the TSP. 197 FIA_UID.2 Unique identification of users FIA_UID.2.1 For all users, the TSF shall uniquely identify the user before performing any TSF mediated actions on behalf of that user. 198 FIA_UAU.1 Basic user authentication FIA_UAU.1.1 The TSF shall provide a mechanism to authenticate any user's claimed identity. FIA_UAU.1.2 The TSF shall perform this authentication before performing any other TSF-mediated actions on behalf of the user. 199 FIA_UAU.6 Policy-based authentication mechanisms FIA_UAU.6.1 The TSF shall provide [2] different types of mechanisms to authenticate any user's claimed identity. FIA_UAU.6.2 The TSF shall enforce the use of separate authentication mechanisms for specific security attributes before performing any other TSF- mediated actions on behalf of the user, with authentication being successful if and only if all of the defined mechanisms individually indicate successful authentication. 200 FIA_UAU.7 Installable authentication mechanisms [component elements to be added] Editor Note: CS3 requires mechanisms to support password (secret) lifetimes and limits on repeated authentication attempts. There are currently no components in Part 2 that require these mechanisms, but Part 2 does contain a note that such components are needed. 201 FIA_ADP.1 Basic user authentication data protection FIA_ADP.1.1The TSF shall protect the stored authentication data from unauthorized use, observation, modification and destruction. 202 FIA_AAA.2: Basic user authentication attribute administration D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 35 of 54 [elements to be added] 203 FDP_SAI.1 Static attribute initialization [for user attributes] FDP_SAI.1.1 The TSF shall provide well-defined default values for relevant security attributes that are used to control the data protection mechanisms. FDP_SAI.1.2 In the absence of any overriding initial values, the TSF shall apply these default attributes when an object, user o subject is newly created. FDP_SAI.1.3 Any functions for specifying initial values shall be controlled in accordance with all the TSF's protection policies. 204 FDP_SAM.1 Minimal attribute modification [for user attributes] FDP_SAM.1.1 The TSF shall limit the ability to modify relevant security attributes of objects, subjects and users to authorised users. 205 FDP_SAQ.1 Minimal attribute query [for user attributes] FDP_SAQ.1.1 The TSF shall provide the ability for authorised users to display relevant security attributes. FDP_SAQ.1.2 The TSF shall provide at least one of the following options: - a) To display all relevant security attributes for an object, user or subject. - b) To display all the objects, users or subjects associated with a relevant security attribute. 2.3.1.4 To satisfy CC/CS3 Audit: 206 FAU_GEN.2 Basic Audit Generation FAU_GEN.2.1 The TSF shall be able to generate a record of the following auditable events: - a) Shutdown of the audit functions. - b) from FIA_ATA.2: - Minimal: Successful use of the user security attribute administration functions. - Basic: All attempted uses of the user security attribute administration functions. - c) from FIA_ATP.1: D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 36 of 54 Version 0.9 94/10/31 - Basic: All attempts by unauthorized users to use, observe, modify, or destroy user attributes. - d) from FIA_USB.1: - Minimal: Successful binding of user security attributes to a subject (i.e., creation of a subject). - Basic: Failure of binding of user security attributes to a subject (i.e., creation of a subject). - e) from FIA_UID.2: - Minimal: Successful use of the user identification mechanisms. - Minimal: Identification of the user identity provided - Basic: All attempts to use the user identification mechanism. - f) from FIA_UAU.7: - Minimal: Successful use of the authentication mechanism. - Basic: Any use of the authentication mechanism. - g) from FIA_ADP.1: - Minimal: Successful attempts to access user authentication data. - Basic: All attempts by an unauthorized user to access user authentication data. - h) from FIA_AAA.2: - Minimal: Successful use of any TSF authentication attribute management mechanism. - Basic: Any attempts to use the TSF authentication attribute management mechanisms. - Basic: Identification of which user authentication attributes have been modified. - I) from FAU_SEL.2: - All modifications to the audit configuration that occur while the audit collection mechanisms are operating shall be audited. - j) from FPT_TSA.3: D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 37 of 54 - Use of security relevant administrative function. - Explicit requests to assume the security administrative role. FAU_GEN.2.2 The TSF shall record within each audit record the following information: date and time of the event, type of event, user responsible for the event, and success or failure of the event. In addition the TSF shall be able to include the following information: - [The list of required information for each audit event type shall be formulated by the PP/ST author based on the auditable event definitions included in the other functional components of the PP/ ST.] 207 FAU_PRO.1 Basic Audit Trail Protection FAU_PRO.1.1 The TSF shall limit access to read, modify and destroy the audit trail to authorized administrators. 208 FAU_SEL.2 Selective Audit by Individuals Only FAU_SEL.2.1 The authorized administrator shall be able to selectively audit the actions of one or more users based on individual identity. FAU_SEL.2.2 If selectivity can be specified during runtime, the mechanism providing this selection capability shall be part of the TSF. 209 FAU_PRP.1 Symbolic Name Association FAU_PRP.1.1 The TSF shall be able to unambiguously associate an audit event to the symbolic name of the object of the user responsible for the event and the symbolic name of the object access (if applicable). 210 FAU_STG.2 Prevention of Audit Data Loss FAU_STG.2.1 Conditions under which loss of audit data due to system failure can occur shall be enumerated and the potential number of audit events lost shall be determined. FAU_STG.2.2 In the event of audit storage exhaustion, the TSF shall be capable of preventing auditable actions from occurring. Actions from users authorized to control audit administration may be excluded. 211 FAU_MGT.1 Administration of Audit FAU_MGT.1.1 Administration control over audit mechanisms and access to audit data shall be restricted to authorized administrators and their delegates. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 38 of 54 Version 0.9 94/10/31 2.3.1.5 To satisfy CC/CS3 System Integrity: 212 FPT_AMT.1 Periodic Abstract Machine Testing FPT_AMT.1.1 The TSF shall provide functions that can be used to periodically validate the correct operation of the protection-relevant functions provided by the TSF's underlying abstract machine. 2.3.1.6 To Satisfy CC-CS3 TOE entry: 213 FTE_TEB.2 Configurable TOE entry banners FTE_TEB.2.1 Prior to entering the TOE, the TSF shall display an advisory warning message to the user regarding unauthorized use of the TOE. FTE_TEB.2.2 The message displayed by the TSF shall indicate the possible consequences of failing to heed the warning. FTE_TEB.2.3 The following warning message shall displayed by default: [message] FTE_TEB.2.4 The warning message shall only be specifiable by a security administrator. 214 FTE_MCS.2 Per-user attribute limitation on multiple concurrent sessions FTE_MCS.2.1 The TSF shall provide a capability to limit the number of login sessions on a per user attribute basis. FTE_MCS.2.2 The number of concurrent login sessions shall only be specifiable by a security administrator. FTE_MCS.2.3 The TOE supplied default shall be a single login sessions for all authorised users. 215 FTE_TME.1 Basic time of entry FTE_TME.1.1 The TOE shall allow or deny TOE entry based on specified ranges of time. FTE_TME.1.2 Entry conditions using these ranges shall be specified using time-of-day, day-of-week, and calendar dates. FTE_TME.1.3 Entry conditions shall be specifiable only by a security administrator. 216 FTE_MDE.1 Basic mode of entry FTE_MDE.1.1 The TSF shall grant TOE entry only in accordance with the authenticated user's policy attributes. D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 39 of 54 FTE_MDE.1.2 TOE entry conditions shall be expressed in terms of users' attributes (e.g., greatest lower bound and least upper bound computations including the user levels, terminal levels, TOE levels). FTE_MDE.1.3 If no explicit TOE entry conditions are defined, the TOE entry default shall be used (i.e., the correct user authentication). FTE_MDE.1.4 Entry conditions shall be specifiable only by a security administrator. 217 FTE_TEM.2 Role-based TOE entry management FTE_TEM.2.1 The TSF shall provide a mechanism for authorized users to display and modify TOE entry parameters. FTE_TEM.2.2 The TSF shall provide the capability for at least one of the following options: a) To list all the TSP entry parameters for a user. b) To list all the users associated with a parameter. FTE_TEM.2.3 The TSF shall restrict use of these functions to a security administrator. FTE_TEM.2.4 The TSF shall provide an TOE entry administrator role which is limited to only performing those activities directly associated with TOE entry parameter administration. 218 FTE_SEH.1 Basic TOE entry history FTE_SEH.1.1 Upon a user's successful entry to the TOE, the TSF shall display the following data to the user and shall not remove them without user intervention: FTE_SEH.1.2 The date, time, means of access and port of entry of the last successful entry to the TOE; and FTE_SEH.1.3 The number of successful, unsuccessful attempts to access the TOE since the last successful entry by the identified user. 219 FTE_SSL.2 User-initiated locking FTE_SSL.2.1 The TSF shall either lock or terminate an interactive session after an administrator-specified interval of user inactivity. FTE_SSL.2.2 The default value for this interval shall be specified. FTE_SSL.2.3 The TSF shall provide a mechanism to allow user-initiated locking of the user's own interactive sessions that include: - clearing or over-writing display devices to make the current contents unreadable; D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 40 of 54 Version 0.9 94/10/31 - requiring user authentication prior to locking the session; - disabling any activity of the user's data entry/display devices other then unlocking the session. 2.3.1.7 To Satisfy CC-CS3 Trusted Path: 220 FTP_TRP.1 Basic Trusted Path FTP_TRP.1.1 The TSF shall provide a capability for a logically isolated and unmistakably distinguishable communication path between itself and any user. FTP_TRP.1.2 Communications via the trusted path shall be initiated exclusively by the user. FTP_TRP.1.3 The trusted path shall be used for the following TSF services: - Initial authentication 2.3.1.8 To Satisfy CC-CS3 Security Management 221 FPT_TSA.3 Multiple Security Administrative Roles FPT_TSA.3.1 All security-relevant administrative functions shall be identified. FPT_TSA.3.2 The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the TSF; minimally, this set shall include the following services: - a) FDP_SAM.1 - Minimal attribute modification - b) FIA_ATA.2 - Basic user security attribute definition - c) FIA_AAA.1 - Minimal user authentication attribute administration - d) FAU_MGT.1 - Administration of Audit FPT_TSA.3.3 The set of security administrative roles shall be defined, and shall minimally include the following: - [The set of defined roles to be minimally supported should be identified by the profile writer.] FPT_TSA.3.4 Each security-relevant administrative function shall be assigned to at least one security administrative role. D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 41 of 54 FPT_TSA.3.5 Use of a security-relevant administrative function shall be restricted to the security administrative role(s) authorized to use that function. FPT_TSA.3.6 Users shall be allowed to assume only those security administrative roles for which they have been authorized. FPT_TSA.3.7 An explicit request to assume a specific security administrative role shall be made to the TSF in order for an authorized user to assume that security administrative role. 2.3.1.9 To Satisfy CC/CS3 Reference Mediation 222 FPT_RVM.1 Mediation of a Defined Set of Objects FPT_RVM.1.1 A defined set of objects (and their associated security attributes) within the scope of the TSP shall be protected by the TSF. FPT_RVM.1.2 The TSF shall mediate all references by subjects external to the TSF to the objects (and their associated security attributes) protected by the TSF. FPT_RVM.1.3 Reference mediation shall ensure that all TSP enforcement functions are invoked before a reference to an object (or an associated security attribute) protected by the TSF is allowed to succeed. 2.3.1.10 To Satisfy CC-CS3 Resource-Allocation Requirements 223 FRU_RSA.1 Simple Quotas FRU_RSA.1.1 For each of the following resources: [Assignment: fill in list of resources, such as processes, disk space, memory, bandwidth, etc.], the TSF shall enforce quotas limiting the maximum quantity of each resource which a subject or defined group of subjects can use at any one time or over a given period of time. FRU_RSA.1.2 For each controlled resource, there shall be an administrative interface allowing an authorized user to set the resource limits for each defined resource. 2.3.1.11 To Satisfy CC/CS3 TCB Protection 224 FPT_SEP.1 TSF Domain Separation FPT_SEP.1.1The TSF shall maintain a domain for its own execution that protects it from interference and tampering (e.g., modification or unauthorized observation of the TSF's code and data structures) by subjects external to the TSF. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 42 of 54 Version 0.9 94/10/31 Editor Note: More detail on domain separation was provided in the FC. Additional components are needed in FPT_SEP to meet CS3. 2.3.1.12 To Satisfy CC/CS3 Physical TCB Protection 225 FPP_PHP.1 Passive Detection of Physical Attack FPP_PHP.1.1 The TOE shall include features that provide unambiguous detection of physical tampering (i.e., unauthorized physical access or modification) to the TSF's physical devices and elements. FPP_PHP.1.2 The TSF shall provide security administrative functions that indicate whether physical tampering (i.e., unauthorized physical access or modification) to the TSF's physical devices and elements has been detected. 2.3.1.13 To Satisfy FC-CS3 TCB Self-Checking [TBD] 2.3.1.14 To Satisfy CC/CS3 TCB Initialization and Recovery [TBD] 2.3.2 Assurance requirements 226 This section provides the CC/CS3 assurance requirements, using an assurance level and assurance components from Part 3. The structure of the assurance level and components follows that of Part 1 annexes C and E respectively. 227 The assurance requirements for CC/CS3 consist of Assurance Level AL3 Augmented -- Advanced Commercial Security, including AL3, Structurally Tested, plus a set of augmentation assurance components from Part 3. 2.3.2.1 AL3 assurance components 228 The assurance components comprising AL3 are the following: ADV_HLD.1- Informal architectural design ADV_TFC.1 - Informal model interpretation ADV_TIS.1 - Informal TSF interface specification ADV_LLD.1 - Informal detailed design ATE_FUN.2 - Minimal testing ATE_DPT.1 - Interface testing ATE_COV.1 - Complete coverage D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 43 of 54 ATE_IND.1 - Third party testing AGD_USR.1 - End-user guidance AGD_ADM.1 - Administration guidance 2.3.2.2 Augmentation assurance components 229 The augmentation components to AL3 which are required to meet CC/CS3 assurance requirements comprise the following: ADV_HLD.2 - Identification of security enforcing components AVA_VLA.3 - Flaw removal ALC_FLR.2 - Flaw reporting procedures ADO_IGS.2 - Generation log ALC_LCD.1 - Developer defined life-cycle process ACM_SCP.3 - Problem tracking CM coverage ACM_CAP.3 - Regeneration support ALC_DVS.1 - Identification of security measures 230 Each augmentation component and its elements are shown below: 231 ADV_HLD.2: Identification of security enforcing components ADV_HLD.2.1D The developer shall provide the architectural design of the TSF. ADV_HLD.2.2D The developer shall argue that the architectural design of the TSF is an implementation of the security functional specification. ADV_HLD.2.1C The presentation of the architectural design shall be informal. ADV_HLD.2.2C The architectural design shall describe the general structure of the TSF. ADV_HLD.2.3C The architectural design shall describe the components of the TSF in terms of major elements (e.g., hardware, kernel, servers) visible from a point-of-view external to the TSF. ADV_HLD.2.4C The architectural design shall divide the components of the TOE into security enforcing, security relevant, and other components, and describe how this separation is achieved. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 44 of 54 Version 0.9 94/10/31 ADV_HLD.2.5C The architectural design shall describe those components of the TSF that provide an external interface to the TSF. ADV_HLD.2.6C The architectural design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. ADV_HLD.2.7C For each component in the TSF, the architectural design shall describe the security functions provided by that component. ADV_HLD2.8C The architectural design shall contain an argument that the TSF mechanisms are an implementation of the security functional specification. 232 AVA_VLA.3: Flaw removal AVA_VLA.3.1D: The developer shall perform a search for obvious ways in which an unauthorized user can bypass or otherwise defeat the security mechanisms of the TSF. AVA_VLA.3.2D: The developer shall perform a search for obvious flaws that would allow violation of resource isolation or that would permit unauthorized access to the audit or authentication data. AVA_VLA.3.3D: The developer shall assemble a team of individuals who thoroughly understand the specific implementation of the TSF. AVA_VLA.3.4D: The developer shall produce available design documentation, source code, and object code. AVA_VLA.3.5D: A test team shall subject the design documentation, source code, and object code to thorough analysis and testing. Their objective shall be to uncover all design and implementation flaws that would permit an untrusted subject to read, change, or delete data normally denied under the security policies, or that would cause the TOE to enter a state such that it is unable to respond to communications initiated by other users. AVA_VLA.3.6D: The developer shall identify for each test the goal of the test and the criteria for success. AVA_VLA.3.7D: The developer shall define the TSF configuration, interface, and protection functions that are subject to penetration tests. AVA_VLA.3.8D: The developer shall demonstrate that previously discovered security flaws in the TSF have been removed. D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 45 of 54 AVA_VLA.3.9D: The developer shall remove or neutralize all flaws discovered, and shall re-test the TSF to demonstrate that the flaws have been eliminated and new flaws have not been introduced. AVA_VLA.3.1C: The documentation shall consist of test plans, test procedure description, and the test results. The documentation shall also include design documentation, source code, and object code. AVA_VLA.3.2C: The test plan shall describe the tests to be performed. AVA_VLA.3.3C: The test results shall show the results of each test. AVA_VLA.3.4C: The developer shall provide recommendations for corrective action in case of attacks that result in a violation of resource isolation or access to TSF internal data. AVA_VLA.3.5C: The test evidence shall identify all product documentation upon which the search for flaws was based. AVA_VLA.3.6C: The penetration evidence shall describe the scenarios for exploiting each potential flaw and the penetration conditions, data (e.g., test setup, function call parameters, and test outcomes), coverage, and conclusions derived from each scenario. AVA_VLA.3.7C: The test plan shall include tests that attempt to exercise flaws discovered in previous versions of the TSF. AVA_VLA.3.8C: The test procedures shall include tests to demonstrate the absence of all flaws discovered in previous versions of the TSF. AVA_VLA.3.9C: The test results shall describe the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target and that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. 233 ALC_FLR.2: Flaw reporting procedures (Augmentation to AL3) ALC_FLR.2.1D: The developer shall establish a procedure to track all reported security flaws in each release of the TOE. ALC_FLR.2.2D: The developer shall use a tracking system that includes a description of the nature and effect of each flaw and the status of finding a correction to that flaw. ALC_FLR.2.3D: The developer shall establish a procedure to identify corrective actions for security flaws. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 46 of 54 Version 0.9 94/10/31 ALC_FLR.2.4D: The developer shall use a procedure that separates security relevant and non-security relevant corrections, changes, or updates to the TOE. ALC_FLR.2.5D: The developer shall establish a procedure to provide flaw information and corrections to registered users. ALC_FLR.2.6D: The developer shall establish a procedure for accepting user reports of security problems and requests for corrections to those problems. ALC_FLR.2.7D: The developer shall designate one or more specific points of contact for user reports and inquires about security issues involving the TOE. ALC_FLR.2.8D: The developer shall produce flaw remediation documentation. ALC_FLR.2.1C: The flaw remediation documentation shall describe the procedures used to track security flaws, identify corrective actions for those flaws, and disseminate the flaw corrections to users. ALC_FLR.2.2C: The point of contacts, and the procedures for reporting and inquiring about security issues, shall be provided in user documentation. 234 ADO_IGS.2: Generation log (Augmentation to AL3) ADO_IGS.2.1D: The developer shall establish procedures for the secure installation, generation, and start-up of the TSF. ADO_IGS.2.2D: The developer shall provide procedures for the secure installation, generation, and start-up of the TSF. ADO_IGS.2.3D: The developer shall produce installation, generation, and start-up documentation. ADO_IGS.2.1C: The documentation shall describe the procedures established for the secure installation, generation, and start-up of the TSF from the delivered copy of the master TSF. ADO_IGS.2.2C: The generation procedures shall be capable of creating a log containing the generation options used to generate the TSF in such a way that it is possible to determine exactly how and when the TSF was generated. 235 ALC_LCD.1: Developer defined life-cycle process (Augmentation to AL3) ALC_LCD.1.1D: The developer shall establish a life-cycle process to be used in the development and maintenance of the TOE. D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 47 of 54 ALC_LCD.1.2D: The developer shall produce life-cycle definition documentation. ALC_LCD.1.1C: The life-cycle definition documentation shall describe the process used to develop and maintain the TOE. 236 ACM_SCP.3: Problem tracking CM coverage (Augmentation to AL3) ACM_SCP.3.1D: The developer shall maintain the following configuration items under a configuration management system: design documentation, source code, object code, test documentation, hardware, firmware, and flaws. ACM_SCP.3.2D: The developer shall produce configuration management documentation. ACM_SCP.3.1C: The configuration management documentation shall show that all of the configuration items are maintained under a configuration management system. 237 ACM_CAP.3: Regeneration support (Augmentation to AL3) ACM_CAP.3.1D: The developer shall develop a configuration management plan. ACM_CAP.3.2D: The developer shall use a configuration management system to ensure that only authorised changes are made to the TOE configuration items. ACM_CAP.3.3D: The developer shall use a configuration management system to ensure that consistency is maintained between the multiple levels of TOE abstractions. ACM_CAP.3.4D: The developer shall use a configuration management system that permits the regeneration of any supported version of the TOE. ACM_CAP.3.5D: The developer shall maintain a configuration list for the TOE. ACM_CAP.3.6D: The developer shall produce configuration management documentation. ACM_CAP.3.1C: The configuration management documentation shall consist of a configuration list and a configuration management plan. ACM_CAP.3.2C: The configuration list shall state the configuration items that comprise the TOE and those items fundamental to the generation of the TOE. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 48 of 54 Version 0.9 94/10/31 ACM_CAP.3.3C: The configuration list shall state the method used to uniquely identify the TOE items. References to configuration items shall use these unique identifiers. ACM_CAP.3.4C: The configuration management plan shall state how the configuration management system is used in practice and how it is applied in the manufacturing process in accordance with quality management procedures. 238 ALC_DVS.1: Identification of security measures (Augmentation to AL3) ALC_DVS.1.1D: The developer shall produce development security documentation. ALC_DVS.1.2D: The developer shall ensure that the security measures are followed during development and maintenance of the TOE. ALC_DVS.1.1C: The development security documentation shall identify the physical, procedural, personnel, and other security measures that are used to protect the confidentiality and integrity of the TOE. 2.3.3 Rationale for CC/CS3 functional requirements Editor Note: The rationale for requirements in a PP should show that the functional and assurance requirements are suitable to meet the security objectives. The characteristics and level of detail of such a rationale statement which would be useful in a PP are still under active consideration. Reviewers are invited to comment whether this material adds conceptually to the PP, and as used in this example PP whether the rationale statement is properly developed. 2.3.3.1 CC/CS3 Access Control Rationale Multiple access control mechanisms are provided by CC/CS3 in order to support a wide range of environments and control requirements. The combination of access rights based on identity, role, physical location and time of access allows an organization employing a CC/CS3 compliant product to fine tune security enforcement along realistic organizational and operational lines. 239 FDP_ACC.2: Resource access control Rationale This component specifies that the policy must cover all operations on a resource if it covers any, but still permits the set of controlled resources to be chosen arbitrarily. permits Specifies that the policy must cover all operations on a resource if it covers any, but still the set of controlled resources to be chosen arbitrarily. 240 FDP_ACC.4Subset fixed protection Rationale D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 49 of 54 The AFS_SPC Security Functional Specification shall define the subset of operations controlled by the policy, describe the intended use of the operations, and provide a detailed rationale for the scope of the subset. 241 FDP_ACM.6 Role-based access control Rationale Role-based access controls recognise allow for direct control and administration of computer access rights based on job duties and responsibilities. The computer based role can be made to mirror the role of an individual within the organization. Security administration becomes more intuitive and easier since there can be less ambiguity in explicitly defined roles as opposed to administration of access rights based on what can appear to be arbitrary group definition. 242 FDP_ACM.7 Time-based access control Rationale Time-based access controls recognise the concept of normal business hours. Certain activities, and the related computer-based operations, take place during particular hours. Transactions such as customer withdrawal of funds from accounts can be restricted to normal bank hours. Customer service transactions attempted after bank closing may be risky. Time-based access control limit the intervals when a system may be susceptible to abuse. 243 FDP_ACM.8 Origin-based access control Rationale CC/CS3 provides origin-based controls to allow tailorability of information services in consideration of the physical facility layout. Origin- based access controls can reduce the likelihood that extensive system misuse could originate from user terminals located in exposed areas such as airport ticket counters or bank lobbies. 244 FDP_SAM.1 Minimal attribute modification CC/CS3 reduces the likelihood that the values of relevant security attributes will be modified by unauthorised users. 245 FDP_SAI.1 Static attribute initialization CC/CS3 reduces the likelihood that relevant security attributes will be set improperly or that newly-created subjects, objects or users will be inadequately or inappropriately protected. 2.3.3.2 CC/CS3 Object Reuse Rationale 246 FDP_RIP.2 Full deletion protection Full deletion protection reduces the likelihood that deleted information will be visible to unauthorised subjects or users. D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 50 of 54 Version 0.9 94/10/31 2.3.3.3 CC/CS3 Identification and Authentication Rationale 247 FIA_ATD.2 Basic user attribute definition Basic user attribute definition prevents the incorrect application of the TSP caused by inappropriate definition of user security attributes. 248 FIA_ATA.2 Basic user security attribute administration This requirement addresses incorrect set-up of user security and uncontrolled modification of user security attributes. 249 FIA_ATP.1 Minimal user attribute protection This requirement reduces the likelihood of unauthorized access to the user's security attribute definitions stored in the TOE. 250 FIA_USB.1 Minimal user-subject binding This requirement addresses the misuse of the user's security attributes attached to a subject, (i.e., by unexpected or incorrect association of inappropriate user security attributes). 251 FIA_UID.2 Unique identification of users This requirement reduces the likelihood of unidentified users obtaining access to TOE resources. 252 FIA_UAU.1 Basic user authentication This requirement addresses the unauthorized impersonation of a user's identity. Basic user authentication also reduces the likelihood of replay of authentication data to gain unauthorized access. 253 FIA_ADP.1 Basic user authentication data protection This requirement addresses the unauthorised modification of the user's authentication data and protects the confidentiality of this authentication information. 254 FIA_AAA.1 Minimal user authentication attribute administration This requirement addresses unauthorised modification of the authentication policy attributes. 255 FDP_SAI.1 Static attribute initialization This requirement provides for the correct and complete setup of relevant security attributes. Static attribute initialization also helps newly-created subjects, objects or users to be adequately protected. D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 51 of 54 256 FDP_SAM.1 Minimal attribute modification This requirement addresses the unauthorised modification of relevant security attributes. 257 FDP_SAQ.1 Minimal attribute query This requirement allows the values of security attributes to be known by authorised users only. 2.3.3.4 CC/CS3 Audit Rationale 258 FAU_GEN.2 Basic Audit Generation CC/CS3 provides protection from misuse by auditing and imposing limits on which users can use certain resources. CC/CS3 provides individual accountability that, when used in conjunction with non-IT safeguards, can detect and mitigate the damage caused by fraudulent use of computing resources, and help identify the threat agent. 259 FAU_PRO.1 Basic Audit Trail Protection This requirement addresses modification and destruction of audit trail, which could have the result of hindering a subsequent investigation of illicit acts. This requirement also addresses the disclosure of the audit trail to unauthorized user. 260 FAU_SEL.2 Selective Audit by Individuals Only This requirement addresses the problem created by accumulation of audit data that could crash the TOE. This requirement also addresses problems that arise when inflexible audit selection is costly or impacts performance to an intolerable degree. 261 FAU_PRP.1 Symbolic Name Association This requirement addresses inconsistent interpretation of audit events between audit security functions and other security functions. 262 FAU_STG.2 Prevention of Audit Data Loss This requirement allows for damage assessment based upon audit activity. 263 FAU_MGT.1 Administration of Audit This requirement addresses (1) inconsistency of setting up security audit parameters or attributes, or incorrect use of the audit tools, (2) uncontrolled modification or access of the security audit attributes, and (3) unauthorized modification or access of the security audit attributes D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 52 of 54 Version 0.9 94/10/31 2.3.3.5 CC/CS3 System Architecture Rationale 264 FPT_SEP.1 TSF Domain Separation This requirement reduces the likelihood of unauthorized observation and/or modification of the TSF's internal code or data. 265 FPT_TSA.2 Separate Security Administrative Role This requirement counters the potential for abuse of the TSF by those entities external to the TOE upon which the TOE's security depends (e.g., administrators, operators). 266 FPT_RVM.1 Mediation of a Defined Set of Objects This requirement counters illicit or errant software, or unauthorized users attempting to bypass security policy enforcement. Note that the requirements for reference mediation are not directly associated with a specific TOE security policy. It is unclear whether a statement such as this needs to be made explicitly. 2.3.3.6 CC/CS3 System Integrity Rationale 267 FPT_AMT.1 Periodic Abstract Machine Testing This requirement reduces the likelihood that an internal failure of the underlying abstract machine will go undetected by the TSF and causing some form of TSP violation. 2.3.4 Rationale for CC/CS3 assurance requirements 268 The augmented AL3 set of assurance requirements provides a minimal degree of confidence that exploitable flaws are discovered and, at least, removed or obviated in later versions. Accordingly, vulnerability analysis, configuration management, and flaw remediation requirements are added and testing requirements are strengthened. Additionally, minimal controls on the development environment are added. 269 The intent at this level remains that of establishing that the external behaviour of the TOE conforms to its user-level and administrative documentation without any analysis of its internal structure of the TCB. 270 Minimal levels of user and administrative guidance and product information are required, sufficient for enabling the correct installation of the TOE and use of its protection features. 271 Elementary flaw discovery and analysis are introduced, as well as the requirements for flaw remediation and additional testing directed toward determining that discovered flaws and previously-known flaws are removed or neutralised. D R A F T CCEB-94/086 2 - Commercial Security 3 (CS3) Protection Profile 94/10/31 Version 0.9 Page 53 of 54 2.4 CC/CS3 Application notes 272 TBD D R A F T 2 - Commercial Security 3 (CS3) Protection Profile CCEB-94/086 Page 54 of 54 Version 0.9 94/10/31