Common Criteria for Information Technology Security Evaluation Protection Profile. General-Purpose Operating System Protection Profile

Transcription

1 Common Criteria for Information Technology Security Evaluation Protection Profile General-Purpose Operating System Protection Profile

2 Table of contents Table of Contents 1 INTRODUCTION PP reference TOE overview TOE usage TOE type Non TOE Hardware and Software Structure of the Protection Profile Terminology Users Groups Subjects Resources Objects Security attributes Trusted users/subjects Security policy Storage object types References Abbreviations PP CONFORMANCE CLAIM CC Conformance Claim PP Claim, Package Claim Conformance Rationale Conformance required by OSPP Extended Packages SECURITY PROBLEM DEFINITION TOE assets Storage TSF Threats Threats countered by the TOE Organizational Policies Policies addressed by the TOE Assumptions Physical aspects Personnel aspects Procedural aspects Connectivity aspects Page 2 of 237 CC version

3 Table of contents 4 SECURITY OBJECTIVES Security Objectives for the TOE Security Objectives for the Operational Environment Security Objectives rationale Security Objectives coverage Security Objectives sufficiency EXTENDED COMPONENTS DEFINITION Functional Extended Components FIA_PKI.1_TEMPLATE Public key based authentication FMT_ERM.1_TEMPLATE Remote Management Capabilities SECURITY REQUIREMENTS FOR THE TOE Functional Security Requirements Requirements related to security audit capabilities of the TOE Requirements related to the protection of the user data Requirements related to identification and authentication Requirements related to security management Requirements related to the protection of the TSF Requirements related to the access to the TOE Requirements related to the use of trusted channels Assurance Security Requirements Tailored Assurance Package for Operating Systems Rationale for the Security Requirements Internal Consistency of Requirements Security Requirements Coverage Security Requirements Dependency Analysis Rationale for unresolved dependencies: Security Assurance Requirements Rationale A OSPP FRAMEWORK A.1 Mandatory information given by the ST A.1.1 Conformance claim A.1.2 SFR reference with OSPP extended package reference A.2 Mandatory information given by OSPP extended packages A.2.1 Extended package identification A.2.2 Extended package composition rules A.2.3 Specification of OSPP extended packages A.3 Specification restricted to the OSPP base B OSPP BASE INTRODUCTION B.1 TOE overview B.1.1 Auditing B.1.2 User data protection B.1.3 Discretionary access control CC version 3.1 Page 3 of 237

4 Table of contents B.1.4 Network information flow control B.1.5 Identification and authentication B.1.6 Management of security mechanisms B.1.7 Trusted channel B.2 Co-operating trusted systems B.3 TOE boundary C ASSURANCE REQUIREMENTS AND EVALUATION ACTIVITIES C.1 Assurance package for the PP Page 4 of 237 CC version

5 List of figures List of figures Figure 1 - Types of TOE instances and their boundaries CC version 3.1 Page 5 of 237

6 List of tables List of tables Table 1 Coverage of security objectives for the TOE Table 2 Coverage of security objectives for the TOE environment Table 3 TOE threats sufficiency Table 4 Security policies sufficiencyc Table 5 Assumptions sufficiency Table 6 Minimum set of auditable events with event specific information Table 7 Tailored Security Assurance Requirements Table 8 Security Functional Requirements coverage Table 9 Security Functional Requirements rationale Table 10 Security Functional Requirements dependency analysis Table 11 Security Assurance Requirements dependency analysis Page 6 of 237 CC version

7 Introduction 1 Introduction 1 This document defines the security functionality expected to be provided by a general-purpose operating system capable of operating in a networked environment. It also provides a set of assurance components that define the minimum set to be used in an evaluation of an operating system for compliance with this Protection Profile. Part 2 of this PP defines the general approach and assurance activities required to be performed during the evaluation, thereby refining the stated assurance components. 2 Unlike most other Protection Profiles, the General-Purpose Operating System Protection Profile (OSPP) is structured into a base part and a set of (optional) extended packages. This structure was chosen to maximize adaptability for different operational environments and different operational requirements, since general-purpose operating systems may provide a wide range of different functionality. In this draft of the harmonized OSPP, extended packages are not yet available. 3 General-purpose operating systems often operate in environments that provide centralized services that can be used by a large number of systems within an organization. It is expected that a modern general-purpose operating system provides the capability to use centralized services for the implementation of security functionality, for example, authentication servers, directory servers, certification services, or audit log servers. While most modern general-purpose operating systems implement functions such as centralized security services, they may also be able to act as the server for those services. Candidates for an extended package must have the capability to act as a server for a centralized security service. 4 Co-operating with another trusted IT system to provide a security service is not restricted to the use of centralized services, but can also be accomplished in a peer-to-peer relationship. An example is a function for the authentication of a human user that is based on a token the user needs to present, for example, a smartcard. In this scenario, the user authenticates to the smart card using his PIN, and the smartcard authenticates the user to the operating system, for example, by presenting the user's certificate and assuring the operating system that it has the private key associated with the public key in the certificate. 5 The security functional requirements specified in this base document specify functions that the operating system needs to provide without online support from other IT systems in its environment. Functions that rely on support of the operational environment will be left to extended packages or ST specific extensions. 6 Operating systems conformant to this Protection Profile are assumed to operate in an environment in which the platform on which they execute (hardware, devices and firmware) is protected from physical attacks and CC version 3.1 Page 7 of 237

8 Introduction manipulation. In addition, it is assumed that all management activities are performed by knowledgeable and trustworthy users. 1.1 PP reference 7 Title: General-Purpose Operating System Protection Profile 8 Version: Version Author: OSPP Technical Community 10 Publication date: TOE overview TOE usage 11 The OSPP covers general-purpose operating systems that provide a multiuser and multi-tasking environment. 12 The main purpose of a general-purpose operating system (from a security point of view) is to provide defined objects, resources and services to entities using the functions provided by the operating system at its external interfaces, and to enforce a defined policy on access to objects, use of resources, and use of services. At a minimum, the operating systems addressed by this Protection Profile export interfaces to programs executing on top of the operating systems and interfaces to external entities, including network interfaces, as well as interfaces to devices that are used to transport data or actions of external entities to the operating system (for example, a keyboard and a mouse). In addition, the operating system uses functions of the underlying hardware and software to provide its functions, including using devices that are not connected to an external entity such that this entity could affect the behavior of the device directly (for example, hard disks or displays). 13 An operating system conformant to this Protection Profile can be operated as a server system within a data center, but also as a client system used directly by one or more human users. While it is mandatory that an operating system conformant to this Protection Profile must be capable of providing and using some basic network services, such a system may also be started in an environment where it is not connected to any network and with the network services inactive. It is mandatory that an operating system conformant to this Protection Profile must provide basic security functionality for user identification and authentication, access control, management and audit. 14 The TOE will provide user services directly or serve as a platform for networked applications, and will support protected communication using one or more cryptographically-protected network protocols or the support of dedicated, physically-separated network links. To support protected communication, the TOE must implement at least the TCP/IP network Page 8 of 237 CC version

9 Introduction protocol family; this Protection Profile makes no statements about the version of IP. 15 The OSPP addresses general-purpose operating systems operating in a wellmanaged enterprise environment. This addresses mostly servers, but also desktop clients if their operating environment fulfills the security problems defined in chapter 4, as well as the security problems defined by any OSPP extended packages claimed in the ST. These security problems include requirements for professional management of the system and basic protection against physical attacks that can be found in enterprise or government environments, but typically not in home environments administered by private users. The enterprise or government environments may include setups for mobile systems or home-offices provided that the TOE implements mechanisms that allow these environments to comply with the security problem definition in this PP. The OSPP makes no claims or statements that it specifically applies to either a server operating system or a client operating system. If an operating system meets the requirements defined in the security problem definition of the OSPP base, with or without any extended packages, the operating system can claim conformance to this Protection Profile TOE type 16 The requirements defined in this PP shall be applicable to general-purpose operating systems. 17 The OSPP shall provide a framework for specifying requirements to be provided by a general-purpose operating system Non TOE Hardware and Software 18 The operating systems covered by the OSPP have dependencies on their underlying platform, which usually consists of hardware (processors, memory, devices) and firmware. In some cases, the operating system may execute on a separate software layer that provides logical partitioning or a virtualization layer. Such virtualization emulates all or part of the hardware in a manner that is either transparent to the TOE or by having the TOE using dedicated interfaces to the virtualization layer. In any case, the interfaces to the underlying platform must be defined and described to allow analysis of how the operating system uses the functionality of the underlying platform. 19 At a minimum, the underlying platform must provide functions the operating system can use to protect itself from untrusted subjects interfering with the functionality of the operating system or bypassing its protection functions. This requires functions that allow the operating system to: Protect areas of main memory from being accessed by untrusted subjects. Protect devices from being directly accessed (without that access being mediated by the operating system) by untrusted subjects CC version 3.1 Page 9 of 237

10 Introduction Protect any other function of the underlying platform from being used by untrusted subjects in a way that would violate the security policy of the operating system. 20 This Protection Profile does not define how the underlying platform implements those mandatory protection functions. 21 At a minimum, the TOE boundary encompasses all parts of the operating system software that are capable of bypassing all or parts of the claimed protection functions. Many operating systems are structured into a kernel operating with privileges of the underlying hardware to configure memory, processor states and devices; and a set of trusted subjects that operate with privileges assigned by the kernel that allow those trusted subjects to violate all or parts of the security policy the whole operating system needs to enforce. Such trusted subjects also must be considered as part of the TSF. 22 The TSF subject to assessment may be augmented with OSPP extended packages adding useful security functionality. 23 In the view of this Protection Profile, the underlying platform is located in the IT environment. This does not preclude a conformant ST from drawing the TOE boundary differently by including all or parts of the underlying platform. For example, an ST author may decide to include the virtualization layer into the TOE, but still exclude the underlying hardware. 1.3 Structure of the Protection Profile 24 This document is structured as follows: Chapter 1 provides the introduction to the OSPP and gives the TOE overview. Please note that this section is expanded with the TOE use and major security functions in the introductory part of the OSPP base and in each OSPP extended package. The statements found in this chapter apply to the base, as well as to the extended packages of the OSPP. Chapter 2 specifies the conformance claims for the OSPP. Chapter 3 contains the security problem definition. Chapter 4 defines the objectives. Chapter 5 contains the definition of extended components. Chapter 6 holds the security requirements definition and rationale. Annex A defines and specifies the OSPP framework, including the split between the base and extended packages. It also defines mandatory information to be added to the ST derived from the OSPP and extended package documents to allow them to be related to the OSPP base or other OSPP extended packages. Page 10 of 237 CC version

11 Introduction Annex B contains an introduction of the OSPP base. This section starts the Protection Profile structure for the OSPP base derived from the CC part 1. When printed with the CEM embedded, Annex C contains the detailed assurance requirements that are applied for the evaluation of a compliant TOE. 25 This structure implies that this document specifies the general OSPP constraints, as well as the OSPP base. The additional OSPP extended packages are defined in separate documents with a structure very similar to the structure found in chapters 3ff. 1.4 Terminology 26 The following sections define terminology for the General-Purpose Operating System Protection Profile (OSPP) Users 27 As defined in the Common Criteria, users are external entities that interact with the TOE. Such external entities include human users, as well as other IT systems. 28 Users can be either anonymous (that is, the operating system does not know the identity of the user) or they may be associated with an identity. In all cases where the security policy enforced by the operating system distinguishes between different users, the operating system must be sure that the identity of the user is correct. 29 It is quite common that an operating system supports different types of users. Those different types of users are allowed to use different sets of interfaces, have different security attributes, are identified and authenticated in different ways, and are subject to different rules of the security policy. For example, an IT system as a user may only be allowed to connect via defined network services, is authenticated using a challenge-response protocol that makes use of digital certificates, and is not allowed to directly access file system objects. On the other hand, human users are allowed to use the system call interfaces (via subjects bound to them), are authenticated using a userid/password combination (and eventually some other authentication mechanisms), and are allowed to directly access (via a subject started on behalf of the user) file system objects in accordance with the rules of a discretionary access control policy for those objects. 30 Users may be locally defined and managed. In this case, the operating system must maintain a list of valid users with their security attributes and must have a policy that defines how those users are managed. 31 In many cases, an operating system also allows users that are not locallydefined and managed to connect to the operating system and request CC version 3.1 Page 11 of 237

12 Introduction services. In those cases, the operating system relies on another trusted IT system to ensure the following: The user is still a valid member of the user community and has not been revoked. User security attributes passed to the operating system by a remote trusted entity are still valid. Note that user security attributes may be passed to the TOE within a digital certificate. In this case, the certification authority that issued the digital certificate is the remote trusted entity, even though the TOE may never have a direct connection to this entity. 32 Note that the requirements specified in this base Protection Profile apply for locally defined users. Therefore an operating system compliant with this Protection Profile must have the capability for defining and managing users locally without support of the TOE environment. The operating system may also have the capability to deal with remotely defined and managed users, which then have to be expressed in additional SFRs included in the Security Target or by claiming compliance to en extended package that defines such functionality Groups 33 Groups define a set of users that can be referred to by a group identifier. Like users, groups may be managed either by the TOE itself or by a remote trusted entity. Management of groups includes: Definition of the group itself. Management of group membership. Management of the security attributes of the group (for example, privileges and access rights given to the members of the group). Definition of how the user and group security attributes or access rights are evaluated when they potentially may be in conflict (for example, when the same security attribute exists as both a user and a group security attribute or when access rights can be assigned to users as well as groups). Rules that define how group security attributes or group access rights are evaluated when a user can be a member of several groups. Rules that define the active group memberships a user may have (if a user can be a member of more than one group, the TOE security policy may restrict the number of groups that are considered when evaluating the rules of the TOE security policy). 34 Groups are often used to define roles by assigning the security attributes and access rights required for a role to a group, and then assigning users that are Page 12 of 237 CC version

13 Introduction Subjects supposed to have a specific role to the group. Alternatively, operating systems may implement roles as a single security attribute that can be assigned to a user, where this security attribute defines a fixed or configurable set of privileges assigned to the user via the role. 35 Subjects are the active entities in the system. With regard to the execution of programs, an OSPP-conformant operating system must allow for identifying and separating different active entities executing on top of the operating system into different subjects that are uniquely identifiable by the operating system, allowing the operating system to control the subject's access to objects, allocation of resources, and use of operating system services by enforcing the rules of a defined policy. The architecture of an OSPP-conformant operating system must prevent such subjects from violating any of the policy rules or bypassing the controls within the operating system that enforce the policy rules. 36 The operating system may recognize trusted subjects for which some or all of the policy rules are not enforced. Such trusted subjects, when part of the evaluated configuration, must be part of the TSF. Such trusted subjects must not provide a way for untrusted users to violate the rules of the security policy. 37 This Protection Profile does not prescribe how an operating system implements, separates and controls the subjects it creates. This aspect must be explained in the Security Target and then further elaborated in the evidence presented for the security architecture assurance component. 38 An operating system conformant to this Protection Profile must be able to bind specific external entities ( users ) to the subject. Subjects bound to a user are operating on his behalf. Since the policy rules enforced by the operating system are often defined by user security attributes, the operating system must have rules that define how the security attributes of a subject operating on behalf of a user are derived when the operating system binds the subject to the user. In the simplest case, the user security attributes are copied one-to-one to the subject security attributes. Significantly more complex rules are implemented in many operating systems. For example, an operating system may have rules that define how the subject security attributes are derived from the user security attributes, the security attributes of the active groups the user is a member of, as well as the environment in which the subject is started (which may include the time and date or the port the user has used to connect to the TOE), and the current state of the TOE. This Protection Profile does not prescribe the rules for user-subject binding. Therefore, those rules must be defined in a Security Target that claims conformance to this Protection Profile. 39 Note that operating systems themselves may create and use subjects that are actively involved in the enforcement of the security policy or that are able to bypass all or part of the policy. These subjects need to be trusted to enforce the defined policy and are, therefore, part of the TSF of the operating system CC version 3.1 Page 13 of 237

14 Introduction In addition, some operating systems create subjects that are part of the TSF upon creation, but change to untrusted subjects afterwards (for example, as part of the process of binding a user to the subject). 40 Subjects may be created by the operating system that are not bound to any user, for example, daemons that are started by the operating system either during start-up or as a result of specific events. For these subjects, the operating system must have a policy that defines the active set of privileges and access rights for these subjects in order to be able to consistently enforce the rules of the security policy. Some operating systems use a mechanism of pseudo-users, whereby subjects are started with the identity of a user without this identity being assigned to any real user. This allows the operating system to use the functions of user management to assign privileges and access rights and to use the rules for user-subject binding to establish the active set of privileges and access rights for these subjects. Since pseudo-users do not represent external entities, usually no user authentication is required Resources 41 Resources are a finite set of logical and/or physical entities that the operating system may allocate to users, subjects or objects. Resource allocation must be managed by the TOE. Blocks of persistent storage, CPU cycles, main memory, and network bandwidth are examples of resources. Resources are usually allocated and if they are re-usable, later de-allocated and prepared for re-use. The OSPP base does not require a specific policy covering resources to be implemented and how they are allocated to subjects, users or objects. However, the OSPP base requires that all re-usable resources, when allocated to a different subject, user or object than the one it was last allocated to, must be prepared for re-use such that upon re-allocation, no information can be obtained from the resource about its previous use or content. OSPP extended packages may define more restricted resource clearing mechanisms, such as the clearing of the contents of a resource upon de-allocation. OSPP extended packages may also require the implementation of specific policies for allocating resources, for example, management of quotas or specific priorities when allocating resources Objects 42 Objects are passive entities created and controlled by the operating system, which provide services to users and/or subjects to use those objects. Named objects are covered by the operating system implementing an access control policy enforcing rules that define the conditions that must be met for users and/or subjects to use a specific type of named objects in a defined way. Named objects must have an identifier that allows the operating system to identify the object when a subject attempts to access the object or when the security attributes of or access rights to the object are managed. Please note that objects may exist or be instantiated by the TOE without being accessible to subjects. For such TOE-internal objects, the security policy of the TOE may not apply as long as they remain internal objects. Page 14 of 237 CC version

15 Introduction 43 The OSPP base requires that at least one type of named object must be created and maintained in persistent storage and must allow users and/or subjects to: Create a new object of this type Write data to an object Read data from an object Delete an object 44 Other operations on this type of named object may be defined, but are not mandatory in the OSPP base. 45 For this type of named object, the OSPP base requires that an access control policy must be implemented that clearly defines the conditions that must be met to allow a user and/or subject to perform one of the four defined operations on an object of this type. Further conditions the access control policy must meet are defined later in this document. 46 An operating system usually implements a number of different types of named objects and may implement a different access control policy for each named object type Security attributes 47 An operating system defines security attributes it associates with nonanonymous users, subjects, and named objects. Some of these security attributes are then used by the operating system within the rules of the access control policy; some attributes may be used for different purposes, for example, to determine if a user or subject is allowed to perform certain management actions. 48 Privileges usually are authorizations that are required to perform administrative tasks. As administrative actions that have implications for security mechanisms must be restricted, the TOE must base these restrictions on verifiable properties, for example, the privileges of the subject performing these actions. 49 Such privileges may be specifically-assigned properties, such as the UID 0 in UNIX-like environments, or specific access control settings on resources that contain user and/or TSF data, in order to operate on otherwise inaccessible data. 50 In addition, privileges may be granted to subjects based on any other mechanism, for example, the state of the TOE, the interface through which the user on behalf of whom the subject is acting entered the TOE, the time in which the subject performs its actions, etc. 51 For each privilege referenced by the security functionality specification, the ST author must specify how this privilege is assigned to a subject CC version 3.1 Page 15 of 237

16 Introduction Trusted users/subjects 52 Some users have security attributes or access rights that give them the capability to bypass some or all of the rules defined in the security policy or the capability to manage the TSF data on which the security policy relies. These users are trusted to not misuse their capabilities. Note that in some cases, those capabilities may be very limited, for example, the case in which a user is allowed to manage the access control lists of objects he owns. Also, such a user is trusted to use this capability in a sensible way and not, for example, to give all users access to a storage object he has used to store information that only a limited set of users of the system should have access to. 53 In addition to trusted users, an operating system may also have trusted subjects. Similar to trusted users, these are subjects that have the capability to bypass some or all of the rules defined in the security policy or the capability to manage TSF data on which the security policy relies. These subjects may either not be bound to a user, or they may be bound to a user and allow this user to access objects and/or resources he is not allowed to access when bound to an untrusted subject. Trusted subjects, therefore, have additional capabilities that untrusted subjects do not have, and they enforce a subject-specific policy on the use of such capabilities. An example is a trusted subject that allows a user to modify specific TSF data (for example, his own password). Because of their additional capabilities, trusted subjects are part of the TSF Security policy 54 The Security Policy of an operating system is the set of security-related rules it enforces when untrusted, as well as trusted subjects and users request services from the operating system. This set of security-related rules is defined in the Security Target of an operating system; this Protection Profile defines a minimum set of such rules that each operating system conformant to this Protection Profile must enforce Storage object types 55 This Protection Profile employs the terms persistent storage objects and transient storage objects. The following definitions apply: 56 Persistent storage objects are objects that can hold user data and/or TSF data and/or TSF functions that retain the stored data in the following ways: During initialization of the TOE During re-initialization of the TOE During powering off or power-cycling the TOE 57 Transient storage objects, on the other hand, can also hold user data and/or TSF data and/or TSF functions, but this data does not remain intact during Page 16 of 237 CC version

17 Introduction the events specified for persistent storage objects. Note that this does not imply that transient storage objects are always cleared or zeroized after the above-mentioned events. Note that the OSPP base requires that transient storage objects or resources that could store data must be prepared for re-use when their re-allocation is performed without going through an event that causes them to automatically lose their data. No preparation for re-use is required when transient storage objects or resources are re-allocated to the same subject to which they previously were allocated or are allocated to another subject with identical security attributes to the subject to which they previously were allocated. 1.5 References 58 The following references are applicable to this document, as well as all OSPP extended package documents unless a reference is re-defined. CC Common Criteria for Information Technology Security Evaluation Parts 1 through 3, September 2012, Version 3.1 Revision 4 CEM Common Methodology for Information Technology Security Evaluation, September 2012, Version 3.1 Revision Abbreviations AH CC DAC EAL ESP IKE IPSEC MAC OSPP PP SAR SFP SFR SSH ST TOE TLS TSF TSFI TSP Authentication Header Common Criteria Discretionary Access Control Evaluation Assurance Level Encapsulating Security Payload Internet Key Exchange IP Security Protocol Mandatory Access Control General-Purpose Operating System Protection Profile Protection Profile Security Assurance Requirement Security Function Policy Security Functional Requirement Secure Shell Security Target Target of Evaluation Transport Layer Security TOE security function TSF Interface TOE security policy CC version 3.1 Page 17 of 237

18 PP conformance claim 2 PP conformance claim 59 The following sections describe the conformance claims of the General- Purpose Operating System Protection Profile (OSPP). 2.1 CC Conformance Claim 60 OSPP is CC version 3.1 revision 4 Part 2 extended and Part 3 conformant. 2.2 PP Claim, Package Claim 61 OSPP does not claim conformance to any other Protection Profile. 2.3 Conformance Rationale 62 Something really convincing needs to be said here. 63 OSPP requires strict conformance by an ST. 64 Note that the ST author must verify when claiming conformance with multiple OSPP extended packages that the integration of the OSPP base and all claimed OSPP extended packages into the ST complies with the rules specified by the [CC] for strict conformance. It may be possible that an OSPP extended package is mutually exclusive with another OSPP extended package. Although the OSPP extended package author shall have performed an assessment of compatibility, the result of that assessment may be superseded by newer versions of OSPP extended packages or even newlyspecified OSPP extended packages. 2.4 Conformance required by OSPP Extended Packages 65 OSPP extended packages are allowed to extend the functionality of the OSPP base. To extend the functionality, not only are SFRs added, but new objectives and additions to the security problem definition may be specified by extended packages. However, these extended packages must comply with the rules of the Common Criteria, specifically the rules outlined for strict conformance in [CC] Part 1, Appendix D. 66 This requirement implies among others that: Assumptions stated in the OSPP base or a dependent OSPP extended package may be replaced with threats and/or organizational security policies that translate into SFRs to be covered by the TOE. No assumptions may be added for functionality that is already included in the OSPP base or dependent OSPP extended packages, as such assumptions would move functionality expected to be implemented by the TOE into the environment. Page 18 of 237 CC version

19 Security Problem Definition 3 Security Problem Definition 67 The security problem definition of the OSPP base functionality shall define a general-purpose operating system implemented as a multiple-user, multipleprocess system. 68 The following sections provide a definition of various important terms, threats, assumptions and policies that are the basis for the security functionality of the OSPP base. 69 The definition of protected assets and threat agents that follows is applicable to the OSPP base, as well as to the OSPP extended packages, unless noted otherwise. 3.1 TOE assets 70 Assets to be protected are: Storage TSF A.STORAGE; Storage objects used to store user data and/or TSF data, where this data needs to be protected from any of the following operations: 1. Unauthorized read access 2. Unauthorized modification 3. Unauthorized deletion of the object 4. Unauthorized creation of new objects 5. Unauthorized management of object attributes A.TSF; TSF functions and associated TSF data. A.TSF2; 3.2 Threats The resources managed by the TSF that are used to store the abovementioned objects, including the metadata needed to manage these objects. 71 Threats to be countered by the TOE are characterized by the combination of an asset being subject to a threat, a threat agent and an adverse action CC version 3.1 Page 19 of 237

20 Security Problem Definition 72 Threat agents are external entities that potentially may attack the TOE. They satisfy one or more of the following criteria: External entities not authorized to access assets may attempt to access them either by masquerading as an authorized entity or by attempting to use TSF services without proper authorization. External entities authorized to access certain assets may attempt to access other assets they are not authorized to either by misusing services they are allowed to use or by masquerading as a different external entity. Untrusted subjects may attempt to access assets they are not authorized to either by misusing services they are allowed to use or by masquerading as a different subject. 73 Threat agents are typically characterized by a number of factors, such as expertise, available resources, and motivation, with motivation being linked directly to the value of the assets at stake. The TOE protects against intentional and unintentional breach of TOE security by attackers possessing an enhanced-basic attack potential. 74 The following threats are addressed by the OSPP base-conformant TOEs. The PP covers these threats and organizational security policies necessary to derive the necessary security functionality. There are no threats and policies to justify the assurance level. This is deemed unnecessary, since the chosen evaluation assurance level is already defined in the CC with a rationale explaining the threats countered by the assurance measures Threats countered by the TOE T.ACCESS.TSFDATA; A threat agent may read or modify TSF data using functions of the TOE without the necessary authorization. T.ACCESS.USERDATA; A threat agent may gain access to user data stored, processed or transmitted by the TOE without being appropriately authorized according to the TOE security policy by using functions provided by the TOE. T.ACCESS.TSFFUNC; A threat agent may use or manage functionality of the TSF bypassing protection mechanisms of the TSF. T.ACCESS.COMM; Page 20 of 237 CC version

21 Security Problem Definition A threat agent may access cryptographically protected data transferred via a trusted channel between the TOE and another remote trusted IT system, modify such data during transfer in a way not detectable by the receiving party or masquerade as a remote trusted IT system. T.RESTRICT.NETTRAFFIC; A threat agent may send data packets to the recipient in the TOE via a network communication channel in violation of the information flow control policy. T.IA.MASQUERADE; A threat agent may masquerade as an authorized entity including the TOE itself or a part of the TOE in order to gain unauthorized access to user data, TSF data, or TOE resources. T.IA.USER; A threat agent may gain access to user data, TSF data or TOE resources with the exception of public objects without being identified and authenticated by the TSF. T.UNATTENDED_SESSION; A threat agent may gain unauthorized access to an unattended session. 3.3 Organizational Policies 75 The following organizational security policies are addressed by PPconformant TOEs: Policies addressed by the TOE P.ACCOUNTABILITY; The users of the TOE shall be held accountable for their securityrelevant actions within the TOE. P.USER; Authority shall only be given to users who are trusted to perform the actions correctly. P.ROLES; Administrative authority to TSF functionality shall be given to trusted personnel and be as restricted as possible supporting only the administrative duties the person has CC version 3.1 Page 21 of 237

22 Security Problem Definition 3.4 Assumptions 76 The specific conditions below are assumed to exist in a PP-conformant TOE environment Physical aspects A.PHYSICAL; Personnel aspects It is assumed that the IT environment provides the TOE with appropriate physical security, commensurate with the value of the IT assets protected by the TOE. A.MANAGE; The TOE security functionality is managed by one or more competent individuals. The system administrative personnel are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the guidance documentation. A.AUTHUSER; Authorized users possess the necessary authorization to access at least some of the information managed by the TOE and are expected to act in a cooperating manner in a benign environment. A.TRAINEDUSER; Procedural aspects Users are sufficiently trained and trusted to accomplish some task or group of tasks within a secure IT environment by exercising complete control over their user data. A.DETECT; Any modification or corruption of security-enforcing or securityrelevant files of the TOE, user or the underlying platform caused either intentionally or accidentally will be detected by an administrative user. A.PEER.MGT; All remote trusted IT systems trusted by the TSF to provide TSF data or services to the TOE, or to support the TSF in the enforcement of security policy decisions are assumed to be under the same management control and operate under security policy constraints compatible with those of the TOE. A.PEER.FUNC; Page 22 of 237 CC version

23 Security Problem Definition Connectivity aspects All remote trusted IT systems trusted by the TSF to provide TSF data or services to the TOE, or to support the TSF in the enforcement of security policy decisions are assumed to correctly implement the functionality used by the TSF consistent with the assumptions defined for this functionality. A.CONNECT; All connections to and from remote trusted IT systems and between physically-separate parts of the TSF not protected by the TSF itself are physically or logically protected within the TOE environment to ensure the integrity and confidentiality of the data transmitted and to ensure the authenticity of the communication end points. If the TOE consists of separate parts and the TOE implements mechanisms ensuring the protection TSF data in transit between these parts, the ST author may consider claiming FPT_ITT.1 to supplement or replace A.CONNECT CC version 3.1 Page 23 of 237

24 Security Objectives 4 Security Objectives 4.1 Security Objectives for the TOE 77 The following objectives are defined for the TOE. O.AUDITING; The TSF must be able to record defined security-relevant events (which usually include security-critical actions of users of the TOE). The TSF must protect this information and present it to authorized users if the audit trail is stored on the local system. The information recorded for security-relevant events must contain the time and date the event happened and, if possible, the identification of the user that caused the event, and must be in sufficient detail to help the authorized user detect attempted security violations or potential misconfiguration of the TOE security features that would leave the IT assets open to compromise. O.DISCRETIONARY.ACCESS; The TSF must control access of subjects and/or users to named resources based on identity of the object. The TSF must allow authorized users to specify for each access mode which users/subjects are allowed to access a specific named object in that access mode. O.NETWORK.FLOW; The TOE shall mediate network communication between an entity outside of the TOE and a recipient within the TOE in accordance with its network information flow security policy. O.SUBJECT.COM; O.IA; The TOE shall mediate any possible sharing of objects or resources between subjects acting with different subject security attributes in accordance with its discretionary access control policy. The TOE must ensure that users have been successfully authenticated before allowing any action the TOE has defined to be provided to authenticated users only. O.MANAGE; The TSF must provide all the functions and facilities necessary to support the authorized users that are responsible for the management of TOE security mechanisms, must allow restricting such Page 24 of 237 CC version

25 Security Objectives management actions to dedicated users, and must ensure that only such authorized users are able to access management functionality. O.TRUSTED_CHANNEL; The TSF must allow authorized users to remotely access the TOE using a cryptographically-protected network protocol that ensures integrity and confidentiality of the transported data and is able to authenticate the end points of the communication. Note that the same protocols may also be used in the case where the TSF is physically separated into multiple parts that must communicate securely with each other over untrusted network connections. The protocol must also prevent masquerading of the remote trusted IT system. O.UNATTENDED_SESSION; The TOE must allow for the temporary suspension of a user's session allowing the continuation of such a suspended session and user related input and output only after the user has resumed the session by re-authenticating himself to the TSF. 4.2 Security Objectives for the Operational Environment 78 The following objectives are to be met by the operational environment of the TOE. OE.ADMIN; Those responsible for the TOE are competent and trustworthy individuals, capable of managing the TOE and the security of the information it contains. OE.REMOTE; If the TOE relies on remote trusted IT systems to support the enforcement of its policy, those systems provide the functions required by the TOE and are sufficiently protected from any attack that may cause those functions to provide false results. OE.INFO_PROTECT; Those responsible for the TOE must establish and implement procedures to ensure that information is protected in an appropriate manner. In particular: 1. All network and peripheral cabling must be approved for the transmittal of the most sensitive data held by the system. Such physical links are assumed to be adequately protected against threats to the confidentiality and integrity of the data transmitted CC version 3.1 Page 25 of 237

26 Security Objectives 2. DAC protections on security-relevant files (such as audit trails and authentication databases) shall always be set up correctly. 3. Users are authorized to access parts of the data managed by the TOE and are trained to exercise control over their own data. OE.INSTALL; Those responsible for the TOE must establish and implement procedures to ensure that the hardware, software and firmware components that comprise the system are distributed, installed and configured in a secure manner supporting the security mechanisms provided by the TOE. OE.MAINTENANCE; Authorized users of the TOE must ensure that the comprehensive diagnostics facilities provided by the product are invoked at every scheduled preventative maintenance period. OE.PHYSICAL; Those responsible for the TOE must ensure that those parts of the TOE critical to enforcement of the security policy are protected from physical attack that might compromise IT security objectives. The protection must be commensurate with the value of the IT assets protected by the TOE. OE.RECOVER; Those responsible for the TOE must ensure that procedures and/or mechanisms are provided to assure that after system failure or other discontinuity, recovery without a protection (security) compromise is achieved. OE.TRUSTED.IT.SYSTEM; The remote trusted IT systems implement the protocols and mechanisms required by the TSF to support the enforcement of the security policy. These remote trusted IT systems are under the same management domain as the TOE, are managed based on the same rules and policies applicable to the TOE, and are physically and logically protected equivalent to the TOE. 4.3 Security Objectives rationale 79 The following tables provide a mapping of security objectives to the environment defined by the threats, policies and assumptions, illustrating Page 26 of 237 CC version

27 Security Objectives that each security objective covers at least one threat, assumption or policy and that each threat, assumption or policy is covered by at least one security objective Security Objectives coverage Objectives O.AUDITING O.DISCRETIONAR Y.ACCESS O.NETWORK.FLO W O.SUBJECT.COM O.IA O.MANAGE O.TRUSTED_CHA NNEL O.UNATTENDED_S ESSION SPD coverage P.ACCOUNTABILITY T.ACCESS.USERDATA T.ACCESS.TSFDATA T.RESTRICT.NETTRAFFIC T.ACCESS.USERDATA T.ACCESS.TSFDATA T.IA.MASQUERADE T.IA.USER P.ACCOUNTABILITY P.USER T.ACCESS.TSFFUNC T.ACCESS.USERDATA T.ACCESS.TSFDATA T.ACCESS. TSFFUNC T.ACCESS.COMM T.UNATTENDED_SESSION Table 1 Coverage of security objectives for the TOE Objectives OE.ADMIN OE.REMOTE OE.INFO_PROTECT OE.INSTALL OE.MAINTENANCE OE.PHYSICAL OE.RECOVER OE.TRUSTED.IT.SYSTEM SPD coverage A.AUTHUSER A.MANAGE A.TRAINEDUSER T.ACCESS.COMM A.CONNECT P.USER A.AUTHUSER A.TRAINEDUSER Physical aspects A.MANAGE A.MANAGE A.DETECT A.DETECT Physical aspects A.MANAGE A.DETECT A.CONNECT A.PEER.MGT A.PEER.FUNC Table 2 Coverage of security objectives for the TOE environment Threats T.ACCESS.TSFDATA Security Objectives The threat of accessing TSF data without proper authorization is mitigated by: O.TRUSTED_CHANNEL requiring cryptographically-protected communication channels for data including TSF data controlled by the TOE in transit between trusted IT systems, O.DISCRETIONARY.ACCESS requiring that data, including TSF data stored with the TOE, have discretionary access control CC version 3.1 Page 27 of 237

28 Security Objectives Threats Security Objectives protection, O.SUBJECT.COM requiring the TSF to mediate communication between subjects. The threat of accessing user data without proper authorization is mitigated by: T.ACCESS.USERDATA O.TRUSTED_CHANNEL requiring cryptographically-protected communication channels for data including user data controlled by the TOE in transit between trusted IT systems, O.DISCRETIONARY.ACCESS requiring that data including user data stored with the TOE, have discretionary access control protection, O.SUBJECT.COM requiring the TSF to mediate communication between subjects. The threat of accessing TSF functions without proper authorization is mitigated by: T.ACCESS.TSFFUNC O.TRUSTED_CHANNEL requiring cryptographically-protected communication channels to limit which TSF functions are accessible to external entities, O.MANAGE requiring that only authorized users utilize management TSF functions. The threat of accessing a communication channel that establishes a trust relationship between the TOE and another remote trusted IT system is mitigated by: T.ACCESS.COMM O.TRUSTED_CHANNEL requiring that the TOE implements a trusted channel between itself and a remote trusted IT system protecting the user data and TSF data transferred over this channel from Page 28 of 237 CC version

29 Security Objectives Threats Security Objectives disclosure and undetected modification and prevents masquerading of the remote trusted IT system, OE.REMOTE requiring that those systems providing the functions required by the TOE are sufficiently protected from any attack that may cause those functions to provide false results. T.RESTRICT.NETTRAFF IC The threat of accessing information or transmitting information to other recipients via network communication channels without authorization for this communication attempt is mitigated by: O.NETWORK.FLOW requiring the TOE to mediate the communication between itself and remote entities in accordance with its security policy. The threat of masquerading as an authorized entity in order to gain unauthorized access to user data, TSF data or TOE resources is mitigated by: T.IA.MASQUERADE O.IA requiring that each entity interacting with the TOE is properly identified and authenticated before allowing any action the TOE is defined to provide to authenticated users only. The threat of accessing user data, TSF data or TOE resources without being identified and authenticated is mitigated by: T.IA.USER T.UNATTENDED_SESSI ON O.IA requiring that each entity interacting with the TOE is properly identified and authenticated before allowing any action the TOE has defined to provide to authenticated users only. The threat of an attack agent using an unattended session to gain access to protected functionality of the TSF, user data, or TSF data is mitigated: CC version 3.1 Page 29 of 237

30 Security Objectives Threats Security Objectives O.UNATTENDED_SESSION requiring the capability that unattended sessions can be protected from use by unauthorized persons. Table 3 TOE threats sufficiency Security Objectives sufficiency Security Policiesc P.ACCOUNTABILITY Security Objectivesc The policy to hold users accountable for their securityrelevant actions within the TOE is implemented by: O.AUDITING providing the TOE with audit functionality, O.MANAGE allowing the management of this function. The policy to match the trust given to a user and the actions the user is given authority to perform is implemented by: P.USER O.MANAGE allowing appropriately-authorized users to manage the TSF, OE.INFO_PROTECT, which requires that users are trusted to use the protection mechanisms of the TOE to protect their data. Table 4 Security policies sufficiencyc Assumptions Physical aspects Security Objectives The assumption on the IT environment to provide the TOE with appropriate physical security, commensurate with the value of the IT assets protected by the TOE is covered by: OE.INFO_PROTECT requiring the approval of network and peripheral cabling, OE.PHYSICAL requiring physical protection. A.MANAGE The assumptions on the TOE security functionality being managed by one or more trustworthy individuals is covered Page 30 of 237 CC version

31 Security Objectives Assumptions Security Objectives by: OE.ADMIN requiring trustworthy personnel managing the TOE, OE.INFO_PROTECT requiring personnel to ensure that information is protected in an appropriate manner, OE.INSTALL requiring personnel to ensure that components that comprise the system are distributed, installed and configured in a secure manner supporting the security mechanisms provided by the TOE, OE.RECOVER requiring personnel to assure that after system failure or other discontinuity, recovery without a protection (security) compromise is achieved. The assumption on authorized users to possess the necessary authorization to access at least some of the information managed by the TOE and to act in a cooperating manner in a benign environment is covered by: A.AUTHUSER OE.ADMIN ensuring that those responsible for the TOE are competent and trustworthy individuals, capable of managing the TOE and the security of the information it contains, OE.INFO_PROTECT requiring that DAC protections on security-relevant files (such as audit trails and authentication databases) shall always be set up correctly and that users are authorized to access parts of the data maintained by the TOE. A.TRAINEDUSER The assumptions on users to be sufficiently trained and trusted to accomplish some task or group of tasks within a secure IT environment by exercising complete control over their user data is covered by: OE.ADMIN requiring competent personnel managing the TOE, CC version 3.1 Page 31 of 237

32 Security Objectives Assumptions Security Objectives OE.INFO_PROTECT requiring that those responsible for the TOE must establish and implement procedures to ensure that information is protected in an appropriate manner and that users are trained to exercise control over their own data. The assumption that modification or corruption of securityenforcing or security-relevant files will be detected by an administrative user is covered by: OE.INSTALL requiring an administrative user to ensure that the TOE is distributed, installed and configured in a secure manner supporting the security mechanisms provided by the TOE, A.DETECT OE.MAINTENANCE requiring an administrative user to ensure that the diagnostics facilities are invoked at every scheduled preventative maintenance period, verifying the correct operation of the TOE, OE.RECOVER requiring an administrative user to ensure that procedures and/or mechanisms are provided to assure that after system failure or other discontinuity, recovery without a protection (security) compromise is achieved. The assumption on all remote trusted IT systems to be under the same management control and operate under security policy constraints compatible with those of the TOE is covered by: A.PEER.MGT A.PEER.FUNC OE.TRUSTED.IT.SYSTEM requiring that these remote trusted IT systems are under the same management domain as the TOE, and are managed based on the same rules and policies applicable to the TOE. The assumption on all remote trusted IT systems to correctly implement the functionality used by the TSF consistent with Page 32 of 237 CC version

33 Security Objectives Assumptions Security Objectives the assumptions defined for this functionality is covered by: OE.TRUSTED.IT.SYSTEM requiring that the remote trusted IT systems implement the protocols and mechanisms required by the TSF to support the enforcement of the security policy. The assumption on all connections to and from remote trusted IT systems and between physically separate parts of the TSF not protected by the TSF itself are physically or logically protected is covered by: A.CONNECT OE.REMOTE requiring that remote trusted IT systems provide the functions required by the TOE and are sufficiently protected from any attack that may cause those functions to provide false results, OE.TRUSTED.IT.SYSTEM demanding the physical and logical protection equivalent to the TOE. Table 5 Assumptions sufficiency CC version 3.1 Page 33 of 237

34 Extended Components Definition 5 Extended Components Definition 5.1 Functional Extended Components FIA_PKI.1_TEMPLATE Public key based authentication Hierarchical to: No other components. Dependencies satisfied by: FMT_MTD.1 Management of TSF data (AE) Rationale 80 FIA_PKI.1_TEMPLATE Public key based authentication is a SFR related to public key cryptography used for authentication of remote IT systems. 81 Remote IT entities are often authenticated based on public key cryptography. This SFR specifies the method used for public key based authentication and the cryptographic protocols that perform public key based authentication. If digital certificates are used it also defines the standard used for certificate path validation. User application notes 82 The use of public key based authentication must be compliant with the definition of the use of public key based authentication in the cryptographic protocol selected. FIA_PKI.1.1_TEMPLATE The TSF shall use [selection: [assignment: certificate format standard],public key cryptography] as defined by [assignment: certificate management and certificate validation standards or other method for key management/key validation] to support authentication for [assignment: cryptographic protocol] connections. FIA_PKI.1.2_TEMPLATE The TSF shall store and protect certificates and/or public keys from unauthorized deletion and modification FMT_ERM.1_TEMPLATE Remote Management Capabilities Hierarchical to: No other components. Dependencies satisfied by: FTP_ITC.1 Inter-TSF trusted channel Rationale 83 FMT_ERM.1_TEMPLATE Remote Management Capabilities is a SFR related to remote management. 84 Remote management capabilities using a trusted channel are required for general-purpose operating systems. Administrators using this capability need to be authenticated, which can either be done by requesting them to provide valid authentication information in the same way as for local user Page 34 of 237 CC version

35 Extended Components Definition FMT_ERM.1.1_TEMPLATE authentication or by certificates that are unambiguously bound to the administrative user. The TSF shall allow management functions also to be performed from a remote IT entity using a trusted channel established in accordance with the requirements stated in FTP_ITC.1 Inter-TSF trusted channel CC version 3.1 Page 35 of 237

36 Security Requirements for the TOE 6 Security Requirements for the TOE 85 This chapter specifies the requirements set forth for the TOE. If the OSPP mandates a specific option that cannot be specified as part of the SFR or SAR, the PP marks it as ST Author Note. The ST author must apply this note when writing an ST and claiming conformance with this PP. 6.1 Functional Security Requirements 86 The Security Functional Requirements included in this section are derived from Part 2 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 3, with additional extended functional components Requirements related to security audit capabilities of the TOE FAU_GEN.1 Audit data generation Hierarchical to: No other components. Dependencies satisfied by: FPT_STM.1 Reliable time stamps User application notes 87 FAU_GEN.1.1 has the operations being partially performed to reflect the minimum set of events each operating system conformant to this PP must be able to audit. Since the OSPP base requires that an authorized administrator has the capability to select the events to be audited, all activities that change this set are required to be auditable. In addition, all user authentication attempts must be auditable, but it is allowed that an authorized administrator restricts the events that are actually audited to failed authentication attempts, authentication attempts for specific types of users, authentication attempts when specific authentication methods are used, etc. The rules that allow an authorized administrator to define the events that are actually audited from the set of events the TOE is capable of auditing must be defined in the FAU_SEL.1 Selective audit (or a hierarchically higher component). 88 It is also required that the operating system is capable of auditing denied access attempts to objects listed in the access control policies. This requirement allows for analysis of denied access attempts in order to detect a potential misconfiguration of access rights, for example, an attack that performs a large number of access attempts. 89 Explicit modifications of access rights are those that are performed by an explicit request for access right modification. These are critical if, for example, they are performed by a Trojan Horse. FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: Page 36 of 237 CC version

37 Security Requirements for the TOE Start-up and shutdown of the audit functions; All auditable events for the [selection: not specified] level of audit; and [assignment: 1. all modifications to the set of events being audited; 2. all user authentication attempts; 3. all denied accesses to objects for which the access control policy defined in the OSPP base applies; 4. explicit modifications of access rights to objects covered by the access control policies; and 5. other specifically defined auditable events as defined in the table in FAU_GEN.1.2. ] FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and For all management SFRs included in the Security Target: the identity of the user that performed/attempted to perform the management operation, an identification of what was managed and the indication what the administrative user has changed as part of the management operation, and For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment: SFR FAU_SAR.1 Events and Event specific information Event: Any attempt to access the audit records 1. identity of the user attempting to access the audit records 2. success or failure Event: Any attempt to modify the events to be audited FAU_SEL.1 1. identity of the user attempting to modify the events to be audited 2. success or failure 3. in case of success: modification to CC version 3.1 Page 37 of 237

38 Security Requirements for the TOE SFR Events and Event specific information the set of events to be audited Event: Any attempt to access an object protected by the SFP FDP_ACF.1 1. identity of the user attempting to access an object protected by the SFP. Note: if the operation is attempted by a subject not operating on behalf of a user: identity of the subject 2. identity of the object the user attempts to access Event: Denied information flow 3. attempted operation 4. Success or failure FDP_IFF.1 FIA_AFL.1 1. identification of the network interface 2. reason for denying information flow Event: Exceeding the limit of unsuccessful consecutive authentication attempts 1. user identity where the limit was exceeded Event: Verification that a user has been successfully authenticated 1. user identity FIA_UAU.1(HU) 2. indicator that the user has been successfully authenticated In the case the authentication is performed by the TOE, also the event of a failed authentication attempt needs to be auditable: 1. user identity provided 2. indicator that the authentication failed FTA_SSL.1 Event: Re-authentication attempt to unlock a session Page 38 of 237 CC version

39 Security Requirements for the TOE SFR Events and Event specific information 1. user identity 2. success or failure of reauthentication Event: Re-authentication attempt to unlock a session FTA_SSL.2 1. user identity 2. success or failure of reauthentication Event: Initialization of a trusted channel 1. identity of the communication partner FTP_ITC.1 2. protocol used to establish the channel 3. success or failure of setting up the channel Table 6 Minimum set of auditable events with event specific information (Note: The specified level of audit applies to all SFRs defined in the OSPP base, as well as every OSPP extended package with which the ST claims conformance. The table defined above defines a minimum set of events an operating system compliant to this Protection Profile must be able to audit, together with the minimum amount of information that needs to be contained in the audit record in addition to the general information of time and date, event type. The event specific information often refines the requirements for subject identity and outcome of the event. For example if the event specific information in an entry in the table specifies the identity of the user, there is no need to also record a subject identity in addition to this information. The subject identity may be identical to the user identity in the case where the subject identity is established by the user-subject binding process. In this case, only one identity needs to be included in the audit record. The purpose here is the ability to trace an event to the user that caused the event. This may not be possible if the subject identity does not allow to identify the user the subject was bound to when the event happened. In order to support FAU_GEN.2 User identity association, the user identity has, therefore, been added as the information to be recorded. The outcome to be recorded with the audited event can either be binary (success or failure) or the value resulting from the event, depending on the implementation of the TOE. For example the access control decision functionality shall store the information about the result of the access control decision with the audit trail. A TOE may implement more decision results than just access allowed or denied, where all of these results shall be recorded as outcome of the CC version 3.1 Page 39 of 237

40 Security Requirements for the TOE access control check event. A Security Target that includes additional SFRs e. g. for additional management activities needs to specify the audit requirements for such an additional SFR in an extension to the table above in the Security Target. As a general rule for all management activities initiated by an administrative user, the event specific information needs to contain the identity of the user that performed/attempted to perform the management operation, an identification of what was managed and the indication what the administrative user has changed as part of the management operation. Operations where an administrative user just queries the status of manageable items do not need to be auditable. )] FAU_GEN.2 User identity association Hierarchical to: No other components. Dependencies satisfied by: FAU_GEN.1 Audit data generation FIA_UID.1 Timing of identification FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event FAU_SAR.1 Audit review Hierarchical to: No other components. Dependencies satisfied by: FAU_GEN.1 Audit data generation User application notes 90 Authorized users can either be human users or other trusted IT systems. The ST author must define the conditions that must be satisfied to allow a user to read audit trail information. An operating system conformant to this Protection Profile may well define different types of users with the conditions they need to meet to read different information from the audit records. An operating system that allows defined human users to read specific types of audit records or specific fields from audit records while also allowing a specific external system to download all audit records is compliant with this requirement. 91 The ST author needs to define the exact authorizations required to read the information from the audit record. This may be a specific role that has this capability assigned or one or more privileges that must be assigned to a user. FAU_SAR.1.1 The TSF shall provide [assignment: the authorised identified roles, or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity] (Note: the ST author should specify the additional rules that allow users to perform the activity. )] with the capability to read [assignment: list of audit information (Note: the ST author should specify the type of information the specified user is permitted to obtain from the audit records. Examples are all, subject identity, all information belonging to audit records referencing this user. When Page 40 of 237 CC version

41 Security Requirements for the TOE employing the SFR, FAU_SAR.1 Audit review, it is not necessary to repeat, in full detail, the list of audit information first specified in FAU_GEN.1 Audit data generation. Use of terms such as all or all audit information assist in eliminating ambiguity and the further need for comparative analysis between the two security requirements.)] from the audit records. FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information FAU_SAR.2 Restricted audit review Hierarchical to: No other components. Dependencies satisfied by: FAU_SAR.1 Audit review FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access FAU_SEL.1 Selective audit Hierarchical to: No other components. Dependencies satisfied by: FAU_GEN.1 Audit data generation FMT_MTD.1 Management of TSF data (AE) FAU_SEL.1.1 The TSF shall be able to select the set of events to be audited from the set of all auditable events based on the following attributes: [selection: object identity,user identity,subject identity,event type,outcome (success or failure) of the event] [assignment: list of additional attributes that audit selectivity is based upon (Note: the ST author should specify any additional attributes upon which audit selectivity is based. If there are no additional rules upon which audit selectivity is based, this assignment can be completed with none. )] FAU_STG.1 Protected audit trail storage Hierarchical to: No other components. Dependencies satisfied by: FAU_GEN.1 Audit data generation User application notes 92 The TOE may store its audit records locally, or it may pass its audit records on to a remote trusted IT system for storage and further processing. Even in this case, the TOE will usually need some kind of local audit trail as a (probably volatile) cache to buffer some audit records or to bridge the time when the remote audit server might not be available. Such a local audit trail must be protected as described in this SFR CC version 3.1 Page 41 of 237

42 Security Requirements for the TOE FAU_STG.1.1 FAU_STG.1.2 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion. The TSF shall be able to [selection, choose one of: prevent,detect (Note: the ST author should specify whether the TSF shall prevent or only be able to detect modifications of the stored audit records in the audit trail. Only one of these options may be chosen. )] unauthorised modifications to the stored audit records in the audit trail FAU_STG.3 Action in case of possible audit data loss Hierarchical to: No other components. Dependencies satisfied by: FAU_STG.1 Protected audit trail storage User application notes 93 There may be a number of conditions that potentially could lead to a loss of audit data; reaching a defined threshold is just one of them. In cases where the audit data is automatically transferred to another trusted IT system, any problem in the communication link with this system could potentially lead to a loss of audit data. FAU_STG.3.1 requires the author of an ST to list the conditions of potential loss of audit data the TSF is able to detect and describe the reaction of the TSF when such a condition is detected. When the reaction is different for different conditions detected, the ST author shall use multiple iterations of FAU_STG.3.1 to describe the different reactions and associate them with the conditions for potential audit data loss detected by the TSF. 94 This SFR explicitly is not restricted to the audit trail stored by the TSF only. If the TOE stores the audit trail with a remote trusted IT system, it must be ensured that if the audit trail storage reaches the specified threshold, the TOE sends a notification to the remote trusted IT systems sending audit data to the TOE to inform about this state. FAU_STG.3.1 The TSF shall [assignment: actions to be taken in case of possible audit storage failure (Note: the ST author should indicate the pre-defined limit. If the management functions indicate that this number might be changed by the authorised user, this value is the default value. The ST author might choose to let the authorised user define this limit. In that case the assignment can be for example an authorised user set limit.)] if the audit trail exceeds [assignment: pre-defined limit (Note: the ST author should specify actions that should be taken in case of imminent audit storage failure indicated by exceeding the threshold. Actions might include informing an authorised user.)] Page 42 of 237 CC version

43 Security Requirements for the TOE FAU_STG.4 Prevention of audit data loss Hierarchical to: No other components. Dependencies satisfied by: FAU_STG.1 Protected audit trail storage User application notes 95 This SFR explicitly is not restricted to the audit trail stored by the TSF only. If the TOE stores the audit trail with a remote trusted IT system, it must be ensured that if the audit trail storage is full, the TOE sends a notification to the remote trusted IT systems sending audit data to the TOE to inform about this state. FAU_STG.4.1 The TSF shall [selection, choose one of: ignore audited events, prevent audited events, except those taken by the authorised user with special rights, overwrite the oldest stored audit records (Note: the ST author should select whether the TSF shall ignore audited actions, or whether it should prevent audited actions from happening, or whether the oldest audit records should be overwritten when the TSF can no longer store audit records. Only one of these options may be chosen.)] and [assignment: other actions to be taken in case of audit storage failure (Note: the ST author should specify other actions that should be taken in case of audit storage failure, such as informing the authorised user. If there is no other action to be taken in case of audit storage failure, this assignment can be completed with none.)] if the audit trail is full Requirements related to the protection of the user data FDP_ACC.1 Subset access control Hierarchical to: No other components. Dependencies satisfied by: FDP_ACF.1 Security attribute based access control User application notes 96 An operating system may implement multiple access control SFPs and the intention here is to allow for multiple instantiations of FDP_ACC.1 Subset access control, FDP_ACF.1 Security attribute based access control and associated management SFRs to describe each access control SFP in terms of the types of users/subjects, types of objects, and operations covered by the SFP with the related instantiation of FDP_ACF.1 describing precisely the rules that are followed in order to determine if a specific user/subject is allowed to perform a specific operation on a specific object covered by the SFP. 97 The list of operations on the object needs to cover the creation of a new object, the destruction of an object, all types of access to the object, as well as operations on TSF data associated and stored with the object (for example, object name, access control list associated with the object, other object security attributes). If some of those operations are covered by SFRs related CC version 3.1 Page 43 of 237

44 Security Requirements for the TOE to the management of TSF data, the ST author shall include a reference to those SFRs in order to allow the ST reader to identify where those operations are described. FDP_ACC.1.1 The TSF shall enforce the [assignment: access control SFP (Note: the ST author should specify a uniquely named access control SFP to be enforced by the TSF.)] on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP (Note: the ST author should specify the list of subjects, objects, and operations among subjects and objects covered by the SFP.)] FDP_ACF.1 Security attribute based access control Hierarchical to: No other components. Dependencies satisfied by: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation (DAC) User application notes 98 There must be at least one access control SFP for persistent storage objects (e. g. files) that allows for the specification of access rights down to the granularity of a single user/subject. Access control lists that allow for specifying access right for individual users while by default denying access to user or groups that are not part of an entry in the access control list is an example of an implementation that would satisfy this condition. An additional capability to assign access to groups or bind access to privileges which themselves can be assigned individually to users/subjects and/or groups does not violate the condition of being able to assign access down to the level of a single user. 99 Access control policies can be highly complex and an operating system may implement a large number of exceptions e. g. by binding some access rights to specific privileges. In order to avoid the overall rule set to become overly complex the ST author may decide to describe not all those exceptions. This is allowed provided that the guidance for the evaluated configuration clearly describes how to configure and manage the TOE such that those exceptions are not relevant for the evaluated configuration. For example an access right automatically given to a user with a specific privilege may be ignored in the description of the access control rules provided the guidance clearly states that this privilege shall not be assigned to a user when operating in the evaluated configuration. 100 The ST has to repeat FDP_ACF.1 Security attribute based access control for each instance of FDP_ACC.1 Subset access control with FDP_ACF.1 Security attribute based access control describing the relevant security attributes used in the rules that determine access as well as the rules that determine access themselves. The description provided must allow the reader/evaluator to identify the TSF data that is used in making the access decision as well as derive a model of the access decision process. The identification of the TSF data used in the access decision rules is required Page 44 of 237 CC version

45 Security Requirements for the TOE since the evaluator needs to determine how this TSF data is derived and managed in order to identify possible ways an attacker may influence the access control decision by influencing the TSF data used in the decision process. FDP_ACF.1.1 FDP_ACF.1.2 FDP_ACF.1.3 FDP_ACF.1.4 The TSF shall enforce the [assignment: access control SFP (Note: the ST author should specify an access control SFP name that the TSF is to enforce. The name of the access control SFP, and the scope of control for that policy are defined in components from FDP_ACC. )] to objects based on the following: [assignment: list of subjectsor users and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes (Note: the ST author should specify, for each controlled subject or user and object, the security attributes and/or named groups of security attributes that the function will use in the specification of the rules. For example, such attributes may be things such as the user identity, subject identity, role, time of day, location, ACLs, or any other attribute specified by the PP/ST author. Named groups of security attributes can be specified to provide a convenient means to refer to multiple security attributes. Named groups could provide a useful way to associate roles defined in FMT_SMR.1 Security roles, and all of their relevant attributes, with subjects. In other words, each role could relate to a named group of attributes.)] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: rules governing access among controlled subjectsand/or users and controlled objects using controlled operations on controlled objects (Note: the ST author should specify the SFP rules governing access among controlled subjects and/or users and controlled objects using controlled operations on controlled objects. These rules specify when access is granted or denied. It can specify general access control functions (e.g. typical permission bits) or granular access control functions (e.g. ACLs).)] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributesor other TSF data, that explicitly authorise access of subjects to objects (Note: the ST author should specify the rules, based on security attributes or other TSF data (which then turn into attributes by definition), that explicitly authorise access of subjects to objects that will be used to explicitly authorise access. These rules are in addition to those specified in FDP_ACF.1.1. They are included in FDP_ACF.1.3 as they are intended to contain exceptions to the rules in FDP_ACF.1.1. An example of rules to explicitly authorise access is based on a privilege vector associated with a subject that always grants access to objects covered by the access control SFP that has been specified. If such a capability is not desired, then the ST author should specify none.)] The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributesor other TSF data, that explicitly deny access of subjects to objects (Note: the ST author should specify the rules, based on security attributes or other TSF CC version 3.1 Page 45 of 237

46 Security Requirements for the TOE data, that explicitly deny access of subjects to objects. These rules are in addition to those specified in FDP_ACF.1.1. They are included in FDP_ACF.1.4 as they are intended to contain exceptions to the rules in FDP_ACF.1.1. An example of rules to explicitly deny access is based on a privilege vector associated with a subject that always denies access to objects covered by the access control SFP that has been specified. If such a capability is not desired, then the ST author should specify none.)] FDP_IFC.1 Subset information flow control Hierarchical to: No other components. Dependencies satisfied by: FDP_IFF.1 Simple security attributes User application notes 101 This SFR together with FDP_IFF.1 Simple security attributes requires the TOE to implement the capability to define basic packet filtering rules for both incoming and outgoing network packets. The requirement is as a minimum to have filtering capabilities for TCP/IP, VLANs or both where an administrator can define rules for inspecting packets and then deciding if a packet is allowed to be sent to the intended recipient or discarded. 102 The OSPP explicitly does not specify the version of the Internet Protocol. This implies that the Internet Protocol versions usable in the evaluated configuration must be covered by this SFR. FDP_IFC.1.1 The TSF shall enforce the [assignment: Network Information Flow Control Policy] on [assignment: Originating entities: 1. unauthenticated external IT entities that send network data to a network interface of the TOE; 2. subjects within the TOE that send network data to unauthenticated external IT entities via a network interface of the TOE; Information: 1. Network data received by the TOE from an external IT entity; 2. Network data provided to the TOE by a subject executing on the TOE intended to be sent to an external IT entity via a network interface controlled by the TOE; 3. [selection: [assignment: other information covered by the SFP],none] Operations: Page 46 of 237 CC version

47 Security Requirements for the TOE 1. Receiving network data from an unauthenticated external IT entity; 2. Sending network data to an unauthenticated IT entity by a subject within the TOE; ] FDP_IFF.1 Simple security attributes Hierarchical to: No other components. Dependencies satisfied by: FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation (DAC) User application notes 103 A TOE compliant to this Protection Profile does not need to allow for different rule sets applicable to different network interfaces, but in case it provides this capability the network interface the data has been received or is intended to be sent out needs to be considered by the TOE as a security attribute used to select the correct set of rules that needs to be applied. 104 The minimum requirement of the network flow control specified in FDP_IFF.1 Simple security attributes.3 defines the purpose of the Network Information Flow Control Policy, namely to identify network data using the security attributes specified here and to at least discard the identified network data or allow it to pass the TOE unaltered. FDP_IFF.1.1 The TSF shall enforce the [assignment: Network Information Flow Control Policy] based on the following types of subject and information security attributes: [assignment:, Layer 2 security attributes Object security attribute: the logical or physical network interface through which the network data from an external IT entity entered the TOE or is intended to be sent out; [selection: TCP/IP information security attributes: 1. Source and destination IP address, 2. Source and destination TCP port number, 3. Source and destination UDP port number, 4. Network protocol of IP, TCP, UDP, [selection: ICMP,[assignment: other protocols]] 5. [selection: TCP header flags of[selection: SYN, ACK],[assignment: other TCP header flags],[assignment: other network data information security attributes], no other security attributes] CC version 3.1 Page 47 of 237

48 Security Requirements for the TOE 1. MAC address; 2. VLAN identifier, 3. [selection: [assignment: other network data information security attributes], no other security attributes] (Note: the ST author should select one or both of this options )]] FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [assignment: for both receiving network data from an external IT entity and sending network data by a subject within the TOE to an external IT entity: if the set of rules defined in accordance with the security attributes defined in FDP_IFF.1 Simple security attributes.3 define that the network data is discarded the network data shall not be delivered by the TOE to the intended recipient; if the set of rules defined in accordance with the security attributes defined in FDP_IFF.1 Simple security attributes.3 define that the network data is to be delivered unaltered the network data shall be delivered unaltered by the TOE to the intended recipient; if the set of rules defined in accordance with the security attributes defined in FDP_IFF.1 Simple security attributes.3 define another action to be taken than discarding the network data or delivering the data unaltered to the intended recipient, the TOE shall perform this action. ] User application notes 105 For network data received from an external IT entity the intended recipient is the process within the TOE the network data is supposed to be delivered to for further processing. This may be a subject operating on behalf of a user, another subject (e. g. a network daemon) or a dedicated part of the TSF. 106 For network data generated within the TOE that is intended to be sent to a remote IT entity the intended recipient is the remote IT entity identified by either the IP address or the MAC address as specified in the network data before it is processed by the filtering rules. FDP_IFF.1.3 The TSF shall enforce the [assignment: following rules consisting of an identification when the rule fires and an action to be taken when the rule fires: Identification of network data using one or more of the following concepts: 1. Information security attribute matching based on the following security attributes [assignment: list of security attributes used in the matching rules (Note: requires the ST Page 48 of 237 CC version

49 Security Requirements for the TOE author to define those security attributes in the network protocol that are used in the rules for simple matching (i. e. where a simple comparison with the value of the security attribute decides if the network package is allowed to pass or is not allowed to pass. )] 2. [selection: [assignment: matching rules based on the state of a TCP connection],[assignment: time-based matching rules],[assignment: statistical analysis matching rules],[selection: no other matching concepts,[assignment: other matching concepts]] (Note: requires the TOE to have at least one more complex set of rules are either based on the state of TCP connections, based on time or based on some statistical properties (e. g. too many network packages of the same kind coming from specific sources). )] Performing one or more of the following actions: 1. Discard the network data [selection: without any further processing, with sending a notification to the sender]; 2. Allow the network data to be delivered unaltered by the TOE to the intended recipient; 3. [selection: and perform no other action,[assignment: other actions that are performed when the rule fires]] (Note: The ST author may specify in FDP_IFF.1 Simple security attributes.3 the rules for at least one of those concepts, explaining which matching concept he uses and shall also specify other matching concepts implemented by the TOE that are used to decide if a network package is allowed to pass or not. Specifying the complete set of rules is important to determine the expected results for tests at the network interfaces and compare those with the real results obtained. The ST author then needs to specify the possible actions that can be taken when the rules fire, which must at least allow for discarding the network data or passing the network data unaltered. )] FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly authorise information flows (Note: the ST author should specify the rules, based on security attributes, that explicitly authorise information flows. These rules are in addition to those specified in the preceding elements. They are included in FDP_IFF.1.4 as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that always grants the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the ST author should specify none.)] CC version 3.1 Page 49 of 237

50 Security Requirements for the TOE FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly deny information flows (Note: the ST author should specify the rules, based on security attributes, that explicitly deny information flows. These rules are in addition to those specified in the preceding elements. They are included in FDP_IFF.1.5 as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly deny information flows is based on a privilege vector associated with a subject that always denies the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the ST author should specify none.)]. User application notes 107 The OSPP explicitly does not specify the version of the Internet Protocol for the TCP/IP network data security attributes. This implies that the Internet Protocol versions usable in the evaluated configuration must be covered by this SFR FDP_RIP.2 Full residual information protection User application notes 108 The purpose of this SFR is to ensure that an untrusted subject or user is not able to obtain TSF or user data from a resource that has been previously assigned to another subject. This includes of course disk space previously allocated to a file belonging to another user, main memory previously allocated to a subject operating on behalf of another user, but also registers after a context switch from a process belonging to a subject operating on behalf of another user, or TSF internal memory previously used for storing information that requires protection against disclosure.note that resources reassigned to the same subject/user or the same object do not require preparation for re-use, since the information they contain had anyhow been accessible to the subject or user before it was released. FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: allocation of the resource to, deallocation of the resource from (Note: the ST author should specify the event, allocation of the resource to or deallocation of the resource from, that invokes the residual information protection function.)] all objects, subjects or subject/object related TSF data before the resource is assigned or made available to another subject or use Requirements related to identification and authentication 109 The TOE must support different types of identification and authentication schemes for human users (administrators and untrusted users) and IT entities in the course of its operation. Some of the requirements that might normally be considered part of the I&A process are specified in other sections of this PP, particularly those related to cryptographic protocols called out in FTP_ITC.1 Inter-TSF trusted channel. So, for IT entity authentication, where Page 50 of 237 CC version

51 Security Requirements for the TOE the authentication is solely at a machine level, the authentication is performed using a cryptographic protocol using X.509v3 certificates. This was done to keep I&A requirements on IT entities grouped with the identified protocols and their respective RFCs grouped together for understandability ( FTP_ITC.1 Inter-TSF trusted channel). 110 The requirements in this section cover the following distinct aspects of the I&A capabilities of conformant TOEs: I&A for the human user. The TOE must provide a password mechanism that may be used by users connecting the TOE locally (e.g., console), or when the user is connecting to the TOE remotely (e.g., trusted channel via an IT entity). It is required that every user is authenticated using at least one of the user authentication mechanisms the ST author defines in FIA_UAU.5 Multiple authentication mechanisms. Credentials. The protocols ( FTP_ITC.1 Inter-TSF trusted channel) and mechanisms ( FIA_UAU.5 Multiple authentication mechanisms) specified in this and other sections of the PP rely on different credentials that are used in the I&A process: passwords or optional other user authentication mechanisms listed in FIA_UAU.5 Multiple authentication mechanisms for users, and certificates for IT entities connecting to the TOE using a trusted channel and one of the protocols listed in FTP_ITC.1 Inter-TSF trusted channel (IPsec, TLS, SSH)) FIA_AFL.1 Authentication failure handling Hierarchical to: No other components. Dependencies satisfied by: FIA_UAU.1 Timing of authentication (RITE) User application notes 111 The TOE may use different authentication methods for different types of users and have different rules for how to handle authentication failures based on the authentication method and/or user type. Authentication failures for remote systems are usually treated differently from authentication attempts for human users. Even for human users, the reaction to authentication failures may be different for authentication via userid/password and authentication via smartcards or digital certificates. 112 The unsuccessful authentication attempts need not be consecutive, but rather related to an authentication event. Such an authentication event could be the count from the last successful session establishment at a given terminal. 113 Although the list of actions can be TOE specific, the set of actions needs to ensure that any subsequent authentication attempts will prevent an attack based on semi-exhaustive searches through the space of possible authentication data. For example an action that limits the number of CC version 3.1 Page 51 of 237

52 Security Requirements for the TOE unsuccessful additional authentication attempts to one per day would be acceptable while an action that just modifies an optional audit of unsuccessful authentication attempts into a mandatory audit would not be acceptable. FIA_AFL.1.1 FIA_AFL.1.2 The TSF shall detect when [selection: an administrator configurable positive integer within[assignment: range of acceptable values (Note: the ST author should specify the range of acceptable values from which the administrator of the TOE may configure the number of unsuccessful authentication attempts. The number of authentication attempts should be less than or equal to the upper bound and greater or equal to the lower bound values. )]] unsuccessful authentication attempts for the authentication method password based authentication[assignment: other authentication method or none (Note: requires the ST Author to list any authentication methods that may be employed that are subject to some form of failure handling. )] occur related to [assignment: list of authentication events (Note: requires the ST Author to list any authentication methods that may be employed that are subject to some form of failure handlinghe second assignment relates to how the authentication failure attempts are measured, and may be different depending on the authentication method. This is true for the selection and assignment in FIA_AFL.1.2 as well there may be different actions taken based upon the authentication method. For example, for a user locally entering a password at the console and failing three times, may result in the account being locked, whereas a user remotely entering a password and failing three times, may simply result in the remote session being terminated. The action taken may be different for untrusted users versus administrative users. All these examples are acceptable, what is important is that the requirement is clear as to what authentication methods are covered, under what circumstances an action will result, and what the resulting action will be. )]. When the defined number of unsuccessful authentication attempts has been [selection: met], the TSF shall [assignment: list of actions (Note: the ST author should specify the actions to be taken in case the threshold is met. These actions could be disabling of an account for 5 minutes, disabling the terminal for an increasing amount of time (2 to the power of the number of unsuccessful attempts in seconds), or disabling of the account until unlocked by the administrator and simultaneously informing the administrator. The actions should specify the measures and if applicable the duration of the measure (or the conditions under which the measure will be ended). )] FIA_ATD.1 User attribute definition User application notes 114 Note that the user security attributes defined beldefined belowpara> to enforce its SFRs even in the case when supportin g trusted systems in the TOE environment are not available. This does not prohibit a TOE that operates in an environment where support of other trusted IT systems is availab is available to use such support. Page 52 of 237 CC version

53 Security Requirements for the TOE 115 If the TOE allows a remote trusted IT system to maintain the user attributes and the TOE maintains a local data store for either a backup reason (for example, if the connection to the remote trusted IT system is severed) or as a supplement to the remote trusted IT system, the ST author shall iterate this SFR with one iteration applicable to the security attribute maintained by the TSF and the other one applicable to the security attribute maintained by the remote trusted IT system expressing clearly which security attribute is held where. FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: User identifier; Group memberships; User password; Security roles; [assignment: other user security attributes]] FIA_UAU.1 Timing of authentication (RITE) Hierarchical to: No other components. Dependencies satisfied by: FIA_UID.1 Timing of identification FIA_UAU.1.1 The TSF shall allow [assignment: the information flow covered by the Network Information Flow Control Policy (for remote IT entities); [assignment: list of TSF other mediated actions (Note: the ST author should specify a list of further TSF-mediated actions that can be performed by the TSF on behalf of a user before the claimed identity of the user is authenticated. )] ] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. User application notes 116 This element applies to network traffic sent by remote IT entities and processed by the TOE. Some network traffic sent by remote IT entities is used to set up a communications channel that is subsequently used for authenticating the remote IT entity. The FTP_ITC.1.3 element is where the ST author specifies which conditions (actions performed using the trusted channel) require the remote IT entity to be authenticated. Additionally, remote IT entities may send traffic that does not require authentication as CC version 3.1 Page 53 of 237

54 Security Requirements for the TOE allowed by the Network Information Flow Control Policy described in the FDP_IF* components. Both of these cases are covered under the a portion of the FIA_UAU.1.1 element. There may be other actions that the TOE takes with respect to remote IT entities that are not covered by the FDP_IF* requirements as they are specified in the ST; in these cases, the ST author uses the assignment to specify these capabilities FIA_UAU.1_HU Timing of authentication (HU) Hierarchical to: No other components. Dependencies satisfied by: FIA_UID.1 Timing of identification FIA_UAU.1.1_HU The TSF shall allow [assignment: list of TSF mediated actions (Note: the ST author should specify a list of TSF-mediated actions that can be performed by the TSF on behalf of a user before the claimed identity of the user is authenticated. This list cannot be empty. If no actions are appropriate, component FIA_UAU.2 should be used instead. An example of such an action might include the request for help on the login procedure.)] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2_HU The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user FIA_UAU.5 Multiple authentication mechanisms User application notes 117 If any aspect of the rules for authentication can be managed, the ST author shall specify an iteration of FMT_MTD.1 covering this management aspect. FIA_UAU.5.1 The TSF shall provide [assignment: the following authentication mechanisms Authentication based on username and password (for human users); [selection: [assignment: list of other authentication mechanisms],none] ] to support user authentication. FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the [assignment: following rules: Authentication based on username and password is performed for TOE-originated requests and with credentials stored by the TSF by default unless another authentication method defined for human users in FIA_UAU.5.1 b is selected; Users with expired passwords are [selection: required to create a new password after correctly entering the expired password, locked out until their password is reset by an administrator]; Page 54 of 237 CC version

55 Security Requirements for the TOE [assignment: other rules describing how the multiple authentication mechanisms provide authentication and to which authentication policy it applies] (Note: requires that the TOE provides a complete self-sufficient identification and authentication mechanism based on on username and password with locally stored credentials which supports the identification and authentication mechanism defined by the OSPP base. Nevertheless, the ST author is allowed to specify additional username/password based authentication mechanisms with potentially remote credential stores. In such a case, the ST author must specify the relationship between the two (or more) username/password based authentication mechanisms, such as the specification of the precedence. )]. User application notes 118 In general, if multiple authentication methods are specified for the same credentials, the ST author must specify the relationship between them. 119 If any aspect of the rules for authentication can be managed, the ST author shall specify an iteration of FMT_MTD.1 covering this management aspect FIA_UAU.7 Protected authentication feedback Hierarchical to: No other components. Dependencies satisfied by: FIA_UAU.1 Timing of authentication (RITE) FIA_UAU.7.1 The TSF shall provide only [assignment: obscured feedback (Note: No feedback is viewed as a specific (stronger) method of providing obscured feedback. )] to the user while the authentication is in progress FIA_UID.1 Timing of identification FIA_UID.1.1 FIA_UID.1.2 The TSF shall allow [assignment: list of TSF-mediated actions (Note: the PP/ST author should specify a list of TSF-mediated actions that can be performed by the TSF on behalf of a user before the user has to identify itself. )] on behalf of the user to be performed before the user is identified. The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user FIA_USB.1 User-subject binding Hierarchical to: No other components. Dependencies satisfied by: FIA_ATD.1 User attribute definition User application notes 120 Throughout the SFR FIA_USB.1 User-subject binding the term user security attribute has been refined to security attribute since operating CC version 3.1 Page 55 of 237

56 Security Requirements for the TOE systems may assign security attributes to a subject that are not derived from security attributes of the user the subject is bound to. 121 Roles, groups and privileges also need to be assigned to the subject as long as they are used to enforce any SFR mentioned in the Security Target. A TOE may allow for the definition of roles as a set of privileges that can be assigned to a user but during user-subject binding the TOE may resolve those roles into the privileges that define the role and assign the individual privileges. In this case the roles themselves are no longer visible when the subject is executing. For simplification purpose it is still valid to state in a Security Target the set of security attributes as a role assigned to the subject rather than listing the individual privileges that define the role. This is required for cases where the set of privileges that define a role can be managed. 122 It is permissible to assign only a subset of the specified attributes to a subject acting on behalf of a user at one specific user-subject binding process. However, all of the specified assignments must be supported and enforced by the TOE depending on the type of the user-subject binding process in case multiple types are implemented. These types must be enumerated in the following assignments. FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects acting on the behalf of that human user: [assignment: The user identity; 1. list of security attributes used to enforce the access control policies 2. enforce the management policies 3. or used to satisfy auditing requirements ] FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: [assignment: rules for the initial association of attributes (Note: the ST author should specify any rules that are to apply upon initial association of attributes with subjects, or none. The rules shall define how the TSF identifies and selects the subject's security attributes upon user-subject binding. In many cases the subject will just inherit user security attributes from a user's profile. For some security attributes, the TSF may decide based on specific rules if the user security attribute is included in the subject's security attributes (e. g. a TOE may allow a user to select his active role(s) from the list of overall roles he has). Other subject security attributes derived from user security attributes may be determined by the TSF based on other TSF data. For example the TSF may assign a specific critical management privilege to a subject only if the user has this privilege assigned and the user connects to the TOE via a specific connection like a local console. While a TOE compliant to this Protection Profile is not required to implement such complicated rules, they need to be specified precisely if he does. )] Page 56 of 237 CC version

57 Security Requirements for the TOE FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: [assignment: rules for the changing of attributes (Note: the ST author should specify any rules that are to apply when changes are made to the user security attributes associated with subjects acting on behalf of users, or none. Changes to a subject's security attributes may be allowed by explicit user or administrator action or may happen automatically as the result of specific activities. For example in Unix-type systems the effective user- and group-id may change as the result of invoking programs with specific attributes. This part of the SFR is intended to define such rules. )] User application notes 123 The SFR above applies to human users, not necessarily remote IT entities. Many operating systems implement subjects that are not directly bound to a human user but in order to avoid having to implement two different ways of user-subject binding, they have a mechanisms that allows the definition of pseudo-users, which are protected from being used by a human user (they do not have authentication information associated with them) but can only be used by the TSF. The TSF may start specific subjects and bind those to the security attributes defined for pseudo-users. Daemons in Unix are a typical example for such subjects. A TOE that implements such a concept has to include an instantiation of FIA_USB.1 that describes the rules of such a usersubject binding process (in case they differ from the ones defined for human users) FIA_PKI.1 Public key based authentication Hierarchical to: No other components. Dependencies satisfied by: FMT_MTD.1 Management of TSF data (AE) User application notes 124 The use of public key based authentication must be compliant with the definition of the use of public key based authentication in the cryptographic protocol selected. FIA_PKI.1.1 The TSF shall use [selection: [assignment: X.509v3],public key cryptography (Note: the ST author should select the protocols that are used to implement administrative connectivity that also use public key based authentication. It should be noted that if X.509v3 certificates are used, RFC 5280 defines certificate validation and certification path validation requirements that must be implemented by the TOE as per this requirement. Depending on the protocols selected, there may be additional protocolspecific certificate-related requirements (and associated assurance activities) specified (for instance, RFC 4945 for IPsec). These additional requirements are specified in the requirements associated with that protocol. )] as defined by [assignment: RFC5280 or other method for key management/key validation if no X.509v3 certificates are used] to support authentication for [assignment: [selection: IPSec,TLS,SSH]] connections CC version 3.1 Page 57 of 237

58 Security Requirements for the TOE FIA_PKI.1.2 The TSF shall store and protect certificates and/or public keys from unauthorized deletion and modification. User application notes 125 FIA_PKI.1.2 applies to certificates and/or public keys that are used and processed by the TSF. Certificates or public keys that are used and process by other components in the Operational Environment (e.g., the RADIUS server) are not intended to be covered by this element. 126 If a TOE contains preloaded certificates or public keys, this is acceptable as long as the administrator can disable (e.g., revoke, delete) and enable their use Requirements related to security management FMT_MOF.1 Management of security functions behaviour Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles FMT_MOF.1.1 The TSF shall restrict the ability to [selection: modify the behaviour of] the functions [assignment: password based user authentication] to [assignment: rules that need to be satisfied for other users to perform the operations]by allowing those users to specify rules for acceptable passwords that: allow for uppercase characters, lowercase characters, digits, and special characters to be used in passwords; define a minimum password length of 8 characters or more (at least up to 15 characters); define that passwords must have at least one digit and one special character; reject passwords used by the same user before up to a history of at least 6 passwords FMT_MSA.1 Management of security attributes Hierarchical to: No other components. Dependencies satisfied by: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_MSA.1.1 The TSF shall enforce the [assignment: access control SFP] to restrict the ability to modify and [selection: change_default, query, delete,[assignment: other operations (Note: if selected, the ST author should specify which other operations the role could perform. An example of such an operation could be create.)] (Note: the ST author should specify the operations that can be Page 58 of 237 CC version

59 Security Requirements for the TOE applied to the identified security attributes. The ST author can specify that the role can modify the default value (change_default), query, modify the security attribute, delete the security attributes entirely or define their own operation.)] the security attributes [assignment: of the objects covered by the SFP] to [assignment: the owner of the object and[assignment: rules that need to be satisfied for other users to perform the operations]. ] FMT_MSA.3 Static attribute initialisation (DAC) Hierarchical to: No other components. Dependencies satisfied by: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1 FMT_MSA.3.2 The TSF shall enforce the [assignment: access control SFP] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP. The TSF shall allow the [assignment: the authorised identified roles, or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify any additional rule that will allow a user to perform the action. )] (Note: the ST author should specify the roles that are allowed to modify the values of the security attributes. The possible roles are specified in FMT_SMR.1 Security roles. )] to specify alternative initial values to override the default values when an object or information is created FMT_MSA.3_NI Static attribute initialisation (NI) Hierarchical to: No other components. Dependencies satisfied by: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1_NI FMT_MSA.3.2_NI The TSF shall enforce the [assignment: Network Information Flow Control Policy] to provide [selection, choose one of: restrictive, permissive,[assignment: other property (Note: if the ST author selects another property, the ST author should specify the desired characteristics of the default values. )] (Note: the ST author should select whether the default property of the access control attribute will be restrictive, permissive, or another property. Only one of these options may be chosen.)] default values for security attributes that are used to enforce the SFP. The TSF shall allow the [assignment: the authorised identified roles, or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify any additional rule that will allow a user to perform the action. )] (Note: the ST author should specify the roles that are allowed to modify the values of the security attributes. The possible roles are specified in FMT_SMR.1 Security roles. )] to specify alternative initial values to override the default values when an object or information is created CC version 3.1 Page 59 of 237

60 Security Requirements for the TOE FMT_MSA.4 Security attribute value inheritance Hierarchical to: No other components. Dependencies satisfied by: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] User application notes 127 The rules need to specify how a new object covered by one of the access control policies gets its security attributes initialized. If those rules differ per object type, the ST author shall use multiple instantiations of FMT_MSA.4 to cover all object types that have security attributes. Inheriting security attributes from another object or from the user/subject that creates the object is one possible way a specific TOE may determine how to initialize an object's security attributes. FMT_MSA.4.1 The TSF shall use the following rules to set the value of security attributes for objects covered by an access control policy: [assignment: rules for setting the values of security attributes (Note: the ST author specifies the rules governing the value that will be inherited by the specified security attribute, including the conditions that are to be met for the rules to be applied. For example, if a new file or directory is created (in a multilevel filesystem), its label is the label at which the user is logged in at the time it is created. )] FMT_MTD.1 Management of TSF data (AE) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles User application notes 128 This SFR applies to FAU_SEL.1 Selective audit. FMT_MTD.1.1 The TSF shall restrict the ability to [selection: query, modify] the [assignment: set of audited events] to [assignment: the authorised identified roles,or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify the additional rules that allow a user to perform the activity. )] (Note: the ST author should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in FMT_SMR.1 Security roles. )]. Page 60 of 237 CC version

61 Security Requirements for the TOE FMT_MTD.1_AS Management of TSF data (AS) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles User application notes 129 This SFR applies to FAU_STG.1 Protected audit trail storage. FMT_MTD.1.1_AS The TSF shall restrict the ability to [selection: clear,[selection: configure the storage location,create,delete,[assignment: other operations]]] the [assignment: audit storage] to [assignment: the authorised identified roles,or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify the additional rules that allow a user to clear the audit storage. )] (Note: the ST author should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in FMT_SMR.1 Security roles. )] FMT_MTD.1_AT Management of TSF data (AT) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles User application notes 130 This SFR applies to FAU_STG.3 Action in case of possible audit data loss. FMT_MTD.1.1_AT The TSF shall restrict the ability to [selection: modify,[selection: add,delete]] the [assignment: threshold of the audit trail when an action is performed; action when the threshold is reached ] to [assignment: the authorised identified roles,or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify the additional rules that allow a user to perform the activity. )] (Note: the ST author should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in FMT_SMR.1 Security roles. )] FMT_MTD.1_AF Management of TSF data (AF) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles User application notes 131 This SFR applies to FAU_STG.4 Prevention of audit data loss CC version 3.1 Page 61 of 237

62 Security Requirements for the TOE FMT_MTD.1.1_AF The TSF shall restrict the ability to [selection: modify,[selection: add,delete]] the [assignment: actions to be taken in case of audit storage failure] to [assignment: the authorised identified roles,or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify the additional rules that allow a user to perform the activity. )] (Note: the ST author should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in FMT_SMR.1 Security roles. )] FMT_MTD.1_CM Management of TSF data (CM) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles User application notes 132 This SFR applies to FTP_ITC.1 Inter-TSF trusted channel. 133 The ability to disable could include deletion or revocation of a certificate or key. The enable aspect would make a certificate or key valid for use. These management functions apply to preloaded certificates or public keys as well as those loaded by an administrator. FMT_MTD.1.1_CM The TSF shall restrict the ability to [selection: import, enable, disable] the [assignment: digital certificates or public keys used for remote entity authentication[selection: [assignment: other security functions],no other security function]] to [assignment: the authorised identified roles,or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify the additional rules that allow a user to perform the activity. )] (Note: the ST author should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in FMT_SMR.1 Security roles. )] FMT_MTD.1_NI Management of TSF data (NI) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles User application notes 134 This SFR applies to FDP_IFF.1 Simple security attributes. FMT_MTD.1.1_NI The TSF shall restrict the ability to [selection: define, query, modify, delete,[assignment: other operations]] the [assignment: security attributes for the rules governing the identification and matching of network data; actions performed on the identified network data Page 62 of 237 CC version

63 Security Requirements for the TOE ] to [assignment: the authorised identified roles,or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify the additional rules that allow a user to perform the activity. )] (Note: the ST author should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in FMT_SMR.1 Security roles. )] FMT_MTD.1_IAT Management of TSF data (IAT) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles User application notes 135 This SFR applies to FIA_AFL.1 Authentication failure handling. FMT_MTD.1.1_IAT The TSF shall restrict the ability to [selection: modify] the [assignment: threshold for unsuccessful authentication attempts] to [assignment: the authorised identified roles,or users that satisfy the following rules: [assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify the additional rules that allow a user to perform the activity. )] (Note: the ST author should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in FMT_SMR.1 Security roles. )] FMT_MTD.1_IAF Management of TSF data (IAF) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles User application notes 136 This SFR applies to FIA_ATD.1 User attribute definition, FIA_UAU.1 Timing of authentication (RITE) and FIA_UID.1 Timing of identification. FMT_MTD.1.1_IAF The TSF shall restrict the ability to [selection: re-enable] the [assignment: authentication to the account subject to authentication failure] to [assignment: the authorised identified roles,or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify the additional rules that allow a user to perform the activity. )] (Note: the ST author should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in FMT_SMR.1 Security roles. )] CC version 3.1 Page 63 of 237

64 Security Requirements for the TOE FMT_MTD.1_IAU Management of TSF data (IAU) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles User application notes 137 This SFR applies to FIA_ATD.1 User attribute definition, FIA_UAU.1 Timing of authentication (RITE) and FIA_UID.1 Timing of identification. FMT_MTD.1.1_IAU The TSF shall restrict the ability to [selection: initialize, modify, delete] the [assignment: user security attributes] to [assignment: the authorised identified roles,or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify the additional rules that allow a user to perform the activity. )] (Note: the ST author should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in FMT_SMR.1 Security roles. )] FMT_REV.1 Revocation (OBJ) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles FMT_REV.1.1 The TSF shall restrict the ability to revoke [assignment: object security attributes defined by SFPs] associated with the [selection: corresponding object] under the control of the TSF to [assignment: the authorised identified roles,or users that satisfy the following rules: rules that define when a user is allowed to perform the activity the ST author should specify the additional rules that allow a user to perform the activity. ] FMT_REV.1.2 The TSF shall enforce the following rules [assignment: The access rights associated with an object shall be enforced when an access check is made; [assignment: specification of other revocation rules]] FMT_REV.1_USR Revocation (USR) Hierarchical to: No other components. Dependencies satisfied by: FMT_SMR.1 Security roles FMT_REV.1.1_USR The TSF shall restrict the ability to revoke [assignment: user security attributes defined by SFPs] associated with the [selection: corresponding Page 64 of 237 CC version

65 Security Requirements for the TOE user] under the control of the TSF to [assignment: the authorised identified roles,or users that satisfy the following rules:[assignment: rules that define when a user is allowed to perform the activity (Note: the ST author should specify the additional rules that allow a user to perform the activity. )]] FMT_REV.1.2_USR The TSF shall enforce the following rules [assignment: The enforcement of the revocation of security-relevant authorizations with the next user-subject binding process during the next authentication of the user; [assignment: specification of other revocation rules] ] FMT_ERM.1 Remote Management Capabilities Hierarchical to: No other components. Dependencies satisfied by: FTP_ITC.1 Inter-TSF trusted channel FMT_ERM.1.1 The TSF shall allow management functions also to be performed from a remote IT entity using a trusted channel established in accordance with the requirements stated in FTP_ITC.1 Inter-TSF trusted channel FMT_SMR.1 Security roles Hierarchical to: No other components. Dependencies satisfied by: FIA_UID.1 Timing of identification User application notes 138 When the TOE is started for the first time there needs to be one role that is able to perform the management functions required to configure the TOE. This is viewed as the authorized administrator. A TOE may have predefined additional roles (e. g. for specific management operations) and may also allow for the dynamic definition of additional roles. This SFR is intended to specify the pre-defined roles (as far as they are relevant for the security policy defined by the SFRs), but of course can not be used to specify all roles that may be created dynamically.therefore this Protection Profile requires the specification of general rules used by the policy to decide if a user is allowed to perform specific management operations. Those rules may be based on the roles a user has, but also on specific privileges assigned to a user or the group the user belongs to, as well as on additional TSF data (e. g. the user is bound to a specific subject, time and date, approval of the activity by another user, etc.). As long as those rules allow for the restriction of management activities to a defined set of users and as long as the overall rules do not allow user to escalate their own privileges, such rules such rules are acceptable. The ST author is required to specify those rules in the Security Target.A specific TOE may support more privileges than the developer may want to be specified in the security policy defined by the CC version 3.1 Page 65 of 237

66 Security Requirements for the TOE SFRs. For those privileges that are not used in the Security Target, the developer shall provide some user guidance explaining that any privileges not mentioned in the Security Target may only be assigned to users at the risk of the organization operating the TOE, since their correct implementation with respect to the overall guidance documentation has not been tested or otherwise analyzed as part of the evaluation. FMT_SMR.1.1 The TSF shall maintain the roles [assignment: authorized administrator; regular user; [assignment: other management roles (Note: the ST author should specify the further management roles that are recognised by the system. )]] FMT_SMR.1.2 The TSF shall be able to associate users with roles Requirements related to the protection of the TSF FPT_STM.1 Reliable time stamps User application notes 139 A TSF may obtain reliable time stamps from a local hardware clock or may use a secured network connection to obtain the time stamp from a trusted remote entity (if such an entity is available). In the case of a local hardware clock, either the TSF needs to export a management interface that allows a trusted administrator to set or modify the local time, which causes the TSF to use its interfaces to the local hardware clock to perform those actions, or have a protected interface to the hardware in the IT environment that allows for setting or modifying the time clock. For example the possibility to manage the local hardware clock using a dedicated management console used to configure the hardware is acceptable. FPT_STM.1.1 The TSF shall be able to provide reliable time stamps Requirements related to the access to the TOE FTA_SSL.1 TSF-initiated session locking Hierarchical to: No other components. Dependencies satisfied by: FIA_UAU.1 Timing of authentication (RITE) FTA_SSL.1.1 The TSF shall lock an interactive session to a human user maintained by the TSF after [assignment: time interval of user inactivity (Note: the ST author should specify the interval of user inactivity that will trigger the locking of an interactive session. If so desired the ST author could, through the assignment, specify that the time interval is left to the authorised administrator or the user. The management functions in the FMT class can Page 66 of 237 CC version

67 Security Requirements for the TOE specify the capability to modify this time interval, making it the default value.)] by: clearing or overwriting TSF controlled display devices, making the current contents unreadable; disabling any activity of the user's data access/tsf controlled display devices other than unlocking the session. User application notes 140 FTA_SSL.1.1 b) does not prohibit an operating system to continue operation for processes operating on behalf of the user when a session is locked. The operating system should just not display any output from such processes on the display device and not accept any input from input devices associated with the display device (e. g. keyboard and mouse) except those required for unlocking the session as long as the session is locked. FTA_SSL.1.2 The TSF shall require the following events to occur prior to unlocking the session: [assignment: Successful re-authentication with the credentials of the user owning the session using[assignment: list of authentication methods out of the list of allowed methods specified in FIA_UAU.5 Multiple authentication mechanisms (Note: The intent of this assignment is that a specific time period or range of time periods are available for the administrator to set. For example, a TOE may allow an administrator to choose a timeout to be 5 minutes, 15 minutes, an hour, or anywhere between using 1 minute increments. It is important that the TOE can be configured such that only an administrator, or a user with some form of privilege, can set the timeout period. )] [assignment: other events to occur]] User application notes 141 It is possible that a user connects to the TOE from a remote system, for example when using SSH, however this requirement does not apply to such sessions FTA_SSL.2 User-initiated locking Hierarchical to: No other components. Dependencies satisfied by: FIA_UAU.1 Timing of authentication (RITE) User application notes 142 The notes defined above for FTA_SSL.1 TSF-initiated session locking also apply here CC version 3.1 Page 67 of 237

68 Security Requirements for the TOE FTA_SSL.2.1 The TSF shall allow user-initiated locking of the user's own interactive session maintained by the TSF, by: clearing or overwriting TSF controlled display devices, making the current contents unreadable; disabling any activity of the user's data access/tsf controlled display devices other than unlocking the session. FTA_SSL.2.2 The TSF shall require the following events to occur prior to unlocking the session: [assignment: Successful re-authentication with the credentials of the user owning the session using[assignment: list of authentication methods out of the list of allowed methods specified in FIA_UAU.5 Multiple authentication mechanisms] [assignment: other events to occur]] Requirements related to the use of trusted channels FTP_ITC.1 Inter-TSF trusted channel User application notes 143 For a specification of below cited cipher suites, see the RFCs mentioned. 144 It is mandatory that the TOE can be configured to reject the setup of a trusted channel if not one of the below mentioned cipher suites is used. A TOE compliant with this base OSPP may still implement a subset of the cipher suites listed below and may also implement cipher suites not contained in the list below but listed in the RFCs referenced. It just needs to provide the capability to ensure that a combination of cryptographic algorithms mentioned below is used if a trusted channel is requested. Other cipher suites may only be used for untrusted channels. FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or/and disclosure using the following mechanisms:[selection: SSH as defined in RFCs 4251, 4252, 4253, and 4254 with a combination of the following cipher suites defined there: For encryption: 3DES-CBC, AES256-CBC, AES128-CBC, [selection: AES192-CBC,AEAD_AES_128_GCM (as defined in RFC 5647),AEAD_AES_256_GCM (as defined in RFC 5647),no other algorithms] For integrity: [selection: HMAC_SHA1,HMAC-SHA1-96,HMAC- MD5,HMAC-MD5-96] Page 68 of 237 CC version

69 Security Requirements for the TOE For key exchange: DIFFIE-HELLMAN-GROUP14-SHA1, [selection: DIFFIE-HELLMAN-GROUP1-SHA1,no other algorithm] For public key encryption: SSH-DSS, SSH-RSA [selection: PGP- SIGN-RSA,PGP-SIGN-DSS,no other algorithm], TLS as defined in RFC 5246 using X.509 certificates and supporting the following cipher suites defined there: TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA[selection: TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_2 56_CBC_SHA256,TLS_DH_DSS_WITH_AES_128_CBC_SHA,TLS_ DH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_ 128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_D H_DSS_WITH_AES_256_CBC_SHA,TLS_DH_RSA_WITH_AES_25 6_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DH E_RSA_WITH_AES_256_CBC_SHA,TLS_DH_DSS_WITH_AES_128 _CBC_SHA256,TLS_DH_RSA_WITH_AES_128_CBC_SHA256,TLS _DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH _AES_128_CBC_SHA256,TLS_DH_DSS_WITH_AES_256_CBC_SH A256,TLS_DH_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_DS S_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256 _CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA 256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_E CDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECD SA_WITH_AES_256_CBC_SHA384], IPSEC protocol ESP as defined in RFC 4303 using the cryptographic algorithms For ESP encryption: AES-CBC-128, AES-CBC-256 (both specified by RFC 3602), [selection: Triple-DES,AES-GCM-128 as specified in RFC 4106,AES-GCM-256 as specified in RFC 4106,no other algorithm] For ESP authentication and authentication header protection: [selection: HMAC-SHA1-96,AES-XCBC-MAC-96] For key negotiation and SA establishment: [selection: IKEv1 as defined in RFCs 2407, 2408, 2409, RFC 4109,[selection: RFC 4868 for hash functions,no other RFCs for hash functions],ikev2 as defined in RFCs 5996, 4307,[selection: RFC 4868 for hash functions,no other RFC 4868 for hash functions],,no other algorithm] For use in IKE key establishment: DH Groups 14 (2048-bit MODP), and [selection: 24 (2048-bit MODP with 256-bit POS),19 (256-bit Random ECP),20 (384-bit Random ECP),[assignment: other DH groups that are implemented by the TOE],no other DH groups] For Peer Authentication: [selection: DSA,rDSA,ECDSA]] FTP_ITC.1.2 The TSF shall permit [selection: the TSF, another trusted IT product (Note: the ST author must specify whether the local TSF, another trusted IT product, or both shall have the capability to initiate the trusted channel.)] to initiate communication via the trusted channel CC version 3.1 Page 69 of 237

70 Security Requirements for the TOE FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [assignment: all security functions specified in the ST that interact with remote trusted IT systems and[assignment: list of functions or other conditions which require a trusted channel (Note: the ST author should specify the further functions or conditions for which a trusted channel is required. Examples of these functions may include transfer of user, subject, and/or object security attributes and ensuring consistency of TSF data.)]]. 6.2 Assurance Security Requirements 145 This protection profiles includes the following assurance components, which are refined/complemented by the assurance activities indicated in the functional requirements Tailored Assurance Package for Operating Systems SAR Title ASE_INT.1 ST introduction ASE_CCL.1 Conformance claims ASE_SPD.1 Security problem definition ASE_OBJ.2 Security objectives ASE_ECD.1 Extended components definition ASE_REQ.2 Derived security requirements ASE_TSS.1 TOE summary specification ADV_ARC.1 Security architecture description ADV_FSP.1 Basic functional specification AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC_CMC.3 Authorisation controls ALC_CMS.3 Implementation representation CM coverage ALC_DEL.1 Delivery procedures ALC_FLR.3 Systematic flaw remediation ALC_LCD.1 Developer defined life-cycle model ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: basic design ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample AVA_VAN.2 Vulnerability analysis Table 7 Tailored Security Assurance Requirements Page 70 of 237 CC version

71 Security Requirements for the TOE 6.3 Rationale for the Security Requirements 146 This section provides the rationale for the internal consistency and completeness of the security functional requirements defined in this Protection Profile Internal Consistency of Requirements 147 The mutual support and internal consistency of the components selected for this Protection Profile is described in this section. 148 The following rationale demonstrates the internal consistency of the functional requirements Audit 149 The TOE shall implement a general audit mechanism. This audit mechanism shall generate audit records for all security-relevant events, where an authorized user shall have the capability to select the events to be audited. An authorized user shall be provided with the means to read and interpret the audit data. The TOE shall protect the audit trail and ensure that proper actions are taken when the audit trail fills up or is full. This applies to local audit storage, which the TOE must provide. Optionally the TOE may allow a configuration where audit data is transferred to a remote trusted IT system where it is stored User Data Protection 150 User data needs to be protected from unauthorized access. This requires the TOE to implement an access control policy for all types of objects that may be used to share user data between different users or subjects. For at least one type of persistent objects the access control policy must allow for specifying access control down to the level of a single user. In addition, an information flow control policy ensures that only intended network traffic is allowed by the TOE. The user data protection is supported by proper residual information protection Identification and Authentication 151 Entities interacting with the TOE shall be properly identified and authenticated (with the exception of the information flow controlled by the TOE security policy, which only requires proper identification). The usersubject binding process ensures that external entities have a TSF-controlled representation to allow the enforcement of the security policies on them. Supporting to the identification and authentication is the password quality mechanism mandated by the TOE Security Management 152 The TOE shall provide management mechanisms for all security functions, including the management functionality itself CC version 3.1 Page 71 of 237

72 Security Requirements for the TOE TOE Access 153 The TOE shall provide the capability to lock sessions established for subjects either initiated by the user controlling the subject or by the TOE TOE Protection 154 The TOE shall provide a cryptographically-protected network protocol based on symmetric ciphers, which supports certificate based authentication of the remote peer. For supporting the authentication, the TOE shall use digital certificates as defined in the protocol specifications Security Requirements Coverage SFE FAU_GEN.1 Audit data generation FAU_GEN.2 User identity association FAU_SAR.1 Audit review FAU_SAR.2 Restricted audit review FAU_SEL.1 Selective audit FAU_STG.1 Protected audit trail storage FAU_STG.3 Action in case of possible audit data loss FAU_STG.4 Prevention of audit data loss FDP_ACC.1 Subset access control FDP_ACF.1 Security attribute based access control FDP_IFC.1 Subset information flow control Objectives O.AUDITING O.AUDITING O.AUDITING O.AUDITING O.AUDITING O.AUDITING O.AUDITING O.AUDITING O.DISCRETIONARY.ACCESS O.SUBJECT.COM O.DISCRETIONARY.ACCESS O.SUBJECT.COM O.NETWORK.FLOW Page 72 of 237 CC version

73 Security Requirements for the TOE SFE FDP_IFF.1 Simple security attributes FDP_RIP.2 Full residual information protection FIA_AFL.1 Authenticatio n failure handling FIA_ATD.1 User attribute definition FIA_UAU.1 Timing of authentication (RITE) FIA_UAU.1_ HU Timing of authentication (HU) FIA_UAU.5 Multiple authentication mechanisms FIA_UAU.7 Protected authentication feedback FIA_UID.1 Timing of identification FIA_USB.1 User-subject binding FIA_PKI.1 Public key based authentication FMT_MOF.1 Management of security functions behaviour FMT_MSA.1 Management of security Objectives O.NETWORK.FLOW O.AUDITING O.DISCRETIONARY.ACCESS O.SUBJECT.COM O. NETWORK.FLOW O.IA O.IA O.IA O.NETWORK.FLOW O.IA O.IA O.IA O.IA O.IA O.TRUSTED_CHANNEL O.IA O.MANAGE O.MANAGE CC version 3.1 Page 73 of 237

74 Security Requirements for the TOE SFE Objectives attributes FMT_MSA.3 Static attribute O.MANAGE initialisation (DAC) FMT_MSA.3 _NI Static attribute O.MANAGE initialisation (NI) FMT_MSA.4 Security O.MANAGE attribute value inheritance FMT_MTD.1 Management O.MANAGE of TSF data (AE) FMT_MTD.1 _AS Management O.MANAGE of TSF data (AS) FMT_MTD.1 _AT Management O.MANAGE of TSF data (AT) FMT_MTD.1 _AF Management O.MANAGE of TSF data (AF) FMT_MTD.1 _CM Management O.MANAGE of TSF data (CM) FMT_MTD.1 _NI Management O.MANAGE of TSF data (NI) FMT_MTD.1 _IAT Management O.MANAGE of TSF data (IAT) FMT_MTD.1 O.MANAGE Page 74 of 237 CC version

75 Security Requirements for the TOE SFE _IAF Management of TSF data (IAF) FMT_MTD.1 _IAU Management of TSF data (IAU) FMT_REV.1 Revocation (OBJ) FMT_REV.1 _USR Revocation (USR) FMT_ERM.1 Remote Management Capabilities FMT_SMR.1 Security roles FPT_STM.1 Reliable time stamps FTA_SSL.1 TSF-initiated session locking FTA_SSL.2 User-initiated locking FTP_ITC.1 Inter-TSF trusted channel Objectives O.MANAGE O.MANAGE O.MANAGE O.MANAGE O.MANAGE O.AUDITING O.IA O.IA O.TRUSTED_CHANNEL Table 8 Security Functional Requirements coverage Objectives O.AUDITING Coverage Rationale The events to be audited are defined in [FAU_GEN.1] and are associated with the identity of the user that caused the event [FAU_GEN.2]. Authorized users are provided the capability to read the audit records [FAU_SAR.1], while all other users are denied access to the audit records [FAU_SAR.2]. The CC version 3.1 Page 75 of 237

76 Security Requirements for the TOE Objectives O.DISCRETIONARY.ACCESS O.NETWORK.FLOW O.SUBJECT.COM Coverage Rationale authorized user must have the capability to specify which audit records are generated [FAU_SEL.1]. The TOE prevents the audit log from being modified or deleted [FAU_STG.1] and ensures that the audit log is not lost due to resource shortage [FAU_STG.3, FAU_STG.4]. To support auditing, the TOE is able to maintain proper time stamps [FPT_STM.1]. The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2]. The TSF must control access to resources based on the identity of users that are allowed to specify which resources they want to access for storing their data. The access control policy must have a defined scope of control [FDP_ACC.1]. The rules for the access control policy are defined [FDP_ACF.1]. The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2]. The network information flow control mechanism controls the information flowing between different entities [FDP_IFC.1]. The TOE implements a rule-set governing the information flow [FDP_IFF.1]. Information flow control is enforced for unauthenticated remote IT entity, allowing authenticated remote IT entity to be excluded from the rules of the network information flow control policy (FIA_UAU.1(RITE)). The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2]. The TSF must control the exchange of data using transient storage objects between subjects based on the identity of users. The access control policy must have a defined scope of control [FDP_ACC.1]. The rules for the access control policy Page 76 of 237 CC version

77 Security Requirements for the TOE Objectives O.IA O.MANAGE Coverage Rationale are defined [FDP_ACF.1]. The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2]. The TSF must ensure that only authorized users gain access to the TOE and its resources. Users authorized to access the TOE must use an identification and authentication process [FIA_UID.1, FIA_UAU.1(HU)]. Multiple I&A mechanisms are allowed as specified in [FIA_UAU.5]. To ensure authorized access to the TOE, authentication data is protected [FIA_ATD.1, FIA_UAU.7]. Proper authorization for subjects acting on behalf of users is also ensured [FIA_USB.1]. To support the strength of authentication methods, the TOE is capable of identifying and reacting to unsuccessful authentication attempts [FIA_AFL.1] and define password rules [FMT_MOF.1]. In addition, user-initiated and TSF-initiated session locking [FTA_SSL.1, FTA_SSL.2] protect the authenticated user's session. The protection of reused resources ensures that no data leaks from other protected sources [FDP_RIP.2] are present. The TOE provides management interfaces for: the access control policies [FMT_MSA.1, FMT_MSA.3( DAC)]; the information flow control policy [FMT_MSA CC version 3.1 Page 77 of 237

78 Security Requirements for the TOE Objectives Coverage Rationale (NI), FMT_MTD.1( NI)]; the auditing aspects [FMT_MTD.1 (AE), FMT_MTD.1( AS), FMT_MTD.1( AT), FMT_MTD.1( AF)]; digital certificates [FMT_MTD.1 (CM)]; the identification and authentication aspects [FMT_MTD.1 (IAT), FMT_MTD.1( IAF), FMT_MTD.1( IAU)]. O.TRUSTED_CHANNEL Persistently stored user data is stored either in hierarchical or relational fashion, which implies an inheritance of security attributes from parent object [FMT_MSA.4]. The rights management for the different management aspects is defined with [FMT_SMR.1]. The management interfaces for the revocation of user and object attributes is provided with [FMT_REV.1(OBJ) and FMT_REV.1(USR)]. Management of password rules is defined in [FMT_MOF.1]. Remote management capabilities need to be provided as defined in [FMT_ERM.1]. The TOE provides a trusted channel protecting communication between a remote trusted IT system and itself [FTP_ITC.1]. Digital certificates must be used for remote entity authentication [FIA_PKI.1]. Page 78 of 237 CC version

79 Security Requirements for the TOE Table 9 Security Functional Requirements rationale Security Requirements Dependency Analysis SFR Dependencies Resolved FAU_GEN.1 FPT_STM.1 Yes FAU_GEN.2 FAU_GEN.1 Yes: FAU_GEN.1 Yes: FIA_UID.1 FIA_UID.1 FAU_SAR.1 FAU_GEN.1 Yes FAU_SAR.2 FAU_SAR.1 Yes FAU_SEL.1 FAU_GEN.1 Yes: FAU_GEN.1 Yes: FMT_MTD.1 FMT_MTD.1(AE) FAU_STG.1 FAU_GEN.1 Yes FAU_STG.3 FAU_STG.1 Yes FAU_STG.4 FAU_STG.1 Yes FDP_ACC.1 FDP_ACF.1 Yes: FDP_ACF.1 FDP_ACF.1 FDP_ACC.1 Yes: FDP_ACC.1 Yes: FMT_MSA.3 FMT_MSA.3(DAC) FDP_IFC.1 FDP_IFF.1 Yes: FDP_IFF.1 FDP_IFF.1 FDP_IFC.1 Yes: FDP_IFC.1 Yes: FMT_MSA.3 FMT_MSA.3(NI) FDP_RIP.2 N/A Yes FIA_AFL.1 FIA_UAU.1 Yes FIA_ATD.1 N/A Yes FIA_UAU.1(RITE) FIA_UID.1 Yes FIA_UAU.1(HU) FIA_UID.1 Yes FIA_UAU.5 N/A Yes FIA_UAU.7 FIA_UAU.1 Yes: FIA_UAU.1(HU) FIA_UID.1 N/A Yes FIA_USB.1 FIA_ATD.1 Yes: FIA_ATD.1 FIA_PKI.1 FMT_MTD.1 Yes: FMT_MTD.1(CM) FMT_MOF.1 FMT_SMR.1 Yes: FMT_SMR.1 Yes: FMT_SMF.1 FMT_SMF.1 FMT_MSA.1 [FDP_ACC.1 or Yes: FDP_ACC.1 Yes: FDP_IFC.1] FMT_SMR.1 Yes: FMT_SMR.1 FMT_SMF.1 FMT_SMF.1 FMT_MSA.3(DAC) FMT_MSA.3(NI) FMT_MSA.1 FMT_SMR.1 FMT_MSA.1 FMT_SMR.1 Yes: FMT_MSA.1 Yes: FMT_SMR.1 NO, but satisfied with FMT_MTD.1(NI) Yes: FMT_SMR.1 FMT_MSA.4 [FDP_ACC.1 or FDP_IFC.1] Yes: FDP_ACC.1 FMT_MTD.1(AE) FMT_SMR.1 Yes: FMT_SMR.1 No: FMT_SMF.1 FMT_SMF.1 FMT_MTD.1(AS) FMT_SMR.1 Yes: FMT_SMR.1 No: FMT_SMF.1 FMT_SMF.1 FMT_MTD.1(AT) FMT_SMR.1 Yes: FMT_SMR.1 No: CC version 3.1 Page 79 of 237

80 Security Requirements for the TOE SFR Dependencies Resolved FMT_SMF.1 FMT_SMF.1 FMT_MTD.1(AF) FMT_SMR.1 Yes: FMT_SMR.1 No: FMT_SMF.1 FMT_SMF.1 FMT_MTD.1(CM) FMT_SMR.1 Yes: FMT_SMR.1 No: FMT_SMF.1 FMT_SMF.1 FMT_MTD.1(NI) FMT_SMR.1 Yes: FMT_SMR.1 No: FMT_SMF.1 FMT_SMF.1 FMT_MTD.1(IAT) FMT_SMR.1 Yes: FMT_SMR.1 No: FMT_SMF.1 FMT_SMF.1 FMT_MTD.1(IAF) FMT_SMR.1 Yes: FMT_SMR.1 No: FMT_SMF.1 FMT_SMF.1 FMT_MTD.1(IAU) FMT_SMR.1 Yes: FMT_SMR.1 No: FMT_SMF.1 FMT_SMF.1 FMT_REV.1(OBJ) FMT_SMR.1 Yes FMT_REV.1(USR) FMT_SMR.1 Yes FMT_ERM.1 FTP_ITC.1 Yes FMT_SMR.1 FIA_UID.1 Yes FPT_STM.1 N/A Yes FTA_SSL.1 FIA_UAU.1 Yes: FIA_AUA.1(HU) FTA_SSL.2 FIA_UAU.1 Yes: FIA_AUA.1(HU) FTP_ITC.1 N/A Yes Table 10 Security Functional Requirements dependency analysis Rationale for unresolved dependencies: 155 The dependencies in several SFRs on FMT_SMF.1 have not been resolved, since the SFR FMT_SMF.1 has not been included in the Protection Profile. Instead the Protection Profiles contains specific instances of FMT_MTD.1 for each individual management aspect with the ability (and requirement) for the ST author to specify exactly the rules a TOE uses to determine if a user has the required authority to perform a management activity. 156 FMT_MSA.3(NI): FMT_MTD.1(NI) is specified to require the management of security attributes for the Network Information Flow Control Policy, just as a potential FMT_MSA.1(NI) would have been specified. However, the Network Information Flow Control Policy is not required to be enforced when managing the security attributes, as the management aspect of the network information flow control functionality is not protected by the network information flow control mechanism. Therefore, FMT_MSA.1 is not applicable and is replaced with FMT_MTD.1(NI) Security Assurance Requirements Rationale SAR Dependencies Resolved ASE_INT.1 ASE_INT.1 Yes ASE_CCL.1 ASE_ECD.1 Yes ASE_REQ.1 Yes Page 80 of 237 CC version

81 Security Requirements for the TOE SAR Dependencies Resolved ASE_SPD.1 ASE_OBJ.2 ASE_SPD.1 Yes ASE_ECD.1 ASE_REQ.2 ASE_OBJ.2 Yes ASE_ECD.1 Yes ASE_INT.1 Yes ASE.TSS.1 ASE_REQ.1 Yes ADV_FSP.1 Yes ADV_ARC.1 ADV_FSP.1 Yes ADV_TDS.1 No ADV_FSP.1 AGD_OPE.1 ADV_FSP.1 Yes AGD_PRE.1 ALC_CMS.1 Yes ALC_CMC.3 ALC_DVS.1 No ALC_LCD.1 Yes ALC_CMS.3 ALC_DEL.1 ALC_FLR.3 ALC_LCD.1 ATE_COV.2 ADV_FSP.2 No ATE_FUN.1 Yes ADV_ARC.1 Yes ATE_DPT.1 ADV_TDS.2 No ATE_FUN.1 Yes ATE_FUN.1 ATE_COV.1 Yes ADV_FSP.2 No AGD_OPE.1 Yes ATE_IND.2 AGD_PRE.1 Yes ATE_COV.1 Yes ATE_FUN.1 Yes ADV_ARC.1 Yes ADV_FSP.2 No AVA_VAN.2 ADV_TDS.1 No AGD_OPE.1 Yes AGD_PRE.1 Yes Table 11 Security Assurance Requirements dependency analysis Rationale for unresolved dependencies 157 Several dependencies on components of the ADV_TDS family have not been satisfied (ADV_ARC.1, ATE_DPT.1, AVA_VAN.2). Although no component from the ADV_TDS family is included in this mapping, designrelated aspects from the description of the SFR-related assurance activities described in this document have to be considered during an evaluation. No component of the ADV_TDS family has been included since none of them fits the view on the required design evaluation aspects for products compliant CC version 3.1 Page 81 of 237

82 Security Requirements for the TOE with this Protection Profile. Still, the authors believe that sufficient design information is provided to perform the evaluation activities for the components with unsatisifed dependencies. 158 Several dependencies on ADV_FSP.2 have not been satisfied (ATE_COV.2, ATE_IND.2, AVA_VAN.2). This protection profile only includes ADV_FSP.1. However, the intention is that all TSFI provided by the developer are described to the extent that they can be used to develop test cases, correctly identify the expected test result and to perform the vulnerability analysis. Therefore, the authors believe that sufficient information on the TSFI is provided to allow for the evaluation activities for the components with unsatisfied dependencies to be performed. 159 The dependency of ALC_CMC.3 to ALC_DVS.1 is not satisfied. However, it is expected that the evaluator will examine that the CM processes described by the developer for ALC_CMC.3 are established as described. This can be achieved for example by verifying that the described process steps are being applied during an evaluators on-site visit (e.g., to perform independent testing). Therefore, the authors believe that the evaluator will gain sufficient confidence in the existence and proper application of the CM processes described in ALC_CMC.3. Page 82 of 237 CC version

83 OSPP Framework A OSPP Framework (normative) 160 The OSPP allows the definition of functional extensions that can be optionally claimed by an ST in addition to the OSPP base. As such, the OSPP defines the following components: The OSPP base specifies the conformance claim, security problem, objectives, security functional requirements, and security assurance requirements that are to be satisfied by every general-purpose operating system claiming conformance to the OSPP base. The OSPP base is mandatory and defines the common denominator for all operating systems claiming conformance with the OSPP. An OSPP extended package specifies the security problem definition, objectives, and security functional requirements for mechanisms that may be implemented in addition to the OSPP base. Usually, an OSPP extended package defines an extension that is either desired or implemented by several general-purpose operating systems. However, the functionality specified in an OSPP extended package is not commonly found among general-purpose operating systems. OSPP extended packages can optionally be added to the OSPP base functionality when writing an ST. The ST author may choose from the set of OSPP extended packages when deriving an ST. To avoid fragmentation of security functionality into OSPP extended packages that are too small to be practical, an OSPP extended package shall define a set of functional requirements that address one or more general security problems. OSPP extended packages need to be approved by the OSPP Technical Community or at least by the scheme where the extended package is used. 161 The OSPP is defined as an extensible framework. The current set of OSPP extended packages can be enhanced with newly-developed or updated OSPP extended packages. Those will then be part of a re-evaluation and recertification of the OSPP base. Therefore, this framework invites anybody interested in specifying an aspect of general-purpose operating systems to author an OSPP extended package and commit it to the OSPP forum, where the OSPP is managed. Using this approach, there will always be a valid set of OSPP base and extended packages, which are compliant to each other. Dependencies on other OSPP extended packages can be specified. A.1 Mandatory information given by the ST 162 The following information must be given as part of the ST derived from the OSPP CC version 3.1 Page 83 of 237

84 OSPP Framework A.1.1 Conformance claim 163 When specifying conformance to the OSPP, the ST must specify any OSPP extended packages with which the ST shall conform to. 164 In addition, the ST must claim conformance to any OSPP extended packages that are dependencies of the OSPP extended packages claimed by the ST. A.1.2 SFR reference with OSPP extended package reference 165 When specifying the SFRs as part of the ST, a reference to the OSPP base or OSPP extended package abbreviation must be given in order to facilitate a direct mapping of the SFR, specifically considering iterations. 166 This requirement shall support ST authors and evaluators to ensure that no SFR from the OSPP base or an OSPP extended package the ST claims conformance to is left uncovered. A.2 Mandatory information given by OSPP extended packages 167 The following information must be given for each OSPP extended package to allow the extended package to be embedded into the framework of the OSPP. A.2.1 Extended package identification 168 The following information must be given to identify an OSPP extended package: Extended package name in narrative English Abbreviation of the extended package name to allow easy and unambiguous reference to the extended package Version of the extended package Owner of the extended package; that is, who is in charge of performing authoritative changes A.2.2 Extended package composition rules 169 To specify how the OSPP extended package can be used together with other OSPP extended packages, the following information must be provided: A list of dependent OSPP extended packages with their respective minimum versions. A list of disallowed OSPP extended packages with their respective minimum versions. Page 84 of 237 CC version

85 OSPP Framework 170 Note that the extended package must not exclude the OSPP base or any portion of it; however, the extended package may specify a minimum version of the OSPP base that is required for the respective extended package. 171 If an existing extended package must be changed to accommodate another extended package (the current extended package), the author of the current extended package is requested to approach the owner of the existing extended package to agree on the required modifications. A.2.3 Specification of OSPP extended packages 172 The OSPP extended packages may define many aspects as an addition to the OSPP base. Specification includes the following information: Package introduction Dependencies on other OSPP extended packages Security Problem Definition Objectives Security Functional Requirements Refinements to Security Assurance Requirements. Note that specification of higher or extended Security Assurance Requirements is not allowed; the entire OSPP in intended to be covered by the mutual recognition agreement, and the OSPP base shall ensure this. A.3 Specification restricted to the OSPP base 173 The OSPP base exclusively defines the following properties: Conformance claims to other Protection Profiles Conformance type (strict) Conformance claim to the security assurance requirements including any augmentation 174 An OSPP extended package may define refinements to assurance components. Refinements may provide guidance on how to satisfy the assurance requirements specifically for the SFRs in the extended package. However, one of the core requirements for OSPP is to keep the Protection Profile and all its modules covered under the mutual recognition agreement. Therefore, no OSPP extended package shall add an SAR or modify the level of an SAR that would exceed the boundary set by the mutual recognition agreement. Note that refinements are allowed operations for SFRs and SARs, and such refinements can well be used to guide the evaluator on how to evaluate aspects specific for the functionality defined in a package CC version 3.1 Page 85 of 237

86 OSPP Framework Especially for SARs, refinements should be used; extended assurance components should be avoided when possible. Page 86 of 237 CC version

87 OSPP Base Introduction B OSPP Base Introduction (normative) 175 The OSPP base defines the basic functionality found in today's generalpurpose operating systems. It specifies functions and mechanisms that must be provided and that are already implemented in every general-purpose operating system. 176 The general audit requirement is added to the OSPP base, as this functionality is mandated by government users and required to fulfill basic accountability requirements mandated by many IT security standards. 177 The TOE may provide the security functionality in cooperation with other trusted IT entities. The security problem definition considers such scenarios as a possible way to utilize the TOE. B.1 TOE overview 178 This section outlines the security functionality provided by a TOE claiming conformance with the OSPP base. 179 A general-purpose operating system as seen in this document has the following capabilities: Provides services to different users, which may be human users, as well as other IT systems (called remote IT entity in this Protection Profile). Simultaneously supports multiple subjects (usually processes or address spaces), potentially operating on behalf of different users; and separates subjects operating for different users from each other. Mediates and enforces access to operating system-defined named objects and allows or disallows such access based on well-defined rules. Verifies the identity of external users, which allows the access control policy rules to be based on security attributes the operating system associates with such users. Records defined events with sufficient data that allows a reviewer to identify the type of event, the time the event happened, and when possible, the identity of the user that caused the event. Defines aspects of the security policy that can be managed, together with rules to restrict the users that can perform management activities CC version 3.1 Page 87 of 237

88 OSPP Base Introduction Protects itself and the data/objects it relies on from tampering and from bypass of the security policy. B.1.1 Auditing 180 All operating systems conformant with this Protection Profile must implement audit functionality that allows the operating system to record events viewed as security-relevant. The records created by the operating system for such events must contain at least the type of the event, the time the event occurred, the identity of the user or subject that caused the event (where appropriate), and further event-specific data. If the event is a request to use a function, the record also needs to contain sufficient information about how the function was intended to be used (usually defined by the parameter passed to the function) and the outcome of the function. If the event is related to an operation performed on an object, the identity of the object must be contained in the record. 181 Audit records must be stored in an audit trail in persistent storage. They may alternatively be transmitted to a trusted centralized audit server, but the operating system must support local audit storage in the case the user does not configure a centralized audit storage or such centralized audit storage becomes unavailable. Local storage used for the audit trail must be protected from unauthorized access by users or subjects. A policy must exist that defines: The actual events to be audited (from the overall list of auditable events) Rules that define when a user or subject can define the events to be audited Rules that define when a user or subject can read audit records from the audit trail Rules that define when a user or subject can delete or re-initialize the audit trail 182 The operating system must monitor the amount of space allocated to the local audit trail and take appropriate actions when it detects that it has insufficient space to store further audit records. 183 The audit generation functionality is completely provided locally (by the TSF exclusively). The TOE shall be able to: Gather audit information from security-relevant events Provide functionality to store audit information locally, and potentially provide a remote storage mechanism (analysis of audit data applies to locally-stored audit data only) Provide local analysis of the audit trail if the trail is stored locally Page 88 of 237 CC version

89 OSPP Base Introduction Allow selection of which audit records are to be generated Provide protection of the audit trail when stored locally Provide protection that no audit records are lost 184 Note that remote audit handling is moved to an OSPP extended package. In addition, a TOE can use remote functions to store and/or evaluate audit data and allow appropriately authorized users to define which of the different audit capabilities are used. B.1.2 User data protection 185 The following sections describe user data protection considerations of the General-Purpose Operating System Protection Profile. B.1.3 Discretionary access control 186 Discretionary access control implies that the access control settings on a specific named object can be defined individually for each user/subject object relationship covered by the discretionary access control policy. 187 To support discretionary access control and allow the ruleset to apply to the intended users, the TSF may perform a user-subject binding. During this process, a subject is associated with a specific user and the operating system derives security attributes for the subject from the security attributes of the user it binds the subject to. After such a binding, the subject is a representative of the user. This binding is further detailed and specified in section A single operating system may well implement different discretionary access control policies for different types of subjects or objects and this should not be a problem as long as all of those access control policies satisfy the basic requirement of being able to specify access rights down to the granularity of a single user and as long as the sum of all those access control policies covers all types of subjects and objects. 189 A full specification of a discretionary access control policy needs to include: The type(s) of objects covered by the policy The type(s) of subjects/users covered by the policy The operations covered by the policy The rules that are used to determine if a specific subject/user is allowed to perform an operation covered by the access control policy on a specific object, including the subjects/user security attributes, the object security attributes and any other TSF data used in those rules 190 In addition the following aspects need to be covered: CC version 3.1 Page 89 of 237

90 OSPP Base Introduction The rules that determine if an object can be created The rules that determine the default security attributes of the object used in the discretionary access control policy The rules that determine when user is allowed to add/modify/delete an access right The rules that determine when a user is allowed to modify/add/delete an object security attribute used in the policy The rules that determine when a user is allowed to delete an object 191 Access control policies have to exist for all types of objects that may be used by users to share data. This includes persistent objects (e. g. files) as well as temporary objects (e. g. shared memory). The intention is that an operating system compliant with this Protection Profile allows users to operate in isolation from other regular users (i. e. to not share data with any other nonadministrative user of the operating system) as well as the capability to define sharing down to the granularity of a single user. To achieve this goal, there must be at least one discretionary access control policy for at least one type of persistent objects that allows for the definition of access rights down to the granularity of a single user. Note that not all discretionary access control policies are required to provide this level of granularity. 192 Note that in certain circumstances objects may be contained in other objects (for example, file systems implemented in a single file). In such a case, two different and possibly conflicting access control policies may be applicable to the same portion of persistent storage. If the operating system does not resolve such conflicts automatically, the guidance must explain how to set appropriate access rights such that the two access control policies do not conflict. 193 The OSPP requires the ST author to specify the default access rights for new subjects, as well as new access-controlled objects including - if applicable - the rules defining how those default access rights can be managed. 194 Finally, the OSPP requires the ST author to specify the rules the TOE enforces before allowing a user or subject to manage TSF data used within the access control rules. Usually those rules are based on specific TSF data (like user privileges). If this TSF data can be managed, the management rules that apply also must be specified. It is up to the ST author to describe the conditions that must be satisfied in order to manage TSF data (including the TSF data used in the access control rules). 195 The OSPP allows locally- and remotely-stored TSF data to be used within the access control rules. 196 In addition, the OSPP allows the ST author to specify whether the TOE provides access control decisions for other remote trusted IT products. With this option, the ST author can specify the server side of permission storage. Page 90 of 237 CC version

91 OSPP Base Introduction B.1.4 Network information flow control 197 The TOE shall allow filtering of network data sent by an external entity to the TOE or network data generated by a subject within the TOE to be sent to an external entity using an information flow control policy that defines how network data received are treated by the filter mechanism. The filtering functionality required by the OSPP base is limited to static filter rules for the protocols stated in section For TCP/IP based filtering, the OSPP allows the ST author to define whether stateless and/or stateful packet filtering is supported. Those filtering rules are defined as an information flow policy, since the filter rules specify the conditions that need to be satisfied to allow network data to flow from a network interface to its target consumer in the TOE. 198 The information flow control policy defines the rules to identify the network data and the operation to be performed on the network data. 199 The TOE performs the network information flow control based on initially identifying network data and subsequently performing actions on the network data. The identification of network data can be based upon properties of the network data and additional information maintained by the TOE when mediating the network traffic, for example, the state of TCP connections, time-based rules, or rules based on statistical methods like matching every nth IP packet. Actions imposed on the identified network data can range from discarding the data, modifying the data, sending a notification to the sender, or allowing the network data to pass unaltered. B.1.5 Identification and authentication 200 Identification and authentication is required to allow the TOE to establish the necessary trust in the identity of a user that interacts with the TOE. Identification and authentication of a user is required when the operating system grants a service protected by the security policy based on the identity of a user. The methods used for user identification and authentication may differ for different types of users, and an operating system may also allow different methods for identification and authentication for the same type of users. An operating system compliant with this Protection Profile must support user ID/password for human users, as well as authentication based on cryptographic tokens for remote IT entities that want to establish a trusted channel. The authentication method using cryptographic tokens are defined by the network protocol and a TOE compliant with this Protection Profile must support at least one the protocols SSH, TLS, or IPSec (with certificate based authentication). 201 A TOE compliant with this protection Profile may support additional authentication methods for human and remote IT entities, which then need to be defined in the Security Target together with the management functionality required to manage the authentication method. 202 After successful identification and authentication of a human user, an operating system will perform a user-to-subject binding whenever it starts an CC version 3.1 Page 91 of 237

92 OSPP Base Introduction untrusted subject that shall operate on behalf of the authenticated user. If the operating system allows for other IT systems to have subjects started on their behalf and if the user-subject binding process is different for this case, the Security Target needs to include a second instantiation of the user-subjectbinding security functional requirement specifying the rules how the subject security attributes are derived for such subjects. 203 The OSPP requires that a user or another IT system must be authenticated before utilizing any services of the operating system that are restricted by the security policy to specific users. An OSPP-conformant system may allow unauthenticated users to access objects controlled by the access control policy. The access control policy must be capable to restrict the operations allowed for unauthenticated users to such public to operations that do not modify the object. 204 An operating system may accept users as identified and authenticated when another trusted IT system reports the identity of the user in a way that allows the operating system to verify the integrity and authenticity of the message that containing the information about the remotely authenticated user. This would be a functionality beyond what is specified in this base Protection Profile and would require additional SFRs that define such functionality. 205 An operating system may also authenticate users with the help of another trusted IT system, for example, when it either retrieves information used for the authentication from the other system (for example, the hash value of a password), or redirects information it retrieves from the user to the other system such that the remote trusted IT system can perform the user authentication and report the result back to the TOE. 206 For the OSPP base, the TOE shall provide identification and authentication services by allowing locally- and remotely-performed identification and authentication with the following definitions: Local identification and authentication implies that the TOE performs the operations to establish the identity of the user. This definition allows storing the TSF data holding the user's credentials either on the TOE or on a remote trusted IT system. However, the TOE must be able to completely fetch the TSF data with the credential information and perform the necessary operations and checks that implement the identification and authentication logic locally. Another local identification and authentication is performed when a user provides a token (a certificate, Kerberos token, etc.) which defines the user's identity; the TOE must verify that token. Remote identification and authentication implies that the TOE is a client to an authentication server. The TOE sends the user-supplied identification and authentication data to the server and queries the server as to whether the transmitted credentials are positively or negatively verified. The TOE then enforces the decision made by the authentication server. Page 92 of 237 CC version

93 OSPP Base Introduction For accessing public objects, the TOE shall allow operations by unauthenticated users (which shall be exempt from identification and authentication). The allowed operations and public objects must be defined by the ST author. 207 For example, a Directory Server may store the user credentials or the internal representations of the user credentials. When the TOE is able to obtain all credentials, including the user password, and performs the operations to validate the user-given credentials with the stored ones, then a local identification and authentication is performed. However, if the TOE only performs, for example, an LDAP-bind operation with the user-supplied credentials and observes whether the LDAP server rejects the operation, then remote identification and authentication is performed. 208 The OSPP allows for local, remote and combined local and remote identification and authentication, which can usually be found in large installations. For example, a local user database is defined with administrative user IDs that are only usable when the connection to the authentication server is severed. Another example would be that the TOE caches the user database of the authentication server and applies this database in case the link to the authentication server is severed. Note that if the TOE allows multiple authentication methods concurrently (such as local and remote authentication), the ST author shall specify the order in which the authentication methods are applied. 209 In addition, the OSPP shall allow the ST author to specify whether the TOE provides identification and authentication for other remote trusted IT products. With this option, the ST author can specify the server side of the credential storage. 210 When credentials or the internal representations of the user credentials are stored within the TOE, the TOE shall ensure the quality of the credentials when they are being changed by administrative users or authorized users. 211 At a minimum, the identification and authentication functionality shall provide all of the following mechanisms: User ID / password (for human users) Software token-based authentication (for remote IT entities that want to set up a trusted channel) 212 After successful identification and authentication, the TSF may perform a user-subject binding. Such a binding is required when the operating system creates and starts a subject to operate on behalf of the user. This process ensures that the external entity (or user) binds to the subject. The ST author must define the rules applicable to the user-subject binding process. Those rules define how the security attributes of the subject are initialized, usually derived from security attributes of the user. See section for more details. During the user-subject binding, all security attributes of a subject used by the rules of the security policy must be established CC version 3.1 Page 93 of 237

94 OSPP Base Introduction B.1.6 Management of security mechanisms 213 The TOE must provide management mechanisms for all security functions that are provided by the TOE. 214 If in addition the TOE is supported by remote trusted IT systems, the management requirement only covers the functional aspects provided by the TOE. 215 The authority to perform management of aspects of security functions is based on dedicated management rules, which are often based on privileges. These privileges can be explicitly implemented by the TOE by requiring a specific privilege to use an administrative interface or to access resources that govern the behavior of the TSF. Privileges may also be given implicitly by granting write access to TSF data, such as configuration files or configuration databases holding the configuration of all or parts of the TSF. On the other hand, the rules that regulate how management operations can be performed can also be based on other aspects, like access to storage objects that contain TSF data, access to specific interfaces or devices, the state of the system, or any combination of these aspects. 216 In the OSPP base, the ST author must define the TSF data that can be managed, as well as the rules that determine if a management operation is allowed. At a minimum, TSF data that can be managed must include: Management of users and their manageable security attributes. Management of security attributes that are used for the discretionary access control policies. The manageable security attributes must be able to define access down to the granularity of a single user (for the type of users that are allowed to access the objects controlled by the access control policy). Management of security attributes that are used for the information flow control policy. Management of the audit policy, which includes at least the selection of the events to be audited and the management of the storage objects that contain the audit trail. 217 The OSPP does not mandate any specific implementation. However, the TOE must: Allow administrative functions to be assigned to zero, one, or more users. 218 The ST author shall specify the rules used to determine if a management activity is allowed and the TSF data used in those rules. The OSPP does not specify any policy or any specific set of rules. As such, the ST author has the ability to specify one user that is granted all privileges (like the UNIX root user). In addition, the ST author can also specify a sophisticated Page 94 of 237 CC version

95 OSPP Base Introduction administration policy including hierarchical privileges or role-based management. 219 The TOE shall allow localized and/or centralized management of these security functions: Localized management implies that tools are provided with the TOE to configure aspects of security functions. The SFRs will not make any statement about whether the TOE data is stored remotely (see discussion about local identification and authentication above). Remote management implies that the management of the security functionality is not provided by the TOE, but the TOE enforces the management actions. Note that this would be an optional functionality that needs to be defined using additional SFRs not in included in this base Protection Profile. 220 Irrespective of the management type (localized or remote), the configuration data can be stored locally or remotely. If stored remotely, there is no restriction about whether the configuration data is stored with the remote management system or on another system. 221 The OSPP allows locally- and remotely-stored TSF data used within the management rules. 222 In addition, the OSPP allows the ST author to specify whether the TOE provides management decisions for other remote trusted IT products. With this option, the ST author can specify the server side of the management operations. B.1.7 Trusted channel 223 In order to support remote management, the OSPP requires that an operating system has the capability to establish a trusted channel to a trusted remote entity. Remote management activities shall require such a trusted channel, which also needs to use public key based authentication of the remote entity. 224 In addition, if the TOE relies on input from remote trusted IT systems to support security policy enforcement, the TOE shall establish a trusted channel to this remote trusted IT system. Involvement of the remote trusted IT system can mean active support by providing functions like user authentication, or simple remote storage and management of TSF data imported by the TOE from the remote trusted IT system (for example, user security attributes stored in a directory). The TOE can also use remote trusted IT systems to store user and TSF data such that the data can be used by the TOE, by the remote trusted IT system, or by other trusted IT systems. In addition, the TOE may provide security-related services to a remote trusted IT system. In all those cases, the communication between the TOE and the remote trusted IT system must ensure that the data exchanged between the TOE and the remote trusted IT system is sufficiently protected, CC version 3.1 Page 95 of 237

96 OSPP Base Introduction ensuring authenticity, integrity and confidentiality of the exchanged TSF data. 225 In many cases, an operating system will therefore use a trusted channel, which provides confidentiality and integrity protection as well as the mutual authentication of the end points of the channel. The capability to establish and maintain a trusted channel to remote IT systems is also a service an operating system can offer to subjects and users. An operating system conformant to this Protection Profile must provide such a capability to subjects. B Cryptographically-protected network protocols 226 The TOE shall provide applied cryptographic services in the form of network protocols to allow the integrity, confidentiality, and authenticity-protected transmission of user and TSF data. 227 At a minimum, the TOE must implement one of the following protocols: SSH (version 1 of this protocol is not allowed) TLS IPSEC the OSPP mandates that the implementation must provide IKE and ESP; AH is not required by the OSPP when specifying IPSEC, but may be added by the ST author. 228 For more details see the section on trusted channels above. 229 In addition a TOE may implement generic cryptographic services it may make directly available to users or subjects. Those services are not addressed by this base Protection Profile, but may be specified as additional SFRs in a Security Target. It is also intended to specify basic requirements for a cryptographic service provider in an extended package. 230 The OSPP neither mandates nor prohibits use of the cryptographic mechanisms underlying the above-mentioned protocols by other components or security functions outlined in different OSPP extended packages. However, if other network mechanisms implement their own instances of cryptographic mechanisms apart from other security functions, the evaluator must also assess these instances. B.2 Co-operating trusted systems 231 It is common in current IT architectures that IT applications, as well as operating systems use services offered by centralized servers for use within a whole IT environment. This applies also for operating system functionality implementing security functions as defined in this Protection Profile. Examples are the use of Directory Servers used for the centralized management of user security attributes, centralized authentication servers, centralized access managers, centralized audit collection and evaluation, as Page 96 of 237 CC version

97 OSPP Base Introduction well as centralized functions for security management. While the OSPP base does not mandate that such centralized services are used, it also does not prohibit an operating system conformant to the OSPP base to implement security functionality using remote trusted IT systems that provide part of the security functionality. Still, as mentioned above, an Operating System conformant to the OSPP base must implement functionality that satisfies the SFRs listed in the OSPP base locally, i. e. without support by the IT environment. As an example, an operating system that wants to claim compliance to the OSPP base may of course offer identification and authentication services or user management that rely on an external directory server as an option, but it must also support local user authentication and user management. 232 In cases where the operating system provides functionality that uses support from the IT environment, it is still required that the operating system must provide the interfaces for the security functionality claimed to users and subjects, and ensure that any service provided by a remote trusted system is invoked correctly, with the results of such a service being used appropriately in accordance with the security policy of the TOE. For example, if an operating system allows the optional use of a centralized access manager to support access control decisions, its TSF must ensure that the services of the remote access manager are invoked when required and are correctly invoked with respect to the access decision to be made, and that the TSF correctly uses the results passed back to it by the invocation of the remote access manager. 233 A TOE that uses such remote trusted systems for the support of its security policy must define in its Security Target which parts of the security policy are enforced with the support of a remote trusted IT product and any assumptions on the functionality of such remote trusted IT systems. Although not required, it may be helpful to specify those assumptions using the notion of security functional requirements. This allows for easier mapping of those assumptions to the security functional requirements defined in the Security Target of such a remote trusted IT system (provided this system is also implemented using an evaluated product). 234 Many operating systems that use remote trusted IT systems to support security services also offer the possibility to configure the operating system such that it also is capable of providing such services. This allows system integrators to set up an IT environment with multiple systems all based on the same operating system product, where one of those systems is configured to act as the server for a centralized service and all other are configured to act as clients for this service, and use the centralized service in the enforcement of their security policy. A typical example is a Directory Server as a central service to store and manage user security attributes that are used by all systems within a specific IT environment to support user authentication and supply the user security attributes required for user-subject binding. 235 Such co-operation between trusted IT systems is not necessarily restricted to a client-server type of relationship. It may also be a peer-to-peer relationship, for example, where a smartcard is used as part of the user authentication CC version 3.1 Page 97 of 237

98 OSPP Base Introduction process. In addition, an operating system may make use of multiple remote trusted IT systems to provide a single security functionality: to authenticate a user, the TOE may require the user to present a smartcard. The smart card (as the representative of the user) may present a digital certificate, in response to which the TOE may use a challenge-response protocol to verify that the smart card actually contains the private key associated with the digital certificate it presents. Furthermore, the TOE may use the services of a Directory Server to validate that the certificate has not been revoked. In addition, the TOE may also use its peer-to-peer connection to a cryptographic module outside of the TOE boundary in order to perform the cryptographic operations required for the smart card authentication process (including the validation of the digital signature of the CA that issued the certificate presented by the smart card) and the process to validate the digital signature of the certificate revocation list provided by the Directory Server. B.3 TOE boundary 236 This Protection Profile considers the TOE boundary as follows: the TOE is a system that acts as a single unit to all external entities. By this definition, the following examples illustrate a single TOE instance and its boundary: A single machine hosting one operating system instance, such as one physical machine or a virtual machine. Multiple hardware components that all execute one single system image; that is, one software instance controlling all hardware components, such as a NUMA system with several hardware machines interconnected executing one operating system kernel. Multiple hardware components, each executing its own instance of the TOE operating system or operating system kernel, but any external entity has only one defined path to access this system and sees these multiple system acting as one, such as a highperformance computing cluster where different nodes have different tasks (such as one node performing the calculation work, one node hosting the disk space, one node establishing the network connectivity for the cluster, one node providing the interface to other entities), but which must work together to provide the entire cluster functionality. 237 Multiple operating system instances where external entities see these instances are considered to form multiple TOE instances. This especially applies to client-server or peer-to-peer setups where each operating system instance forms one TOE instance. For example, a central LDAP server provides the central identification and authentication instance to other operating system instances, where the operating system with the LDAP server and the other operating system instances form individual TOE instances. Similarly, instances of operating systems which share one or more resources like Storage Area Networks (SAN) or distributed file systems constitute independent TOE instances. The decision whether the shared Page 98 of 237 CC version

99 OSPP Base Introduction resource belongs to one TOE or is considered to form a resource independent of any TOE is left to the ST author. 238 The following illustration depicts different forms of TOE instances. Every box shaded in blue is one example of a TOE instance. The lines connecting the boxes illustrate a possible interaction. Figure 1 - Types of TOE instances and their boundaries CC version 3.1 Page 99 of 237

100 C Assurance requirements and evaluation activities (normative) C.1 Assurance package for the PP 239 This protection profiles claims compliance with the following assurance components and associated evaluation methodology, complemented with specific methodology adapted to the already indicated functional requirements. 240 The functional requirements specific assurance requirements are marked in red colour in this annex. ADV_ARC.1 Security architecture description Dependencies satisfied by: ADV_FSP.1 Basic functional specification Error! Reference source not found. Objectives 241 The objective of this sub-activity is to determine whether the TSF is structured such that it cannot be tampered with or bypassed, and whether TSFs that provide security domains isolate those domains from each other. Objectives 242 The TOE design needs to provide an overview on the audit record generation functionality, accompanied by assurance cases addressing the potential problems of bypassing or otherwise disturbing audit functionality such that audit records are not generated when they should be, manipulating information to be included in audit records before and when it is collected by the audit record generation functionality, and the protection of the audit record generation functionality from being misused to generate audit records for events that did not happen. In addition the TOE design information needs to describe the format and content of the audit records required by FAU_GEN.1, mapping the details required by FAU_GEN.1 to the content of the records. The information may (and should) be presented by references to existing developer documentation. Application notes 243 The notions of self-protection, domain separation, and non-bypassability are distinct from security functionality expressed in Part 2 SFRs because selfprotection and non-bypassability largely have no directly observable interface at the TSF. Rather, they are properties of the TSF that are achieved through the design of the TOE, and enforced by the correct implementation of that design. Also, the evaluation of these properties is less straight-forward Page 100 of 237 CC version

101 than the evaluation of mechanisms; it is more difficult to check for the absence of functionality than for its presence. However, the determination that these properties are being satisfied is just as critical as the determination that the mechanisms are properly implemented. 244 The overall approach used is that the developer provides a TSF that meets the above-mentioned properties, and provides evidence (in the form of documentation) that can be analysed to show that the properties are indeed met. The evaluator has the responsibility for looking at the evidence and, coupled with other evidence delivered for the TOE, determining that the properties are achieved. The work units can be characterised as those detailing with what information has to be provided, and those dealing with the actual analysis the evaluator performs. 245 The security architecture description describes how domains are defined and how the TSF keeps them separate. It describes what prevents untrusted processes from getting to the TSF and modifying it. It describes what ensures that all resources under the TSF's control are adequately protected and that all actions related to the SFRs are mediated by the TSF. It explains any role the environment plays in any of these (e.g. presuming it gets correctly invoked by its underlying environment, how is its security functionality invoked?). In short, it explains how the TOE is considered to be providing any kind of security service. 246 The analyses the evaluator performs must be done in the context of all of the development evidence provided for the TOE, at the level of detail the evidence is provided. At lower assurance levels there should not be the expectation that, for example, TSF self-protection is completely analysed, because only high-level design representations will be available. The evaluator also needs to be sure to use information gleaned from other portions of their analysis (e.g., analysis of the TOE design) in making their assessments for the properties being examined in the following work units. Input 247 The evaluation evidence for this sub-activity is: the ST; the functional specification; the TOE design; the security architecture description; the implementation representation (if available); the operational user guidance; CC version 3.1 Page 101 of 237

102 Developer action elements: C ADV_ARC.1.1D 248 The developer shall design and implement the TOE so that the security features of the TSF cannot be bypassed. C ADV_ARC.1.2D 249 The developer shall design and implement the TSF so that it is able to protect itself from tampering by untrusted active entities. C ADV_ARC.1.3D 250 The developer shall provide a security architecture description of the TSF. Content and presentation of evidence elements: C ADV_ARC.1.1C 251 The security architecture description shall be at a level of detail commensurate with the description of the SFR-enforcing abstractions described in the TOE design document. C ADV_ARC.1.2C 252 The security architecture description shall describe the security domains maintained by the TSF consistently with the SFRs. C ADV_ARC.1.3C 253 The security architecture description shall describe how the TSF initialisation process is secure. C ADV_ARC.1.4C 254 The security architecture description shall demonstrate that the TSF protects itself from tampering. C ADV_ARC.1.5C 255 The security architecture description shall demonstrate that the TSF prevents bypass of the SFR-enforcing functionality. C FAU_GEN_2_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. Page 102 of 237 CC version

103 C FAU_SAR_1_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU_SEL_1_ADV_ARC There are no further expectations on the architectural design for those SFRs than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU_STG_1_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU_STG_3_ADV_ARC The architectural design needs to explain how the TSF detects that the audit storage exceeds the pre-defined limit or any other of the conditions specified in FAU_STG.3 and how the actions taken in this case are initiated by the TSF. The architectural design needs to explain how the TSF detects an audit storage failure and how it reacts to such a failure. C FAU_FDP_1_ADV_ARC The TOE design documentation (which consists of the TSS in the Security Target, the functional specification and any additional design related documentation provided for the evaluation) needs to explain the principles of the implementation of the access control policy (or policies), especially how and where the security attributes are stored and maintained by the TSF. In the cases where the internal representation of those security attributes is visible at external interfaces, also the internal representation of the security attributes needs to be described in the public documentation. The TOE design needs to describe how the security attributes are protected by the mechanisms of the TOE architecture. The TOE design documentation needs to include a justification why the access control mechanisms can not be bypassed. Most operating systems for access to persistent storage objects perform access control when the object is opened and not for each access operation to the object. As long as the user/subject is able to maintain the open status for the object, the access operation may be performed for the access operation checked for during open even if the access has been revoked afterwards. This is acceptable as long as it is described in the TOE design, functional specification, or guidance. Sometimes a single object can be accessed using different names or links to the object. The design needs to CC version 3.1 Page 103 of 237

104 explain that the access control rules apply regardless how the object is addressed. C FAU_IFF_1_ADV_ARC In the case not all effects of the filtering rules can not be tested directly at the TSFI, the architectural design needs to explain which TSF internal interfaces can be used for testing the effect of the filtering rules and how those interfaces can be used for testing. C FAU_RIP_2_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU MSA_1_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU_MSA_3_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU_MSA_3_NI_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU_MSA_4_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU_MTD_1_AS_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. Page 104 of 237 CC version

105 C FAU_MTD_1_AT_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU_MTD_1_NI_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU_REV_1_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. C FAU_ITC_1_ADV_ARC There are no further expectations on the architectural design for this SFR than the ones defined for the TSS. The developer may well point in the TSS to existing public design documentation for further detail of this functionality. Evaluator action elements: C ADV_ARC.1.1E 273 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ADV_ARC.1-1 ADV_ARC.1.1C The evaluator shall examine the security architecture description to determine that the information provided in the evidence is presented at a level of detail commensurate with the descriptions of the SFR-enforcing abstractions contained in the functional specification and TOE design document. 274 With respect to the functional specification, the evaluator should ensure that the self-protection functionality described cover those effects that are evident at the TSFI. Such a description might include protection placed upon the executable images of the TSF, and protection placed on objects (e.g., files used by the TSF). The evaluator ensures that the functionality that might be invoked through the TSFI is described. 275 If Error! Reference source not found.or Error! Reference source not found.is included, the evaluator ensures the security architecture description contains information on how any subsystems that contribute to TSF domain separation work CC version 3.1 Page 105 of 237

106 276 If Error! Reference source not found.or higher is available, the evaluator ensures that the security architecture description also contains implementation-dependent information. For example, such a description might contain information pertaining to coding conventions for parameter checking that would prevent TSF compromises (e.g. buffer overflows), and information on stack management for call and return operations. The evaluator checks the descriptions of the mechanisms to ensure that the level of detail is such that there is little ambiguity between the description in the security architecture description and the implementation representation. 277 The evaluator action related to this work unit is assigned a fail verdict if the security architecture description mentions any module, subsystem, or interface that is not described in the functional specification or TOE design document. :ADV_ARC.1-2 ADV_ARC.1.2C The evaluator shall examine the security architecture description to determine that it describes the security domains maintained by the TSF. 278 Security domains refer to environments supplied by the TSF for use by potentially-harmful entities; for example, a typical secure operating system supplies a set of resources (address space, per-process environment variables) for use by processes with limited access rights and security properties. The evaluator determines that the developer's description of the security domains takes into account all of the SFRs claimed by the TOE. 279 For some TOEs such domains do not exist because all of the interactions available to users are severely constrained by the TSF. A packet-filter firewall is an example of such a TOE. Users on the LAN or WAN do not interact with the TOE, so there need be no security domains; there are only data structures maintained by the TSF to keep the users' packets separated. The evaluator ensures that any claim that there are no domains is supported by the evidence and that no such domains are, in fact, available. :ADV_ARC.1-3 ADV_ARC.1.3C The evaluator shall examine the security architecture description to determine that the initialisation process preserves security. 280 The information provided in the security architecture description relating to TSF initialisation is directed at the TOE components that are involved in bringing the TSF into an initial secure state (i.e. when all parts of the TSF are operational) when power-on or a reset is applied. This discussion in the security architecture description should list the system initialisation components and the processing that occurs in transitioning from the down state to the initial secure state. 281 It is often the case that the components that perform this initialisation function are not accessible after the secure state is achieved; if this is the case then the security architecture description identifies the components and explains how they are not reachable by untrusted entities after the TSF has been established. In this respect, the property that needs to be preserved is that these components either 1) cannot be accessed by untrusted entities after Page 106 of 237 CC version

107 the secure state is achieved, or 2) if they provide interfaces to untrusted entities, these TSFI cannot be used to tamper with the TSF. 282 The TOE components related to TSF initialisation, then, are treated themselves as part of the TSF, and analysed from that perspective. It should be noted that even though these are treated as part of the TSF, it is likely that a justification (as allowed by Error! Reference source not found.) can be made that they do not have to meet the internal structuring requirements of ADV_INT. :ADV_ARC.1-4 ADV_ARC.1.4C The evaluator shall examine the security architecture description to determine that it contains information sufficient to support a determination that the TSF is able to protect itself from tampering by untrusted active entities. 283 Self-protection refers to the ability of the TSF to protect itself from manipulation from external entities that may result in changes to the TSF. For TOEs that have dependencies on other IT entities, it is often the case that the TOE uses services supplied by the other IT entities in order to perform its functions. In such cases, the TSF alone does not protect itself because it depends on the other IT entities to provide some of the protection. For the purposes of the security architecture description, the notion ofselfprotectionapplies only to the services provided by the TSF through its TSFI, and not to services provided by underlying IT entities that it uses. 284 Self-protection is typically achieved by a variety of means, ranging from physical and logical restrictions on access to the TOE; to hardware-based means (e.g. execution rings and memory management functionality); to software-based means (e.g. boundary checking of inputs on a trusted server). The evaluator determines that all such mechanisms are described. 285 The evaluator determines that the design description covers how user input is handled by the TSF in such a way that the TSF does not subject itself to being corrupted by that user input. For example, the TSF might implement the notion of privilege and protect itself by using privileged-mode routines to handle user input. The TSF might make use of processor-based separation mechanisms such as privilege levels or rings. The TSF might implement software protection constructs or coding conventions that contribute to implementing separation of software domains, perhaps by delineating user address space from system address space. And the TSF might have reliance its environment to provide some support to the protection of the TSF. 286 All of the mechanisms contributing to the domain separation functions are described. The evaluator should use knowledge gained from other evidence (functional specification, TOE design, TSF internals description, other parts of the security architecture description, or implementation representation, as included in the assurance package for the TOE) in determining if any functionality contributing to self-protection was described that is not present in the security architecture description CC version 3.1 Page 107 of 237

108 287 Accuracy of the description of the self-protection mechanisms is the property that the description faithfully describes what is implemented. The evaluator should use other evidence (functional specification, TOE design, TSF Internals documentation, other parts of the security architecture description, implementation representation, as included in the ST for the TOE) in determining whether there are discrepancies in any descriptions of the selfprotection mechanisms. If Error! Reference source not found.is included in the assurance package for the TOE, the evaluator will choose a sample of the implementation representation; the evaluator should also ensure that the descriptions are accurate for the sample chosen. If an evaluator cannot understand how a certain self-protection mechanism works or could work in the system architecture, it may be the case that the description is not accurate. :ADV_ARC.1-5 ADV_ARC.1.5C The evaluator shall examine the security architecture description to determine that it presents an analysis that adequately describes how the SFR-enforcing mechanisms cannot be bypassed. 288 Non-bypassability is a property that the security functionality of the TSF (as specified by the SFRs) is always invoked. For example, if access control to files is specified as a capability of the TSF via an SFR, there must be no interfaces through which files can be accessed without invoking the TSF's access control mechanism (such as an interface through which a raw disk access takes place). 289 Describing how the TSF mechanisms cannot be bypassed generally requires a systematic argument based on the TSF and the TSFIs. The description of how the TSF works (contained in the design decomposition evidence, such as the functional specification, TOE design documentation) - along with the information in the TSS - provides the background necessary for the evaluator to understand what resources are being protected and what security functions are being provided. The functional specification provides descriptions of the TSFIs through which the resources/functions are accessed. 290 The evaluator assesses the description provided (and other information provided by the developer, such as the functional specification) to ensure that no available interface can be used to bypass the TSF. This means that every available interface must be either unrelated to the SFRs that are claimed in the ST (and does not interact with anything that is used to satisfy SFRs) or else uses the security functionality that is described in other development evidence in the manner described. For example, a game would likely be unrelated to the SFRs, so there must be an explanation of how it cannot affect security. Access to user data, however, is likely to be related to access control SFRs, so the explanation would describe how the security functionality works when invoked through the data-access interfaces. Such a description is needed for every available interface. 291 An example of a description follows. Suppose the TSF provides file protection. Further suppose that although the traditional system call TSFIs for open, read, and write invoke the file protection mechanism described in the TOE design, there exists a TSFI that allows access to a batch job facility Page 108 of 237 CC version

109 (creating batch jobs, deleting jobs, modifying unprocessed jobs). The evaluator should be able to determine from the vendor-provided description that this TSFI invokes the same protection mechanisms as do the traditional interfaces. This could be done, for example, by referencing the appropriate subclauses of the TOE design that discusshowthe batch job facility TSFI achieves its security objectives. 292 Using this same example, suppose there is a TSFI whose sole purpose is to display the time of day. The evaluator should determine that the description adequately argues that this TSFI is not capable of manipulating any protected resources and should not invoke any security functionality. 293 Another example of bypass is when the TSF is supposed to maintain confidentiality of a cryptographic key (one is allowed to use it for cryptographic operations, but is not allowed to read/write it). If an attacker has direct physical access to the device, he might be able to examine sidechannels such as the power usage of the device, the exact timing of the device, or even any electromagnetic emanations of the device and, from this, infer the key. 294 If such side-channels may be present, the demonstration should address the mechanisms that prevent these side-channels from occurring, such as random internal clocks, dual-line technology etc. Verification of these mechanisms would be verified by a combination of purely design-based arguments and testing. 295 For a final example using security functionality rather than a protected resource, consider an ST that contains Error! Reference source not found., which requires that the TSF provides evidence of origination for information types specified in the ST. Suppose that the information types included all information that is sent by the TOE via . In this case the evaluator should examine the description to ensure that all TSFI that can be invoked to send perform the evidence of origination generation function are detailed. The description might point to user guidance to show all places where can originate (e.g., program, notification from scripts/batch jobs) and then how each of these places invokes the evidence generation function. 296 The evaluator should also ensure that the description is comprehensive, in that each interface is analysed with respect to the entire set of claimed SFRs. This may require the evaluator to examine supporting information (functional specification, TOE design, other parts of the security architecture description, operational user guidance, and perhaps even the implementation representation, as provided for the TOE) to determine that the description has correctly capture all aspects of an interface. The evaluator should consider what SFRs each TSFI might affect (from the description of the TSFI and its implementation in the supporting documentation), and then examine the description to determine whether it covers those aspects. :ADV_ARC.1-6 If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and CC version 3.1 Page 109 of 237

110 correctly describes how the association between the user that caused the event and the audit record is established. :ADV_ARC.1-7 :ADV_ARC.1-8 :ADV_ARC.1-9 :ADV_ARC.1-10 :ADV_ARC.1-11 If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the audit data can be read and what the format of the audit data presented is. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the audit events can be managed and what the possibilities for selecting the events to be audited are. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the audit data can be read and what the format of the audit data presented is. The evaluator checks those descriptions for consistency with the specification in the ST. The evaluator verifies that the principles of the implementation of the access control policies are consistent with the description of the policies in the Security Target, the functional specification and the guidance. The evaluator verifies that that the description of the storage and management of the security attributes used in the access control policies is complete (with respect to the ones mentioned in the Security Target) and is consistent with the description in the Security Target and the guidance how they are used and managed. The best way to do this is by creating a table that maps each security attribute to its description in the Security Target, the functional specification, the design and the guidance and validating that those descriptions are consistent. 297 If objects can be addressed in different ways, the evaluator extracts those different ways from the TOE design, functional specification, and user guidance and determines if the TOE design provides sufficient information to ensure that regardless how the object is addressed, access control is enforced. Cases were the evaluator still is not certain may be addressed by additional test cases. :ADV_ARC.1-12 :ADV_ARC.1-13 The evaluator verifies that in the case not all effects of the filtering rules can be tested at the TSFI, the sum of the TSFI described in the functional specification and the TSF internal interfaces are sufficient to test all effects of the filtering rules. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how object re-use is performed. Page 110 of 237 CC version

111 :ADV_ARC.1-14 :ADV_ARC.1-15 :ADV_ARC.1-16 :ADV_ARC.1-17 :ADV_ARC.1-18 :ADV_ARC.1-19 :ADV_ARC.1-20 :ADV_ARC.1-21 :ADV_ARC.1-22 If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the object security attributes can be managed. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the default values of the security attributes used to enforce the discretionary access control policies can be managed. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the default values of the security attributes used to enforce the Network Information Flow Policy can be managed. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the values of object security attributes are inherited. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the audit data storage object can be managed. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the audit data storage object can be managed. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the network data filtering rules can be managed. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the object security attributes can be revoked. If additional design documentation is pointed to in the TSS, the evaluator verifies that this correctly refines the statements made in the TSS and correctly describes how the object security attributes can be revoked. ADV_FSP.1 Basic functional specification Objectives 298 The objective of this sub-activity is to determine whether the developer has provided a high-level description of at least the SFR-enforcing and SFRsupporting TSFIs, in terms of descriptions of their parameters. There is no other required evidence that can be expected to be available to measure the accuracy of these descriptions; the evaluator merely ensures the descriptions seem plausible CC version 3.1 Page 111 of 237

112 Objectives 299 Audit records are usually related to specific events that happen when the operating system is executing. Many of the events defined are directly related to user actions and in those cases the TSFI that are related to the events need to be identified. This is important to allow the evaluator to trigger specific events by using those interfaces and then verifying that the audit record expected to be generated is actually stored in the audit trail. 300 The evaluator therefore needs to ensure that he has obtained sufficient information to trigger the events defined in FAU_GEN.1 using the TSFI. 301 It is worth to note that some of the auditable events defined in FAU_GEN.1 may have several TSFI that will trigger them. In those cases assurance is needed that all of those interfaces actually also generate the related audit record. The evaluator may use design information provided by the developer that allows him to argue why there is no need to test all of the interfaces. If for example the design information clearly shows that different interfaces internally within the TSF use a common execution path and that the generation of the audit record is within this common execution path, the evaluator can justify performing tests only at one of those interfaces. Input 302 The evaluation evidence for this sub-activity is: the ST; the functional specification; the operational user guidance; Dependencies satisfied by: No dependencies. Developer action elements: C ADV_FSP.1.1D 303 The developer shall provide a functional specification. C ADV_FSP.1.2D 304 The developer shall provide a tracing from the functional specification to the SFRs. Content and presentation of evidence elements: C ADV_FSP.1.1C 305 The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI. Page 112 of 237 CC version

113 C ADV_FSP.1.2C 306 The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI. C ADV_FSP.1.3C 307 The functional specification shall provide rationale for the implicit categorisation of interfaces as SFR-non-interfering. C ADV_FSP.1.4C 308 The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. C FAU_GEN_2_ADV_FSP The description of the audit records shall include all the information described as necessary to establish the association between the audit record and the user that caused the event leading to the creation of the audit record. C FAU_SAR_1_ADV_FSP The functional specification shall identify the interface(s) that can be used by appropriately authorized users to read the audit data. The functional specification or the guidance (or both) need to completely and correctly describe the conditions a user needs to meet in order to use those interfaces to read the audit data. The functional specification needs to describe how the audit data is presented in a way that allows extracting the information required by FAU_GEN.2 from the audit records. C FAU_SEL_1_ADV_FSP The functional specification shall identify the interface(s) that can be used by appropriately authorized users to manage the set of events to be audited. The functional specification or the guidance (or both) need to completely and correctly describe the conditions a user needs to meet in order to use those interfaces to manage the event that are audited. C FAU_STG_1_ADV_FSP The functional specification shall identify the audit trail specific interface(s) used for the protection of the audit trail if such interfaces exist e. g. for managing aspects of the protection. The functional specification needs to identify if audit trail specific interfaces for deleting audit records from the audit trail or deleting all record from the audit trail exist. If they do, the functional specification needs to describe how they can be used and how the authorization of the user of those interfaces is validated CC version 3.1 Page 113 of 237

114 C FAU_STG_3_ADV_FSP The functional specification shall identify the interface(s) that can be used by appropriately authorized users to perform potential management activities related to FAU_STG.3. The functional specification shall identify the interfaces that allow the management of the actions to be taken in case of an audit storage failure (which include configuration interfaces that for example allow an automatic switch to another audit storage). C FAU_STG_4_ADV_FSP The functional specification shall identify the interface(s) that can be used by appropriately authorized users to perform potential management activities related to FAU_STG.4. Note that the Protection Profile does not require such management functionality to exist, but leaves the option in FAU_STG.4 to specify a function to overwrite the default values for the action to be taken when the audit trail is full. The functional specification shall identify the interfaces that allow the management of the actions to be taken in case of an audit storage failure (which include configuration interfaces that for example allow an automatic switch to another audit storage). C FAU_FDP_1_ADV_FSP The functional specification (which is publically available) shall identify all the interfaces to the TSF where access control is enforced as well as all the interfaces used to manage the access control policy or the security attributes used in the access control policies. Each interface where access control is enforced needs to describe how the caller is informed in the case access is denied. All the interfaces need to be described such that they can be used in testing the access control policy or the management activity. C FAU_IFF_1_ADV_FSP The interfaces used for testing the effect of FDP_IFC.1 and FDP_IFF.1 are the external network interfaces, the interfaces a subject operating on the operating system can use to send and receive network traffic, and the interfaces an administrator can use to define and manage the filtering rules (which are analyzed and tested in the assurance activities for FMT_MTD.1(NI)). In order to verify the implementation of FDP_IFC.1 and FDP_IFF.1 the network interfaces need to be described with the specification of the network protocols they support (up to layer 3) and the interfaces a subject can use to send and receive network traffic need to be described with their parameter allowing to send and receive network data at a layer where the rules of the network information flow policy can be tested. C FAU_RIP_2_ADV_FSP There is no direct TSF interface for object re-use. Instead the interfaces where the effect of object re-use functionality can be observed need to be identified. Page 114 of 237 CC version

115 C FAU_ATD_1_ADV_FSP The developer is required to have provided a mapping of the interfaces to the I&A functions, including those that map to FIA_ATD.1. C FAU_PKI_1_ADV_FSP The collection of interfaces provided for the TOE will include those that specify how to load and manage keys / certificates. If the TOE has the capability to import certificates from a Certificate Authority (CA) or another trusted entity, the included set of interfaces will describe how the TOE can be configured to import key material / certificates from trusted authorities. This may also include how to set up a trusted channel to communicate with a CA. C FAU MSA_1_ADV_FSP The interfaces used to manage object security attributes need to be identified for all object security attributes listed in the TSS as being manageable. C FAU_MSA_3_ADV_FSP The TSS identifies the interfaces that can be used to manage the default values for security attributes used to enforce the discretionary access control policies and points to the specification of those interfaces. C FAU_MSA_3_NI_ADV_FSP The TSS identifies the interfaces that can be used to manage the default values for security attributes used to enforce the Network Information Flow Policy and points to the specification of those interfaces. C FAU_MSA_4_ADV_FSP There are usually no interfaces related to this SFR except for the case where the inheritance rules can be managed. Inheritance is automatically performed when a new object is created. If the inheritance rules can be managed, the ST needs to define a SFR in the FMT_MTD family that describe the conditions that must be met by a user in order to be allowed to perform this management activity. C FAU_MTD_1_AS_ADV_FSP The functional specification shall identify the interface(s) that can be used by appropriately authorized users to perform management activities related to FMT_MTD.1(AS). C FAU_MTD_1_AT_ADV_FSP The functional specification shall identify the interface(s) that can be used by appropriately authorized users to manage the audit trail threshold use by FAU_STG CC version 3.1 Page 115 of 237

116 C FAU_MTD_1_NI_ADV_FSP The functional specification needs to define the interfaces used for the management of the network data filtering rules, defining the syntax for the management of those rules, the exact semantic of each filtering rule, the functions to define, activate, query, modify, and delete network data filtering rules. Also the conditions a user must meet to perform each of the management actions need to be defined (either in the functional specification or in the guidance documentation). C FAU_MTD_1_IAU_ADV_FSP The relevant interfaces have been identified in the assurance activities for FIA_ATD.1. C FAU_REV_1_ADV_FSP The interfaces used to revoke object security attributes need to be identified for all object security attributes listed in the TSS as being revocable. C FAU_STM_1_ADV_FSP There should be an interface that allows all users/applications to obtain/read the system time. There will also be an interface that is used to set the local system clock. The evaluator ensures the interface specification describes how to use the interfaces to get and set time. The interface description for setting the time should specify what rights or privilege the caller must have in order to set the time. If the TOE supports receiving time from an external entity, the interface specification describes the interface that is used to receive the time; this could be done as a manual activity, or there may be a capability that is configured that will request an update periodically. C FAU_ITC_1_ADV_FSP For FTP_ITC.1 the interfaces are the network interfaces and the interfaces that can be used to set up a trusted channel. The interface specifications are the protocol specifications which are defined by references to the standards with a description of options taken (if the standard allows for different options). For interfaces a user can use to set up a trusted channel, the interface description needs to describe the options the user has for setting up the channel, and how to control the channel. For cases where the TSF (in accordance with the configuration defined by a trusted administrator) automatically and transparent for the user sets up a trusted channel, there may be no explicit user interface for initiating communication via a trusted channel. In this case there must be a management interface (which may be a configuration file) used by the TSF to decide when to initiate communication via a trusted channel and which options to use. Page 116 of 237 CC version

117 Evaluator action elements: C ADV_FSP.1.1E 331 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ADV_FSP.1-1 ADV_FSP.1.1C The evaluator shall examine the functional specification to determine that it states the purpose of each SFR-supporting and SFRenforcing TSFI. 332 The purpose of a TSFI is a general statement summarising the functionality provided by the interface. It is not intended to be a complete statement of the actions and results related to the interface, but rather a statement to help the reader understand in general what the interface is intended to be used for. The evaluator should not only determine that the purpose exists, but also that it accurately reflects the TSFI by taking into account other information about the interface, such as the description of the parameters; this can be done in association with other work units for this component. 333 If an action available through an interface plays a role in enforcing any security policy on the TOE (that is, if one of the actions of the interface can be traced to one of the SFRs levied on the TSF), then that interface issfrenforcing. Such policies are not limited to the access control policies, but also refer to any functionality specified by one of the SFRs contained in the ST. Note that it is possible that an interface may have various actions and results, some of which may be SFR-enforcing and some of which may not. 334 Interfaces to (or actions available through an interface relating to) actions that SFR-enforcing functionality depends on, but need only to function correctly in order for the security policies of the TOE to be preserved, are termedsfr supporting. Interfaces to actions on which SFR-enforcing functionality has no dependence are termedsfr non-interfering. 335 It should be noted that in order for an interface to be SFR supporting or SFR non-interfering it must havenosfr-enforcing actions or results. In contrast, an SFR-enforcing interface may have SFR-supporting actions (for example, the ability to set the system clock may be an SFR-enforcing action of an interface, but if that same interface is used to display the system date that action may only be SFR supporting). An example of a purely SFRsupporting interface is a system call interface that is used both by untrusted users and by a portion of the TSF that is running in user mode. 336 At this level, it is unlikely that a developer will have expended effort to label interfaces as SFR-enforcing and SFR-supporting. In the case that this has been done, the evaluator should verify to the extent that supporting documentation (e.g., operational user guidance) allows that this identification is correct. Note that this identification activity is necessary for several work units for this component CC version 3.1 Page 117 of 237

118 337 In the more likely case that the developer has not labelled the interfaces, the evaluator must perform their own identification of the interfaces first, and then determine whether the required information (for this work unit, the purpose) is present. Again, because of the lack of supporting evidence this identification will be difficult and have low assurance that all appropriate interfaces have been correctly identified, but nonetheless the evaluator examines other evidence available for the TOE to ensure as complete coverage as is possible. :ADV_FSP.1-2 ADV_FSP.1.1C The evaluator shall examine the functional specification to determine that the method of use for each SFR-supporting and SFRenforcing TSFI is given. 338 See work unit 0for a discussion on the identification of SFR-supporting and SFR-enforcing TSFI. 339 The method of use for a TSFI summarises how the interface is manipulated in order to invoke the actions and obtain the results associated with the TSFI. The evaluator should be able to determine, from reading this material in the functional specification, how to use each interface. This does not necessarily mean that there needs to be a separate method of use for each TSFI, as it may be possible to describe in general how kernel calls are invoked, for instance, and then identify each interface using that general style. Different types of interfaces will require different method of use specifications. APIs, network protocol interfaces, system configuration parameters, and hardware bus interfaces all have very different methods of use, and this should be taken into account by the developer when developing the functional specification, as well as by the evaluator evaluating the functional specification. 340 For administrative interfaces whose functionality is documented as being inaccessible to untrusted users, the evaluator ensures that the method of making the functions inaccessible is described in the functional specification. It should be noted that this inaccessibility needs to be tested by the developer in their test suite. :ADV_FSP.1-3 ADV_FSP.1.2C The evaluator shall examine the presentation of the TSFI to determine that it identifies all parameters associated with each SFRenforcing and SFR-supporting TSFI. 341 See work unit 0for a discussion on the identification of SFR-supporting and SFR-enforcing TSFI. 342 The evaluator examines the functional specification to ensure that all of the parameters are described for identified TSFI. Parameters are explicit inputs or outputs to an interface that control the behaviour of that interface. For examples, parameters are the arguments supplied to an API; the various fields in packet for a given network protocol; the individual key values in the Windows Registry; the signals across a set of pins on a chip; etc. 343 While difficult to obtain much assurance that all parameters for the applicable TSFI have been identified, the evaluator should also check other Page 118 of 237 CC version

119 evidence provided for the evaluation (e.g., operational user guidance) to see if behaviour or additional parameters are described there but not in the functional specification. :ADV_FSP.1-4 ADV_FSP.1.3C The evaluator shall examine the rationale provided by the developer for the implicit categorisation of interfaces as SFR-non-interfering to determine that it is accurate. 344 In the case where the developer has provided adequate documentation to perform the analysis called for by the rest of the work units for this component without explicitly identifying SFR-enforcing and SFR-supporting interfaces, this work unit should be considered satisfied. 345 This work unit is intended to apply to cases where the developer has not described a portion of the TSFI, claiming that it is SFR-non-interfering and therefore not subject to other requirements of this component. In such a case, the developer provides a rationale for this characterisation in sufficient detail such that the evaluator understands the rationale, the characteristics of the interfaces affected (e.g., their high-level function with respect to the TOE, such as colour palette manipulation ), and that the claim that these are SFRnon-interfering is supported. Given the level of assurance the evaluator should not expect more detail than is provided for the SFR-enforcing or SFR-supporting interfaces, and in fact the detail should be much less. In most cases, individual interfaces should not need to be addressed in the developer-provided rationale subclause. :ADV_FSP.1-5 ADV_FSP.1.4C The evaluator shall check that the tracing links the SFRs to the corresponding TSFIs. 346 The tracing is provided by the developer to serve as a guide to which SFRs are related to which TSFIs. This tracing can be as simple as a table; it is used as input to the evaluator for use in the following work units, in which the evaluator verifies its completeness and accuracy. :ADV_FSP.1-6 The evaluator needs to ensure that all auditable events that can be directly linked to user actions can be mapped to TSFI where the event can be triggered. The evaluator analyzes those interfaces to the extent that he does not identify obvious problems with respect to the specification of the interface, ensuring that he knows how to use the interface for testing. A more detailed analysis will be performed when the interface is used for testing. 347 As a result of this activity the evaluator shall for every auditable events defined in FAU_GEN.1 have a mapping to the interface(s) that can be used to trigger the event. For events where no such interface exists, the evaluator shall provide his justification why such an interface can not be expected (based on information provided by the developer) and will also indicate his view how those events may be triggered otherwise. This will be the basis for test cases that test the generation of audit records for those events CC version 3.1 Page 119 of 237

120 :ADV_FSP.1-7 The TOE design information provided by the developer needs to be sufficient to address the following issues in the analysis of the functionality for FAU_GEN.1: The evaluator needs to be able to identify a description of the format and structure of all the audit records that map to the auditable events required by FAU_GEN.1. The developer is free to describe the audit records as stored in the TOE internal audit trail or describe the content and format of the audit records extracted from the TOE internal audit trail by a specific tool provided by the developer as part of the TOE. The later case requires the developer to have a description of the use of this tool sufficient to extract and analyze all the audit records required by FAU_GEN.1 The evaluator needs to be able to identify that the audit records are actually generated by the TSF and not by a part of the TOE. The developer needs to provide sufficient arguments that the audit record generation can be influenced or even bypassed by a user. The evaluator needs to be able to identify where the TSF collects the information it stores in the audit record. The developer needs to provide sufficient arguments that this information may not be subject to manipulation. The evaluator needs to be able to identify that the functionality used by the TOE to generate audit records can not be invoked by an untrusted user such that it generates an audit record for an event that never happened by using the audit functionality to produce an audit record indistinguishable from an audit record generated by the TSF for an event defined in FAU_GEN.1 :ADV_FSP.1-8 :ADV_FSP.1-9 The evaluator verifies that the information provided allows for unambiguous association between the user that caused the event recorded in the audit record and the audit record itself. The evaluator verifies that the information provided for accessing the audit data completely describe the conditions that must be met to read the audit data and that this description is consistent with the specification provided in FAU_SAR.1.1 of the Security Target. The evaluator verifies that the description how the data is provided allows him to extract the information required by FAU_GEN Note: this requirement is also satisfied if the required information is provided in the guidance documentation. In this case the evaluator uses the guidance documentation for the activities described below. :ADV_FSP.1-10 The evaluator verifies that the information provided for managing the events to be audited completely describe the conditions that must be met to manage the audited events and that this description is consistent with the specification provided in FAU_SEL.1 and FMT_MTD.1(AE) of the Security Target. Page 120 of 237 CC version

121 349 Note: this requirement is also satisfied if the required information is provided in the guidance documentation. In this case the evaluator uses the guidance documentation for the activities described below. :ADV_FSP.1-11 The evaluator verifies that the information provided for deleting records from the audit trail or all records form the audit trail completely describe the conditions that must be met to delete records from the audit trail. 350 Note: this requirement is also satisfied if the required information is provided in the guidance documentation. In this case the evaluator uses the guidance documentation for the activities described below. :ADV_FSP.1-12 :ADV_FSP.1-13 The evaluator identifies from the description provided possible management actions that can be performed for FAU_STG.4. Those are mapped to the interfaces that have been identified for such management activities and analyzed for consistency with the specification in the ST. The evaluator verifies with all the interfaces identified as one where access control is enforced that the types of objects and the operations of the access control policy (or policies) addressed by the interface are identified and map to the description of the access control policy. If the description of the interface mentions more types of objects or more operations (as being subject to the access control policy) than defined in the access control policy description in the Security Target, the evaluator needs to flag this as an inconsistency. Unless the developer can provide an explanation accepted by the evaluation facility and the scheme that this is not an inconsistency, an update of the Security Target is required that removes this inconsistency. 351 In addition the evaluator verifies that for all security attributes that the Security Target claims are manageable, a management interface is identified in the functional specification that allows for the management action defined in the Security Target and that those interfaces are described such that they can be used for testing the management functionality. 352 Note: this assessment overlaps with assessment activities performed for SFRs in the management area and the evaluator ensures that the different aspects of the management activities are assessed only once. The evaluator may refer in the activities performed for FDP_ACC/FDP_ACF to the assessment performed when analyzing the SFRs related to management or vice versa. :ADV_FSP.1-14 :ADV_FSP.1-15 The evaluator verifies that the interfaces are described to the extent that he can use them to test the effect of the filtering rules. For each resource identified as one that requires object re-use the evaluator identifies from the TSFI provided by the developer: Interfaces that can be used to release a resource Interfaces that can be used to re-allocate a resource CC version 3.1 Page 121 of 237

122 Interfaces that can be used read the content of a resource after reallocation :ADV_FSP.1-16 With an understanding of how the I&A functions are intended to operate, the evaluator turns to the interface specification to see what interfaces support I&A. The developer is required to have provided a mapping of the interfaces to the I&A functions, including those that map to FIA_UAU.5, and the evaluator ensures that the description of the methods of I&A presented in the Security Functional Description are included in the provided interfaces and vice versa. There may be interfaces for authentication that are not subject to the failure handling, and this is acceptable, as long as it is consistent with the authentication methods and authentication events listed in this SFR. For example, there may be interfaces to authenticate to the TOE that employ a smartcard, but authentication failures resulting in the use of a smartcard are not one of the authentication methods considered. 353 However, if during their analysis an evaluator discovers that an advertised interface whose description indicates an action will be taken relating to failed authentication attempts, and it employs the authentication method in the requirement, the evaluator must work with the developer to resolve the discrepancy. On the other hand, if the evaluator discovers an interface that employs an authentication method that is not specified in the requirement, no further action is required, since it is outside the scope of the products claimed security functionality. :ADV_FSP.1-17 Given the user security attributes identified in the TSS, the evaluator turns to the interface specification to see what interfaces support FIA_ATD.1. The evaluator ensures that the description of the methods available to create, view, modify, and delete the security attributes identified in the TSS are presented in the Security Functional Description. 354 Examples of applicable interfaces include those used to create and delete users, as well as any interfaces available to modify any of the security attributes of existing users (e.g., add/remove groups, change password). 355 However, if during their analysis an evaluator discovers that an advertised interface whose description indicates access to create or modify security attributes has not been mapped to FIA_ATD.1, the evaluator must work with the developer to resolve the discrepancy. On the other hand, if the evaluator discovers an interface that manipulates attributes not identified in FIA_ATD.1 (i.e., not security related), no further action is required, since it is outside the scope of the products claimed security functionality. :ADV_FSP.1-18 The evaluator shall identify the TSFI used to authenticate to the TOE, both remotely and locally. The evaluator shall compare these interfaces to the information provided in the TSS, and determine that if the TSS describes an authorization method for a remote user (IT entity or human) or a local user, then there is an interface that corresponds to this method. If services (over and above those covered by the FDP_IFC/FDP_IFF requirements) are listed in the TSS as being available prior to user authorization, the evaluator Page 122 of 237 CC version

123 ensures that the interfaces to these services are identified in the interface specification. :ADV_FSP.1-19 Given the list of available authentication mechanisms in the TSS, the evaluator turns to the interface specification to see what interfaces support FIA_UAU.5. The developer is required to have provided a mapping of the interfaces to the I&A functions, including those that map to FIA_UAU.5, and the evaluator ensures that the description of the methods available to authenticate user identities, along with rules associated with those methods, are presented in the Security Functional Description. The descriptions should address selecting authentication methods and results of both success (e.g., create a new process) and failure (e.g., password expired) conditions. 356 Note that when multiple authentication methods are available, it is possible that only some of those methods are applicable to specific interfaces and that should be clearly identified. 357 However, if during their analysis an evaluator discovers that an advertised interface whose description indicates authentication methods that have not been mapped to FIA_UAU.5, the evaluator must work with the developer to resolve the discrepancy. Unlike some other functions, it is generally not acceptable that available authentication methods are ignored in the context of evaluation. :ADV_FSP.1-20 Given the user security attributes identified in the TSS, the evaluator turns to the interface specification to see what interfaces support FIA_USB.1. The developer is required to have provided a mapping of the interfaces to the I&A functions, including those that map to FIA_USB.1, and the evaluator ensures that the description of the methods available to create subjects and modify security attributes associated with subjects are presented in the Security Functional Description. 358 Note that it is possible that interfaces may be indirect (e.g., a process created as a result of a user login) or direct (e.g., fork a new process), but they need to be identified and described in either case. 359 Note that it is also possible that security attributes associated with subjects cannot be changed, in which case no applicable interfaces should be identified or mapped. 360 The evaluator shall ensure that for each identified interface the rules for initial security attribute assignment and subsequent modifications, described in the TSS, are also described in the Security Functional Description and are consistent with the TSS. 361 Examples of applicable interfaces include those used to login, fork a process, as well as any interfaces available to modify any of the security attributes of existing subjects (e.g., enable/disable a privilege, change real or effective user or group identifiers) CC version 3.1 Page 123 of 237

124 362 However, if during their analysis an evaluator discovers that an advertised interface whose description indicates user-subject binding functions has not been mapped to FIA_USB.1, the evaluator must work with the developer to resolve the discrepancy. On the other hand, if the evaluator discovers an interface that manipulates subject security attributes not identified in FIA_USB.1 (i.e., not security related), no further action is required, since it is outside the scope of the products claimed security functionality. :ADV_FSP.1-21 :ADV_FSP.1-22 :ADV_FSP.1-23 :ADV_FSP.1-24 :ADV_FSP.1-25 :ADV_FSP.1-26 :ADV_FSP.1-27 :ADV_FSP.1-28 :ADV_FSP.1-29 The interfaces that are used to configure the password enforcement capability are identified. The interfaces that are used to change passwords are also identified, and the evaluator ensures that these interfaces correspond to the one used for password-based authentication in the FIA_UAU requirements. The evaluator verifies that for all object security attributes listed as manageable the management interfaces are identified and described and that all management actions listed in FMT_MSA.1 can be performed using those interfaces The evaluator verifies that the management activities mentioned in the SFR and in the TSS can be performed using those interfaces and that the description is sufficient to use those interfaces in testing. The evaluator verifies that the management activities mentioned in the SFR and in the TSS can be performed using those interfaces and that the description is sufficient to use those interfaces in testing. None except when the inheritance rules can be managed. In this case the interfaces for the management of the inheritance rules need to be analyzed that they allow for the management actions defined. The evaluator identifies from the description provided possible management actions that can be performed for FMT_MTD.1(AS). Those are mapped to the interfaces that have been identified for such management activities and analyzed for consistency with the specification in the ST. The evaluator identifies from the description how the audit trail threshold can be managed. This description needs to specify, which authorization is required to perform this management action and what the limits for the possible values of this threshold are. The evaluator verifies that the possible values for the threshold make sense (e. g. are neither negative nor larger than 100% of the audit trail capacity). The evaluator identifies the management interface(s) for managing the actions to be taken in case of an audit storage failure and verifies that they allow the type of management defined in FMT_MTD.1(AF) with the details mentioned in the TSS. The evaluator verifies that the description of the interfaces is sufficient to perform all the management activities defined in FMT_MTD.1(NI) allowing Page 124 of 237 CC version

125 the definition of filtering rules that cover all aspects defined in FDP_IFC.1 and FDP_IFF.1. :ADV_FSP.1-30 :ADV_FSP.1-31 :ADV_FSP.1-32 :ADV_FSP.1-33 :ADV_FSP.1-34 The evaluator shall further ensure that for each identified interface the restrictions, described in the TSS, are also described in the Security Functional Description and are consistent with the TSS. The evaluator verifies that for all object security attributes listed as revocable the management interfaces are identified and described and that they allow for the revocation of the object security attributes. When examining the interfaces associated with the time function, the evaluator ensures that the descriptions of the interfaces are consistent with what the TSS states about setting system time. The evaluator shall examine the interface specification for the interfaces associated with these components to determine that the capabilities present in the system defined by the TSS are consistent with what the interfaces descriptions state. At the very least, there should be interfaces that provide the ability to set the time interval, lock the session, and unlock the session. The evaluator verifies that either user interfaces exist which allows a user to initiate communication with a remote IT product using a trusted channel, or communication via a trusted channel is initiated automatically by the TSF in accordance with the administrator defined configuration. In either case the evaluator verifies that he is able to get a communication link using the trusted channel protocols specified in FTP_ITC.1 with all the options defined in the SFR. He verifies that those options can either be selected when initiating the trusted channel or can be selected with an appropriate configuration defined via a management interface. C ADV_FSP.1.2E 363 The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. :ADV_FSP.1-35 The evaluator shall examine the functional specification to determine that it is a complete instantiation of the SFRs. 364 To ensure that all SFRs are covered by the functional specification, as well as the test coverage analysis, the evaluator may build upon the developer's tracing (see ADV_FSP.1-5a map between the TOE security functional requirements and the TSFI). Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. 365 For example, the FDP_ACC.1component contains an element with assignments. If the ST contained, for instance, ten rules in CC version 3.1 Page 125 of 237

126 the FDP_ACC.1assignment, and these ten rules were covered by three different TSFI, it would be inadequate for the evaluator to map FDP_ACC.1to TSFI A, B, and C and claim they had completed the work unit. Instead, the evaluator would map FDP_ACC.1(rule 1) to TSFI A; FDP_ACC.1(rule 2) to TSFI B; etc. It might also be the case that the interface is a wrapper interface (e.g., IOCTL), in which case the mapping would need to be specific to certain set of parameters for a given interface. 366 The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that they completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the TOE design ( ADV_TDS) when included in the ST. It is also important to note that since the parameters associated with TSFIs must be fully specified, the evaluator should be able to determine if all aspects of an SFR appear to be implemented at the interface level. :ADV_FSP.1-36 The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the SFRs. 367 For each functional requirement in the ST that results in effects visible at the TSF boundary, the information in the associated TSFI for that requirement specifies the required functionality described by the requirement. For example, if the ST contains a requirement for access control lists, and the only TSFI that map to that requirement specify functionality for Unix-style protection bits, then the functional specification is not accurate with respect to the requirements. 368 The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., FDP_RIP) it is not expected that the evaluator completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the TOE design ( ADV_TDS) when included in the ST. AGD_OPE.1 Operational user guidance Dependencies satisfied by: ADV_FSP.1 Basic functional specification Objectives 369 The objectives of this sub-activity are to determine whether the user guidance describes for each user role the security functionality and interfaces provided by the TSF, provides instructions and guidelines for the secure use of the TOE, addresses secure procedures for all modes of operation, facilitates prevention and detection of insecure TOE states, or whether it is misleading or unreasonable. Page 126 of 237 CC version

127 Objectives 370 The user guidance related to FAU_GEN.1 needs to explain how a user authorized to extract the audit records can do this. It further needs to explain how individual information from the audit records can be presented or extracted in order to verify that all audit records expected have been generated and that the audit records contain the expected information. Input 371 The evaluation evidence for this sub-activity is: the ST; the functional specification; the TOE design, if applicable; the user guidance; Developer action elements: C AGD_OPE.1.1D 372 The developer shall provide operational user guidance. Content and presentation of evidence elements: C AGD_OPE.1.1C 373 The operational user guidance shall describe, for each user role, the useraccessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. C AGD_OPE.1.2C 374 The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner. C AGD_OPE.1.3C 375 The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. C AGD_OPE.1.4C 376 The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF CC version 3.1 Page 127 of 237

128 C AGD_OPE.1.5C 377 The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation. C AGD_OPE.1.6C 378 The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfil the security objectives for the operational environment as described in the ST. C AGD_OPE.1.7C 379 The operational user guidance shall be clear and reasonable. C FAU_GEN_2_AGD_OPE If a specific configuration is required to establish the association between the user that caused the event and the audit record, it is expected that the configuration and the steps to get to this configuration are correctly and completely described in the guidance. C FAU_SAR_1_AGD_OPE The guidance (or the functional specification) needs to explain the conditions that must be met to allow a user to read the audit data. The guidance needs to explain the format the audit records are presented. C FAU_SEL_1_AGD_OPE The guidance (or the functional specification) needs to explain the conditions that must be met to allow a user to manage the set of auditable events. C FAU_STG_1_AGD_OPE The guidance (or the functional specification) needs to explain the conditions that must be met to allow a user to delete records from the audit trail. C FAU_STG_4_AGD_OPE If there are management activities for FAU_STG.4, the guidance needs to explain those activities, the conditions that need to be met to perform those activities and the impact of those activities on the capability of the TOE to generate audit records. Especially if specific types of audit records get lost or if the TOE starts to overwrite old audit records, this needs to be explained in the guidance. The guidance also needs to provide advice how to avoid getting into a situation where audit records get lots (e. g, by automatically initiating backup procedures for the audit trail). The guidance needs to explain the options an administrator has for the actions to be taken in case of an audit storage failure and what the consequences of each of those options are. Page 128 of 237 CC version

129 C FAU_FDP_1_AGD_OPE The user guidance is expected to describe the different access control policies with their algorithms used to determine if access is allowed. The guidance also needs to explain the access control algorithm, allowing a user to understand what decision the algorithm will take based on the set of security attributes used in the rules of the algorithm. The user guidance is expected to describe how the access control policy and the security attributes used by the access control rules can be managed, identifying the conditions that need to be satisfied to perform the individual management operations. Depending on how the developer has structured his public documentation, this information may be described together with the interfaces used for management, which is of course an acceptable way to provide this information. The user guidance is expected to explain how to set up the policies securely and how a user responsible for managing access control or security attributes can query the current status of security attributes that are used in the access control rules. The guidance also needs to explain the access control algorithm, allowing a user to understand what decision the algorithm will take based on the set of security attributes used in the rules of the algorithm. There may not always be the possibility for someone allowed to manage specific security attributes to query the status of other security attributes used in an access control policy. For example a user that is allowed to modify the access control list of objects he owns, may not be allowed to query the list of members belonging to a group, although he is allowed to assign access rights to groups. This is not viewed as a security problem as long as this concept and how to use it securely is explained in the guidance. C FAU_RIP_2_AGD_OPE There is no expectation on specific guidance related to object re-use unless there are management functions that can be used to specify details how object re-use is performed. If this is the case and if the TOE allows for configuration where the object re-use requirement is not satisfied, the guidance needs to describe clearly the configuration steps that have to be taken to ensure that the object re-use functionality is active. C FAU_UAU_1_AGD_OPE The Operational Guidance should contain information describing the relationship between configuration the rules under which the TOE will allow information from remote IT entities and the implications of allowing flows that do not require endpoints to be authenticated. It should be possible for the administrator to determinebased on the guidance providedwhat processing will be performed by the TOE (in terms of the service being allowed; for instance, allowing ICMP to pass will result in remote entities being able to ping the TOE without being authenticated) in response to the configuration of the rules implemented to meet the FDP_IFC/FDP_IFF requirements. The administrative guidance will also cover the configuration of the TOE to support remote authentication; CC version 3.1 Page 129 of 237

130 C FAU_UAU_1_HU_AGD_OPE For remote users, the operational guidance shall contain information pertaining to the configuration of the TOE to allow a user to authenticate remotely. This may involve establishing the credentials to be used by the user, as well as configuration of the TOE credentials depending on the protocol. C FAU_PKI_1_AGD_OPE The operational guidance provides the administrator instruction as to how they configure the TOE to import key material / certificates. The importation of certificates can be from a CA, and may require the configuration steps that ensure the CA is authenticated and the communication path is protected (e.g., trusted channel). Importing other key material from a trusted entity also requires the authentication of this entity and the transfer of the key material via a trusted channel. The guidance also instructs the administrator how they can load key material manually (e.g., through portable media), if this is supported by the TOE. If the TOE comes preloaded with keys or certificates, the guidance instructs the administrator to manage those. This guidance will also most likely be relevant to keys or certificates that are manually loaded, or imported from a CA as well. The guidance covers how to enable or disable the trust relationship of the certificates, if this applies. C FAU_MOF_1_AGD_OPE The operational guidance shall describe the characteristics for passwords that are available; instructions for setting the enforcement mechanism; and a discussion of strong passwords and recommended minimum settings. C FAU MSA_1_AGD_OPE The guidance (or the functional specification) needs to explain the conditions that must be met to allow a user to manage the object security attributes. C FAU_MSA_3_AGD_OPE The guidance (or the functional specification) needs to explain the conditions that must be met to allow a user to manage the default values for security attributes used to enforce the discretionary access control policies. C FAU_MSA_3_NI_AGD_OPE The guidance (or the functional specification) needs to explain the conditions that must be met to allow a user to manage the default values for security attributes used to enforce the Network Information Flow Policy. C FAU_MTD_1_AS_AGD_OPE The guidance (or the functional specification) needs to explain the conditions that must be met to allow a user to manage the audit trail storage object. Page 130 of 237 CC version

131 C FAU_MTD_1_AT_AGD_OPE The guidance (or the functional specification) needs to explain the conditions that must be met to allow a user to manage the audit trail storage threshold. C FAU_MTD_1_NI_AGD_OPE Unless this is already covered in the assessment of the functional specification the guidance is expected to describe the conditions a user must satisfy to perform the different management activities for the network data filtering rules. In addition the guidance is expected to explain the semantics of the different rules and define how potential conflicts are addressed in a set of rules. C FAU_MTD_1_IAU_AGD_OPE The relevant guidance has been identified in the assurance activities for FIA_ATD.1. However, if the rules above are subject to change, the guidance must provide any necessary instructions. Given the open ended nature of such a possibility, this activity would need to be revisited when the rules for access to the user security attributes can be changed in the context of a given TOE. It is not necessarily expected that the administrative guidance should identify the applicable restrictions, but if it does and the evaluator finds a contradiction between the administrative guidance and TSS or Security Functional Description, the evaluator must work with the developer to resolve the discrepancy. C FAU_REV_1_AGD_OPE The guidance (or the functional specification) needs to explain the conditions that must be met to allow a user to revoke the object security attributes. C FAU_STM_1_AGD_OPE If the TOE supports the use of an external entity to receive or update the time, the operational guidance provides the administrator guidance on how to setup the TOE in order to receive time from the authorized entity. The guidance should provide instructions on how to ensure the communication path is protected from attacks that could compromise the integrity of the time. For example, if the TOE is able to use an NTP server, the guidance would instruct the administrator how to configure the NTP client, and may instruct how to use a trusted channel to ensure the NTP server is authenticated and the integrity of the information transported across the channel is either maintained, or any changes are detected. C FAU_ITC_1_AGD_OPE The guidance needs to explain how a trusted channel can be established and what the parameters for setting up a trusted channel are. The guidance needs to describe what options an administrator or a user may select and how those options affect the establishment and maintenance of the trusted channel CC version 3.1 Page 131 of 237

132 Especially options for selecting or excluding cipher suites that can be used as part of the protocol need to be documented, allowing an installation to restrict the cipher suites to those that are viewed as secure or are required to be used to comply with national or organizational policies. Evaluator action elements: C AGD_OPE.1.1E 401 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :AGD_OPE.1-1 AGD_OPE.1.1C The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. 402 The configuration of the TOE may allow different user roles to have dissimilar privileges in making use of the different functions of the TOE. This means that some users are authorised to perform certain functions, while other users may not be so authorised. These functions and privileges should be described, for each user role, by the user guidance. 403 The user guidance identifies, for each user role, the functions and privileges that must be controlled, the types of commands required for them, and the reasons for such commands. The user guidance should contain warnings regarding the use of these functions and privileges. Warnings should address expected effects, possible side effects, and possible interactions with other functions and privileges. :AGD_OPE.1-2 AGD_OPE.1.2C The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the secure use of the available interfaces provided by the TOE. 404 The user guidance should provide advice regarding effective use of the TSF (e.g. reviewing password composition practises, suggested frequency of user file backups, discussion on the effects of changing user access privileges). :AGD_OPE.1-3 AGD_OPE.1.3C The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the available security functionality and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. 405 The user guidance should contain an overview of the security functionality that is visible at the user interfaces. 406 The user guidance should identify and describe the purpose, behaviour, and interrelationships of the security interfaces and functionality. 407 For each user-accessible interface, the user guidance should: Page 132 of 237 CC version

133 describe the method(s) by which the interface is invoked (e.g. command-line, programming-language system call, menu selection, command button); describe the parameters to be set by the user, their particular purposes, valid and default values, and secure and insecure use settings of such parameters, both individually or in combination; describe the immediate TSF response, message, or code returned. 408 The evaluator should consider the functional specification and the ST to determine that the TSF described in these documents is consistent to the operational user guidance. The evaluator has to ensure that the operational user guidance is complete to allow the secure use through the TSFI available to all types of human users. The evaluator may, as an aid, prepare an informal mapping between the guidance and these documents. Any omissions in this mapping may indicate incompleteness. :AGD_OPE.1-4 AGD_OPE.1.4C The evaluator shall examine the operational user guidance to determine that it describes, for each user role, each type of security-relevant event relative to the user functions that need to be performed, including changing the security characteristics of entities under the control of the TSF and operation following failure or operational error. 409 All types of security-relevant events are detailed for each user role, such that each user knows what events may occur and what action (if any) he may have to take in order to maintain security. Security-relevant events that may occur during operation of the TOE (e.g. audit trail overflow, system crash, updates to user records, such as when a user account is removed when the user leaves the organisation) are adequately defined to allow user intervention to maintain secure operation. :AGD_OPE.1-5 AGD_OPE.1.5C The evaluator shall examine the operational user guidance and other evaluation evidence to determine that the guidance identifies all possible modes of operation of the TOE (including, if applicable, operation following failure or operational error), their consequences and implications for maintaining secure operation. 410 Other evaluation evidence, particularly the functional specification, provide an information source that the evaluator should use to determine that the guidance contains sufficient guidance information. 411 If test documentation is included in the assurance package, then the information provided in this evidence can also be used to determine that the guidance contains sufficient guidance documentation. The detail provided in the test steps can be used to confirm that the guidance provided is sufficient for the use and administration of the TOE. 412 The evaluator should focus on a single human visible TSFI at a time, comparing the guidance for securely using the TSFI with other evaluation evidence, to determine that the guidance related to the TSFI is sufficient for CC version 3.1 Page 133 of 237

134 the secure usage (i.e. consistent with the SFRs) of that TSFI. The evaluator should also consider the relationships between interfaces, searching for potential conflicts. :AGD_OPE.1-6 AGD_OPE.1.6C The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the security measures to be followed in order to fulfil the security objectives for the operational environment as described in the ST. 413 The evaluator analyses the security objectives for the operational environment in the ST and determines that for each user role, the relevant security measures are described appropriately in the user guidance. 414 The security measures described in the user guidance should include all relevant external procedural, physical, personnel and connectivity measures. 415 Note that those measures relevant for secure installation of the TOE are examined in Error! Reference source not found.. :AGD_OPE.1-7 AGD_OPE.1.7C The evaluator shall examine the operational user guidance to determine that it is clear. 416 The guidance is unclear if it can reasonably be misconstrued by an administrator or user, and used in a way detrimental to the TOE, or to the security provided by the TOE. :AGD_OPE.1-8 AGD_OPE.1.7C The evaluator shall examine the operational user guidance to determine that it is reasonable. 417 The guidance is unreasonable if it makes demands on the TOE's usage or operational environment that are inconsistent with the ST or unduly onerous to maintain security. :AGD_OPE.1-9 :AGD_OPE.1-10 :AGD_OPE.1-11 :AGD_OPE.1-12 :AGD_OPE.1-13 The evaluator needs to ensure that the user guidance contains information about the audit records that can be generated, how to extract the audit records and how to identify the information specified in FAU_GEN.1 in the individual audit records. This information is required to be able to test FAU_GEN.1 and to ensure that all the required information is included in the different audit records that map to the requirements in FAU_GEN.1. If a specific configuration is required to establish the association between the user that caused the event and the audit record, the evaluator follows this guidance to configure the TOE such that the association between the user that caused the event and the audit record can be established. See the evaluator activities for the functional specification. See the evaluator activities for the functional specification. See the evaluator activities for the functional specification. Page 134 of 237 CC version

135 :AGD_OPE.1-14 :AGD_OPE.1-15 For the assessment of the management interfaces see the evaluator activities for the functional specification. The evaluator also analyzes the guidance given for preventing the loss of audit records and the management of actions in case of an audit storage failure and uses this in the development of test cases. The evaluator verifies that the algorithms for the different access control policies are completely and correctly described in the user guidance. 418 The evaluator also verifies that for all security attributes that can be managed the user guidance describes: How they can be managed The rules that define when a user is allowed to perform the individual management operations The effect of the management operation on the access control policy behavior Potential side effects that may not be immediately obvious with warnings in cases those side effects may lead to security problems. An example would be a management operation that makes the object inaccessible to any user. (including the conditions that need to be satisfied to perform the query operation). 419 In addition the evaluator verifies that the guidance describes all the steps to initialize and configure each access control policy, including the steps to set default values for security attributes, assign the required privileges to perform management operations, and activate the access control policy. 420 The guidance is further required to explain situations where the TOE does not implement immediate revocation of access control related security attributes, providing guidance how to avoid situations where a user may access an object for a significant amount of time after the security attributes have been modified such that his access is revoked. For example the guidance could explain how to determine the users that currently have an active access path to the object together with possible actions an authorized administrator could take to force the access path to be closed. 421 The evaluator will use the guidance when configuring the access control policies, defining and modifying access rights and other security attributes used in the access control algorithms when defining the test cases he needs to perform. :AGD_OPE.1-16 Only in the case where the TOE needs to be specifically initialized and configured to provide object re-use capabilities for all resources the evaluator will follow the description in the TSS to identify the interfaces and parameter required to initialize and/or configure the TOE to ensure that the object re CC version 3.1 Page 135 of 237

136 use functionality is active. This is required before using the TOE for testing of the object re-use functionality. :AGD_OPE.1-17 The evaluator determines that the administrative guidance for creating, viewing, modifying, and deleting user security attributes, in whole (e.g., create/delete users) or in part (e.g., change password), are consistent with FIA_ATD.1. The evaluator should, at a minimum, find instructions for creating and deleting users. Additional instructions may be available to manipulate one or more of the user security attributes individually and should be identified where available. 422 The description of the interface used to create or otherwise initially define users in the administrative guidance should serve to identify each of the required user attributes assignable upon creation. The description of any interface used to manipulate individual security attributes should clearly identify the applicable attribute(s). :AGD_OPE.1-18 :AGD_OPE.1-19 The evaluator shall examine the operational guidance to determine that any necessary preparatory steps (e.g., establishing credential material such as pre-shared keys, tunnels, certificates, etc.) to authentication are described. For each supported the authentication method, the evaluator shall ensure the operational guidance provides clear instructions for successfully performing the authentication. Some of all of these configuration activities are also addressed in the assurance activity for FTP_ITC.1. The evaluator determines that the administrative guidance for functions requiring authentication is consistent with FIA_UAU.5. The evaluator should, at a minimum, find instructions for authenticating during initial login. Additional instructions may be available for additional functions requiring authentication such as changing passwords, activating privileges, etc. 423 If the TOE support for multiple authentication mechanisms is configurable (e.g., to enable or set up an authentication mechanism), the guidance may also have instructions for enabling/disabling mechanisms, configuring mechanisms, defining rules for the use of mechanisms, etc. The possibilities are extensive, so the activities here may need to be augmented during an evaluation to address additional variations. :AGD_OPE.1-20 The evaluator determines that the administrative guidance for creating subjects and changing security attributes associated with subjects are consistent with FIA_USB.2. The evaluator should, at a minimum, find instructions for logging in (to create a user process). Additional instructions may be available to manipulate one or more of the security attributes of subjects and should be identified where available. 424 The description of any interface used to manipulate security attributes of subjects should clearly identify the applicable attribute(s). Page 136 of 237 CC version

137 :AGD_OPE.1-21 :AGD_OPE.1-22 :AGD_OPE.1-23 :AGD_OPE.1-24 :AGD_OPE.1-25 :AGD_OPE.1-26 :AGD_OPE.1-27 :AGD_OPE.1-28 :AGD_OPE.1-29 The evaluator verifies that the conditions defined in the guidance for managing object security attributes match the conditions defined in FMT_MSA.1. The evaluator verifies that the conditions defined in the guidance for managing the default values of the security attributes match the conditions defined in FMT_MSA.3(DAC). The evaluator verifies that the conditions defined in the guidance for managing the default values for the security attributes match the conditions defined in FMT_MSA.3(NI). For the assessment of the management interfaces see the evaluator activities for the functional specification. For the assessment of the management interfaces see the evaluator activities for the functional specification. The evaluator verifies that the guidance describe the semantics of the network data filtering rules including the aspect of potentially conflicting rules in a rule set allowing the evaluator to determine for each set of rules he defines to determine the expected effect on the network traffic. The evaluator verifies that the conditions defined in the guidance for revoking object security attributes match the conditions defined in FMT_REV.1(OBJ). The evaluator examines the operational guidance, which may reference the interface specification for the applicable interfaces, to ensure it instructs the administrator how to set the time. The evaluator shall examine the operational user guidance to ensure it instructs the administrator how to configure the inactivity time period. If the TOE provides a means to specify what is displayed when the session is locked, the operational guide describes how this is done, and the evaluator shall ensure it is consistent with the description provided in the TSS. 425 The evaluator shall ensure the guide describes the options that are available when the system responds to activity, and how the user can invoke those options. 426 The evaluator shall determine that the guide describes how users can initiate a session-lock. :AGD_OPE.1-30 The evaluator verifies that the guidance describes how to set up a trusted channel using the protocols defined in FTP_ITC.1 with all options defined there. Note that this activity overlaps significantly with the assessment of the functional specification and should therefore be performed together with the assessment of the interfaces CC version 3.1 Page 137 of 237

138 AGD_PRE.1 Preparative procedures Objectives 427 The objective of this sub-activity is to determine whether the procedures and steps for the secure preparation of the TOE have been documented and result in a secure configuration. Application notes 428 The preparative procedures refer to all acceptance and installation procedures, that are necessary to progress the TOE to the secure configuration as described in the ST. Input 429 The evaluation evidence for this sub-activity is: the ST; the TOE including its preparative procedures; the description of developer's delivery procedures, if applicable; Dependencies satisfied by: No dependencies. Developer action elements: C AGD_PRE.1.1D 430 The developer shall provide the TOE including its preparative procedures. Content and presentation of evidence elements: C AGD_PRE.1.1C 431 The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. C AGD_PRE.1.2C 432 The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST. Evaluator action elements: C AGD_PRE.1.1E 433 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Page 138 of 237 CC version

139 :AGD_PRE.1-1 AGD_PRE.1.1C The evaluator shall examine the provided acceptance procedures to determine that they describe the steps necessary for secure acceptance of the TOE in accordance with the developer's delivery procedures. 434 If it is not anticipated by the developer's delivery procedures that acceptance procedures will or can be applied, this work unit is not applicable, and is therefore considered to be satisfied. 435 The acceptance procedures should include as a minimum, that the user has to check that all parts of the TOE as indicated in the ST have been delivered in the correct version. 436 The acceptance procedures should reflect the steps the user has to perform in order to accept the delivered TOE that are implied by the developer's delivery procedures. 437 The acceptance procedures should provide detailed information about the following, if applicable: making sure that the delivered TOE is the complete evaluated instance; detecting modification/masquerading of the delivered TOE. :AGD_PRE.1-2 AGD_PRE.1.2C The evaluator shall examine the provided installation procedures to determine that they describe the steps necessary for secure installation of the TOE and the secure preparation of the operational environment in accordance with the security objectives in the ST. 438 If it is not anticipated that installation procedures will or can be applied (e.g. because the TOE may already be delivered in an operational state), this work unit is not applicable, and is therefore considered to be satisfied. 439 The installation procedures should provide detailed information about the following, if applicable: minimum system requirements for secure installation; requirements for the operational environment in accordance with the security objectives provided by the ST; the steps the user has to perform in order to get to an operational TOE being commensurate with its evaluated configuration. Such a description shall include - for each step - a clear scheme for the decision on the next step depended on success, failure or problems at the current step; changing the installation specific security characteristics of entities under the control of the TSF (for example parameters, settings, passwords); CC version 3.1 Page 139 of 237

140 handling exceptions and problems. C AGD_PRE.1.2E 440 The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation. :AGD_PRE.1-3 The evaluator shall perform all user procedures necessary to prepare the TOE to determine that the TOE and its operational environment can be prepared securely using only the supplied preparative procedures. 441 Preparation requires the evaluator to advance the TOE from a deliverable state to the state in which it is operational, including acceptance and installation of the TOE, and enforcing the SFRs consistent with the security objectives for the TOE specified in the ST. 442 The evaluator should follow only the developer's procedures and may perform the activities that customers are usually expected to perform to accept and install the TOE, using the supplied preparative procedures only. Any difficulties encountered during such an exercise may be indicative of incomplete, unclear or unreasonable guidance. 443 This work unit may be performed in conjunction with the evaluation activities under Error! Reference source not found If it is known that the TOE will be used as a dependent component for a composed TOE evaluation, then the evaluator should ensure that the operational environment is satisfied by the base component used in the composed TOE. ALC_CMC.3 Authorisation controls Dependencies satisfied by: Error! Reference source not found. Error! Reference source not found. ALC_LCD.1 Developer defined life-cycle model Objectives 445 A unique reference is required to ensure that there is no ambiguity in terms of which instance of the TOE is being evaluated. Labelling the TOE with its reference ensures that users of the TOE can be aware of which instance of the TOE they are using. 446 Unique identification of the configuration items leads to a clearer understanding of the composition of the TOE, which in turn helps to determine those items which are subject to the evaluation requirements for the TOE. Page 140 of 237 CC version

141 447 The use of a CM system increases assurance that the configuration items are maintained in a controlled manner. 448 Providing controls to ensure that unauthorised modifications are not made to the TOE ( CM access control ), and ensuring proper functionality and use of the CM system, helps to maintain the integrity of the TOE. Objectives 449 The objectives of this sub-activity are to determine whether the developer uses a CM system that uniquely identifies all configuration items, and whether the ability to modify these items is properly controlled. Input 450 The evaluation evidence for this sub-activity is: the ST; the TOE suitable for testing; the configuration management documentation. Developer action elements: C ALC_CMC.3.1D 451 The developer shall provide the TOE and a reference for the TOE. C ALC_CMC.3.2D 452 The developer shall provide the CM documentation. C ALC_CMC.3.3D 453 The developer shall use a CM system. Content and presentation of evidence elements: C ALC_CMC.3.1C 454 The TOE shall be labelled with its unique reference. C ALC_CMC.3.2C 455 The CM documentation shall describe the method used to uniquely identify the configuration items. C ALC_CMC.3.3C 456 The CM system shall uniquely identify all configuration items CC version 3.1 Page 141 of 237

142 C ALC_CMC.3.4C 457 The CM system shall provide measures such that only authorised changes are made to the configuration items. C ALC_CMC.3.5C 458 The CM documentation shall include a CM plan. C ALC_CMC.3.6C 459 The CM plan shall describe how the CM system is used for the development of the TOE. C ALC_CMC.3.7C 460 The evidence shall demonstrate that all configuration items are being maintained under the CM system. C ALC_CMC.3.8C 461 The evidence shall demonstrate that the CM system is being operated in accordance with the CM plan. Evaluator action elements: C ALC_CMC.3.1E 462 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ALC_CMC.3-1 ALC_CMC.3.1C The evaluator shall check that the TOE provided for evaluation is labelled with its reference. 463 The evaluator should ensure that the TOE contains the unique reference which is stated in the ST. This could be achieved through labelled packaging or media, or by a label displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the TOE (e.g. at the point of purchase or use). 464 The TOE may provide a method by which it can be easily identified. For example, a software TOE may display its name and version number during the start up routine, or in response to a command line entry. A hardware or firmware TOE may be identified by a part number physically stamped on the TOE. 465 Alternatively, the unique reference provided for the TOE may be the combination of the unique reference of each component from which the TOE is comprised (e.g. in the case of a composed TOE). :ALC_CMC.3-2 The evaluator shall check that the TOE references used are consistent. Page 142 of 237 CC version

143 466 If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible to relate any labelled guidance documentation supplied as part of the TOE to the evaluated operational TOE. This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, that they have installed this version, and that they have the correct version of the guidance to operate the TOE in accordance with its ST. 467 The evaluator also verifies that the TOE reference is consistent with the ST. 468 If this work unit is applied to a composed TOE, the following will apply. The composed IT TOE will not be labelled with its unique (composite) reference, but only the individual components will be labelled with their appropriate TOE reference. It would require further development for the IT TOE to be labelled, i.e. during start-up and/or operation, with the composite reference. If the composed TOE is delivered as the constituent component TOEs, then the TOE items delivered will not contain the composite reference. However, the composed TOE ST will include the unique reference for the composed TOE and will identify the components comprising the composed TOE through which the consumers will be able to determine whether they have the appropriate items. :ALC_CMC.3-3 ALC_CMC.3.2C The evaluator shall examine the method of identifying configuration items to determine that it describes how configuration items are uniquely identified. 469 Procedures should describe how the status of each configuration item can be tracked throughout the life-cycle of the TOE. The procedures may be detailed in the CM plan or throughout the CM documentation. The information included should describe: the method how each configuration item is uniquely identified, such that it is possible to track versions of the same configuration item; the method how configuration items are assigned unique identifiers and how they are entered into the CM system; the method to be used to identify superseded versions of a configuration item. :ALC_CMC.3-4 ALC_CMC.3.3C The evaluator shall examine the configuration items to determine that they are identified in a way that is consistent with the CM documentation. 470 Assurance that the CM system uniquely identifies all configuration items is gained by examining the identifiers for the configuration items. For both configuration items that comprise the TOE, and drafts of configuration items that are submitted by the developer as evaluation evidence, the evaluator confirms that each configuration item possesses a unique identifier in a manner consistent with the unique identification method that is described in the CM documentation CC version 3.1 Page 143 of 237

144 :ALC_CMC.3-5 ALC_CMC.3.4C The evaluator shall examine the CM access control measures described in the CM plan to determine that they are effective in preventing unauthorised access to the configuration items. 471 The evaluator may use a number of methods to determine that the CM access control measures are effective. For example, the evaluator may exercise the access control measures to ensure that the procedures could not be bypassed. The evaluator may use the outputs generated by the CM system procedures required by ALC_CMC.3.8C. The evaluator may also witness a demonstration of the CM system to ensure that the access control measures employed are operating effectively. :ALC_CMC.3-6 ALC_CMC.3.5C The evaluator shall check that the CM documentation provided includes a CM plan. 472 The CM plan needs not to be a connected document, but it is recommended that there is a single document that describes where the various parts of the CM plan can be found. If the CM plan is no single document, the list in the following work unit gives hints regarding which context is expected. :ALC_CMC.3-7 ALC_CMC.3.6C The evaluator shall examine the CM plan to determine that it describes how the CM system is used for the development of the TOE. 473 The descriptions contained in a CM plan include, if applicable: all activities performed in the TOE development that are subject to configuration management procedures (e.g. creation, modification or deletion of a configuration item, data-backup, archiving); which means (e.g. CM tools, forms) have to be made available; the usage of the CM tools: the necessary details for a user of the CM system to be able to operate the CM tools correctly in order to maintain the integrity of the TOE; which other objects (development components, tools, assessment environments, etc) are taken under CM control; the roles and responsibilities of individuals required to perform operations on individual configuration items (different roles may be identified for different types of configuration items (e.g. design documentation or source code)); how CM instances (e.g. change control boards, interface control working groups) are introduced and staffed; the description of the change management; the procedures that are used to ensure that only authorised individuals can make changes to configuration items; Page 144 of 237 CC version

145 the procedures that are used to ensure that concurrency problems do not occur as a result of simultaneous changes to configuration items; the evidence that is generated as a result of application of the procedures. For example, for a change to a configuration item, the CM system might record a description of the change, accountability for the change, identification of all configuration items affected, status (e.g. pending or completed), and date and time of the change. This might be recorded in an audit trail of changes made or change control records; the approach to version control and unique referencing of TOE versions (e.g. covering the release of patches in operating systems, and the subsequent detection of their application). :ALC_CMC.3-8 ALC_CMC.3.7C The evaluator shall check that the configuration items identified in the configuration list are being maintained by the CM system. 474 The CM system employed by the developer should maintain the integrity of the TOE. The evaluator should check that for each type of configuration item (e.g. design documents or source code modules) contained in the configuration list there are examples of the evidence generated by the procedures described in the CM plan. In this case, the approach to sampling will depend upon the level of granularity used in the CM system to control CM items. Where, for example, 10,000 source code modules are identified in the configuration list, a different sampling strategy needs to be applied compared to the case in which there are only 5, or even 1. The emphasis of this activity should be on ensuring that the CM system is being operated correctly, rather than on the detection of any minor error. 475 For guidance on sampling see Error! Reference source not found.. :ALC_CMC.3-9 ALC_CMC.3.8C The evaluator shall check the CM documentation to ascertain that it includes the CM system records identified by the CM plan. 476 The output produced by the CM system should provide the evidence that the evaluator needs to be confident that the CM plan is being applied, and also that all configuration items are being maintained by the CM system as required by ALC_CMC.3.7C. Example output could include change control forms, or configuration item access approval forms. :ALC_CMC.3-10 ALC_CMC.3.8C The evaluator shall examine the evidence to determine that the CM system is being operated in accordance with the CM plan. 477 The evaluator should select and examine a sample of evidence covering each type of CM-relevant operation that has been performed on a configuration item (e.g. creation, modification, deletion, reversion to an earlier version) to confirm that all operations of the CM system have been carried out in line with documented procedures. The evaluator confirms that the evidence includes all the information identified for that operation in the CM plan CC version 3.1 Page 145 of 237

146 Examination of the evidence may require access to a CM tool that is used. The evaluator may choose to sample the evidence. 478 For guidance on sampling see Error! Reference source not found Further confidence in the correct operation of the CM system and the effective maintenance of configuration items may be established by means of interviews with selected development staff. In conducting such interviews, the evaluator aims to gain a deeper understanding of how the CM system is used in practise as well as to confirm that the CM procedures are being applied as described in the CM documentation. Note that such interviews should complement rather than replace the examination of documentary evidence, and may not be necessary if the documentary evidence alone satisfies the requirement. However, given the wide scope of the CM plan it is possible that some aspects (e.g. roles and responsibilities) may not be clear from the CM plan and records alone. This is one case where clarification may be necessary through interviews. 480 It is expected that the evaluator will visit the development site in support of this activity. 481 For guidance on site visits see Error! Reference source not found.. ALC_CMS.3 Implementation representation CM coverage Dependencies satisfied by: No dependencies. Objectives 482 A CM system can control changes only to those items that have been placed under CM (i.e., the configuration items identified in the configuration list). Placing the TOE itself, the parts that comprise the TOE, the TOE implementation representation and the evaluation evidence required by the other SARs under CM provides assurance that they have been modified in a controlled manner with proper authorisations. Application notes 483 ALC_CMS.3.1C introduces the requirement that the TOE implementation representation be included in the list of configuration items and hence be subject to the CM requirements of Error! Reference source not found.. Objectives 484 The objective of this sub-activity is to determine whether the configuration list includes the TOE, the parts that comprise the TOE, the TOE implementation representation, and the evaluation evidence. These configuration items are controlled in accordance with Error! Reference source not found.. Page 146 of 237 CC version

147 Input 485 The evaluation evidence for this sub-activity is: the ST; the configuration list. Developer action elements: C ALC_CMS.3.1D 486 The developer shall provide a configuration list for the TOE. Content and presentation of evidence elements: C ALC_CMS.3.1C 487 The configuration list shall include the following: the TOE itself; the evaluation evidence required by the SARs; the parts that comprise the TOE; and the implementation representation. C ALC_CMS.3.2C 488 The configuration list shall uniquely identify the configuration items. C ALC_CMS.3.3C 489 For each TSF relevant configuration item, the configuration list shall indicate the developer of the item. Evaluator action elements: C ALC_CMS.3.1E 490 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ALC_CMS.3-1 ALC_CMS.3.1C The evaluator shall check that the configuration list includes the following set of items: the TOE itself; the parts that comprise the TOE; the TOE implementation representation; the evaluation evidence required by the SARs in the ST. :ALC_CMS.3-2 ALC_CMS.3.2C The evaluator shall examine the configuration list to determine that it uniquely identifies each configuration item CC version 3.1 Page 147 of 237

148 491 The configuration list contains sufficient information to uniquely identify which version of each item has been used (typically a version number). Use of this list will enable the evaluator to check that the correct configuration items, and the correct version of each item, have been used during the evaluation. :ALC_CMS.3-3 ALC_CMS.3.3C The evaluator shall check that the configuration list indicates the developer of each TSF relevant configuration item. 492 If only one developer is involved in the development of the TOE, this work unit is not applicable, and is therefore considered to be satisfied. ALC_DEL.1 Delivery procedures Objectives 493 The objective of this sub-activity is to determine whether the delivery documentation describes all procedures used to maintain security of the TOE when distributing the TOE to the user. Input 494 The evaluation evidence for this sub-activity is: the ST; the delivery documentation. Dependencies satisfied by: No dependencies. Developer action elements: C ALC_DEL.1.1D 495 The developer shall document and provide procedures for delivery of the TOE or parts of it to the consumer. C ALC_DEL.1.2D 496 The developer shall use the delivery procedures. :ALC_DEL.1-1 The evaluator shall examine aspects of the delivery process to determine that the delivery procedures are used. 497 The approach taken by the evaluator to check the application of delivery procedures will depend on the nature of the TOE, and the delivery process itself. In addition to examination of the procedures themselves, the evaluator seeks some assurance that they are applied in practise. Some possible approaches are: Page 148 of 237 CC version

149 a visit to the distribution site(s) where practical application of the procedures may be observed; examination of the TOE at some stage during delivery, or after the user has received it (e.g. checking for tamper proof seals); observing that the process is applied in practise when the evaluator obtains the TOE through regular channels; questioning end users as to how the TOE was delivered. 498 For guidance on site visits see Error! Reference source not found It may be the case of a newly developed TOE that the delivery procedures have yet to be exercised. In these cases, the evaluator has to be satisfied that appropriate procedures and facilities are in place for future deliveries and that all personnel involved are aware of their responsibilities. The evaluator may request a dry run of a delivery if this is practical. If the developer has produced other similar products, then an examination of procedures in their use may be useful in providing assurance. Content and presentation of evidence elements: C ALC_DEL.1.1C 500 The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to the consumer. Evaluator action elements: C ALC_DEL.1.1E 501 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ALC_DEL.1-2 ALC_DEL.1.1C The evaluator shall examine the delivery documentation to determine that it describes all procedures that are necessary to maintain security when distributing versions of the TOE or parts of it to the consumer. 502 The delivery documentation describes proper procedures to maintain security of the TOE during transfer of the TOE or its component parts and to determine the identification of the TOE. 503 The delivery documentation should cover the entire TOE, but may contain different procedures for different parts of the TOE. The evaluation should consider the totality of procedures. 504 The delivery procedures should be applicable across all phases of delivery from the production environment to the installation environment (e.g. packaging, storage and distribution). Standard commercial practise for packaging and delivery may be acceptable. This includes shrink wrapped packaging, a security tape or a sealed envelope. For the distribution, physical CC version 3.1 Page 149 of 237

150 (e.g. public mail or a private distribution service) or electronic (e.g. electronic mail or downloading off the Internet) procedures may be used. 505 Cryptographic checksums or a software signature may be used by the developer to ensure that tampering or masquerading can be detected. Tamper proof seals additionally indicate if the confidentiality has been broken. For software TOEs, confidentiality might be assured by using encryption. If availability is of concern, a secure transportation might be required. 506 Interpretation of the term necessary to maintain security will need to consider: The nature of the TOE (e.g. whether it is software or hardware). The overall security level stated for the TOE by the chosen level of the Vulnerability Assessment. If the TOE is required to be resistant against attackers of a certain potential in its intended environment, this should also apply to the delivery of the TOE. The evaluator should determine that a balanced approach has been taken, such that delivery does not present a weak point in an otherwise secure development process. The security objectives provided by the ST. The emphasis in the delivery documentation is likely to be on measures related to integrity, as integrity of the TOE is always important. However, confidentiality and availability of the delivery will be of concern in the delivery of some TOEs; procedures relating to these aspects of the secure delivery should also be discussed in the procedures. ALC_FLR.3 Systematic flaw remediation Dependencies satisfied by: No dependencies. Objectives 507 In order for the developer to be able to act appropriately upon security flaw reports from TOE users, and to know to whom to send corrective fixes, TOE users need to understand how to submit security flaw reports to the developer, and how to register themselves with the developer so that they may receive these corrective fixes. Flaw remediation guidance from the developer to the TOE user ensures that TOE users are aware of this important information. Objectives 508 The objective of this sub-activity is to determine whether the developer has established flaw remediation procedures that describe the tracking of security flaws, the identification of corrective actions, and the distribution of corrective action information to TOE users. Additionally, this sub-activity determines whether the developer's procedures provide for the corrections of Page 150 of 237 CC version

151 security flaws, for the receipt of flaw reports from TOE users, for assurance that the corrections introduce no new security flaws, for the establishment of a point of contact for each TOE user, and for the timely issue of corrective actions to TOE users. 509 In order for the developer to be able to act appropriately upon security flaw reports from TOE users, TOE users need to understand how to submit security flaw reports to the developer, and developers need to know how to receive these reports. Flaw remediation guidance addressed to the TOE user ensures that TOE users are aware of how to communicate with the developer; flaw remediation procedures describe the developer's role is such communication. Input 510 The evaluation evidence for this sub-activity is: the flaw remediation procedures documentation; flaw remediation guidance documentation. Developer action elements: C ALC_FLR.3.1D 511 The developer shall document and provide flaw remediation procedures addressed to TOE developers. C ALC_FLR.3.2D 512 The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws. C ALC_FLR.3.3D 513 The developer shall provide flaw remediation guidance addressed to TOE users. Content and presentation of evidence elements: C ALC_FLR.3.1C 514 The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. C ALC_FLR.3.2C 515 The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw CC version 3.1 Page 151 of 237

152 C ALC_FLR.3.3C 516 The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. C ALC_FLR.3.4C 517 The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. C ALC_FLR.3.5C 518 The flaw remediation procedures shall describe a means by which the developer receives from TOE users reports and enquiries of suspected security flaws in the TOE. C ALC_FLR.3.6C 519 The flaw remediation procedures shall include a procedure requiring timely response and the automatic distribution of security flaw reports and the associated corrections to registered users who might be affected by the security flaw. C ALC_FLR.3.7C 520 The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users. C ALC_FLR.3.8C 521 The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws. C ALC_FLR.3.9C 522 The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE. C ALC_FLR.3.10C 523 The flaw remediation guidance shall describe a means by which TOE users may register with the developer, to be eligible to receive security flaw reports and corrections. C ALC_FLR.3.11C 524 The flaw remediation guidance shall identify the specific points of contact for all reports and enquiries about security issues involving the TOE. Page 152 of 237 CC version

153 Evaluator action elements: C ALC_FLR.3.1E 525 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ALC_FLR.3-1 ALC_FLR.3.1C The evaluator shall examine the flaw remediation procedures documentation to determine that it describes the procedures used to track all reported security flaws in each release of the TOE. 526 The procedures describe the actions that are taken by the developer from the time each suspected security flaw is reported to the time that it is resolved. This includes the flaw's entire time frame, from initial detection through ascertaining that the flaw is a security flaw, to resolution of the security flaw. 527 If a flaw is discovered not to be security-relevant, there is no need (for the purposes of the Error! Reference source not found.requirements) for the flaw remediation procedures to track it further; only that there be an explanation of why the flaw is not security-relevant. :ALC_FLR.3-2 ALC_FLR.3.2C The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would produce a description of each security flaw in terms of its nature and effects. 528 The procedures identify the actions that are taken by the developer to describe the nature and effects of each security flaw in sufficient detail to be able to reproduce it. The description of the nature of a security flaw addresses whether it is an error in the documentation, a flaw in the design of the TSF, a flaw in the implementation of the TSF, etc. The description of the security flaw's effects identifies the portions of the TSF that are affected and how those portions are affected. For example, a security flaw in the implementation might be found that affects the identification and authentication enforced by the TSF by permitting authentication with the password BACKDOOR. :ALC_FLR.3-3 ALC_FLR.3.2C The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would identify the status of finding a correction to each security flaw. 529 The flaw remediation procedures identify the different stages of security flaws. This differentiation includes at least: suspected security flaws that have been reported, suspected security flaws that have been confirmed to be security flaws, and security flaws whose solutions have been implemented. It is permissible that additional stages (e.g. flaws that have been reported but not yet investigated, flaws that are under investigation, security flaws for which a solution has been found but not yet implemented) be included. :ALC_FLR.3-4 ALC_FLR.3.3C The evaluator shall check the flaw remediation procedures to determine that the application of these procedures would identify the corrective action for each security flaw CC version 3.1 Page 153 of 237

154 530 Corrective actionmay consist of a repair to the hardware, firmware, or software portions of the TOE, a modification of TOE guidance, or both. Corrective action that constitutes modifications to TOE guidance (e.g. details of procedural measures to be taken to obviate the security flaw) includes both those measures serving as only an interim solution (until the repair is issued) as well as those serving as a permanent solution (where it is determined that the procedural measure is the best solution). 531 If the source of the security flaw is a documentation error, the corrective action consists of an update of the affected TOE guidance. If the corrective action is a procedural measure, this measure will include an update made to the affected TOE guidance to reflect these corrective procedures. :ALC_FLR.3-5 ALC_FLR.3.4C The evaluator shall examine the flaw remediation procedures documentation to determine that it describes a means of providing the TOE users with the necessary information on each security flaw. 532 The necessary informationabout each security flaw consists of its description (not necessarily at the same level of detail as that provided as part of work unit ALC_FLR.3-2), the prescribed corrective action, and any associated guidance on implementing the correction. 533 TOE users may be provided with such information, correction, and documentation updates in any of several ways, such as their posting to a website, their being sent to TOE users, or arrangements made for the developer to install the correction. In cases where the means of providing this information requires action to be initiated by the TOE user, the evaluator examines any TOE guidance to ensure that it contains instructions for retrieving the information. 534 The only metric for assessing the adequacy of the method used for providing the information, corrections and guidance is that there be a reasonable expectation that TOE users can obtain or receive it. For example, consider the method of dissemination where the requisite data is posted to a website for one month, and the TOE users know that this will happen and when this will happen. This may not be especially reasonable or effective (as, say, a permanent posting to the website), yet it is feasible that the TOE user could obtain the necessary information. On the other hand, if the information were posted to the website for only one hour, yet TOE users had no way of knowing this or when it would be posted, it is infeasible that they would ever get the necessary information. 535 For TOE users who register with the developer (see work unit ALC_FLR.3-12), the passive availability of this information is not sufficient. Developers must actively send the information (or a notification of its availability) to registered TOE users. :ALC_FLR.3-6 ALC_FLR.3.5C The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in a means for the developer to receive from TOE user reports of suspected security flaws or requests for corrections to such flaws. Page 154 of 237 CC version

155 536 The procedures ensure that TOE users have a means by which they can communicate with the TOE developer. By having a means of contact with the developer, the user can report security flaws, enquire about the status of security flaws, or request corrections to flaws. This means of contact may be part of a more general contact facility for reporting non-security related problems. 537 The use of these procedures is not restricted to TOE users; however, only the TOE users are actively supplied with the details of these procedures. Others who might have access to or familiarity with the TOE can use the same procedures to submit reports to the developer, who is then expected to process them. Any means of submitting reports to the developer, other than those identified by the developer, are beyond the scope of this work unit; reports generated by other means need not be addressed. :ALC_FLR.3-7 ALC_FLR.3.6C The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in a timely means of providing the registered TOE users who might be affected with reports about, and associated corrections to, each security flaw. 538 The issue of timeliness applies to the issuance of both security flaw reports and the associated corrections. However, these need not be issued at the same time. It is recognised that flaw reports should be generated and issued as soon as an interim solution is found, even if that solution is as drastic as turn off the TOE. Likewise, when a more permanent (and less drastic) solution is found, it should be issued without undue delay. 539 It is unnecessary to restrict the recipients of the reports and associated corrections to only those TOE users who might be affected by the security flaw; it is permissible that all TOE users be given such reports and corrections for all security flaws, provided such is done in a timely manner. :ALC_FLR.3-8 ALC_FLR.3.6C The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in automatic distribution of the reports and associated corrections to the registered TOE users who might be affected. 540 Automatic distributiondoes not mean that human interaction with the distribution method is not permitted. In fact, the distribution method could consist entirely of manual procedures, perhaps through a closely monitored procedure with prescribed escalation upon the lack of issue of reports or corrections. 541 It is unnecessary to restrict the recipients of the reports and associated corrections to only those TOE users who might be affected by the security flaw; it is permissible that all TOE users be given such reports and corrections for all security flaws, provided such is done automatically. :ALC_FLR.3-9 ALC_FLR.3.7C The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would help to ensure that every reported flaw is corrected CC version 3.1 Page 155 of 237

156 542 The flaw remediation procedures cover not only those security flaws discovered and reported by developer personnel, but also those reported by TOE users. The procedures are sufficiently detailed so that they describe how it is ensured that each reported security flaw is remediated. The procedures contain reasonable steps that show progress leading to the eventual, inevitable resolution. 543 The procedures describe the process that is taken from the point at which the suspected security flaw is determined to be a security flaw to the point at which it is resolved. :ALC_FLR.3-10 ALC_FLR.3.7C The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would help to ensure that the TOE users are issued remediation procedures for each security flaw. 544 The procedures describe the process that is taken from the point at which a security flaw is resolved to the point at which the remediation procedures are provided. The procedures for delivering remediation procedures should be consistent with the security objectives; they need not necessarily be identical to the procedures used for delivering the TOE, as documented to meet Error! Reference source not found., if included in the assurance requirements. For example, if the hardware portion of a TOE were originally delivered by bonded courier, updates to hardware resulting from flaw remediation would likewise be expected to be distributed by bonded courier. Updates unrelated to flaw remediation would follow the procedures set forth in the documentation meeting the Error! Reference source not found.requirements. :ALC_FLR.3-11 ALC_FLR.3.8C The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in safeguards that the potential correction contains no adverse effects. 545 Through analysis, testing, or a combination of the two, the developer may reduce the likelihood that adverse effects will be introduced when a security flaw is corrected. The evaluator assesses whether the procedures provide detail in how the necessary mix of analysis and testing actions is to be determined for a given correction. 546 The evaluator also determines that, for instances where the source of the security flaw is a documentation problem, the procedures include the means of safeguarding against the introduction of contradictions with other documentation. :ALC_FLR.3-12 ALC_FLR.3.9C The evaluator shall examine the flaw remediation guidance to determine that the application of these procedures would result in a means for the TOE user to provide reports of suspected security flaws or requests for corrections to such flaws. 547 The guidance ensures that TOE users have a means by which they can communicate with the TOE developer. By having a means of contact with Page 156 of 237 CC version

157 the developer, the user can report security flaws, enquire about the status of security flaws, or request corrections to flaws. :ALC_FLR.3-13 ALC_FLR.3.10C The evaluator shall examine the flaw remediation guidance to determine that it describes a means of enabling the TOE users to register with the developer. 548 Enabling the TOE users to register with the developersimply means having a way for each TOE user to provide the developer with a point of contact; this point of contact is to be used to provide the TOE user with information related to security flaws that might affect that TOE user, along with any corrections to the security flaw. Registering the TOE user may be accomplished as part of the standard procedures that TOE users undergo to identify themselves to the developer, for the purposes of registering a software licence, or for obtaining update and other useful information. 549 There need not be one registered TOE user per installation of the TOE; it would be sufficient if there were one registered TOE user for an organisation. For example, a corporate TOE user might have a centralised acquisition office for all of its sites. In this case, the acquisition office would be a sufficient point of contact for all of that TOE user's sites, so that all of the TOE user's installations of the TOE have a registered point of contact. 550 In either case, it must be possible to associate each TOE that is delivered with an organisation in order to ensure that there is a registered user for each TOE. For organisations that have many different addresses, this assures that there will be no user who is erroneously presumed to be covered by a registered TOE user. 551 It should be noted that TOE users need not register; they must only be provided with a means of doing so. However, users who choose to register must be directly sent the information (or a notification of its availability). :ALC_FLR.3-14 ALC_FLR.3.11C The evaluator shall examine the flaw remediation guidance to determine that it identifies specific points of contact for user reports and enquiries about security issues involving the TOE. 552 The guidance includes a means whereby registered TOE users can interact with the developer to report discovered security flaws in the TOE or to make enquiries regarding discovered security flaws in the TOE. ALC_LCD.1 Developer defined life-cycle model Objectives 553 The objective of this sub-activity is to determine whether the developer has used a documented model of the TOE life-cycle CC version 3.1 Page 157 of 237

158 Input 554 The evaluation evidence for this sub-activity is: the ST; the life-cycle definition documentation. Dependencies satisfied by: No dependencies. Developer action elements: C ALC_LCD.1.1D 555 The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE. C ALC_LCD.1.2D 556 The developer shall provide life-cycle definition documentation. Content and presentation of evidence elements: C ALC_LCD.1.1C 557 The life-cycle definition documentation shall describe the model used to develop and maintain the TOE. C ALC_LCD.1.2C 558 The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE. Evaluator action elements: C ALC_LCD.1.1E 559 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ALC_LCD.1-1 ALC_LCD.1.1C The evaluator shall examine the documented description of the life-cycle model used to determine that it covers the development and maintenance process. 560 The description of the life-cycle model should include: information on the life-cycle phases of the TOE and the boundaries between the subsequent phases; information on the procedures, tools and techniques used by the developer (e.g. for design, coding, testing, bug-fixing); Page 158 of 237 CC version

159 overall management structure governing the application of the procedures (e.g. an identification and description of the individual responsibilities for each of the procedures required by the development and maintenance process covered by the life-cycle model); information on which parts of the TOE are delivered by subcontractors, if subcontractors are involved. 561 ALC_LCD.1 Developer defined life-cycle modeldoes not require the model used to conform to any standard life-cycle model. :ALC_LCD.1-2 ALC_LCD.1.2C The evaluator shall examine the life-cycle model to determine that use of the procedures, tools and techniques described by the life-cycle model will make the necessary positive contribution to the development and maintenance of the TOE. 562 The information provided in the life-cycle model gives the evaluator assurance that the development and maintenance procedures adopted would minimise the likelihood of security flaws. For example, if the life-cycle model described the review process, but did not make provision for recording changes to components, then the evaluator may be less confident that errors will not be introduced into the TOE. The evaluator may gain further assurance by comparing the description of the model against an understanding of the development process gleaned from performing other evaluator actions relating to the TOE development (e.g. those covered under the Error! Reference source not found.). Identified deficiencies in the lifecycle model will be of concern if they might reasonably be expected to give rise to the introduction of flaws into the TOE, either accidentally or deliberately. 563 The CC does not mandate any particular development approach, and each should be judged on merit. For example, spiral, rapid-prototyping and waterfall approaches to design can all be used to produce a quality TOE if applied in a controlled environment. ASE_INT.1 ST introduction Objectives 564 The objective of this sub-activity is to determine whether the ST and the TOE are correctly identified, whether the TOE is correctly described in a narrative way at three levels of abstraction (TOE reference, TOE overview and TOE description), and whether these three descriptions are consistent with each other. Input 565 The evaluation evidence for this sub-activity is: CC version 3.1 Page 159 of 237

160 the ST. Dependencies satisfied by: No dependencies. Developer action elements: C ASE_INT.1.1D 566 The developer shall provide an ST introduction. Content and presentation of evidence elements: C ASE_INT.1.1C 567 The ST introduction shall contain an ST reference, a TOE reference, a TOE overview and a TOE description. C ASE_INT.1.2C 568 The ST reference shall uniquely identify the ST. C ASE_INT.1.3C 569 The TOE reference shall identify the TOE. C ASE_INT.1.4C 570 The TOE overview shall summarise the usage and major security features of the TOE. C ASE_INT.1.5C 571 The TOE overview shall identify the TOE type. C ASE_INT.1.6C 572 The TOE overview shall identify any non-toe hardware/software/firmware required by the TOE. C ASE_INT.1.7C 573 The TOE description shall describe the physical scope of the TOE. C ASE_INT.1.8C 574 The TOE description shall describe the logical scope of the TOE. Evaluator action elements: C ASE_INT.1.1E 575 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Page 160 of 237 CC version

161 :ASE_INT.1-1 :ASE_INT.1-2 ASE_INT.1.1C The evaluator shall check that the ST introduction contains an ST reference, a TOE reference, a TOE overview and a TOE description. ASE_INT.1.2C The evaluator shall examine the ST reference to determine that it uniquely identifies the ST. 576 The evaluator determines that the ST reference identifies the ST itself, so that it may be easily distinguished from other STs, and that it also uniquely identifies each version of the ST, e.g. by including a version number and/or a date of publication. 577 In evaluations where a CM system is provided, the evaluator may validate the uniqueness of the reference by checking the configuration list. In the other cases, the ST should have some referencing system that is capable of supporting unique references (e.g. use of numbers, letters or dates). :ASE_INT.1-3 ASE_INT.1.3C The evaluator shall examine the TOE reference to determine that it identifies the TOE. 578 The evaluator determines that the TOE reference identifies the TOE, so that it is clear to which TOE the ST refers, and that it also identifies the version of the TOE, e.g. by including a version/release/build number, or a date of release. :ASE_INT.1-4 ASE_INT.1.3C The evaluator shall examine the TOE reference to determine that it is not misleading. 579 If the TOE is related to one or more well-known products, it is allowed to reflect this in the TOE reference. However, this should not be used to mislead consumers: situations where only a small part of a product is evaluated, yet the TOE reference does not reflect this, are not allowed. :ASE_INT.1-5 ASE_INT.1.4C The evaluator shall examine the TOE overview to determine that it describes the usage and major security features of the TOE. 580 The TOE overview should briefly (i.e. several paragraphs) describe the usage and major security features of the TOE. The TOE overview should enable potential consumers to quickly determine whether the TOE may be suitable for their security needs. 581 The TOE overview in an ST for a composed TOE should describe the usage and major security feature of the composed TOE, rather than those of the individual component TOEs. 582 The evaluator determines that the overview is clear enough for consumers, and sufficient to give them a general understanding of the intended usage and major security features of the TOE. :ASE_INT.1-6 ASE_INT.1.5C The evaluator shall check that the TOE overview identifies the TOE type CC version 3.1 Page 161 of 237

162 :ASE_INT.1-7 ASE_INT.1.5C The evaluator shall examine the TOE overview to determine that the TOE type is not misleading. 583 There are situations where the general consumer would expect certain functionality of the TOE because of its TOE type. If this functionality is absent in the TOE, the evaluator determines that the TOE overview adequately discusses this absence. 584 There are also TOEs where the general consumer would expect that the TOE should be able to operate in a certain operational environment because of its TOE type. If the TOE is unable to operate in such an operational environment, the evaluator determines that the TOE overview adequately discusses this. :ASE_INT.1-8 ASE_INT.1.6C The evaluator shall examine the TOE overview to determine that it identifies any non-toe hardware/software/firmware required by the TOE. 585 While some TOEs are able to run stand-alone, other TOEs (notably software TOEs) need additional hardware, software or firmware to operate. If the TOE does not require any hardware, software or firmware, this work unit is not applicable and therefore considered to be satisfied. 586 The evaluator determines that the TOE overview identifies any additional hardware, software and firmware needed by the TOE to operate. This identification does not have to be exhaustive, but detailed enough for potential consumers of the TOE to determine whether their current hardware, software and firmware support use of the TOE, and, if this is not the case, which additional hardware, software and/or firmware is needed. :ASE_INT.1-9 ASE_INT.1.7C The evaluator shall examine the TOE description to determine that it describes the physical scope of the TOE. 587 The evaluator determines that the TOE description lists the hardware, firmware, software and guidance parts that constitute the TOE and describes them at a level of detail that is sufficient to give the reader a general understanding of those parts. 588 The evaluator also determines that there is no possible misunderstanding as to whether any hardware, firmware, software or guidance part is part of the TOE or not. :ASE_INT.1-10 ASE_INT.1.8C The evaluator shall examine the TOE description to determine that it describes the logical scope of the TOE. 589 The evaluator determines that the TOE description discusses the logical security features offered by the TOE at a level of detail that is sufficient to give the reader a general understanding of those features. 590 The evaluator also determines that there is no possible misunderstanding as to whether any logical security feature is offered by the TOE or not. Page 162 of 237 CC version

163 591 An ST for a composed TOE may refer out to the description of the logical scope of the component TOEs, provided in the component TOE STs to provide the majority of this description for the composed TOE. However, the evaluator determines that the composed TOE ST clearly discusses which features of the individual components are not within the composed TOE, and therefore not a feature of the composed TOE. C ASE_INT.1.2E 592 The evaluator shall confirm that the TOE reference, the TOE overview, and the TOE description are consistent with each other. :ASE_INT.1-11 The evaluator shall examine the TOE reference, TOE overview and TOE description to determine that they are consistent with each other. ASE_CCL.1 Conformance claims Dependencies satisfied by: ASE_INT.1 ST introduction ASE_ECD.1 Extended components definition Error! Reference source not found. Objectives 593 The objective of this sub-activity is to determine the validity of various conformance claims. These describe how the ST and the TOE conform to the CC and how the ST conforms to PPs and packages. Input 594 The evaluation evidence for this sub-activity is: the ST; the PP(s) that the ST claims conformance to; the package(s) that the ST claims conformance to. Developer action elements: C ASE_CCL.1.1D 595 The developer shall provide a conformance claim. C ASE_CCL.1.2D 596 The developer shall provide a conformance claim rationale CC version 3.1 Page 163 of 237

164 Content and presentation of evidence elements: C ASE_CCL.1.1C 597 The conformance claim shall contain a CC conformance claim that identifies the version of the CC to which the ST and the TOE claim conformance. C ASE_CCL.1.2C 598 The CC conformance claim shall describe the conformance of the ST to CC Part 2 as either CC Part 2 conformant or CC Part 2 extended. C ASE_CCL.1.3C 599 The CC conformance claim shall describe the conformance of the ST to CC Part 3 as either CC Part 3 conformant or CC Part 3 extended. C ASE_CCL.1.4C 600 The CC conformance claim shall be consistent with the extended components definition. C ASE_CCL.1.5C 601 The conformance claim shall identify all PPs and security requirement packages to which the ST claims conformance. C ASE_CCL.1.6C 602 The conformance claim shall describe any conformance of the ST to a package as either package-conformant or package-augmented. C ASE_CCL.1.7C 603 The conformance claim rationale shall demonstrate that the TOE type is consistent with the TOE type in the PPs for which conformance is being claimed. C ASE_CCL.1.8C 604 The conformance claim rationale shall demonstrate that the statement of the security problem definition is consistent with the statement of the security problem definition in the PPs for which conformance is being claimed. C ASE_CCL.1.9C 605 The conformance claim rationale shall demonstrate that the statement of security objectives is consistent with the statement of security objectives in the PPs for which conformance is being claimed. Page 164 of 237 CC version

165 C ASE_CCL.1.10C 606 The conformance claim rationale shall demonstrate that the statement of security requirements is consistent with the statement of security requirements in the PPs for which conformance is being claimed. Evaluator action elements: C ASE_CCL.1.1E 607 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ASE_CCL.1-1 ASE_CCL.1.1C The evaluator shall check that the conformance claim contains a CC conformance claim that identifies the version of the CC to which the ST and the TOE claim conformance. 608 The evaluator determines that the CC conformance claim identifies the version of the CC that was used to develop this ST. This should include the version number of the CC and, unless the International English version of the CC was used, the language of the version of the CC that was used. 609 For a composed TOE, the evaluator will consider any differences between the version of the CC claimed for a component and the version of the CC claimed for the composed TOE. If the versions differ the evaluator will assess whether the differences between the versions will lead to conflicting claims. 610 For instances where the CC conformance claims for the base TOE and dependent TOE are for different major releases of the CC (e.g. one component TOE conformance claim is CC v2.x and the other component TOE conformance claim is CC v3.x), the conformance claim for the composed TOE will be the earlier release of the CC, as the CC is developed with an aim to provide backwards compatibility (although this may not be achieved in the strictest sense, it is understood to be achieved in principle). :ASE_CCL.1-2 ASE_CCL.1.2C The evaluator shall check that the CC conformance claim states a claim of either CC Part 2 conformant or CC Part 2 extended for the ST. 611 For a composed TOE, the evaluator will consider whether this claim is consistent not only with the CC Part 2, but also with the claims of conformance to CC Part 2 by each of the component TOEs. I.e. if one or more component TOEs claims to be CC Part 2 extended, then the composed TOE should also claim to be CC Part 2 extended. 612 The CC conformance claim for the composed TOE may be CC Part 2 extended, even though the component TOEs are Part 2 conformant, in the event that additional SFRs are claimed for the base TOE (see composed TOE guidance for C ) :ASE_CCL.1-3 ASE_CCL.1.3C The evaluator shall check that the CC conformance claim states a claim of either CC Part 3 conformant or CC Part 3 extended for the ST CC version 3.1 Page 165 of 237

166 :ASE_CCL.1-4 ASE_CCL.1.4C The evaluator shall examine the CC conformance claim for CC Part 2 to determine that it is consistent with the extended components definition. 613 If the CC conformance claim contains CC Part 2 conformant, the evaluator determines that the extended components definition does not define functional components. 614 If the CC conformance claim contains CC Part 2 extended, the evaluator determines that the extended components definition defines at least one extended functional component. :ASE_CCL.1-5 ASE_CCL.1.4C The evaluator shall examine the CC conformance claim for CC Part 3 to determine that it is consistent with the extended components definition. 615 If the CC conformance claim contains CC Part 3 conformant, the evaluator determines that the extended components definition does not define assurance components. 616 If the CC conformance claim contains CC Part 3 extended, the evaluator determines that the extended components definition defines at least one extended assurance component. :ASE_CCL.1-6 ASE_CCL.1.5C The evaluator shall check that the conformance claim contains a PP claim that identifies all PPs for which the ST claims conformance. 617 If the ST does not claim conformance to a PP, this work unit is not applicable and therefore considered to be satisfied. 618 The evaluator determines that any referenced PPs are unambiguously identified (e.g. by title and version number, or by the identification included in the introduction of that PP). 619 The evaluator is reminded that claims of partial conformance to a PP are not permitted. Therefore, conformance to a PP requiring a composite solution may be claimed in an ST for a composed TOE. Conformance to such a PP would not have been possible during the evaluation of the component TOEs, as these components would not have satisfied the composed solution. This is only possible in the instances where the composite PP permits use of the composition evaluation approach (use of ACOcomponents). 620 The ST for a composed TOE will identify the STs of the component TOEs from which the composed ST is comprised. The composed TOE is essentially claiming conformance to the STs of the component TOEs. :ASE_CCL.1-7 ASE_CCL.1.5C The evaluator shall check that the conformance claim contains a package claim that identifies all packages to which the ST claims conformance. 621 If the ST does not claim conformance to a package, this work unit is not applicable and therefore considered to be satisfied. Page 166 of 237 CC version

167 622 The evaluator determines that any referenced packages are unambiguously identified (e.g. by title and version number, or by the identification included in the introduction of that package). 623 The evaluator determines that the component TOE STs from which the composed TOE is derived are also unambiguously identified. 624 The evaluator is reminded that claims of partial conformance to a package are not permitted. :ASE_CCL.1-8 ASE_CCL.1.6C The evaluator shall check that, for each identified package, the conformance claim states a claim of either package-name conformant or package-name augmented. 625 If the ST does not claim conformance to a package, this work unit is not applicable and therefore considered to be satisfied. 626 If the package conformance claim contains package-name conformant, the evaluator determines that: If the package is an assurance package, then the ST contains all SARs included in the package, but no additional SARs. If the package is a functional package, then the ST contains all SFRs included in the package, but no additional SFRs. 627 If the package conformance claim contains package-name augmented, the evaluator determines that: If the package is an assurance package then the ST contains all SARs included in the package, and at least one additional SAR or at least one SAR that is hierarchical to a SAR in the package. If the package is a functional package, then the ST contains all SFRs included in the package, and at least one additional SFR or at least one SFR that is hierarchical to a SFR in the package. :ASE_CCL.1-9 ASE_CCL.1.7C The evaluator shall examine the conformance claim rationale to determine that the TOE type of the TOE is consistent with all TOE types of the PPs. 628 If the ST does not claim conformance to a PP, this work unit is not applicable and therefore considered to be satisfied. 629 The relation between the types may be simple: a firewall ST claiming conformance to a firewall PP, or more complex: a smart card ST claiming conformance to a number of PPs at the same time (a PP for the integrated circuit, a PP for the smart card OS, and two PPs for two applications on the smart card). 630 For a composed TOE, the evaluator will determine whether the conformance claim rationale demonstrates that the TOE types of the component TOEs are CC version 3.1 Page 167 of 237

168 consistent with the composed TOE type. This does not mean that both the component and the composed TOE types have to be the same, but rather that the component TOEs are suitable for integration to provide the composed TOE. It should be made clear in the composed TOE ST which SFRs are only included as a result of composition, and were not examined as SFRs in the base and dependent TOE (e.g. EALx) evaluation. :ASE_CCL.1-10 ASE_CCL.1.8C The evaluator shall examine the conformance claim rationale to determine that it demonstrates that the statement of security problem definition is consistent, as defined by the conformance statement of the PP, with the statements of security problem definition stated in the PPs to which conformance is being claimed. 631 If the ST does not claim conformance with a PP, this work unit is not applicable and therefore considered to be satisfied. 632 If the PP does not have a statement of security problem definition, this work unit is not applicable and therefore considered to be satisfied. 633 If strict conformance is required by the PP to which conformance is being claimed no conformance claim rationale is required. Instead, the evaluator determines whether: the threats in the ST are a superset of or identical to the threats in the PP to which conformance is being claimed; the OSPs in the ST are a superset of or identical to the OSPs in the PP to which conformance is being claimed; the assumptions in the ST are identical to the assumptions in the PP to which conformance is being claimed, with two possible exceptions described in the following two bullet points; an assumption (or part of an assumption) from the PP can be omitted, if all security objectives for the operational environment addressing this assumption (or part of an assumption) are replaced by security objectives for the TOE; an assumption can be added to the assumptions defined in the PP, if a rationale is given, why the new assumption neither mitigates a threat (or a part of a threat) meant to be addressed by security objectives for the TOE in the PP, nor fulfils an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the PP. When examining an ST claiming a PP, which omits assumptions from the PP or adds new assumptions, the evaluator shall carefully determine, if the conditions given above are fulfilled. The following discussion gives some motivation and examples for these cases: Example for omitting an assumption: A PP may contain an assumption stating that the operational environment prevents Page 168 of 237 CC version

169 unauthorised modification or interception of data sent to an external interface of the TOE. This may be the case if the TOE accepts data in clear text and without integrity protection at this interface and is assumed to be located in a secure operational environment, which will prevent attackers from accessing these data. The assumption will then be mapped in the PP to some objective for the operational environment stating that the data interchanged at this interface are protected by adequate measures in the operational environment. If an ST claiming this PP defines a more secure TOE, which has an additional security objective stating that the TOE itself protects these data, for example by providing a secure channel for encryption and integrity protection of all data transferred via this interface, the corresponding objective and assumption for the operational environment can be omitted from the ST. This is also called re-assigning of the objective, since the objective is re-assigned from the operational environment to the TOE. Note, that this TOE is still secure in an operational environment fulfilling the omitted assumption and therefore still fulfils the PP. Example for adding an assumption: In this example the PP is designed to specify requirements for a TOE of type "Firewall" and an ST author wishes to claim this PP for a TOE, which implements a firewall, but additionally provides the functionality of a virtual private network (VPN) component. For the VPN functionality the TOE needs cryptographic keys and these keys may also have to be handled securely by the operational environment (e. g. if symmetric keys are used to secure the network connection and therefore need to be provided in some secure way to other components in the network). In this case it is acceptable to add an assumption that the cryptographic keys used by the VPN are handled securely by the operational environment. This assumption does not address threats or OSPs of the PP and therefore fulfils the conditions stated above. Counterexample for adding an assumption: In a variant of the first example a PP may already contain an objective for the TOE to provide a secure channel for one of its interfaces, and this objective is mapped to a threat of unauthorised modification or reading of the data on this interface. In this case it is clearly not allowed for an ST claiming this PP to add an assumption for the operational environment, which assumes that the operational environment protects data on this interface against modification or unauthorised reading of the data. This assumption would reduce a threat, which is meant to be addressed by the TOE. Therefore a TOE fulfilling an ST with this added assumption would not automatically fulfil the PP any more and this addition is therefore not allowed CC version 3.1 Page 169 of 237

170 Second counterexample for adding an assumption: In the example above of a TOE implementing a firewall it would not be admissible to add a general assumption that the TOE is only connected to trusted devices, because this would obviously remove essential threats relevant for a firewall (namely that there is untrusted IP traffic, which needs to be filtered). Therefore this addition would not be allowed. 634 If demonstrable conformance is required by the PP, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security problem definition of the ST is equivalent or more restrictive than the statement of security problem definition in the PP to which conformance is being claimed. 635 For this, the conformance claim rationale needs to demonstrate that the security problem definition in the ST is equivalent (or more restrictive) than the security problem definition in the PP. This means that: all TOEs that would meet the security problem definition in the ST also meet the security problem definition in the PP. This can also be shown indirectly by demonstrating that every event, which realises a threat defined in the PP or violates an OSP defined in the PP, would also realise a threat stated in the ST or violate an OSP defined in the ST. Note that fulfilling an OSP stated in the ST may avert a threat stated in the PP or that averting a threat stated in the ST may fulfil an OSP stated in the PP, so threats and OSPs can substitute each other; all operational environments that would meet the security problem definition in the PP would also meet the security problem definition in the ST (with one exception in the next bullet); besides a set of assumptions in the ST needed to demonstrate conformance to the SPD of the PP, an ST may specify further assumptions, but only if these additional assumptions are independent of and do not affect the security problem definition as defined in the PP. More detailed, there are no assumptions in the ST that exclude threats to the TOE that need to be countered by the TOE according to the PP. Similarly, there are no assumptions in the ST that realise aspects of an OSP stated in the PP, which are meant to be fulfilled by the TOE according to the PP." 636 For a composed TOE, the evaluator will consider whether the security problem definition of the composed TOE is consistent with that specified in the STs for the component TOEs. This is determined in terms of demonstrable conformance. In particular, the evaluator examines the conformance claim rationale to determine that: Threat statements and OSPs in the composed TOE ST do not contradict those from the component STs. Page 170 of 237 CC version

171 Any assumptions made in the component STs are upheld in the composed TOE ST. That is, either the assumption should also be present in the composed ST, or the assumption should be positively addressed in the composed ST. The assumption may be positively addressed through specification of requirements in the composed TOE to provide functionality fulfilling the concern captured in the assumption. :ASE_CCL.1-11 ASE_CCL.1.9C The evaluator shall examine the conformance claim rationale to determine that the statement of security objectives is consistent, as defined by the conformance statement of the PP, with the statement of security objectives in the PPs to which conformance is being claimed. 637 If the ST does not claim conformance to a PP, this work unit is not applicable and therefore considered to be satisfied. 638 If strict conformance is required by the PP to which conformance is being claimed, no conformance claim rationale is required. Instead, the evaluator determines whether: The ST contains all security objectives for the TOE of the PP to which conformance is being claimed. Note that it is allowed for the ST under evaluation to have additional security objectives for the TOE; The security objectives for the operational environment in the ST are identical to the security objectives for the operational environment in the PP to which conformance is being claimed, with two possible exceptions described in the following two bullet points; a security objective for the operational environment (or part of such security objective) from the PP can be replaced by the same (part of the) security objective stated for the TOE; a security objective for the operational environment can be added to the objectives defined in the PP, if a justification is given, why the new objective neither mitigates a threat (or a part of a threat) meant to be addressed by security objectives for the TOE in the PP, nor fulfils an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the PP. When examining an ST claiming a PP, which omits security objectives for the operational environment from the PP or adds new security objectives for the operational environment, the evaluator shall carefully determine, if the conditions given above are fulfilled. The examples given for the case of assumptions in the preceding work unit are also valid here. 639 If demonstrable conformance is required by the PP to which conformance is being claimed, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security objectives of the CC version 3.1 Page 171 of 237

172 ST is equivalent or more restrictive than the statement of security objectives in the PP to which conformance is being claimed. 640 For this the conformance claim rationale needs to demonstrate that the security objectives in the ST are equivalent (or more restrictive) than the security objectives in the PP. This means that: all TOEs that would meet the security objectives for the TOE in the ST also meet the security objectives for the TOE in the PP; all operational environments that would meet the security objectives for the operational environment in the PP would also meet the security objectives for the operational environment in the ST (with one exception in the next bullet); besides a set of security objectives for the operational environment in the ST, which are used to demonstrate conformance to the set of security objectives defined in the PP, an ST may specify further security objectives for the operational environment, but only if these security objectives neither affect the original set of security objectives for the TOE nor the security objectives for the operational environment as defined in the PP to which conformance is claimed." 641 For a composed TOE, the evaluator will consider whether the security objectives of the composed TOE are consistent with that specified in the STs for the component TOEs. This is determined in terms of demonstrable conformance. In particular, the evaluator examines the conformance claim rationale to determine that: The statement of security objectives in the dependent TOE ST relevant to any IT in the operational environment are consistent with the statement of security objectives for the TOE in the base TOE ST. It is not expected that the statement of security objectives for the environment within in the dependent TOE ST will cover all aspects of the statement of security objectives for the TOE in the base TOE ST. The statement of security objectives in the composed ST is consistent with the statements of security objectives in the STs for the component TOEs. 642 If demonstrable conformance is required by the PP, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security objectives of the ST is at least equivalent to the statement of security objectives in the PP, or component TOE ST in the case of a composed TOE ST. :ASE_CCL.1-12 ASE_CCL.1.10C The evaluator shall examine the ST to determine that it is consistent, as defined by the conformance statement of the PP, with all security requirements in the PPs for which conformance is being claimed. Page 172 of 237 CC version

173 643 If the ST does not claim conformance to a PP, this work unit is not applicable and therefore considered to be satisfied. 644 If strict conformance is required by the PP to which conformance is being claimed, no conformance claim rationale is required. Instead, the evaluator determines whether the statement of security requirements in the ST is a superset of or identical to the statement of security requirements in the PP to which conformance is being claimed (for strict conformance). 645 If demonstrable conformance is required by the PP to which conformance is being claimed, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security requirements of the ST is equivalent or more restrictive than the statement of security requirements in the PP to which conformance is being claimed. 646 For: SFRs: The conformance rationale in the ST shall demonstrate that the overall set of requirements defined by the SFRs in the ST is equivalent (or more restrictive) than the overall set of requirements defined by the SFRs in the PP. This means that all TOEs that would meet the requirements defined by the set of all SFRs in the ST would also meet the requirements defined by the set of all SFRs in the PP; SARs: The ST shall contain all SARs in the PP, but may claim additional SARs or replace SARs by hierarchically stronger SARs. The completion of operations in the ST must be consistent with that in the PP; either the same completion will be used in the ST as that in the PP or a completion that makes the SAR more restrictive (the rules of refinement apply). 647 For a composed TOE, the evaluator will consider whether the security requirements of the composed TOE are consistent with that specified in the STs for the component TOEs. This is determined in terms of demonstrable conformance. In particular, the evaluator examines the conformance rationale to determine that: The statement of security requirements in the dependent TOE ST relevant to any IT in the operational environment is consistent with the statement of security requirements for the TOE in the base TOE ST. It is not expected that the statement of security requirements for the environment within in the dependent TOE ST will cover all aspects of the statement of security requirements for the TOE in the base TOE ST, as some SFRs may need to be added to the statement of security requirements in the composed TOE ST. However, the statement of security requirements in the base should support the operation of the dependent component. The statement of security objectives in the dependent TOE ST relevant to any IT in the operational environment is consistent with the statement of security requirements for the TOE in the base TOE CC version 3.1 Page 173 of 237

174 ST. It is not expected that the statement of security objectives for the environment within in the dependent TOE ST will cover all aspects of the statement of security requirements for the TOE in the base TOE ST. The statement of security requirements in the composed is consistent with the statements of security requirements in the STs for the component TOEs. 648 If demonstrable conformance is required by the PP to which conformance is being claimed, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security requirements of the ST is at least equivalent to the statement of security requirements in the PP, or component TOE ST in the case of a composed TOE ST. ASE_SPD.1 Security problem definition Objectives 649 The objective of this sub-activity is to determine that the security problem intended to be addressed by the TOE and its operational environment is clearly defined. Input 650 The evaluation evidence for this sub-activity is: the ST. Dependencies satisfied by: No dependencies. Developer action elements: C ASE_APD.1.1D 651 The developer shall provide a security problem definition. Content and presentation of evidence elements: C ASE_SPD.1.1C 652 The security problem definition shall describe the threats. C ASE_SPD.1.2C 653 All threats shall be described in terms of a threat agent, an asset, and an adverse action. C ASE_SPD.1.3C 654 The security problem definition shall describe the OSPs. Page 174 of 237 CC version

175 C ASE_SPD.1.4C 655 The security problem definition shall describe the assumptions about the operational environment of the TOE. Evaluator action elements: C ASE_SPD.1.1E 656 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ASE_SPD.1-1 ASE_SPD.1.1C The evaluator shall check that the security problem definition describes the threats. 657 If all security objectives are derived from assumptions and/or OSPs only, the statement of threats need not be present in the ST. In this case, this work unit is not applicable and therefore considered to be satisfied. 658 The evaluator determines that the security problem definition describes the threats that must be countered by the TOE and/or operational environment. :ASE_SPD.1-2 ASE_SPD.1.2C The evaluator shall examine the security problem definition to determine that all threats are described in terms of a threat agent, an asset, and an adverse action. 659 If all security objectives are derived from assumptions and/or OSPs only, the statement of threats need not be present in the ST. In this case, this work unit is not applicable and therefore considered to be satisfied. 660 Threat agents may be further described by aspects such as expertise, resource, opportunity, and motivation. :ASE_SPD.1-3 ASE_SPD.1.3C The evaluator shall examine that the security problem definition describes the OSPs. 661 If all security objectives are derived from assumptions and threats only, OSPs need not be present in the ST. In this case, this work unit is not applicable and therefore considered to be satisfied. 662 The evaluator determines that OSP statements are made in terms of rules or guidelines that must be followed by the TOE and/or its operational environment. 663 The evaluator determines that each OSP is explained and/or interpreted in sufficient detail to make it clearly understandable; a clear presentation of policy statements is necessary to permit tracing security objectives to them. :ASE_SPD.1-4 ASE_SPD.1.4C The evaluator shall examine the security problem definition to determine that it describes the assumptions about the operational environment of the TOE CC version 3.1 Page 175 of 237

176 664 If there are no assumptions, this work unit is not applicable and is therefore considered to be satisfied. 665 The evaluator determines that each assumption about the operational environment of the TOE is explained in sufficient detail to enable consumers to determine that their operational environment matches the assumption. If the assumptions are not clearly understood, the end result may be that the TOE is used in an operational environment in which it will not function in a secure manner. ASE_OBJ.2 Security objectives Dependencies satisfied by: ASE_SPD.1 Security problem definition Objectives 666 The objective of this sub-activity is to determine whether the security objectives adequately and completely address the security problem definition and that the division of this problem between the TOE and its operational environment is clearly defined. Input 667 The evaluation evidence for this sub-activity is: the ST. Developer action elements: C ASE_OBJ.2.1D 668 The developer shall provide a statement of security objectives. C ASE_OBJ.2.2D 669 The developer shall provide a security objectives rationale. Content and presentation of evidence elements: C ASE_OBJ.2.1C 670 The statement of security objectives shall describe the security objectives for the TOE and the security objectives for the operational environment. C ASE_OBJ.2.2C 671 The security objectives rationale shall trace each security objective for the TOE back to threats countered by that security objective and OSPs enforced by that security objective. Page 176 of 237 CC version

177 C ASE_OBJ.2.3C 672 The security objectives rationale shall trace each security objective for the operational environment back to threats countered by that security objective, OSPs enforced by that security objective, and assumptions upheld by that security objective. C ASE_OBJ.2.4C 673 The security objectives rationale shall demonstrate that the security objectives counter all threats. C ASE_OBJ.2.5C 674 The security objectives rationale shall demonstrate that the security objectives enforce all OSPs. C ASE_OBJ.2.6C 675 The security objectives rationale shall demonstrate that the security objectives for the operational environment uphold all assumptions. Evaluator action elements: C ASE_OBJ.2.1E 676 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ASE_OBJ.2-1 ASE_OBJ.2.1C The evaluator shall check that the statement of security objectives defines the security objectives for the TOE and the security objectives for the operational environment. 677 The evaluator checks that both categories of security objectives are clearly identified and separated from the other category. :ASE_OBJ.2-2 ASE_OBJ.2.2C The evaluator shall check that the security objectives rationale traces all security objectives for the TOE back to threats countered by the objectives and/or OSPs enforced by the objectives. 678 Each security objective for the TOE may trace back to threats or OSPs, or a combination of threats and OSPs, but it must trace back to at least one threat or OSP. 679 Failure to trace implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the TOE has no useful purpose. :ASE_OBJ.2-3 ASE_OBJ.2.3C The evaluator shall check that the security objectives rationale traces the security objectives for the operational environment back to threats countered by that security objective, to OSPs enforced by that security objective, and to assumptions upheld by that security objective CC version 3.1 Page 177 of 237

178 680 Each security objective for the operational environment may trace back to threats, OSPs, assumptions, or a combination of threats, OSPs and/or assumptions, but it must trace back to at least one threat, OSP or assumption. 681 Failure to trace implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the operational environment has no useful purpose. :ASE_OBJ.2-4 ASE_OBJ.2.4C The evaluator shall examine the security objectives rationale to determine that it justifies for each threat that the security objectives are suitable to counter that threat. 682 If no security objectives trace back to the threat, the evaluator action related to this work unit is assigned a fail verdict. 683 The evaluator determines that the justification for a threat shows whether the threat is removed, diminished or mitigated. 684 The evaluator determines that the justification for a threat demonstrates that the security objectives are sufficient: if all security objectives that trace back to the threat are achieved, the threat is removed, sufficiently diminished, or the effects of the threat are sufficiently mitigated. 685 Note that the tracings from security objectives to threats provided in the security objectives rationale may be part of a justification, but do not constitute a justification by themselves. Even in the case that a security objective is merely a statement reflecting the intent to prevent a particular threat from being realised, a justification is required, but this justification may be as minimal as Security Objective X directly counters Threat Y. 686 The evaluator also determines that each security objective that traces back to a threat is necessary: when the security objective is achieved it actually contributes to the removal, diminishing or mitigation of that threat. :ASE_OBJ.2-5 ASE_OBJ.2.5C The evaluator shall examine the security objectives rationale to determine that for each OSP it justifies that the security objectives are suitable to enforce that OSP. 687 If no security objectives trace back to the OSP, the evaluator action related to this work unit is assigned a fail verdict. 688 The evaluator determines that the justification for an OSP demonstrates that the security objectives are sufficient: if all security objectives that trace back to that OSP are achieved, the OSP is enforced. 689 The evaluator also determines that each security objective that traces back to an OSP is necessary: when the security objective is achieved it actually contributes to the enforcement of the OSP. 690 Note that the tracings from security objectives to OSPs provided in the security objectives rationale may be part of a justification, but do not constitute a justification by themselves. In the case that a security objective is Page 178 of 237 CC version

179 merely a statement reflecting the intent to enforce a particular OSP, a justification is required, but this justification may be as minimal as Security Objective X directly enforces OSP Y. :ASE_OBJ.2-6 ASE_OBJ.2.6C The evaluator shall examine the security objectives rationale to determine that for each assumption for the operational environment it contains an appropriate justification that the security objectives for the operational environment are suitable to uphold that assumption. 691 If no security objectives for the operational environment trace back to the assumption, the evaluator action related to this work unit is assigned a fail verdict. 692 The evaluator determines that the justification for an assumption about the operational environment of the TOE demonstrates that the security objectives are sufficient: if all security objectives for the operational environment that trace back to that assumption are achieved, the operational environment upholds the assumption. 693 The evaluator also determines that each security objective for the operational environment that traces back to an assumption about the operational environment of the TOE is necessary: when the security objective is achieved it actually contributes to the operational environment upholding the assumption. 694 Note that the tracings from security objectives for the operational environment to assumptions provided in the security objectives rationale may be a part of a justification, but do not constitute a justification by themselves. Even in the case that a security objective of the operational environment is merely a restatement of an assumption, a justification is required, but this justification may be as minimal as Security Objective X directly upholds Assumption Y. ASE_ECD.1 Extended components definition Objectives 695 The objective of this sub-activity is to determine whether extended components have been clearly and unambiguously defined, and whether they are necessary, i.e. they may not be clearly expressed using existing CC Part 2 or CC Part 3 components. Input 696 The evaluation evidence for this sub-activity is: the ST CC version 3.1 Page 179 of 237

180 Dependencies satisfied by: No dependencies. Developer action elements: C ASE_ECD.1.1D 697 The developer shall provide a statement of security requirements. C ASE_ECD.1.2D 698 The developer shall provide an extended components definition. Content and presentation of evidence elements: C ASE_ECD.1.1C 699 The statement of security requirements shall identify all extended security requirements. C ASE_ECD.1.2C 700 The extended components definition shall define an extended component for each extended security requirement. C ASE_ECD.1.3C 701 The extended components definition shall describe how each extended component is related to the existing CC components, families, and classes. C ASE_ECD.1.4C 702 The extended components definition shall use the existing CC components, families, classes, and methodology as a model for presentation. C ASE_ECD.1.5C 703 The extended components shall consist of measurable and objective elements such that conformance or nonconformance to these elements can be demonstrated. Evaluator action elements: C ASE_ECD.1.1E 704 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ASE_ECD.1-1 ASE_ECD.1.1C The evaluator shall check that all security requirements in the statement of security requirements that are not identified as extended requirements are present in CC Part 2 or in CC Part 3. Page 180 of 237 CC version

181 :ASE_ECD.1-2 ASE_ECD.1.2C The evaluator shall check that the extended components definition defines an extended component for each extended security requirement. 705 If the ST does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. 706 A single extended component may be used to define multiple iterations of an extended security requirement, it is not necessary to repeat this definition for each iteration. :ASE_ECD.1-3 ASE_ECD.1.3C The evaluator shall examine the extended components definition to determine that it describes how each extended component fits into the existing CC components, families, and classes. 707 If the ST does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. 708 The evaluator determines that each extended component is either: a member of an existing CC Part 2 or CC Part 3 family, or a member of a new family defined in the ST. 709 If the extended component is a member of an existing CC Part 2 or CC Part 3 family, the evaluator determines that the extended components definition adequately describes why the extended component should be a member of that family and how it relates to other components of that family. 710 If the extended component is a member of a new family defined in the ST, the evaluator confirms that the extended component is not appropriate for an existing family. 711 If the ST defines new families, the evaluator determines that each new family is either: a member of an existing CC Part 2 or CC Part 3 class, or a member of a new class defined in the ST. 712 If the family is a member of an existing CC Part 2 or CC Part 3 class, the evaluator determines that the extended components definition adequately describes why the family should be a member of that class and how it relates to other families in that class. 713 If the family is a member of a new class defined in the ST, the evaluator confirms that the family is not appropriate for an existing class. :ASE_ECD.1-4 ASE_ECD.1.3C The evaluator shall examine the extended components definition to determine that each definition of an extended component identifies all applicable dependencies of that component CC version 3.1 Page 181 of 237

182 714 If the ST does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. 715 The evaluator confirms that no applicable dependencies have been overlooked by the ST author. :ASE_ECD.1-5 ASE_ECD.1.4C The evaluator shall examine the extended components definition to determine that each extended functional component uses the existing CC Part 2 components as a model for presentation. 716 If the ST does not contain extended SFRs, this work unit is not applicable and therefore considered to be satisfied. 717 The evaluator determines that the extended functional component is consistent with CC Part 2 Subclause Error! Reference source not found If the extended functional component uses operations, the evaluator determines that the extended functional component is consistent with CC Part 1 Subclause Error! Reference source not found If the extended functional component is hierarchical to an existing functional component, the evaluator determines that the extended functional component is consistent with CC Part 2 Subclause Error! Reference source not found.. :ASE_ECD.1-6 ASE_ECD.1.4C The evaluator shall examine the extended components definition to determine that each definition of a new functional family uses the existing CC functional families as a model for presentation. 720 If the ST does not define new functional families, this work unit is not applicable and therefore considered to be satisfied. 721 The evaluator determines that all new functional families are defined consistent with CC Part 2 Subclause Error! Reference source not found.. :ASE_ECD.1-7 ASE_ECD.1.4C The evaluator shall examine the extended components definition to determine that each definition of a new functional class uses the existing CC functional classes as a model for presentation. 722 If the ST does not define new functional classes, this work unit is not applicable and therefore considered to be satisfied. 723 The evaluator determines that all new functional classes are defined consistent with CC Part 2 Subclause Error! Reference source not found.. :ASE_ECD.1-8 ASE_ECD.1.4C The evaluator shall examine the extended components definition to determine that each definition of an extended assurance component uses the existing CC Part 3 components as a model for presentation. 724 If the ST does not contain extended SARs, this work unit is not applicable and therefore considered to be satisfied. Page 182 of 237 CC version

183 725 The evaluator determines that the extended assurance component definition is consistent with CC Part 3 Subclause Error! Reference source not found If the extended assurance component uses operations, the evaluator determines that the extended assurance component is consistent with CC Part 1 Subclause Error! Reference source not found If the extended assurance component is hierarchical to an existing assurance component, the evaluator determines that the extended assurance component is consistent with CC Part 3 Subclause Error! Reference source not found.. :ASE_ECD.1-9 ASE_ECD.1.4C The evaluator shall examine the extended components definition to determine that, for each defined extended assurance component, applicable methodology has been provided. 728 If the ST does not contain extended SARs, this work unit is not applicable and therefore considered to be satisfied. 729 The evaluator determines that, for each evaluator action element of each extended SAR, one or more work units are provided and that successfully performing all work units for a given evaluator action element will demonstrate that the element has been achieved. :ASE_ECD.1-10 ASE_ECD.1.4C The evaluator shall examine the extended components definition to determine that each definition of a new assurance family uses the existing CC assurance families as a model for presentation. 730 If the ST does not define new assurance families, this work unit is not applicable and therefore considered to be satisfied. 731 The evaluator determines that all new assurance families are defined consistent with CC Part 3 Subclause Error! Reference source not found.. :ASE_ECD.1-11 ASE_ECD.1.4C The evaluator shall examine the extended components definition to determine that each definition of a new assurance class uses the existing CC assurance classes as a model for presentation. 732 If the ST does not define new assurance classes, this work unit is not applicable and therefore considered to be satisfied. 733 The evaluator determines that all new assurance classes are defined consistent with CC Part 3 Subclause Error! Reference source not found.. :ASE_ECD.1-12 ASE_ECD.1.5C The evaluator shall examine the extended components definition to determine that each element in each extended component is measurable and states objective evaluation requirements, such that conformance or nonconformance can be demonstrated. 734 If the ST does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied CC version 3.1 Page 183 of 237

184 735 The evaluator determines that elements of extended functional components are stated in such a way that they are testable, and traceable through the appropriate TSF representations. 736 The evaluator also determines that elements of extended assurance components avoid the need for subjective evaluator judgement. 737 The evaluator is reminded that whilst being measurable and objective is appropriate for all evaluation criteria, it is acknowledged that no formal method exists to prove such properties. Therefore the existing CC functional and assurance components are to be used as a model for determining what constitutes conformance with this requirement. C ASE_ECD.1.2E 738 The evaluator shall confirm that no extended component can be clearly expressed using existing components. :ASE_ECD.1-13 The evaluator shall examine the extended components definition to determine that each extended component can not be clearly expressed using existing components. 739 If the ST does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. 740 The evaluator should take components from CC Part 2 and CC Part 3, other extended components that have been defined in the ST, combinations of these components, and possible operations on these components into account when making this determination. 741 The evaluator is reminded that the role of this work unit is to preclude unnecessary duplication of components, that is, components that may be clearly expressed by using other components. The evaluator should not undertake an exhaustive search of all possible combinations of components including operations in an attempt to find a way to express the extended component by using existing components. ASE_REQ.2 Derived security requirements Dependencies satisfied by: ASE_OBJ.2 Security objectives ASE_ECD.1 Extended components definition Objectives 742 The objective of this sub-activity is to determine whether the SFRs and SARs are clear, unambiguous and well-defined, whether they are internally consistent, and whether the SFRs meet the security objectives of the TOE. Page 184 of 237 CC version

185 Input 743 The evaluation evidence for this sub-activity is: the ST. Developer action elements: C ASE_REQ.2.1D 744 The developer shall provide a statement of security requirements. C ASE_REQ.2.2D 745 The developer shall provide a security requirements rationale. Content and presentation of evidence elements: C ASE_REQ.2.1C 746 The statement of security requirements shall describe the SFRs and the SARs. C ASE_REQ.2.2C 747 All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs shall be defined. C ASE_REQ.2.3C 748 The statement of security requirements shall identify all operations on the security requirements. C ASE_REQ.2.4C 749 All operations shall be performed correctly. C ASE_REQ.2.5C 750 Each dependency of the security requirements shall either be satisfied, or the security requirements rationale shall justify the dependency not being satisfied. C ASE_REQ.2.6C 751 The security requirements rationale shall trace each SFR back to the security objectives for the TOE. C ASE_REQ.2.7C 752 The security requirements rationale shall demonstrate that the SFRs meet all security objectives for the TOE CC version 3.1 Page 185 of 237

186 C ASE_REQ.2.8C 753 The security requirements rationale shall explain why the SARs were chosen. C ASE_REQ.2.9C 754 The statement of security requirements shall be internally consistent. Evaluator action elements: C ASE_REQ.2.1E 755 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ASE_REQ.2-1 ASE_REQ.2.1C The evaluator shall check that the statement of security requirements describes the SFRs. 756 The evaluator determines that each SFRs is identified by one of the following means: by reference to an individual component in CC Part 2; by reference to an extended component in the extended components definition of the ST; by reference to an individual component in a PP that the ST claims to be conformant with; by reference to an individual component in a security requirements package that the ST claims to be conformant with; by reproduction in the ST. 757 It is not required to use the same means of identification for all SFRs. :ASE_REQ.2-2 ASE_REQ.2.1C The evaluator shall check that the statement of security requirements describes the SARs. 758 The evaluator determines that all SARs are identified by one of the following means: by reference to an individual component in CC Part 3; by reference to an extended component in the extended components definition of the ST; by reference to an individual component in a PP that the ST claims to be conformant with; by reference to an individual component in a security requirements package that the ST claims to be conformant with; Page 186 of 237 CC version

187 by reproduction in the ST. 759 It is not required to use the same means of identification for all SARs. :ASE_REQ.2-3 ASE_REQ.2.2C The evaluator shall examine the ST to determine that all subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs are defined. 760 The evaluator determines that the ST defines all: (types of) subjects and objects that are used in the SFRs; (types of) security attributes of subjects, users, objects, information, sessions and/or resources, possible values that these attributes may take and any relations between these values (e.g. top_secret is higher than secret); (types of) operations that are used in the SFRs, including the effects of these operations; (types of) external entities in the SFRs; other terms that are introduced in the SFRs and/or SARs by completing operations, if these terms are not immediately clear, or are used outside their dictionary definition. 761 The goal of this work unit is to ensure that the SFRs and SARs are welldefined and that no misunderstanding may occur due to the introduction of vague terms. This work unit should not be taken into extremes, by forcing the ST writer to define every single word. The general audience of a set of security requirements should be assumed to have a reasonable knowledge of IT, security and Common Criteria. 762 All of the above may be presented in groups, classes, roles, types or other groupings or characterisations that allow easy understanding. 763 The evaluator is reminded that these lists and definitions do not have to be part of the statement of security requirements, but may be placed (in part or in whole) in different subclauses. This may be especially applicable if the same terms are used in the rest of the ST. :ASE_REQ.2-4 ASE_REQ.2.3C The evaluator shall check that the statement of security requirements identifies all operations on the security requirements. 764 The evaluator determines that all operations are identified in each SFR or SAR where such an operation is used. Identification may be achieved by typographical distinctions, or by explicit identification in the surrounding text, or by any other distinctive means. :ASE_REQ.2-5 ASE_REQ.2.4C The evaluator shall examine the statement of security requirements to determine that all assignment operations are performed correctly CC version 3.1 Page 187 of 237

188 765 Guidance on the correct performance of operations may be found in CC Part 1 Annex Error! Reference source not found.. :ASE_REQ.2-6 ASE_REQ.2.4C The evaluator shall examine the statement of security requirements to determine that all iteration operations are performed correctly. 766 Guidance on the correct performance of operations may be found in CC Part 1 Annex Error! Reference source not found.. :ASE_REQ.2-7 ASE_REQ.2.4C The evaluator shall examine the statement of security requirements to determine that all selection operations are performed correctly. 767 Guidance on the correct performance of operations may be found in CC Part 1 Annex Error! Reference source not found.. :ASE_REQ.2-8 ASE_REQ.2.4C The evaluator shall examine the statement of security requirements to determine that all refinement operations are performed correctly. 768 Guidance on the correct performance of operations may be found in CC Part 1 Annex Error! Reference source not found.. :ASE_REQ.2-9 ASE_REQ.2.5C The evaluator shall examine the statement of security requirements to determine that each dependency of the security requirements is either satisfied, or that the security requirements rationale justifies the dependency not being satisfied. 769 A dependency is satisfied by the inclusion of the relevant component (or one that is hierarchical to it) within the statement of security requirements. The component used to satisfy the dependency should, if necessary, be modified by operations to ensure that it actually satisfies that dependency. 770 A justification that a dependency is not met should address either: why the dependency is not necessary or useful, in which case no further information is required; or that the dependency has been addressed by the operational environment of the TOE, in which case the justification should describe how the security objectives for the operational environment address this dependency. :ASE_REQ.2-10 ASE_REQ.2.6C The evaluator shall check that the security requirements rationale traces each SFR back to the security objectives for the TOE. 771 The evaluator determines that each SFR is traced back to at least one security objective for the TOE. Page 188 of 237 CC version

189 772 Failure to trace implies that either the security requirements rationale is incomplete, the security objectives for the TOE are incomplete, or the SFR has no useful purpose. :ASE_REQ.2-11 ASE_REQ.2.7C The evaluator shall examine the security requirements rationale to determine that for each security objective for the TOE it demonstrates that the SFRs are suitable to meet that security objective for the TOE. 773 If no SFRs trace back to the security objective for the TOE, the evaluator action related to this work unit is assigned a fail verdict. 774 The evaluator determines that the justification for a security objective for the TOE demonstrates that the SFRs are sufficient: if all SFRs that trace back to the objective are satisfied, the security objective for the TOE is achieved. 775 The evaluator also determines that each SFR that traces back to a security objective for the TOE is necessary: when the SFR is satisfied, it actually contributes to achieving the security objective. 776 Note that the tracings from SFRs to security objectives for the TOE provided in the security requirements rationale may be a part of the justification, but do not constitute a justification by themselves. :ASE_REQ.2-12 ASE_REQ.2.8C The evaluator shall check that the security requirements rationale explains why the SARs were chosen. 777 The evaluator is reminded that any explanation is correct, as long as it is coherent and neither the SARs nor the explanation have obvious inconsistencies with the remainder of the ST. 778 An example of an obvious inconsistency between the SARs and the remainder of the ST would be to have threat agents that are very capable, but an AVA_VANSAR that does not protect against these threat agents. :ASE_REQ.2-13 ASE_REQ.2.9C The evaluator shall examine the statement of security requirements to determine that it is internally consistent. 779 The evaluator determines that the combined set of all SFRs and SARs is internally consistent. 780 The evaluator determines that on all occasions where different security requirements apply to the same types of developer evidence, events, operations, data, tests to be performed etc. or to all objects, all subjects etc., that these requirements do not conflict. 781 Some possible conflicts are: an extended SAR specifying that the design of a certain cryptographic algorithm is to be kept secret, and another extended assurance requirement specifying an open source review; CC version 3.1 Page 189 of 237

190 FAU_GEN.1 Audit data generationspecifying that subject identity is to be logged, FDP_ACC.1 Subset access controlspecifying who has access to these logs, and Error! Reference source not found.specifying that some actions of subjects should be unobservable to other subjects. If the subject that should not be able to see an activity may access logs of this activity, these SFRs conflict; Error! Reference source not found.specifying deletion of information no longer needed, and Error! Reference source not found.specifying that a TOE may return to a previous state. If the information that is needed for the rollback to the previous state has been deleted, these requirements conflict; Multiple iterations of FDP_ACC.1 Subset access controlespecially where some iterations cover the same subjects, objects, or operations. If one access control SFR allows a subject to perform an operation on an object, while another access control SFR does not allow this, these requirements conflict. ASE_TSS.1 TOE summary specification Dependencies satisfied by: ASE_INT.1 ST introduction Error! Reference source not found. ADV_FSP.1 Basic functional specification Objectives 782 The objective of this sub-activity is to determine whether the TOE summary specification addresses all SFRs, and whether the TOE summary specification is consistent with other narrative descriptions of the TOE. Objectives 783 Operating Systems often have extensive auditing capabilities where not all events recorded are security related. It is therefore necessary to identify the event types and related audit records the operating system is capable to record that map to the generic event types defined in FAU_GEN.1 in the Protection Profile. This is usually one or more record types in the audit trail(s) maintained by the operating system. It is the task of the evaluator to confirm that the operating system is capable to correctly generate the audit records and that the audit records contain the information required by FAU_GEN.1. Input 784 The evaluation evidence for this sub-activity is: the ST. Page 190 of 237 CC version

191 Developer action elements: C ASE_TSS.1.1D 785 The developer shall provide a TOE summary specification. Content and presentation of evidence elements: C ASE_TSS.1.1C 786 The TOE summary specification shall describe how the TOE meets each SFR. C FAU_GEN_1_ASE_TSS The TOE Summary Specification shall briefly describe the principle how the operating system generates audit records and name the audit mechanism used to generate the audit records required by FAU_GEN.1. Often this is a single system component and in this case it is just required to name the component and define where the component stores the audit records and how they are protected. The TSS should point to the developer documentation that defines the audit record format, either as they are stored or as they can be extracted (in the case they can only be extracted by a specific function of the TSF). It is important to describe how an administrative user (and the evaluator) can extract the audit records for further processing and analysis. The description in the TSS can be quite generic when it contains sufficient pointers to the developer documentation allowing the evaluator to generate test cases that analyze the audit records in the trail. C FAU_GEN_2_ASE_TSS The TSS shall identify and describe the possible ways where an audit record is created by a subject that at the time of the creation of the audit record is not bound to the user that caused the related event. The TSS shall explain how the identity of the user that caused the event is associated with the audit record for the event also in those cases. If the identity of that user is not part of the audit record, the TSS shall describe how someone evaluating the audit records can easily and unambiguously establish the association between the audit record and the user that caused the event recorded in the audit record. C FAU_SAR_1_ASE_TSS The TSS shall describe when a user is allowed to read the audit data. The TSS or documentation pointed to by the TSS need to describe the interface(s) that can be used to read the audit data and the format of the audit records when read using those interfaces. In the case a regular file interface is used to read the audit data where the file access control functionality is used to restrict the users able to read the audit data, the format of the audit data in the file needs to be described to the extent that it is possible to correctly identify and interpret the information in the audit record CC version 3.1 Page 191 of 237

192 C FAU_DEL_1_ASE_TSS The TSS needs to explain how the set of events that are actually audited can be limited in compliance with the criteria defined in FAU_SEL.1. The also TSS needs to describe how the management of this set of auditable events, pointing to the interface(s) used for this management. C FAU_STG_1_ASE_TSS The TSS shall describe how the audit records are protected from unauthorized deletion. C FAU_STG_3_ASE_TSS FAU_STG.3.1 requires the author of an ST to list in the TSS the conditions of potential loss of audit data the TSF is able to detect and describe the reaction of the TSF when such a condition is detected. C FAU_STG_4_ASE_TSS FAU_STG.4.1 is specific for the condition that the audit trail reaches its storage limits. The TSS needs to specify the actions the TSF take when the audit trail is full, explain which audit records may get lost and which options an authorized administrator has to configure the actions taken by the TSF when the audit trail is full. C FAU_FDP_1_ASE_TSS The TOE Summary Specification (or public documentation pointed to by the TSS) shall briefly describe the mechanisms the TOE uses to implement the access control policies and the security attributes used in the policy. For example if the TOE uses a combination of permission bits and access control lists the TOE Summary Specification needs to explain this and needs to explain how they are managed. This applies also to any other security attribute mentioned in the access control policies. Concerning the management of those security attributes, the TOE Summary Specification needs to provide information about: How each security attribute is initialized, resp. what the default value of the security attribute is How the value of the security attribute can be modified (if at all) and what the rules are the TOE uses to determine if the modification is allowed In addition the TOE Summary Specification (or public documentation pointed to by the TSS) needs to describe: The conditions that need to be satisfied when a user/subject requests to create a new object (for all objects mentioned in one of the access control policies), Page 192 of 237 CC version

193 The rules that determine the default access rights assigned when a new object is created (for all objects mentioned in one of the access control policies), The conditions that need to be satisfied when a user/subject requests to delete an object (for all objects mentioned in one of the access control policies) C FAU_IFF_1_ASE_TSS The TSS (or public documentation pointed to by the TSS) needs to describe the type of filtering rules for network traffic the TOE implements with: The network protocol(s) for which the rules apply The network protocol data the filtering rules can be based upon The criteria that can be defines for the rule to fire The possible action(s) taken when the rule fires The TSS (or public documentation pointed to by the TSS) also needs to describe the management interface used to define and/or activate the filtering rules C FAU_RIP_2_ASE_TSS The TSS (or public documentation pointed to by the TSS) needs to identify the resources that may be subject to residuals and briefly describe for each of those resources the strategy implemented by the TOE to make information stored by a subject or user unavailable before the resource is made accessible to another user or subject. If the TOE needs specific initialization and/or configuration steps to enforce object re-use for all resources, this and the steps required need to be identified in the TSS (with pointers to additional public documentation were necessary). C FAU_UAU_1_HU_ASE_TSS If the TOE implements a protocol used for remote authentication of users that provides a super-set of RFC-specified functionalityor if the protocol is not specified in an RFC or other published documentthe TSS describes the portions of the protocol that are implemented that occur prior to the user being authenticated. For each action listed in the assignment that is allowed before a user logs on locally to the TOE, the TSS shall describe the functionality being provided by the TOE. C FAU_UAU_7_ASE_TSS For each authentication method where the TOE is in control of the feedback provided to the user, the TSS indicates that the feedback provided is CC version 3.1 Page 193 of 237

194 obscured, and how it is obscured (not provided, masked, etc.). Each authentication method must be explicitly covered, and include not only login methods, but methods that require re-authentication such as changing a password, for example. C FAU_USB_1_ASE_TSS The evaluator will find the user security attributes associated with each subject enumerated in the TSS. The list of user security attributes may differ from those identified in FIA_USB.1 and also serve to extend the minimum set in the context of additional user security attributes assigned in FIA_USB.1. When the list of user security attributes identified in the TSS differs from those in FIA_USB.1, the TSS must provide a clear mapping showing the association and coverage of the required user security attributes. Any non-security related attributes associated with subject need not be identified in the TSS. While FIA_USB.1 supports assignment of user security attributes related to access control decisions, security management restrictions, and auditing, such attributes only need be identified in the SFR if they extend the minimum set of user security attributes (user identity, groups, and roles). Regardless, the evaluator will find that the TSS describes the association of all of the identified user security attributes in the context of other SFRs relate to access control, security management restrictions, and auditing. In other words, the use of each of the required user security attributes will be described in the TSS in association with at least one security function. The Evaluator will find a description of how user security attributes are assigned to subjects. The description will describe how the user security attributes are initially assigned to a new subject, whether and how user security attributes can be changed, and how any additional security attributes might be associated with a subject. The description will serve to define all relationships between the user security attributes identified in FIA_ATD.1 and the security attributed identified in FIA_USB.1. The definition will also define all rules involved in the initial assignment and changes to security attributes associated with each subject. If there are multiple types of subjects, potentially with different security attributes, the TSS will describe each case accordingly. C FAU_PKI_1_ASE_TSS The TSS shall describe all public and private key stores implemented that contain the keys used to meet the requirements of this PP. This description shall contain information pertaining to how those keys are loaded into the store, and how the store is protected from unauthorized access. That is to say that those key material used to authorize remote IT entities can only be managed by administrative users, while untrusted users may have the ability to manage keys for their use. C FAU_MOF_1_ASE_TSS The TSS shall describe the characteristics that are enforced for passwords, and describe the point at which the enforcement is performed. Page 194 of 237 CC version

195 C FAU_MSA_1_ASE_TSS The TSS (or public documentation pointed to by the TSS) needs to list the object security attributes used for enforcing access control, management, and audit policies together with the rules that define when they can be managed. C FAU_MSA_3_ASE_TSS For all object security attributes used in the discretionary access control policies the TSS (or public documentation pointed to by the TSS) needs to describe how they are initialized when a new object is created and how their initial default values are defined. The TSS also needs to describe if and how those default values can be managed, what the interfaces used for those management activities are and which conditions need to be satisfied to perform those management activities. C FAU_MSA_3_NI_ASE_TSS For all security attributes used in the Network Information Flow Policy the TSS (or public documentation pointed to by the TSS) needs to describe how they are initialized and how their initial default values are defined. The TSS also needs to describe if and how those default values can be managed, what the interfaces used for those management activities are and which conditions need to be satisfied to perform those management activities. Note: most likely those management actions overlap significantly with those for FMT_MTD.1(NI) and will be covered by the assurance activities defined for FMT_MTD.1(NI). C FAU_MSA_4_ASE_TSS The TSS (or public documentation pointed to by the TSS) needs to identify the object security attributes that are inherited when a new object is created, needs to describe what the rules for inheritance are and from where they are inherited. C FAU_MTD_1_AS_ASE_TSS The TSS needs to describe how the storage intended to contain the audit trail is initially set up and configured, needs to describe the operations that can be performed on the audit trail storage object and how those operations are controlled. C FAU_MTD_1_AT_ASE_TSS The TSS needs to describe how the threshold for the audit storage that triggers the actions defined in FAU_STG.3.1 can be managed. C FAU_MTD_1_NI_ASE_TSS The TSS (or public documentation pointed to by the TSS) needs to explain how network data filtering rules can be defined and how they can be viewed, activated, modified, and deleted. The TSS also needs to identify the CC version 3.1 Page 195 of 237

196 interfaces that can be used for those activities and the conditions a user needs to meet when performing any of those management activities. C FAU_MTD_1_IAU_ASE_TSS The relevant user security attributes have been identified in the assurance activities for FIA_ATD.1. C FAU_REV_1_ASE_TSS The TSS (or public documentation pointed to by the TSS) needs to list the object security attributes that can be revoked and needs to explain how revocation can be performed and what the conditions are that a user must satisfy to perform the revocation of an object security attribute. If those conditions are different for different objects security attributes, those differences need to be defined in the SFR. C FAU_ITC_1_ASE_TSS The TSS (or public documentation pointed to by the TSS) needs to list the protocols specified in the SFR and the standards implemented, including options taken where the standard allows for different options. Evaluator action elements: C ASE_TSS.1.1E 812 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ASE_TSS.1-1 ASE_TSS.1.1C The evaluator shall examine the TOE summary specification to determine that it describes how the TOE meets each SFR. 813 The evaluator determines that the TOE summary specification provides, for each SFR from the statement of security requirements, a description on how that SFR is met. 814 The evaluator is reminded that the objective of each description is to provide potential consumers of the TOE with a high-level view of how the developer intends to satisfy each SFR and that the descriptions therefore should not be overly detailed. Often several SFRs will be implemented in one context; for instance a password authentication mechanism may implement FIA_UAU.1, FIA_SOS.1and FIA_UID.1. Therefore usually the TSS will not consist of a long list with texts for each single SFR, but complete groups of SFRs may be covered by one text passage. 815 For a composed TOE, the evaluator also determines that it is clear which component provides each SFR or how the components combine to meet each SFR. :ASE_TSS.1-2 The evaluator analyzes the TSS and the documentation the TSS points to in order to verify that this information allows him: Page 196 of 237 CC version

197 to identify the audit trail(s) that contain the audit records related to events defined by FAU_GEN.1 to identify the record types for each event defined in FAU_GEN.1 to verify that the description of the audit record contains the information required by FAU_GEN.1 to identify the interface(s) that can be used to extract and analyze the audit records :ASE_TSS.1-3 :ASE_TSS.1-4 :ASE_TSS.1-5 :ASE_TSS.1-6 :ASE_TSS.1-7 The evaluator analyzes the TSS and the documentation the TSS points to in order to verify that this information allows him to establish an unambiguous link between the audit record and the user that caused the event. The evaluator analyzes the TSS and the documentation the TSS points to in order to verify that this information allows him to identify the exact conditions that need to be met for a user to be allowed to read audit data. The evaluator analyzes also the information provided on how the audit records are provided to ensure that all information required by FAU_GEN.2 is provided and that the information is suitable for the intended purpose. The intended purpose may be either reading the audit data directly (which requires them to be in printable form) or in a format suitable for postprocessing by a program. In both cases the information required by FAU_GEN.2 needs to be identifiable and needs to be described such that they can be correctly interpreted, The evaluator verifies that the explanation in the TSS and the documents pointed to by the TSS is consistent with the requirements defined in FAU_SEL.1 (i. e. allows restricting the set of audited events in accordance with the criteria defined in FAI_SEL.1) and is consistent with the conditions that must be met to perform this management operation as defined in FMT_MTD.1(AE). The evaluator analyzes the TSS and the documentation the TSS points to and identifies if the TOE uses audit trail specific protection mechanisms. If this is the case, the evaluator needs to perform the complete set of assurance activities defined for FAU_STG.1. Otherwise the evaluation only verifies that the general protection mechanisms used are covered by other SFRs (usually those for access control to storage objects) and refers to the assurance activities defined there. In this case the evaluator only verifies that the guidance provided for the protection of the audit trail ensures that the protection mechanisms are used correctly. The evaluator verifies that the explanation in the TSS and the documents pointed to by the TSS describe the reaction of the TOE to the situation described and that this is consistent with the specification in the FAU_STG CC version 3.1 Page 197 of 237

198 816 The evaluator verifies that the TSS (and the documents pointed to by the TSS) define the possible actions taken by the TOE in case of an audit storage failure and those can be managed. :ASE_TSS.1-8 :ASE_TSS.1-9 The evaluator verifies that the description of the actions taken in case the audit trail is full are consistent with the specification in FAU_STG.4. The evaluator first analyzes the access control algorithm(s) defined in the SFRs (which may potentially be refined in the TSS) to validate that they are complete, providing a yes or no decision with all possible combinations of security attributes used in the rules defining the policy. 817 The evaluator analyzes the SFRs and the TSS for consistency. All access control policies listed in the SFRs should also be described in the TSS with the same types of objects, subjects and operations and for all security attributes mentioned in the policy the TSS needs to explain if and how they can be managed. The evaluator constructs for each access control policy a list of security attributes mentioned in the rules of the access control policy and verifies for each security attribute that the TSS either mentions it as either non-manageable (or managed internally by the TSS) or defines the rules governing the management of the security attribute. The evaluator then should have a complete model for all access control policies that define the types of subjects/users, the type of objects, and the operations covered by the access control policy as well as the full set of rules used by the TOE to determine if access is allowed by the policy. The evaluator also has the list of all security attributes used in the rules of the access control policy together with the rules that determine how those security attributes can be managed. In addition the evaluator has the rules that determine when a new object can be created together with the values of the object security attributes assigned at creation and the rules that determine when an object can be deleted. 818 The evaluator uses this model of the access control policies to check for completeness and for inconsistencies within this model. An example for an inconsistency would be a type of object that appears in more than one access control policy where the evaluator identifies an overlap also in the types of subjects/users and the operations and where the rules for the overlapping parts differ between the two policies. Another example of an inconsistency would be when the rules for an operation that implies another operation provide more access than the implied operation (e. g. the rules would allow a read and write operation in cases where it would not allow a read operation). :ASE_TSS.1-10 The evaluator verifies that the network protocols, network protocol data, the criteria for the rules to fire and the possible action(s) as mentioned in the TSS are consistent with the definition in the SFRs FDP_IFC.1 and FDP_IFF.1, i. e. the criteria and rules defined in the SFRs can all be mapped to the description in the TSS or public documentation pointed to by the TSS. Note that the possibility for an administrator to define rules that match the capabilities defined in FDP_IFF.1 is verified in the assurance activities for FMT_MTD.1(NI). Page 198 of 237 CC version

199 :ASE_TSS.1-11 :ASE_TSS.1-12 :ASE_TSS.1-13 :ASE_TSS.1-14 :ASE_TSS.1-15 The evaluator verifies that at least all resources related to objects mentioned in the access control policy SFRs (including partial release of space occupied by the object), main memory and processor resources are addressed in the description of the object re-use related description in the TSS and that the description explains sufficiently the strategy used to ensure that information about the previous content of the resource is made unavailable. The evaluator will find the user security attributes maintained for each defined user enumerated in the TSS. The list of user security attributes may differ from those identified in FIA_ATD.1 and also serve to extend the minimum set in the context of additional user security attributes assigned in FIA_ATD.1. When the list of user security attributes identified in the TSS differs from those in FIA_ATD.1, the TSS must provide a clear mapping showing the association and coverage of the required user security attributes. Any non-security related attributes associated with users need not be identified in the TSS. The evaluators shall examine the TSS to determine that it identifies the information flows that both support remote IT authentication as well as those that might be allowed prior to the remote IT entity being authenticated. The information in the TSS pertaining to how the FDP_IFC/FDP_IFF requirements are implemented will be a key part of this information, in that it will detail what might be allowed by the mechanism that is implemented to meet those requirements. When the TOE is configured for operational use the allowed protocols will be determined by the configuration of the parameters supported by functionality implementing FDP_IFC/FDP_IFF, so it may not be possible to provide an itemized list of what is and is not allowed prior to remote IT entity authentication. However, the evaluator shall determine that the information provided in the TSS allows a reader to understand the relationship between the configuration mechanisms supporting the FDP_IFC/FDP_IFF requirements and the resultant capabilities and functions available to remote IT entities prior to authentication. The evaluator shall examine the TSS to determine that it describes the logon process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the product. This description shall contain information pertaining to the credentials allowed/used, any protocol transactions that take place, and what constitutes a successful authentication. The evaluator will find the available authentication mechanisms identified in the TSS. At a minimum, the TSS will describe a username/password-based authentication mechanism as well as any other mechanisms that are assigned in FIA_UAU The evaluator will also find that the username/password-based mechanism description explains the behavior of the TOE when a password is expired in a manner consistent with that selected in FIA_UAU.5.2c. 820 If multiple authentication mechanisms are identified, the evaluator will also find that the description explains rules associated with the additional CC version 3.1 Page 199 of 237

200 authentication mechanisms, including rules for determining which authentication mechanism will be used in each case. :ASE_TSS.1-16 In order to show that the TSF supports the use of public keys the evaluator shall ensure that the TSS describes the following information: 821 If X.509v3 certificates according to RFC 5280 are used: For each section of RFC 5280, any statement that is not "MUST" (for example, "MAY", "SHOULD", "SHOULD NOT", etc.) shall be described so that the reader can determine whether the TOE implements that specific part of the standard; For each section of RFC 5280, any non-conformance to "MUST" or SHOULD" statements shall be described; 822 Any TOE-specific extensions or processing that is not included in the standard that may impact the security requirements the TOE is to enforce shall be described. 823 If key material can be loaded and handled directly (e. g. when keys are used without digital certificates), the TSS shall describe which methods of managing the key material are supported by the TOE and what conditions need to be satisfied to perform key material management operations. :ASE_TSS.1-17 :ASE_TSS.1-18 :ASE_TSS.1-19 The evaluator compares the list of object security attributes mentioned in the SFRs in the rules for access control, object management and object related audit policies with the ones listed in the TSS as being manageable. For object security attributes that are mentioned in the TSS as being manageable but which are not used in any SFR, the evaluator needs to clarify their purpose. For object security attributes mentioned in SFRs but not defined as manageable in the TSS, the evaluator needs to verify that those object security attributes can not be managed by the object owner or any other user. The evaluator verifies that the algorithm for initializing the security attributes used in the discretionary access control policies is defined for all security attributes. The evaluator verifies that the default values restrict access to only a defined set of users (e. g. the owner and the administrators). The evaluator verifies that the default values that can be managed and the conditions that need to be satisfied to perform those management activities are consistent with the specification in FMT_MSA.3(DAC). The evaluator verifies that the algorithm for initializing the security attributes used in the Network Information Flow Policy is defined for all security attributes. The evaluator verifies that the default values satisfy the specification in FMT_MSA.3(NI). The evaluator verifies that the default values that can be managed and the conditions that need to be satisfied to perform those management activities are consistent with the specification in FMT_MSA.3(NI). Page 200 of 237 CC version

201 :ASE_TSS.1-20 :ASE_TSS.1-21 :ASE_TSS.1-22 :ASE_TSS.1-23 :ASE_TSS.1-24 :ASE_TSS.1-25 :ASE_TSS.1-26 The evaluator verifies that the algorithm for inheriting security attributes used in the discretionary access control policies is defined for all security attributes that are inherited. The evaluator verifies that the description of the audit trail storage management covers the life-cycle of the audit trail storage object from its creation, assignment as the audit trail storage object and initial configuration, to its management (clearing, re-assignment of audit trail storage (if possible), pt o deleting the audit trail storage object (if possible). For all those actions the authority required to perform the action needs to be specified. The evaluator verifies that this management model is consistent with the management of other audit trail functions. The evaluator verifies that the functionality described in the TSS specifies how the audit trail threshold can be managed and which interface(s) can be used for this action. The evaluator verifies that the management functions and interfaces described in the TSS allow for all the management actions defined in FMT_MTD.1(NI) and that the conditions a user needs to meet to perform those activities is consistent with the description in the SFR. The evaluator shall further find that the TSS describes the restrictions that apply to creating (initializing), viewing, modifying, and deleting each of the identified user security attributes. If additional or alternate operations are available, the TSS must map them to the controlled operations identified in FMT_MTD.1(IAU). The restrictions shall identify the roles that can perform specific operations and/or rules that determine whether specific operations can be performed on each of the user security attributes. The description of restrictions must necessarily address both methods that manipulate user security attributes collectively, such as creating or deleting a user, and methods that manipulate user security attributes individual (or in groups), such as changing passwords and added/removing group memberships or roles. The evaluator compares the list of object security attributes mentioned in the SFRs with the ones listed in the TSS as being revocable and ensures that those lists are identical. The evaluator shall examine the TSS to determine how the TOE determines when the period of inactivity has been reached (e.g., no activity on the keyboard or mouse, no active programs streaming video to the monitor, no dialog boxes being popped up on the screen). The TSS also describes what controls the ability to set the time period, and whether the time period is global (i.e., system wide) or is it configurable per user account. 824 The evaluator also determines from the TSS description how the TOE renders the display unreadable (e.g., a user defined screen saver is activated; administrators control what is displayed when the time period is reached, a system-defined screen is presented that cannot be modified) CC version 3.1 Page 201 of 237

202 825 The evaluator shall examine the TSS to ensure it identifies what activity the system responds to (e.g., depressing key on keyboard, moving the mouse, program interacting with display) and describes how the system responds to activity and what options are presented to a user (e.g., dialog box to enter authentication credentials to unlock the session, ability to login as another user, option to shutdown the machine). 826 Finally, the evaluator shall examine the TSS to make certain that it describes how the user initiates a locked session, and what happens when they initiate a session-lock. It may be the case where the TSS behaves the exactly the same way as when the time out occurs. If not, the TSS describes any differences in behavior. :ASE_TSS.1-27 The evaluator verifies that the standards are referenced correctly, that they describe the protocol completely, and that any options that the standard leaves open are defined in the TSS or the developer documentation pointed to by the TSS. C ASE_TSS.1.2E 827 The evaluator shall confirm that the TOE summary specification is consistent with the TOE overview and the TOE description. :ASE_TSS.1-28 The evaluator shall examine the TOE summary specification to determine that it is consistent with the TOE overview and the TOE description. 828 The TOE overview, TOE description, and TOE summary specification describe the TOE in a narrative form at increasing levels of detail. These descriptions therefore need to be consistent. ATE_COV.2 Analysis of coverage Dependencies satisfied by: Error! Reference source not found. ATE_FUN.1 Functional testing Objectives 829 The objective of this component is to confirm that all of the TSFIs have been tested. Application notes 830 In this component the developer confirms that tests in the test documentation correspond to all of the TSFIs in the functional specification. This can be achieved by a statement of correspondence, perhaps using a table, but the developer also provides an analysis of the test coverage. Page 202 of 237 CC version

203 Objectives 831 The objective of this sub-activity is to determine whether the developer has tested all of the TSFIs, and that the developer's test coverage evidence shows correspondence between the tests identified in the test documentation and the TSFIs described in the functional specification. Input the ST; the functional specification; the test documentation; the test coverage analysis. Developer action elements: C ATE_COV.2.1D 832 The developer shall provide an analysis of the test coverage. Content and presentation of evidence elements: C ATE_COV.2.1C 833 The analysis of the test coverage shall demonstrate the correspondence between the tests in the test documentation and the TSFIs in the functional specification. C ATE_COV.2.2C 834 The analysis of the test coverage shall demonstrate that all TSFIs in the functional specification have been tested. Evaluator action elements: C ATE_COV.2.1E 835 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ATE_COV.2-1 ATE_COV.2.1C The evaluator shall examine the test coverage analysis to determine that the correspondence between the tests in the test documentation and the interfaces in the functional specification is accurate. 836 A simple cross-table may be sufficient to show test correspondence. The identification of the tests and the interfaces presented in the test coverage analysis has to be unambiguous CC version 3.1 Page 203 of 237

204 837 The evaluator is reminded that this does not imply that all tests in the test documentation must map to interfaces in the functional specification. :ATE_COV.2-2 ATE_COV.2.1C The evaluator shall examine the test plan to determine that the testing approach for each interface demonstrates the expected behaviour of that interface. 838 Guidance on this work unit can be found in: Error! Reference source not found. Error! Reference source not found. :ATE_COV.2-3 ATE_COV.2.1C The evaluator shall examine the test procedures to determine that the test prerequisites, test steps and expected result(s) adequately test each interface. 839 Guidance on this work units, as it pertains to the functional specification, can be found in: Error! Reference source not found. :ATE_COV.2-4 ATE_COV.2.2C The evaluator shall examine the test coverage analysis to determine that the correspondence between the interfaces in the functional specification and the tests in the test documentation is complete. 840 All TSFIs that are described in the functional specification have to be present in the test coverage analysis and mapped to tests in order for completeness to be claimed, although exhaustive specification testing of interfaces is not required. Incomplete coverage would be evident if an interface was identified in the functional specification and no test was mapped to it. 841 The evaluator is reminded that this does not imply that all tests in the test documentation must map to interfaces in the functional specification. ATE_DPT.1 Testing: basic design Dependencies satisfied by: ADV_ARC.1 Security architecture description Error! Reference source not found. ATE_FUN.1 Functional testing Objectives 842 The subsystem descriptions of the TSF provide a high-level description of the internal workings of the TSF. Testing at the level of the TOE subsystems provides assurance that the TSF subsystems behave and interact as described in the TOE design and the security architecture description. Page 204 of 237 CC version

205 Objectives 843 The objective of this sub-activity is to determine whether the developer has tested the TSF subsystems against the TOE design and the security architecture description. Input the ST; the functional specification; the TOE design; the security architecture description; the test documentation; the depth of testing analysis. Developer action elements: C ATE_DPT.1.1D 844 The developer shall provide the analysis of the depth of testing. Content and presentation of evidence elements: C ATE_DPT.1.1C 845 The analysis of the depth of testing shall demonstrate the correspondence between the tests in the test documentation and the TSF subsystems in the TOE design. C ATE_DPT.1.2C 846 The analysis of the depth of testing shall demonstrate that all TSF subsystems in the TOE design have been tested. Evaluator action elements: C ATE_DPT.1.1E 847 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ATE_DPT.1-1 ATE_DPT.1.1C The evaluator shall examine the depth of testing analysis to determine that the descriptions of the behaviour of TSF subsystems and of their interactions is included within the test documentation. 848 This work unit verifies the content of the correspondence between the tests and the descriptions in the TOE design. In cases where the description of the CC version 3.1 Page 205 of 237

206 TSF's architectural soundness (in Error! Reference source not found.) cites specific mechanisms, this work unit also verifies the correspondence between the tests and the descriptions of the behaviour of such mechanisms. 849 A simple cross-table may be sufficient to show test correspondence. The identification of the tests and the behaviour/interaction presented in the depth-of coverage analysis has to be unambiguous. 850 When 0is combined with a component of Error! Reference source not found., which includes descriptions at the module level (e.g. Error! Reference source not found.), the level of detail needed to map the test cases to the behaviour of the subsystems may require information from the module description to be used. This is because Error! Reference source not found.allows the description of details to be shifted from the subsystem level to the module level, or even to omit the subsystems altogether. 851 In any case, the required level of detail in the provided reference to the tested behaviour can be defined as the level of detail required for the description of subsystem behaviour as defined by Error! Reference source not found.(in particular work unit Error! Reference source not found.). It states that a detailed description of the behaviour typically discusses how the functionality is provided, in terms of what key data and data structures re present; what control relationships exist within a subsytem and how these elements work together to provide the SFR-enforcing behaviour. 852 The evaluator is reminded that not all tests in the test documentation must map to a subsystem behaviour or interaction description. :ATE_DPT.1-2 ATE_DPT.1.1C The evaluator shall examine the test plan, test prerequisites, test steps and expected result(s) to determine that the testing approach for the behaviour description demonstrates the behaviour of that subsystem as described in the TOE design. 853 Guidance on this work unit can be found in: Error! Reference source not found. Error! Reference source not found. 854 When 0is combined with a component of Error! Reference source not found., which includes descriptions at the module level (e.g. Error! Reference source not found.), the level of detail needed to map the test cases to the behaviour of the subsystems may require information from the module description to be used. This is because Error! Reference source not found.allows the description of details to be shifted from the subsystem level to the module level, or even to omit the subsystems altogether. 855 In any case, the required level of detail in the provided reference to the tested behaviour can be defined as the level of detail required for the description of subsystem behaviour as defined by Error! Reference source not found.(in particular work unit Error! Reference source not found.). It Page 206 of 237 CC version

207 states that a detailed description of the behaviour typically discusses how the functionality is provided, in terms of what key data and data structures re present; what control relationships exist within a subsytem and how these elements work together to provide the SFR-enforcing behaviour. 856 If TSF subsystem interfaces are described, the behaviour of those subsystems may be tested directly from those interfaces. Otherwise, the behaviour of those subsystems is tested from the TSFI interfaces. Or a combination of the two may be employed. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the behaviour that is described in the TOE design. :ATE_DPT.1-3 ATE_DPT.1.1C The evaluator shall examine the test plan, test prerequisites, test steps and expected result(s) to determine that the testing approach for the behaviour description demonstrates the interactions among subsystems as described in the TOE design. 857 While the previous work unit addresses behaviour of subsystems, this work unit addresses the interactions among subsystems. 858 Guidance on this work unit can be found in: Error! Reference source not found. Error! Reference source not found. 859 If TSF subsystem interfaces are described, the interactions with other subsystems may be tested directly from those interfaces. Otherwise, the interactions among subsystems must be inferred from the TSFI interfaces. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the interactions among subsystems that are described in the TOE design. :ATE_DPT.1-4 ATE_DPT.1.2C The evaluator shall examine the test procedures to determine that all descriptions of TSF subsystem behaviour and interaction are tested. 860 This work unit verifies the completeness of work unit ATE_DPT.1-1. All descriptions of TSF subsystem behaviour and of interactions among TSF subsystems that are provided in the TOE design have to be tested. Incomplete depth of testing would be evident if a description of TSF subsystem behaviour or of interactions among TSF subsystems was identified in the TOE design and no tests could be attributed to it. 861 When 0is combined with a component of Error! Reference source not found., which includes descriptions at the module level (e.g. Error! Reference source not found.), the level of detail needed to map the test cases to the behaviour of the subsystems may require information from the module description to be used. This is because Error! Reference source not found.allows the description of details to be shifted from the subsystem level to the module level, or even to omit the subsystems altogether CC version 3.1 Page 207 of 237

208 862 In any case, the required level of detail in the provided reference to the tested behaviour can be defined as the level of detail required for the description of subsystem behaviour as defined by Error! Reference source not found.(in particular work unit Error! Reference source not found.). It states that a detailed description of the behaviour typically discusses how the functionality is provided, in terms of what key data and data structures re present; what control relationships exist within a subsytem and how these elements work together to provide the SFR-enforcing behaviour. 863 The evaluator is reminded that this does not imply that all tests in the test documentation must map to the subsystem behaviour or interaction description in the TOE design. ATE_FUN.1 Functional testing Dependencies satisfied by: Error! Reference source not found. Objectives 864 The objective is for the developer to demonstrate that the tests in the test documentation are performed and documented correctly. Objectives 865 The objective of this sub-activity is to determine whether the developer correctly performed and documented the tests in the test documentation. Objectives 866 The developer should be able to present test results from his test suite demonstrating that: audit records have been generated when they should be audit records contain the expected information and correctly reflect the event 867 Usually there is little specific testing required since the generation of audit records is (in the case of the events described in FAU_GEN.1 in the base OSPP) related to the invocation of security functions provided by the TOE that need to be tested for their specific security functionality anyhow. In order to validate the generation of the audit records, the TOE should be tested generally with all auditable events specified in FAU_GEN.1 being turned on. As long as this is not done as part of stress testing, the timing overhead associated with this extensive auditing can be neglected. Stress tests or fuzz tests that are performed in addition to pure functional testing may well be performed with a configuration where no or only a few auditable events are actually being audited. Page 208 of 237 CC version

209 868 The tests shall cover all audit events defined in FAU_GEN.1 in the Security Target to show that for each of the events defined in FAU_GEN.1.1 an audit record is created and contains the information defined for the audit records in FAU_GEN.1.2. Application notes 869 The extent to which the test documentation is required to cover the TSF is dependent upon the coverage assurance component. 870 For the developer tests provided, the evaluator determines whether the tests are repeatable, and the extent to which the developer's tests can be used for the evaluator's independent testing effort. Any TSFI for which the developer's test results indicate that it might not perform as specified should be tested independently by the evaluator to determine whether or not it does. Input 871 The evaluation evidence for this sub-activity is: the ST; the functional specification; the test documentation. Developer action elements: C ATE_FUN.1.1D 872 The developer shall test the TSF and document the results. C ATE_FUN.1.2D 873 The developer shall provide test documentation. Content and presentation of evidence elements: C ATE_FUN.1.1C 874 The test documentation shall consist of test plans, expected test results and actual test results. C ATE_FUN.1.2C 875 The test plans shall identify the tests to be performed and describe the scenarios for performing each test. These scenarios shall include any ordering dependencies on the results of other tests CC version 3.1 Page 209 of 237

210 C ATE_FUN.1.3C 876 The expected test results shall show the anticipated outputs from a successful execution of the tests. C ATE_FUN.1.4C 877 The actual test results shall be consistent with the expected test results. C FAU_GEN_2_ATE_FUN The developer is expected to demonstrate in his testing that the association between the user that caused the event and the audit record can be established. Testing shall cover all cases identified in the TSS where an audit record is created by a subject that at the time of the creation of the audit record is not bound to the user that caused the related event. The test cases must identify the user(s) that caused the events. C FAU_SAR_1_ATE_FUN The developer is expected to demonstrate in his testing that the conditions for reading the audit data are enforced and how the audit records can be read. C FAU_SEL_1_ATE_FUN The developer is expected to demonstrate in his testing that the conditions for managing the set of auditable events are enforced and how the auditable events can be restricted in accordance with the criteria defined in FAU_SEL.1. C FAU_STG_1_ATE_FUN The developer is expected to demonstrate in his testing that the conditions for deleting records from the audit trail are enforced and that only the audit records selected are deleted. C FAU_STG_3_ATE_FUN The developer is expected to provide test cases and test results for the conditions defined in FAU_STG.3.1 showing that each of those conditions causes the TSF to take the actions described in FAU_STG.3.1. The developer is also expected to provide test cases showing the actions taken when the audit trail is full unless this condition can not be reached in normal operation. In this case the developer needs to provide arguments based on the architectural design demonstrating that Reaching the condition that the audit trail gets full is hard to test (even when configuring the minimum size of the audit trail allowed by the TOE) If the audit trail gets full, the TSF will take the action described in FAU_STG.4.1 for this case. Page 210 of 237 CC version

211 Note that in the case the audit records are sent to a remote system, the situation of a full audit trail is equivalent to the situation where the remote system is no longer capable of receiving audit records. In this case the situation of a full audit trail can be easily simulated by disrupting the connection to the remote system. If possible there should also be tests simulating an audit storage failure. For example in cases where audit storage is on local disks and the TOE allows for easy removing of a disk (e. g. in case of a USB disk), the developer is expected to test the case where the audit storage is on such a removable disk and this disk is removed during operation. C FAU_STG_4_ATE_FUN The developer still has to present an estimate for the effort it would take to develop a test case for FAU_STG.4.1. The developer may choose to present a test case where the specific functionality of the TOE reacting to a full a audit trail is executed in a specific environment (e. g. using a debugger or a virtualized environment) that allows to simulate the condition of a full audit trail. C FAU_FDP_1_ATE_FUN Test cases may either be provided by the developer to be executed by the evaluator or be developed by the evaluator. The test cases are required to cover: All access control algorithms mentioned in the Security Target For each access control algorithm all paths through the algorithm (as defined in the Security Target), especially each leaf in the algorithm where the algorithm terminates with a yes or no decision A representative set of combinations of settings of the security attributes used in the access control algorithms Test cases need to exist also for the management functions used to manage the security attributes used in the access control algorithms. Those test cases need to cover all security attributes, each with a representative set of values for the attribute. The test cases need to show: That the conditions for managing the security attributes are enforced (which includes test cases where the request for management is rejected) That the value of the security attribute has the effect described in the access control algorithm. That the values of security attributes can be queried (if the necessary conditions are satisfied) Those test cases will overlap with test cases required for the assessment of some management SFRs. There is of course no need to CC version 3.1 Page 211 of 237

212 execute those tests twice, but instead the test cases may be just mapped to both the SFRs for FDP_ACC/FDP_ACF and the management SFRs. Additional test cases are required in cases where an object can be accessed using different ways. Test cases need to exist that demonstrate that access control is enforced for each possible way to access the object. Note that not all paths through the algorithm need to be tested for each possible way to access the object. C FAU_IFF_1_ATE_FUN The developer is required to present test cases that test the following cases: Single filter rules based on each single security attribute showing that the defined action(s) are taken in each case the rule fires and are not taken if the rule does not fire A combination of two or more filter rules showing that the action(s) expected to be taken for the combination of filter rules are actually taken. Note that the Assurance Activities for FMT_MSA.1(NI) require that the evaluator verifies that for each possible combination of filter rules the developer documentation allows to identify unambiguously the action(s) taken by the TOE on packets inspected. The evaluator will take this specification from the developers documentation to specify the expected result for the following cases: 1. A combination of filter rules that use different security attributes and define different actions 2. If possible, a combination of filter rules that use the same security attributes but define different actions All exceptions listed in FDP_IFF.1.4 and FDP_IFF.1.5 C FAU_RIP_2_ATE_FUN Testing is expected to cover all interfaces that can be used to allocate resources that need to be subject to object re-use and then analyze if the resource potentially contains information from its previous use by a different subject. Testing is expected to cover all attempts to obtain information left from the previous use of the resource. Testing needs to cover at least the following cases: Attempts to read from persistent storage objects from areas that have not been written to since the object was created. Reading from main storage areas that have been obtained using dynamic storage allocation but not yet written to by the subject. Reading user-accessible processor register after a content switch. Page 212 of 237 CC version

213 Reading from other resources listed as being subject to object re-use and allocated to the subject before information has been placed in those resources by the subject. C FAU MSA_1_ATE_FUN The developer is expected to test the interfaces for the management of object security attributes as part of his functional testing. This is often done in conjunction with the testing of the SFRs where the object security attributes are used like in testing of the access control policy where those interfaces are used to set the object security attributes for testing different aspects of the access control algorithm. C FAU_MSA_3_ATE_FUN The developer is expected to test the interfaces for the management of the default values for security attributes used to enforce the discretionary access control policies as part of his functional testing. This is often done in conjunction with the testing of the SFRs for the access control policies where those interfaces are used to set the default values for security attributes for testing different aspects of the access control algorithm. C FAU_MSA_3_NI_ATE_FUN The developer is expected to test the interfaces for the management of the default values for security attributes used to enforce the Network Information Flow Policy as part of his functional testing. This is often done in conjunction with the testing of the SFRs for the Network Information Flow Policy where those interfaces are used to set the default values for security attributes for testing different aspects of the Network Information Flow Policy. C FAU_MSA_4_ATE_FUN The developer is expected to test the inheritance rules by creating new objects and then verify that the values of the object security attributes that are supposed to be inherited are correctly inherited. C FAU_MTD_1_AS_ATE_FUN The developer is expected to provide test cases and test results for the individual management activities defined in FMT_MTD.1(AS), showing that the management activities can be performed and have specified effect when the user has the required authority to perform the activity. The developer is also expected to provide test cases showing the management activities defined in FMT_MTD.1(AS) can not be performed when the user does not have the required authorization CC version 3.1 Page 213 of 237

214 C FAU_MTD_1_AT_ATE_FUN The developer is expected to provide test cases and test results for the setting of the audit trail threshold. The developer is expected to execute the tests for FAU_STG.3.1 using different values for the audit trail threshold, showing that the actions defined in FAU_STG.3.1 are correctly taken when the threshold as defined is exceeded. C FAU_MTD_1_NI_ATE_FUN Testing of FMT_MTD.1(NI) is expected to be performed in conjunction with the testing defined for FDP_IFC.1 and FDP_IFF.1. The management interfaces are used to define the set of network filtering rules used for the testing of the Network Information Flow Policy. In addition the developer is expected to test that the management interfaces enforce the conditions a user must satisfy to perform the different management activities. The test cases shall cover all branches of the algorithm that determines a users right to perform the management action, similar to testing an access control algorithm C FAU_REV_1_ATE_FUN The developer is expected to test the interfaces for the revocation of object security attributes as part of his functional testing. This is often done in conjunction with the testing of the SFRs where the object security attributes are used like in testing of the access control policy where those interfaces are used to revoke the object security attributes for testing different aspects of the access control algorithm. C FAU_ITC_1_ATE_FUN The developer is expected to test the protocols defined in FTP_ITC.1 with all options for the authentication of the remote IT system and all options for the cipher suites defined in FTP_ITC.1. Testing should be performed using a reference system that has a different implementation of the protocols and cipher suites to ensure that the TOE is able to set up and maintain the trusted channel to a product with an independent implementation of the protocol including the cryptographic algorithms used as part of the protocol. Evaluator action elements: C ATE_FUN.1.1E 896 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ATE_FUN.1-1 ATE_FUN.1.1C The evaluator shall check that the test documentation includes test plans, expected test results and actual test results. 897 The evaluator checks that test plans, expected tests results and actual test results are included in the test documentation. Page 214 of 237 CC version

215 :ATE_FUN.1-2 ATE_FUN.1.2C The evaluator shall examine the test plan to determine that it describes the scenarios for performing each test. 898 The evaluator determines that the test plan provides information about the test configuration being used: both on the configuration of the TOE and on any test equipment being used. This information should be detailed enough to ensure that the test configuration is reproducible. 899 The evaluator also determines that the test plan provides information about how to execute the test: any necessary automated set-up procedures (and whether they require privilege to run), inputs to be applied, how these inputs are applied, how output is obtained, any automated clean-up procedures (and whether they require privilege to run), etc. This information should be detailed enough to ensure that the test is reproducible. 900 The evaluator may wish to employ a sampling strategy when performing this work unit. :ATE_FUN.1-3 ATE_FUN.1.2C The evaluator shall examine the test plan to determine that the TOE test configuration is consistent with the ST. 901 The TOE referred to in the developer's test plan should have the same unique reference as established by the Error! Reference source not found.subactivities and identified in the ST introduction. 902 It is possible for the ST to specify more than one configuration for evaluation. The evaluator verifies that all test configurations identified in the developer test documentation are consistent with the ST. For example, the ST might define configuration options that must be set, which could have an impact upon what constitutes the TOE by including or excluding additional portions. The evaluator verifies that all such variations of the TOE are considered. 903 The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. 904 The evaluator may wish to employ a sampling strategy when performing this work unit. 905 If this work unit is applied to a component TOE that might be used/integrated in a composed TOE (see Error! Reference source not found.), the following will apply. In the instances that the component TOE under evaluation depends on other components in the operational environment to support their operation, the developer may wish to consider using the other component(s) that will be used in the composed TOE to fulfil the requirements of the operational environment as one of the test CC version 3.1 Page 215 of 237

216 configurations. This will reduce the amount an additional testing that will be required for the composed TOE evaluation. :ATE_FUN.1-4 ATE_FUN.1.2C The evaluator shall examine the test plans to determine that sufficient instructions are provided for any ordering dependencies. 906 Some steps may have to be performed to establish initial conditions. For example, user accounts need to be added before they can be deleted. An example of ordering dependencies on the results of other tests is the need to perform actions in a test that will result in the generation of audit records, before performing a test to consider the searching and sorting of those audit records. Another example of an ordering dependency would be where one test case generates a file of data to be used as input for another test case. 907 The evaluator may wish to employ a sampling strategy when performing this work unit. :ATE_FUN.1-5 ATE_FUN.1.3C The evaluator shall examine the test documentation to determine that all expected tests results are included. 908 The expected test results are needed to determine whether or not a test has been successfully performed. Expected test results are sufficient if they are unambiguous and consistent with expected behaviour given the testing approach. 909 The evaluator may wish to employ a sampling strategy when performing this work unit. :ATE_FUN.1-6 ATE_FUN.1.4C The evaluator shall check that the actual test results in the test documentation are consistent with the expected test results in the test documentation. 910 A comparison of the actual and expected test results provided by the developer will reveal any inconsistencies between the results. It may be that a direct comparison of actual results cannot be made until some data reduction or synthesis has been first performed. In such cases, the developer's test documentation should describe the process to reduce or synthesise the actual data. 911 For example, the developer may need to test the contents of a message buffer after a network connection has occurred to determine the contents of the buffer. The message buffer will contain a binary number. This binary number would have to be converted to another form of data representation in order to make the test more meaningful. The conversion of this binary representation of data into a higher-level representation will have to be described by the developer in enough detail to allow an evaluator to perform the conversion process (i.e. synchronous or asynchronous transmission, number of stop bits, parity, etc.). 912 It should be noted that the description of the process used to reduce or synthesise the actual data is used by the evaluator not to actually perform the Page 216 of 237 CC version

217 necessary modification but to assess whether this process is correct. It is up to the developer to transform the expected test results into a format that allows an easy comparison with the actual test results. 913 The evaluator may wish to employ a sampling strategy when performing this work unit. :ATE_FUN.1-7 ATE_FUN.1.4C The evaluator shall report the developer testing effort, outlining the testing approach, configuration, depth and results. 914 The developer testing information recorded in the ETR allows the evaluator to convey the overall testing approach and effort expended on the testing of the TOE by the developer. The intent of providing this information is to give a meaningful overview of the developer testing effort. It is not intended that the information regarding developer testing in the ETR be an exact reproduction of specific test steps or results of individual tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the developer's testing approach, amount of testing performed, TOE test configurations, and the overall results of the developer testing. 915 Information that would typically be found in the ETR subclause regarding the developer testing effort is: TOE test configurations. The particular configurations of the TOE that were tested, including whether any privileged code was required to set up the test or clean up afterwards; testing approach. An account of the overall developer testing strategy employed; testing results. A description of the overall developer testing results. 916 This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the developer testing effort. :ATE_FUN.1-8 :ATE_FUN.1-9 The evaluator analyzes the test results presented by the developer and for completeness and correctness. Note that in the case where the developer has produced a massive amount of test results resulting in a very large number of audit records being generated, the developer and the evaluator should work together on a strategy to sample those results. The sample should include cases demonstrating the correct generation of audit records for all events defined in FAU_GEN.1.1. The evaluator verifies that the test cases provided cover all cases identified in the TSS where an audit record is created by a subject that at the time of the creation of the audit record is not bound to the user that caused the related event. The evaluator extracts the audit records generated by those test cases and determines if he is able to establish the association of the event that caused the audit record to be created with the user that caused the event CC version 3.1 Page 217 of 237

218 :ATE_FUN.1-10 The evaluator verifies that sufficient test cases have been provided (with their test results) showing that for each access control policy mentioned in the Security Target all paths through the access control algorithm are covered by at least one test case. He then maps the list of security attributes to test cases, showing that all security attributes are covered with a representative set of values. A representative set of values depends on the overall set of values for the security attribute and its expected effect on the access control policy. For example an access control list is a security attribute where test cases need to exist for each possible type of access, but (of course) not for each possible user. 917 The evaluator also maps each management function to test cases, showing that all management functions are covered by test cases. 918 In most cases the developer will have significantly more test cases than required to show the coverage indicated above. When the evaluator has completed the mappings required in the description above using a subset of the test cases provided by the developer, there is no need for the evaluator to analyze the developers test cases beyond this subset. :ATE_FUN.1-11 :ATE_FUN.1-12 The evaluator verifies that all resources for which object re-use has been defined are covered by testing showing that the no access to previous information is possible. The evaluator verifies that all TSFI where newly allocated resourced can be read are included in the test suite and that in no case access to the previous information is possible. The number of tests used to verify the TOEs behavior will, of course, depend upon the number of authentication methods that are subject to this requirement, the interfaces that invoke those methods, as well as the actions to be taken. It is suggested that the evaluator develops a matrix that contains the authentication methods to be considered, the potential authentication events that may be associated with each of the methods, and the actions that will be taken. Again, there may be various actions that are taken even given the same authentication method, and it is critical that all combinations are addressed in the testing activities. For example, when an untrusted user fails to enter the correct local password three consecutive times, their account may be disabled/locked until an administrator action is taken. On the other hand, when an administrative user fails to enter the correct local password three consecutive times their account may be disabled for 30 seconds. So the nature and number of the tests will vary due to the complexity of the TOEs failure handling mechanism. 919 The evaluator, with the appropriate privilege, shall follow the operational guidance to configure the number of unsuccessful authentication attempts for each authentication method [password-based is minimally required; others may exist depending on the assignment. :ATE_FUN.1-13 The evaluator shall attempt to authenticate successfully using the authentication method under test. After successfully authenticating, the evaluator will attempt X number of failed authentication attempts (number to be determined according to the rules specified in the list of authentication Page 218 of 237 CC version

219 events. Upon satisfying the number of failed attempts, the evaluator shall observe that the TOE electrocutes the user with sufficient amperage to cause much harm. :ATE_FUN.1-14 :ATE_FUN.1-15 :ATE_FUN.1-16 :ATE_FUN.1-17 :ATE_FUN.1-18 :ATE_FUN.1-19 :ATE_FUN.1-20 :ATE_FUN.1-21 :ATE_FUN.1-22 The evaluator shall attempt to modify the variable that enforces the limit on unsuccessful authentication attempts as an untrusted user. They shall be unsuccessful in modifying the controlling variable. The evaluator verifies that testing includes all interfaces defined for the management of object security attributes and all object security attributes, covering a sufficient set of values for the individual object security attributes. The evaluator verifies that the effect of the settings of the object security attributes are tested (often as part of the testing of the access control algorithm). The evaluator verifies that testing includes all interfaces defined for the management of the default values for security attributes used to enforce the discretionary access control policies, covering a sufficient set of values for the individual security attributes. The evaluator verifies that the effect of the settings of the security attributes are tested (often as part of the testing of the access control algorithms). The evaluator verifies that testing includes all interfaces defined for the management of the default values for security attributes used to enforce the Network Information Flow Policy, covering a sufficient set of values for the individual security attributes. The evaluator verifies that the effect of the settings of the security attributes are tested (often as part of the testing of the filtering rules). The evaluator verifies that testing covers all object security attributes that can be inherited with different values for those attributes. The evaluator verifies that the test results show that the actions defined in FAU_STG.3.1 are taken when the threshold is exceeded independent how the value for this threshold has been set. The evaluator shall verify that the test cases cover all combinations of management activities and all branches of the algorithm that determines a users right to perform the management action. The evaluator verifies that testing includes all interfaces defined for the revocation of object security attributes and all object security attributes. The evaluator verifies that the effect of the revocation of the object security attributes are tested (often as part of the testing of the access control algorithm). The evaluator verifies that testing includes all protocols and protocol options defined. The evaluator will set up his own reference system and ensure that this system uses a different implementation of the protocols listed in FTP_ITC.1. The evaluator will perform his own tests by attempting to set up CC version 3.1 Page 219 of 237

220 a trusted channel to an instance of the TOE. The test shall cover the following cases: Attempts to use options (e. g. for remote system authentication) not supported by the TOE. Those attempts need to fail. Attempts to use options supported by the TOE but providing incorrect authentication credentials. Those attempts need to fail. Attempts to use correct authentication credentials and the correct protocol version, but cipher suites not supported by the TOE. Those attempts need to fail. Attempts to use protocol versions not supported by the TOE (e. g. older versions of a supported protocol). Those attempts need to fail. Attempts to use a protocol version supported by the TOE, an authentication method supported by the TOE, correct authentication credentials, and a cipher suite supported by the TOE. Those attempts need to pass (unless there are other conditions defined in the guidance or functional specification that cause the attempt to fail in an expected way). ATE_IND.2 Independent testing - sample Dependencies satisfied by: Error! Reference source not found. AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures Error! Reference source not found. ATE_FUN.1 Functional testing Objectives 920 In this component, the objective is to demonstrate that the TOE operates in accordance with its design representations and guidance documents. Evaluator testing confirms that the developer performed some tests of some interfaces in the functional specification. Application notes 921 The intent is that the developer should provide the evaluator with materials necessary for the efficient reproduction of developer tests. This may include such things as machine-readable test documentation, test programs, etc. 922 This component contains a requirement that the evaluator has available test results from the developer to supplement the programme of testing. The evaluator will repeat a sample of the developer's tests to gain confidence in the results obtained. Having established such confidence the evaluator will build upon the developer's testing by conducting additional tests that exercise the TOE in a different manner. By using a platform of validated developer Page 220 of 237 CC version

221 test results the evaluator is able to gain confidence that the TOE operates correctly in a wider range of conditions than would be possible purely using the developer's own efforts, given a fixed level of resource. Having gained confidence that the developer has tested the TOE, the evaluator will also have more freedom, where appropriate, to concentrate testing in areas where examination of documentation or specialist knowledge has raised particular concerns. Objectives 923 The goal of this activity is to determine, by independently testing a subset of the TSF, whether the TOE behaves as specified in the design documentation, and to gain confidence in the developer's test results by performing a sample of the developer's tests. Input 924 The evaluation evidence for this sub-activity is: the ST; the functional specification; the TOE design description; the operational user guidance; the preparative user guidance; the configuration management documentation; the test documentation; the TOE suitable for testing. Developer action elements: C ATE_IND.2.1D 925 The developer shall provide the TOE for testing. Content and presentation of evidence elements: C ATE_IND.2.1C 926 The TOE shall be suitable for testing. C ATE_IND.2.2C 927 The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF CC version 3.1 Page 221 of 237

222 Evaluator action elements: C ATE_IND.2.1E 928 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :ATE_IND.2-1 ATE_IND.2.1C The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. 929 The TOE provided by the developer and identified in the test plan should have the same unique reference as established by the Error! Reference source not found.sub-activities and identified in the ST introduction. 930 It is possible for the ST to specify more than one configuration for evaluation. The TOE may comprise a number of distinct hardware and software entities that need to be tested in accordance with the ST. The evaluator verifies that all test configurations are consistent with the ST. 931 The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment and ensure they are met in the testing environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. 932 If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that these resources are calibrated correctly. :ATE_IND.2-2 ATE_IND.2.1C The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state. 933 It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous successful completion of the 0sub-activity will satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed properly and is in a known state. If this is not the case, then the evaluator should follow the developer's procedures to install and start up the TOE, using the supplied guidance only. 934 If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work unit when successfully completed could satisfy work unit 0. :ATE_IND.2-3 ATE_IND.2.2C The evaluator shall examine the set of resources provided by the developer to determine that they are equivalent to the set of resources used by the developer to functionally test the TSF. 935 The set of resource used by the developer is documented in the developer test plan, as considered in the Error! Reference source not found.family. The resource set may include laboratory access and special test equipment, Page 222 of 237 CC version

223 among others. Resources that are not identical to those used by the developer need to be equivalent in terms of any impact they may have on test results. C ATE_IND.2.2E 936 The evaluator shall execute a sample of tests in the test documentation to verify the developer test results. :ATE_IND.2-4 The evaluator shall conduct testing using a sample of tests found in the developer test plan and procedures. 937 The overall aim of this work unit is to perform a sufficient number of the developer tests to confirm the validity of the developer's test results. The evaluator has to decide on the size of the sample, and the developer tests that will compose the sample (see Error! Reference source not found.). 938 All the developer tests can be traced back to specific interfaces. Therefore, the factors to consider in the selection of the tests to compose the sample are similar to those listed for subset selection in work-unit 0. Additionally, the evaluator may wish to employ a random sampling method to select developer tests to include in the sample. :ATE_IND.2-5 The evaluator shall check that all the actual test results are consistent with the expected test results. 939 Inconsistencies between the developer's expected test results and actual test results will compel the evaluator to resolve the discrepancies. Inconsistencies encountered by the evaluator could be resolved by a valid explanation and resolution of the inconsistencies by the developer. 940 If a satisfactory explanation or resolution can not be reached, the evaluator's confidence in the developer's test results may be lessened and it may be necessary for the evaluator to increase the sample size to the extent that the subset identified in work unit 0is adequately tested: deficiencies with the developer's tests need to result in either corrective action to the TOE by the developer (e.g., if the inconsistency is caused by incorrect behaviour) or to the developer's tests (e.g., if the inconsistency is caused by an incorrect test), or in the production of new tests by the evaluator. C ATE_IND.2.3E 941 The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. :ATE_IND.2-6 The evaluator shall devise a test subset. 942 The evaluator selects a test subset and testing strategy that is appropriate for the TOE. One extreme testing strategy would be to have the test subset CC version 3.1 Page 223 of 237

224 contain as many interfaces as possible tested with little rigour. Another testing strategy would be to have the test subset contain a few interfaces based on their perceived relevance and rigorously test these interfaces. 943 Typically the testing approach taken by the evaluator should fall somewhere between these two extremes. The evaluator should exercise most of the interfaces using at least one test, but testing need not demonstrate exhaustive specification testing. 944 The evaluator, when selecting the subset of the interfaces to be tested, should consider the following factors: The developer test evidence. The developer test evidence consists of: the test documentation, the available test coverage analysis, and the available depth of testing analysis. The developer test evidence will provide insight as to how the TSF has been exercised by the developer during testing. The evaluator applies this information when developing new tests to independently test the TOE. Specifically the evaluator should consider: 1. augmentation of developer testing for interfaces. The evaluator may wish to perform more of the same type of tests by varying parameters to more rigorously test the interface. 2. supplementation of developer testing strategy for interfaces. The evaluator may wish to vary the testing approach of a specific interface by testing it using another test strategy. The number of interfaces from which to draw upon for the test subset. Where the TSF includes only a small number of relatively simple interfaces, it may be practical to rigorously test all of them. In other cases this may not be cost-effective, and sampling is required. Maintaining a balance of evaluation activities. The evaluator effort expended on the test activity should be commensurate with that expended on any other evaluation activity. 945 The evaluator selects the interfaces to compose the subset. This selection will depend on a number of factors, and consideration of these factors may also influence the choice of test subset size: Rigour of developer testing of the interfaces. Those interfaces that the evaluator determines require additional testing should be included in the test subset. Developer test results. If the results of developer tests cause the evaluator to doubt that an interface is not properly implemented, then the evaluator should include such interfaces in the test subset. Significance of interfaces. Those interfaces more significant than others should be included in the test subset. One major factor of Page 224 of 237 CC version

225 significance is the security-relevance (SFR-enforcing interfaces would be more significant than SFR-supporting interfaces, which are more significant than SFR-non-interfering interfaces; see CC Part 3 Subclause ADV_FSP). The other major factor of significance is the number of SFRs mapping to this interface (as determined when identifying the correspondence between levels of abstraction in ADV). Complexity of interfaces. Interfaces that require complex implementation may require complex tests that impose onerous requirements on the developer or evaluator, which may not be conducive to cost-effective evaluations. Conversely, they are a likely area to find errors and are good candidates for the subset. The evaluator will need to strike a balance between these considerations. Implicit testing. Testing some interfaces may often implicitly test other interfaces, and their inclusion in the subset may maximise the number of interfaces tested (albeit implicitly). Certain interfaces will typically be used to provide a variety of security functionality, and will tend to be the target of an effective testing approach. Types of interfaces (e.g. programmatic, command-line, protocol). The evaluator should consider including tests for all different types of interfaces that the TOE supports. Interfaces that give rise to features that are innovative or unusual. Where the TOE contains innovative or unusual features, which may feature strongly in marketing literature and guidance documents, the corresponding interfaces should be strong candidates for testing. 946 This guidance articulates factors to consider during the selection process of an appropriate test subset, but these are by no means exhaustive. :ATE_IND.2-7 The evaluator shall produce test documentation for the test subset that is sufficiently detailed to enable the tests to be reproducible. 947 With an understanding of the expected behaviour of the TSF, from the ST, the functional specification, and the TOE design description, the evaluator has to determine the most feasible way to test the interface. Specifically the evaluator considers: the approach that will be used, for instance, whether an external interface will be tested, or an internal interface using a test harness, or will an alternate test approach be employed (e.g. in exceptional circumstances, a code inspection); the interface(s) that will be used to test and observe responses; the initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to exist and security attributes they will need to have); CC version 3.1 Page 225 of 237

226 special test equipment that will be required to either stimulate an interface (e.g. packet generators) or make observations of an interface (e.g. network analysers). 948 The evaluator may find it practical to test each interface using a series of test cases, where each test case will test a very specific aspect of expected behaviour of that interface. 949 The evaluator's test documentation should specify the derivation of each test, tracing it back to the relevant interface(s). :ATE_IND.2-8 The evaluator shall conduct testing. 950 The evaluator uses the test documentation developed as a basis for executing tests on the TOE. The test documentation is used as a basis for testing but this does not preclude the evaluator from performing additional ad hoc tests. The evaluator may devise new tests based on behaviour of the TOE discovered during testing. These new tests are recorded in the test documentation. :ATE_IND.2-9 The evaluator shall record the following information about the tests that compose the test subset: identification of the interface behaviour to be tested; instructions to connect and setup all required test equipment as required to conduct the test; instructions to establish all prerequisite test conditions; instructions to stimulate the interface; instructions for observing the interface; descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results; instructions to conclude the test and establish the necessary post-test state for the TOE; actual test results. 951 The level of detail should be such that another evaluator could repeat the tests and obtain an equivalent result. While some specific details of the test results may be different (e.g. time and date fields in an audit record) the overall result should be identical. 952 There may be instances when it is unnecessary to provide all the information presented in this work unit (e.g. the actual test results of a test may not require any analysis before a comparison between the expected results can be Page 226 of 237 CC version

227 made). The determination to omit this information is left to the evaluator, as is the justification. :ATE_IND.2-10 The evaluator shall check that all actual test results are consistent with the expected test results. 953 Any differences in the actual and expected test results may indicate that the TOE does not perform as specified or that the evaluator test documentation may be incorrect. Unexpected actual results may require corrective maintenance to the TOE or test documentation and perhaps require rerunning of impacted tests and modifying the test sample size and composition. This determination is left to the evaluator, as is its justification. :ATE_IND.2-11 The evaluator shall report in the ETR the evaluator testing effort, outlining the testing approach, configuration, depth and results. 954 The evaluator testing information reported in the ETR allows the evaluator to convey the overall testing approach and effort expended on the testing activity during the evaluation. The intent of providing this information is to give a meaningful overview of the testing effort. It is not intended that the information regarding testing in the ETR be an exact reproduction of specific test instructions or results of individual tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the testing approach chosen, amount of evaluator testing performed, amount of developer tests performed, TOE test configurations, and the overall results of the testing activity. 955 Information that would typically be found in the ETR subclause regarding the evaluator testing effort is: TOE test configurations. The particular configurations of the TOE that were tested. subset size chosen. The amount of interfaces that were tested during the evaluation and a justification for the size. selection criteria for the interfaces that compose the subset. Brief statements about the factors considered when selecting interfaces for inclusion in the subset. Interfaces tested. A brief listing of the interfaces that merited inclusion in the subset. developer tests performed. The amount of developer tests performed and a brief description of the criteria used to select the tests. verdict for the activity. The overall judgement on the results of testing during the evaluation CC version 3.1 Page 227 of 237

228 956 This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the testing the evaluator performed during the evaluation. AVA_VAN.2 Vulnerability analysis Dependencies satisfied by: ADV_ARC.1 Security architecture description Error! Reference source not found. Error! Reference source not found. AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures Objectives 957 A vulnerability analysis is performed by the evaluator to ascertain the presence of potential vulnerabilities. 958 The evaluator performs penetration testing, to confirm that the potential vulnerabilities cannot be exploited in the operational environment for the TOE. Penetration testing is performed by the evaluator assuming an attack potential of Basic. Objectives 959 The objective of this sub-activity is to determine whether the TOE, in its operational environment, has vulnerabilities exploitable by attackers possessing Basic attack potential. Application notes 960 The evaluator should consider performing additional tests as a result of potential vulnerabilities encountered during other parts of the evaluation. Input 961 The evaluation evidence for this sub-activity is: the ST; the functional specification; the TOE design; the security architecture description; the guidance documentation; the TOE suitable for testing; Page 228 of 237 CC version

229 information publicly available to support the identification of possible potential vulnerabilities. 962 The remaining implicit evaluation evidence for this sub-activity depends on the components that have been included in the assurance package. The evidence provided for each component is to be used as input in this subactivity. 963 Other input for this sub-activity is: current information regarding public domain potential vulnerabilities and attacks (e.g. from an evaluation authority). Developer action elements: C AVA_VAN.2.1D 964 The developer shall provide the TOE for testing. Content and presentation of evidence elements: C AVA_VAN.2.1C 965 The TOE shall be suitable for testing. Evaluator action elements: C AVA_VAN.2.1E 966 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. :AVA_VAN.2-1 AVA_VAN.2.1C The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. 967 The TOE provided by the developer and identified in the test plan should have the same unique reference as established by the Error! Reference source not found.sub-activities and identified in the ST introduction. 968 It is possible for the ST to specify more than one configuration for evaluation. The TOE may comprise a number of distinct hardware and software entities that need to be tested in accordance with the ST. The evaluator verifies that all test configurations are consistent with the ST. 969 The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment and ensure they are met in the testing environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply CC version 3.1 Page 229 of 237

230 970 If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that these resources are calibrated correctly. :AVA_VAN.2-2 AVA_VAN.2.1C The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state 971 It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous successful completion of the 0sub-activity will satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed properly and is in a known state. If this is not the case, then the evaluator should follow the developer's procedures to install and start up the TOE, using the supplied guidance only. 972 If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work unit when successfully completed could satisfy work unit 0. C AVA_VAN.2.2E 973 The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE. :AVA_VAN.2-3 The evaluator shall examine sources of information publicly available to identify potential vulnerabilities in the TOE. 974 The evaluator examines the sources of information publicly available to support the identification of possible potential vulnerabilities in the TOE. There are many sources of publicly available information which the evaluator should consider using items such as those available on the world wide web, including: specialist publications (magazines, books); research papers. 975 The evaluator should not constrain their consideration of publicly available information to the above, but should consider any other relevant information available. 976 While examining the evidence provided the evaluator will use the information in the public domain to further search for potential vulnerabilities. Where the evaluators have identified areas of concern, the evaluator should consider information publicly available that relate to those areas of concern. 977 The availability of information that may be readily available to an attacker that helps to identify and facilitate attacks may substantially enhance the attack potential of a given attacker. The accessibility of vulnerability information and sophisticated attack tools on the Internet makes it more likely that this information will be used in attempts to identify potential Page 230 of 237 CC version

231 vulnerabilities in the TOE and exploit them. Modern search tools make such information easily available to the evaluator, and the determination of resistance to published potential vulnerabilities and well known generic attacks can be achieved in a cost-effective manner. 978 The search of the information publicly available should be focused on those sources that refer specifically to the product from which the TOE is derived. The extensiveness of this search should consider the following factors: TOE type, evaluator experience in this TOE type, expected attack potential and the level of ADVevidence available. 979 The identification process is iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation. 980 The evaluator will report what actions were taken to identify potential vulnerabilities in the evidence. However, in this type of search, the evaluator may not be able to describe the steps in identifying potential vulnerabilities before the outset of the examination, as the approach may evolve as a result of findings during the search. 981 The evaluator will report the evidence examined in completing the search for potential vulnerabilities. This selection of evidence may be derived from those areas of concern identified by the evaluator, linked to the evidence the attacker is assumed to be able to obtain, or according to another rationale provided by the evaluator. C AVA_VAN.2.3E 982 The evaluator shall perform an independent vulnerability analysis of the TOE using the guidance documentation, functional specification, TOE design and security architecture description to identify potential vulnerabilities in the TOE. :AVA_VAN.2-4 The evaluator shall conduct a search of ST, guidance documentation, functional specification, TOE design and security architecture description evidence to identify possible potential vulnerabilities in the TOE. 983 A search of the evidence should be completed whereby specifications and documentation for the TOE are analysed and then potential vulnerabilities in the TOE are hypothesised, or speculated. The list of hypothesised potential vulnerabilities is then prioritised on the basis of the estimated probability that a potential vulnerability exists and, assuming an exploitable vulnerability does exist the attack potential required to exploit it, and on the extent of control or compromise it would provide. The prioritised list of potential vulnerabilities is used to direct penetration testing against the TOE. 984 The security architecture description provides the developer vulnerability analysis, as it documents how the TSF protects itself from interference from CC version 3.1 Page 231 of 237

232 untrusted subjects and prevents the bypass of security enforcement functionality. Therefore, the evaluator should use this description of the protection of the TSF as a basis for the search for possible ways to undermine the TSF. 985 Subject to the SFRs the TOE is to meet in the operational environment, the evaluator's independent vulnerability analysis should consider generic potential vulnerabilities under each of the following headings: generic potential vulnerabilities relevant for the type of TOE being evaluated, as may be supplied by the evaluation authority; bypassing; tampering; direct attacks; monitoring; misuse. 986 Items b) - f) are explained in greater detail in Error! Reference source not found The security architecture description should be considered in light of each of the above generic potential vulnerabilities. Each potential vulnerability should be considered to search for possible ways in which to defeat the TSF protection and undermine the TSF. :AVA_VAN.2-5 The evaluator shall record in the ETR the identified potential vulnerabilities that are candidates for testing and applicable to the TOE in its operational environment. 988 It may be identified that no further consideration of the potential vulnerability is required if for example the evaluator identifies that measures in the operational environment, either IT or non-it, prevent exploitation of the potential vulnerability in that operational environment. For instance, restricting physical access to the TOE to authorised users only may effectively render a potential vulnerability to tampering unexploitable. 989 The evaluator records any reasons for exclusion of potential vulnerabilities from further consideration if the evaluator determines that the potential vulnerability is not applicable in the operational environment. Otherwise the evaluator records the potential vulnerability for further consideration. 990 A list of potential vulnerabilities applicable to the TOE in its operational environment, which can be used as an input into penetration testing activities, shall be reported in the ETR by the evaluators. Page 232 of 237 CC version

233 C AVA_VAN.2.4E 991 The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential. :AVA_VAN.2-6 The evaluator shall devise penetration tests, based on the independent search for potential vulnerabilities. 992 The evaluator prepares for penetration testing as necessary to determine the susceptibility of the TOE, in its operational environment, to the potential vulnerabilities identified during the search of the sources of information publicly available. Any current information provided to the evaluator by a third party (e.g. evaluation authority) regarding known potential vulnerabilities will be considered by the evaluator, together with any encountered potential vulnerabilities resulting from the performance of other evaluation activities. 993 The evaluator is reminded that, as for considering the security architecture description in the search for vulnerabilities (as detailed in AVA_VAN.2-4), testing should be performed to confirm the architectural properties. This is likely to require negative tests attempting to disprove the properties of the security architecture. In developing the strategy for penetration testing, the evaluator will ensure that each of the major characteristics of the security architecture description are tested, either in functional testing (as considered in Error! Reference source not found.) or evaluator penetration testing. 994 The evaluator will probably find it practical to carry out penetration test using a series of test cases, where each test case will test for a specific potential vulnerability. 995 The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a Basic attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond Basic attack potential, this is reported in the ETR as a residual vulnerability. 996 Guidance on determining the necessary attack potential to exploit a potential vulnerability can be found in Annex Error! Reference source not found Potential vulnerabilities hypothesised as exploitable only by attackers possessing Enhanced-Basic, Moderate or High attack potential do not result in a failure of this evaluator action. Where analysis supports the hypothesis, these need not be considered further as an input to penetration testing. However, such vulnerabilities are reported in the ETR as residual vulnerabilities. 998 Potential vulnerabilities hypothesised as exploitable by an attacker possessing a Basic attack potential and resulting in a violation of the security CC version 3.1 Page 233 of 237

234 objectives should be the highest priority potential vulnerabilities comprising the list used to direct penetration testing against the TOE. :AVA_VAN.2-7 The evaluator shall produce penetration test documentation for the tests based on the list of potential vulnerabilities in sufficient detail to enable the tests to be repeatable. The test documentation shall include: identification of the potential vulnerability the TOE is being tested for; instructions to connect and setup all required test equipment as required to conduct the penetration test; instructions to establish all penetration test prerequisite initial conditions; instructions to stimulate the TSF; instructions for observing the behaviour of the TSF; descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results; instructions to conclude the test and establish the necessary post-test state for the TOE. 999 The evaluator prepares for penetration testing based on the list of potential vulnerabilities identified during the search of the public domain and the analysis of the evaluation evidence The evaluator is not expected to determine the exploitability for potential vulnerabilities beyond those for which a Basic attack potential is required to effect an attack. However, as a result of evaluation expertise, the evaluator may discover a potential vulnerability that is exploitable only by an attacker with greater than Basic attack potential. Such vulnerabilities are to be reported in the ETR as residual vulnerabilities With an understanding of the potential vulnerability, the evaluator determines the most feasible way to test for the TOE's susceptibility. Specifically the evaluator considers: the TSFI or other TOE interface that will be used to stimulate the TSF and observe responses (It is possible that the evaluator will need to use an interface to the TOE other than the TSFI to demonstrate properties of the TSF such as those described in the security architecture description (as required by ADV_ARC). It should the noted, that although these TOE interfaces provide a means of testing the TSF properties, they are not the subject of the test.); Page 234 of 237 CC version

235 initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to exist and security attributes they will need to have); special test equipment that will be required to either stimulate a TSFI or make observations of a TSFI (although it is unlikely that specialist equipment would be required to exploit a potential vulnerability assuming a Basic attack potential); whether theoretical analysis should replace physical testing, particularly relevant where the results of an initial test can be extrapolated to demonstrate that repeated attempts of an attack are likely to succeed after a given number of attempts The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where each test case will test for a specific potential vulnerability The intent of specifying this level of detail in the test documentation is to allow another evaluator to repeat the tests and obtain an equivalent result. :AVA_VAN.2-8 The evaluator shall conduct penetration testing The evaluator uses the penetration test documentation resulting from work unit 0as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learnt during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing Should penetration testing show that a hypothesised potential vulnerability does not exist, then the evaluator should determine whether or not the evaluator's own analysis was incorrect, or if evaluation deliverables are incorrect or incomplete The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a Basic attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond basic attack potential, this is reported in the ETR as a residual vulnerability. :AVA_VAN.2-9 The evaluator shall record the actual results of the penetration tests While some specific details of the actual test results may be different from those expected (e.g. time and date fields in an audit record) the overall result should be identical. Any unexpected test results should be investigated. The impact on the evaluation should be stated and justified CC version 3.1 Page 235 of 237

236 :AVA_VAN.2-10 The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration testing approach and effort expended on this sub-activity. The intent of providing this information is to give a meaningful overview of the evaluator's penetration testing effort. It is not intended that the information regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual penetration tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the penetration testing approach chosen, amount of penetration testing performed, TOE test configurations, and the overall results of the penetration testing activity Information that would typically be found in the ETR subclause regarding evaluator penetration testing efforts is: TOE test configurations. The particular configurations of the TOE that were penetration tested; TSFI penetration tested. A brief listing of the TSFI and other TOE interfaces that were the focus of the penetration testing; Verdict for the sub-activity. The overall judgement on the results of penetration testing This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the penetration testing the evaluator performed during the evaluation. :AVA_VAN.2-11 The evaluator shall examine the results of all penetration testing to determine that the TOE, in its operational environment, is resistant to an attacker possessing a Basic attack potential If the results reveal that the TOE, in its operational environment, has vulnerabilities exploitable by an attacker possessing less than an Enhanced- Basic attack potential, then this evaluator action fails The guidance in Error! Reference source not found.should be used to determine the attack potential required to exploit a particular vulnerability and whether it can therefore be exploited in the intended environment. It may not be necessary for the attack potential to be calculated in every instance, only if there is some doubt as to whether or not the vulnerability can be exploited by an attacker possessing an attack potential less than Enhanced- Basic. :AVA_VAN.2-12 The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing for each: Page 236 of 237 CC version

237 its source (e.g. CEM activity being undertaken when it was conceived, known to the evaluator, read in a publication); the SFR(s) not met; a description; whether it is exploitable in its operational environment or not (i.e. exploitable or residual). the amount of time, level of expertise, level of knowledge of the TOE, level of opportunity and the equipment required to perform the identified vulnerabilities, and the corresponding values using the tables Error! Reference source not found.and Error! Reference source not found.of Annex Error! Reference source not found CC version 3.1 Page 237 of 237