1  Scope

Security functional components, as defined in this CC Part 2, are the basis for the TOE IT security functional requirements expressed in a Protection Profile (PP) or a Security Target (ST). These requirements describe the desired security behaviour expected of a Target of Evaluation (TOE) and are intended to meet the security objectives as stated in a PP or an ST. These requirements describe security properties that users can detect by direct interaction with the TOE (i.e. inputs, outputs) or by the TOE's response to stimulus.

Security functional components express security requirements intended to counter threats in the assumed operating environment of the TOE and/or cover any identified organisational security policies and assumptions.

The audience for this CC Part 2 includes consumers, developers, and evaluators of secure IT systems and products. CC Part 1 clause 3 provides additional information on the target audience of the CC, and on the use of the CC by the groups that comprise the target audience. These groups may use this part of the CC as follows:

-        Consumers who use CC Part 2 when selecting components to express functional requirements to satisfy the security objectives expressed in a PP or ST. CC Part 1 subclause 4.3 provides more detailed information on the relationship between security objectives and security requirements.

-        Developers, who respond to actual or perceived consumer security requirements in constructing a TOE, may find a standardised method to understand those requirements in this part of the CC. They can also use the contents of this part of the CC as a basis for further defining the TOE security functions and mechanisms that comply with those requirements.

-        Evaluators, who use the functional requirements defined in this part of the CC in verifying that the TOE functional requirements expressed in the PP or ST satisfy the IT security objectives and that all dependencies are accounted for and shown to be satisfied. Evaluators also should use this part of the CC to assist in determining whether a given TOE satisfies stated requirements.

1.1  Extending and maintaining functional requirements

The CC and the associated security functional requirements described herein are not meant to be a definitive answer to all the problems of IT security. Rather, the CC offers a set of well understood security functional requirements that can be used to create trusted products or systems reflecting the needs of the market. These security functional requirements are presented as the current state of the art in requirements specification and evaluation.

This part of the CC does not presume to include all possible security functional requirements but rather contains those that are known and agreed to be of value by the CC Part 2 authors at the time of release.

Since the understanding and needs of consumers may change, the functional requirements in this part of the CC will need to be maintained. It is envisioned that some PP/ST authors may have security needs not (yet) covered by the functional requirement components in CC Part 2. In those cases the PP/ST author may choose to consider using functional requirements not taken from the CC (referred to as extensibility), as explained in annexes B and C of CC Part 1.

1.2  Organisation of CC Part 2

Clause 1 is the introductory material for CC Part 2.

Clause 2 introduces the catalogue of CC Part 2 functional components while clauses 3 through 13 describe the functional classes.

Annex A provides additional information of interest to potential users of the functional components including a complete cross reference table of the functional component dependencies.

Annexes B through M provide the application notes for the functional classes. They are a repository for informative supporting material for the users of this part of the CC, which may help them to apply relevant operations and select appropriate audit or documentation information.

Those who author PPs or STs should refer to clause 2 of CC Part 1 for relevant structures, rules, and guidance:

-       CC Part 1, clause 2 defines the terms used in the CC.

-       CC Part 1, annex B defines the structure for PPs.

-       CC Part 1, annex C defines the structure for STs.

1.3  Functional requirements paradigm

This subclause describes the paradigm used in the security functional requirements of this part of the CC. Figures 1.1 and 1.2 depict some of the key concepts of the paradigm. This subclause provides descriptive text for those figures and for other key concepts not depicted. Key concepts discussed are highlighted in bold/italics. This subclause is not intended to replace or supersede any of the terms found in the CC glossary in CC Part 1, clause 2.


Figure 1.1 - Security functional requirements paradigm (Monolithic TOE)

This part of the CC is a catalogue of security functional requirements that can be specified for a Target of Evaluation (TOE). A TOE is an IT product or system (along with user and administrator guidance documentation) containing resources such as electronic storage media (e.g. disks), peripheral devices (e.g. printers), and computing capacity (e.g. CPU time) that can be used for processing and storing information and is the subject of an evaluation.

