An ST contains the IT security requirements of an identified TOE and specifies the functional and assurance security measures offered by that TOE to meet stated requirements.
The ST for a TOE is a basis for agreement between the developers, evaluators and, where appropriate, consumers on the security properties of the TOE and the scope of the evaluation. The audience for the ST is not confined to those responsible for the production of the TOE and its evaluation, but may also include those responsible for managing, marketing, purchasing, installing, configuring, operating, and using the TOE.
205 The ST may incorporate the requirements of, or claim conformance to, one or more PPs. The impact of such a PP conformance claim is not considered when initially defining the required ST content in subclause C.2. Subclause C.2.8 addresses the impact of a PP conformance claim on the required ST content.
This annex contains the requirements for the ST in descriptive form. The assurance class ASE, contained in clause 5 of CC Part 3, contains these requirements in the form of assurance components to be used for evaluation of the ST.
An ST shall conform to the content requirements described in this annex. An ST should be presented as a user-oriented document that minimises reference to other material that might not be readily available to the ST user. The rationale may be supplied separately, if that is appropriate.
The contents of the ST are portrayed in Figure C.1, which should be used when constructing the structural outline of the ST.
The ST introduction shall contain the following document management and overview information.
a) The ST identification shall provide the labelling and descriptive information necessary to control and identify the ST and the TOE to which it refers.
b) The ST overview shall summarise the ST in narrative form. The overview should be sufficiently detailed for a potential consumer of the TOE to determine whether the TOE is of interest. The overview should also be usable as a stand alone abstract for incorporation in evaluated products lists.
c) A CC conformance claim shall state any evaluatable claim of CC conformance for the TOE, as identified in section 5.4 of this Part 1.
Figure C.1 - Security Target content
This part of the ST shall describe the TOE as an aid to the understanding of its security requirements, and shall address the product or system type. The scope and boundaries of the TOE shall be described in general terms both in a physical way (hardware and/or software components/modules) and a logical way (IT and security features offered by the TOE).
The TOE description provides context for the evaluation. The information presented in the TOE description will be used in the course of the evaluation to identify inconsistencies. If the TOE is a product or system whose primary function is security, this part of the ST may be used to describe the wider application context into which such a TOE will fit.
The statement of TOE security environment shall describe the security aspects of the environment in which the TOE is intended to be used and the manner in which it is expected to be employed. This statement shall include the following:
a) A description of assumptions shall describe the security aspects of the
environment in which the TOE will be used or is intended to be used. This
shall include the following:
information about the intended usage of the TOE, including such aspects as
the intended application, potential asset value, and possible limitations of
use; and information about the environment of use of the TOE, including
physical, personnel, and connectivity aspects.
b) A description of threats shall include all threats to the assets against which
specific protection within the TOE or its environment is required. Note that
not all possible threats that might be encountered in the environment need
to be listed, only those which are relevant for secure TOE operation.
A threat shall be described in terms of an identified threat agent, the attack,
and the asset that is the subject of the attack. Threat agents should be
described by addressing aspects such as expertise, available resources, and
motivation. Attacks should be described by addressing aspects such as
attack methods, any vulnerabilities exploited, and opportunity.
If security objectives are derived from only organisational security policies
and assumptions, then the description of threats may be omitted.
c) A description of organisational security policies shall identify, and if
necessary explain, any organisational security policy statements or rules
with which the TOE must comply. Explanation and interpretation may be
necessary to present any individual policy statement in a manner that
permits it to be used to set clear security objectives.
If security objectives are derived from only threats and assumptions, then
the description of organisational security policies may be omitted.
Where the TOE is physically distributed, it may be necessary to discuss the security environmental aspects (assumptions, threats, organisational security policies) separately for distinct domains of the TOE environment.
The statement of security objectives shall define the security objectives for the TOE and its environment. The security objectives shall address all of the security environment aspects identified. The security objectives shall reflect the stated intent and shall be suitable to counter all identified threats and cover all identified organisational security policies and assumptions. The following categories of objectives shall be identified. Note: when a threat or organisational security policy is to be covered partly by the TOE and partly by its environment, then the related objective shall be repeated in each category.
a) The security objectives for the TOE shall be clearly stated and traced back to aspects of identified threats to be countered by the TOE and/or organisational security policies to be met by the TOE.
b) The security objectives for the environment shall be clearly stated and
traced back to aspects of identified threats not completely countered by the
TOE and/or organisational security policies or assumptions not completely
met by the TOE.
Note that security objectives for the environment may be a re-statement, in
whole or part, of the assumptions portion of the statement of the TOE
security environment.
This part of the ST defines the detailed IT security requirements that shall be satisfied by the TOE or its environment. The IT security requirements shall be stated as follows:
a) The statement of TOE security requirements shall define the functional and assurance security requirements that the TOE and the supporting evidence for its evaluation need to satisfy in order to meet the security objectives for the TOE. The TOE security requirements shall be stated as follows:
1) The statement of TOE security functional requirements should
define the functional requirements for the TOE as functional
components drawn from Part 2 where applicable.
drawn from Part 2 where applicable.
Where necessary to cover different aspects of the same requirement
(e.g. identification of more than one type of user), repetitive use (i.e.,
applying the operation of iteration) of the same Part 2 component to
cover each aspect is possible.
Where AVA_SOF.1 is included in the TOE security assurance
requirements (e.g. EAL2 and higher), the statement of TOE security
functional requirements shall include a minimum strength level for
the TOE security functions realised by a probabilistic or
permutational mechanism (e.g. a password or hash function). All such functions shall meet this minimum level. The level shall be one
of the following: SOF-basic, SOF-medium, SOF-high. The selection
of the level shall be consistent with the identified security objectives
for the TOE. Optionally, specific strength of function metrics may
be defined for selected functional requirements, in order to meet
certain security objectives for the TOE.
As part of the strength of TOE security functions evaluation
(AVA_SOF.1), it will be assessed whether the strength claims made
for individual TOE security functions and the overall minimum
strength level are met by the TOE.
2) The statement of TOE security assurance requirements should state the assurance requirements as one of the EALs optionally augmented by Part 3 assurance components. The ST may also extend the EAL by explicitly stating additional assurance requirements not taken from Part 3.
b) The optional statement of security requirements for the IT environment
shall identify the IT security requirements that are to be met by the IT
environment of the TOE. If the TOE has no asserted dependencies on the IT
environment, this part of the ST may be omitted.
Note that security requirements for the non-IT environment, while often
useful in practice, are not required to be a formal part of the ST as they do
not relate directly to the implementation of the TOE.
c) The following common conditions shall apply equally to the expression of security functional and assurance requirements for the TOE and its IT environment:
1) All IT security requirements should be stated by reference to security requirements components drawn from Part 2 or Part 3 where applicable. Should none of the Part 2 or Part 3 requirements components be readily applicable to all or part of the security requirements, the ST may state those requirements explicitly without reference to the CC.
2) Any explicit statement of TOE security functional or assurance requirements shall be clearly and unambiguously expressed such that evaluation and demonstration of compliance is feasible. The level of detail and manner of expression of existing CC functional or assurance requirements shall be used as a model.
3) Any required operations shall be used to amplify the requirements to the level of detail necessary to demonstrate that the security objectives are met. All specified operations on the requirements components shall be performed.
4) All dependencies among the IT security requirements should be satisfied. Dependencies may be satisfied by the inclusion of the relevant requirement within the TOE security requirements, or as a requirement on the environment.
The TOE summary specification shall define the instantiation of the security requirements for the TOE. This specification shall provide a description of the security functions and assurance measures of the TOE that meet the TOE security requirements. Note that the functional information provided as part of the TOE summary specification could be identical in some cases to the information to be provided for the TOE as part of the ADV_FSP requirements.
The TOE summary specification contains the following:
a) The statement of TOE security functions shall cover the IT security functions and shall specify how these functions satisfy the TOE security functional requirements. This statement shall include a bi-directional mapping between functions and requirements that clearly shows which functions satisfy which requirements and that all requirements are met. Each security function shall, as a minimum, contribute to the satisfaction of at least one TOE security functional requirement.
1) The IT security functions shall be defined in an informal style to a level of detail necessary for understanding their intent.
2) All references to security mechanisms included in the ST shall be traced to the relevant security functions so that it can be seen which security mechanisms are used in the implementation of each function.
3) When AVA_SOF.1 is included in the TOE assurance requirements, all IT security functions that are realised by a probabilistic or permutational mechanism (e.g. a password or hash function), shall be identified. The likelihood to breach the mechanisms of such functions by deliberate or accidental attack is of relevance to the security of the TOE. A strength of TOE security function analysis shall be provided for all these functions. The strength of each identified function shall be determined and claimed as either SOF-basic, SOF-medium or SOF-high, or as the optionally defined specific metric. The evidence provided about the strength of function shall be sufficient to allow the evaluators to make their independent assessment and to confirm that the strength claims are adequate and correct.
b) The statement of assurance measures specifies the assurance measures of
the TOE which are claimed to satisfy the stated assurance requirements. The
assurance measures shall be traced to the assurance requirements so that it can be seen which measures contribute to the satisfaction of which
requirements.
If appropriate, the definition of assurance measures may be made by
reference to relevant quality plans, life cycle plans, or management plans.
The ST may optionally make a claim that the TOE conforms with the requirements of one (or possibly more than one) PP. For any PP conformance claims made, the ST shall include a PP claims statement that contains the explanation, justification, and any other supporting material necessary to substantiate the claims.
The content and presentation of the ST statements of TOE objectives and requirements could be affected by PP claims made for the TOE. The impact on the ST can be summarised by considering the following cases for each PP claimed:
a) If there is no claim of PP compliance made, then the full presentation of the TOE objectives and requirements should be made as described in this annex. No PP claims are included.
b) If the ST claims only compliance with the requirements of a PP without need for further qualification, then reference to the PP is sufficient to define and justify the TOE objectives and requirements. Restatement of the PP contents is unnecessary.
c) If the ST claims compliance with the requirements of a PP, and that PP requires further qualification, then the ST shall show that the PP requirements for qualification have been met. Such a situation would typically arise where the PP contains uncompleted operations. In such a situation, the ST may refer to the specific requirements but complete the operations within the ST. In some circumstances, where the requirements to complete operations are substantial, it may be preferable to restate the PP contents within the ST as an aid to clarity.
d) If the ST claims compliance with the requirements of a PP but extends that PP by the addition of further objectives and requirements, then the ST shall define the additions, whereas a PP reference may be sufficient to define the PP objectives and requirements. In some circumstances, where the additions are substantial, it may be preferable to restate the PP contents within the ST as an aid to clarity.
e) The case where an ST claims to be partially conformant to a PP is not admissible for CC evaluation.
The CC is not prescriptive with respect to the choice of restating or referencing PP objectives and requirements. The fundamental requirement is that the ST content be complete, clear, and unambiguous such that evaluation of the ST is possible, the ST is an acceptable basis for the TOE evaluation, and the traceability to any claimed PP is clear.
If any PP conformance claim is made, the PP claims statement shall contain the following material for each PP claimed.
a) The PP reference statement shall identify the PP for which compliance is being claimed plus any amplification that may be needed with respect to that claim. A valid claim implies that the TOE meets all the requirements of the PP.
b) The PP tailoring statement shall identify the IT security requirements statements that satisfy the permitted operations of the PP or otherwise further qualify the PP requirements.
c) The PP additions statement shall identify the TOE objectives and requirements statements that are additional to the PP objectives and requirements.
This part of the ST presents the evidence used in the ST evaluation. This evidence supports the claims that the ST is a complete and cohesive set of requirements, that a conformant TOE would provide an effective set of IT security countermeasures within the security environment, and that the TOE summary specification addresses the requirements. The rationale also demonstrates that any PP conformance claims are valid. The rationale shall include the following:
a) The security objectives rationale shall demonstrate that the stated security objectives are traceable to all of the aspects identified in the TOE security environment and are suitable to cover them.
b) The security requirements rationale shall demonstrate that the set of security requirements (TOE and environment) is suitable to meet and traceable to the security objectives. The following shall be demonstrated:
1) that the combination of the individual functional and assurance requirements components for the TOE and its IT environment together meet the stated security objectives;
2) that the set of security requirements together forms a mutually supportive and internally consistent whole;
3) that the choice of security requirements is justified. Any of the
following conditions shall be specifically justified:
-- choice of requirements not contained in Parts 2 or 3;
-- choice of assurance requirements not including an EAL; and
-- non-satisfaction of dependencies;
4) that the selected strength of function level for the ST, together with any explicit strength of function claim, is consistent with the security objectives for the TOE.
c) The TOE summary specification rationale shall show that the TOE security functions and assurance measures are suitable to meet the TOE security requirements. The following shall be demonstrated:
1) that the combination of specified TOE IT security functions work together so as to satisfy the TOE security functional requirements;
2) that the strength of TOE function claims made are valid, or that assertions that such claims are unnecessary are valid.
3) that the claim is justified that the stated assurance measures are compliant with the assurance requirements.
The statement of rationale shall be presented at a level of detail that matches the level of detail of the definition of the security functions.
d) The PP claims rationale statement shall explain any difference between the ST security objectives and requirements and those of any PP to which conformance is claimed. This part of the ST may be omitted if no claims of PP conformance are made or if ST security objectives and requirements are identical to those of any claimed PP.
This potentially bulky material may be distributed separately as it may not be appropriate or useful to all ST users.