TOE evaluation is concerned primarily with ensuring that a defined TOE Security Policy (TSP) is enforced over the TOE resources. The TSP defines the rules by which the TOE governs access to its resources, and thus all information and services controlled by the TOE.

The TSP is, in turn, made up of multiple Security Function Policies (SFPs). Each SFP has a scope of control, that defines the subjects, objects, and operations controlled under the SFP. The SFP is implemented by a Security Function (SF), whose mechanisms enforce the policy and provide necessary capabilities.


Figure 1.2 - Diagram of security functions in a distributed TOE

Those portions of a TOE that must be relied on for the correct enforcement of the TSP are collectively referred to as the TOE Security Functions (TSF). The TSF consists of all hardware, software, and firmware of a TOE that is either directly or indirectly relied upon for security enforcement.

A reference monitor is an abstract machine that enforces the access control policies of a TOE. A reference validation mechanism is an implementation of the reference monitor concept that possesses the following properties: tamperproof, always invoked, and simple enough to be subjected to thorough analysis and testing. The TSF may consist of a reference validation mechanism and/or other security functions necessary for the operation of the TOE.

The TOE may be a monolithic product containing hardware, firmware, and software.

Alternatively a TOE may be a distributed product that consists internally of multiple separated parts. Each of these parts of the TOE provides a particular service for the TOE, and is connected to the other parts of the TOE through an internal communication channel. This channel can be as small as a processor bus, or may encompass a network internal to the TOE.

When the TOE consists of multiple parts, each part of the TOE may have its own part of the TSF which exchanges user and TSF data over internal communication channels with other parts of the TSF. This interaction is called internal TOE transfer. In this case the separate parts of the TSF abstractly form the composite TSF, which enforces the TSP.

TOE interfaces may be localised to the particular TOE, or they may allow interaction with other IT products over external communication channels. These external interactions with other IT products may take two forms:

a)    The security policy of the 'remote trusted IT product' and the TSP of the local TOEs have been administratively coordinated and evaluated. Exchanges of information in this situation are called inter-TSF transfers, as they are between the TSFs of distinct trusted products.

b)    The remote IT product may not be evaluated, indicated in Figure 1.2 as 'untrusted IT product', therefore its security policy is unknown. Exchanges of information in this situation are called transfers outside TSF control, as there is no TSF (or its policy characteristics are unknown) on the remote IT product.

The set of interactions that can occur with or within a TOE and are subject to the rules of the TSP is called the TSF Scope of Control (TSC). The TSC encompasses a defined set of interactions based on subjects, objects, and operations within the TOE, but it need not encompass all resources of a TOE.

The set of interfaces, whether interactive (man-machine interface) or programmatic (application programming interface), through which resources are accessed that are mediated by the TSF, or information is obtained from the TSF, is referred to as the TSF Interface (TSFI). The TSFI defines the boundaries of the TOE functions that provide for the enforcement of the TSP.

Users are outside of the TOE, and therefore outside of the TSC. However, in order to request that services be performed by the TOE, users interact with the TOE through the TSFI. There are two types of users of interest to the CC Part 2 security functional requirements: human users and external IT entities. Human users are further differentiated as local human users, meaning they interact directly with the TOE via TOE devices (e.g. workstations), or remote human users, meaning they interact indirectly with the TOE through another IT product.

A period of interaction between users and the TSF is referred to as a user session. Establishment of user sessions can be controlled based on a variety of considerations, for example: user authentication, time of day, method of accessing the TOE, and number of allowed concurrent sessions per user.

This part of the CC uses the term authorised to signify a user who possesses the rights and/or privileges necessary to perform an operation. The term authorised user, therefore, indicates that it is allowable for a user to perform an operation as defined by the TSP.

To express requirements that call for the separation of administrator duties, the relevant CC Part 2 security functional components (from family FMT_SMR) explicitly state that administrative roles are required. A role is a pre-defined set of rules establishing the allowed interactions between a user and the TOE. A TOE may support the definition of any number of roles. For example, roles related to the secure operation of a TOE may include "Audit Administrator" and "User Accounts Administrator".

TOEs contain resources that may be used for the processing and storing of information. The primary goal of the TSF is the complete and correct enforcement of the TSP over the resources and information that the TOE controls.

TOE resources can be structured and utilised in many different ways. However, CC Part 2 makes a specific distinction that allows for the specification of desired security properties. All entities that can be created from resources can be characterised in one of two ways. The entities may be active, meaning that they are the cause of actions that occur internal to the TOE and cause operations to be performed on information. Alternatively, the entities may be passive, meaning that they are either the container from which information originates or to which information is stored.

Active entities are referred to as subjects. Several types of subjects may exist within a TOE:

a)    those acting on behalf of an authorised user and which are subject to all therules of the TSP (e.g. UNIX processes);

b)    those acting as a specific functional process that may in turn act on behalf of multiple users (e.g. functions as might be found in client/server architectures); or

c)    those acting as part of the TOE itself (e.g. trusted processes).

CC Part 2 addresses the enforcement of the TSP over types of subjects as those listed above.

Passive entities (i.e. information containers) are referred to in the CC Part 2 security functional requirements as objects. Objects are the targets of operations that may be performed by subjects. In the case where a subject (an active entity) is the target of an operation (e.g. interprocess communication), a subject may also be acted on as an object.

Objects can contain information. This concept is required to specify information flow control policies as addressed in the FDP class.

Users, subjects, information and objects possess certain attributes that contain information that allows the TOE to behave correctly. Some attributes, such as file names, may be intended to be informational (i.e. to increase the user-friendliness of the TOE) while others, such as access control information, may exist specifically for the enforcement of the TSP. These latter attributes are generally referred to as 'security attributes'. The word attribute will be used as a shorthand in this part of the CC for the word 'security attribute', unless otherwise indicated. However, no matter what the intended purpose of the attribute information, it may be necessary to have controls on attributes as dictated by the TSP.

Data in a TOE is categorised as either user data or TSF data. Figure 1.3 depicts this relationship. User Data is information stored in TOE resources that can be operated upon by users in accordance with the TSP and upon which the TSF places no special meaning. For example, the contents of an electronic mail message is user data. TSF Data is information used by the TSF in making TSP decisions. TSF Data may be influenced by users if allowed by the TSP. Security attributes, authentication data and access control list entries are examples of TSF data.

There are several SFPs that apply to data protection such as access control SFPs and information flow control SFPs. The mechanisms that implement access control SFPs base their policy decisions on attributes of the subjects, objects and operations within the scope of control. These attributes are used in the set of rules that govern operations that subjects may perform on objects.

The mechanisms that implement information flow control SFPs base their policy decisions on the attributes of the subjects and information within the scope of control and the set of rules that govern the operations by subjects on information. The attributes of the information, which may be associated with the attributes of the container (or may not, as in the case of a multi-level database) stay with the information as it moves.


Figure 1.3 - Relationship between user data and TSF data

Two specific types of TSF data addressed by CC Part 2 can be, but are not necessarily, the same. These are authentication data and secrets.

Authentication data is used to verify the claimed identity of a user requesting services from a TOE. The most common form of authentication data is the password, which depends on being kept secret in order to be an effective security mechanism. However, not all forms of authentication data need to be kept secret. Biometric authentication devices (e.g. fingerprint readers, retinal scanners) do not rely on the fact that the data is kept secret, but rather that the data is something that only one user possesses and that cannot be forged./P>

The term secrets, as used in CC Part 2 functional requirements, while applicable to authentication data, is intended to also be applicable to other types of data that must be kept secret in order to enforce a specific SFP. For example, a trusted channel mechanism that relies on cryptography to preserve the confidentiality of information being transmitted via the channel can only be as strong as the method used to keep the cryptographic keys secret from unauthorised disclosure.

Therefore, some, but not all, authentication data needs to be kept secret and some, but not all, secrets are used as authentication data. Figure 1.4 shows this relationship between secrets and authentication data. In the Figure the types of data typically encountered in the authentication data and the secrets sections are indicated.


Figure 1.4 - Relationship between "authentication data" and "secrets"