CC STs are produced to the same level of rigour regardless of assurance level. At low levels of assurance this is disproportionately high compared with the overall TOE evaluation effort. Guidance for an EAL1 ST is proposed. The 3 Certification Bodies of CESG, BSI and DCSSI plus NLNCSA produced this proposal.

Guidance for EAL1 Security Targets

This guidance is structured according to the different sections of the ST that need to be completed (see [CC] Part 1, Figure C.1; and also [GUIDE]Chapter 2, section 2.3, table 2). Much of the guidance which follows applies where the ST makes no claims of conformance with any PPs. In the event that such claims are made, the work of the ST author can be reduced by including or referencing PP details with respect to the statement of TOE security environment, security objectives, and security requirements.

ST Introduction

It is not necessary to provide an ST introduction. In other words, there is no need to provide an ST overview or include a CC conformance claim. It is only necessary for the ST to uniquely identify both the TOE and the ST.

TOE description

This section of the ST is required to clearly define the scope of the TOE and its evaluated configurations. Additional information may be provided in this section to the extent considered necessary to provide the reader with contextual information in order to be able to understand the rest of the ST, e.g. describing the intended use of the TOE.

TOE Security Environment

It is necessary to clearly articulate the threats, organisational security policies (OSPs) and assumptions about the environment. To provide a context for the threat specifications, a description of the assets and threat agents should be provided. Threats must be clearly defined in terms of the asset at risk, the threat agent and a brief statement of the attack (e.g. physical, logical, observe, modify). Threat, OSP and assumption statements should be clear and unambiguous. Additional explanation of the TOE security environment aspects should be provided only where necessary; ideally, the statements themselves should be sufficient for the reader to be able to clearly understand the intent.

Security objectives

The main purpose of this section is to clearly define the scope of responsibilities for addressing the Threats, OSPs and Assumptions between the TOE and its environment (including the IT environment). Security objectives should be clearly articulated. However, the security objective statements should be brief and not require further elaboration or explanation; they should provide only the minimum information that is needed in order to enable a reader to determine their suitability to address the security problem. The number of security objectives should, within these constraints, be kept to a minimum. (Alternatively, instead of providing a separate rationale for Threats, OSP and Assumptions, it is acceptable to add the list of Threats, OSP and Assumptions to each Objective Statement.)

Security Requirements

Security functional requirements. The key requirement here is for the ST to contain a set of clearly understandable, unambiguous and testable SFRs. There is no requirement to demonstrate conformance to [CC] Part 2 or justify deviation from it: it is simply to be viewed as a tool that may assist the ST author in the construction of SFRs which meet the above criteria. The following specific guidelines should be followed:

[CC] Part 2 components should be used only where they are obviously suitable for articulating the required functionality. This will generally be the case for 'common' requirements such as audit generation (FAU_GEN.1), access control (FDP_ACF.1), user identification and authentication (FIA_UID.1 and FIA_UAU.1), and so on. [GUIDE] Annex B, section B.7, should be consulted for guidance when identifying functional components for 'common'security requirements. If it is not obvious which is the appropriate CC Part 2 functional component to use, the ST author should construct his/her own SFRs, ensuring that they satisfy the key criteria stated above. No justification is needed for such deviation from CC Part 2. If an appropriate functional component is selected, the ST author should not be constrained by the precise wording as it appears in [CC] Part 2, but should amend it whatever way seems appropriate to express the required functionality. Moreover: requirements elements associated with SFRs may be omitted from an included component if they are not necessary to address the security problem. Completed operations do not need to be highlighted in the ST and freedom to modify the wording of the [CC] Part 2 component applies to the defined assignment and selection operations as well as the core text. Dependencies between functional components should be considered as a check to determine that the set of SFRs is complete. There is no obligation to satisfy dependencies even if they are relevant to the TOE; as a general principle, the set of SFRs should be kept to the minimum that is necessary to address the security problem. Note: an author of an EAL1 ST may choose to spend more effort in the attempt to use appropriate [CC] Part 2 functional components if it is envisaged that a subsequent evaluation may be needed for which a CC-conformant ST will be needed. In this scenario, additional effort invested at this stage may reduce the effort needed to subsequently 'upgrade' the ST to full compliance with CC requirements.

Security assurance requirements

SARs should be stated by reference to an EAL, or explicitly as a list of assurance components. The requirements elements themselves should not be repeated verbatim from [CC] Part 3 unless the requirements are to be refined in any way. Security requirements for the IT environment Dependencies on the IT environment should be clearly stated in the ST, but there is no absolute need to use [CC] Part 2 components to do so.

TOE Summary Specification

There is no need for a separate specification of IT security functions and assurance measures. The IT security functions can be considered to be defined by the SFRs as stated in the preceding section. This is because a statement of SFRs and IT security functions effectively state the same things; therefore, there is no value in including two such statements of security functionality (which then have to be checked for consistency). Similarly, no value (in assurance terms) is provided by including a definition of assurance measures in the ST.

ST Rationale

No separate rationale is needed. However, the following mappings may be provided in the ST if considered appropriate as an aid to reader understanding: threats, OSPs and assumptions to security objectives. (Note: if the mapping of security objectives to Threats, OSPs and Assumptions has been satisfied during the Security Objectives section, it will only be necessary to include TOE Security Objectives to SFRs. This mapping could be given in tablature form.)

TOE Security Objectives to SFRs.

If such mappings are included, these should be presented in tabular form. The removal of the distinction between security requirements and IT security functions and assurance measures removes the need for any mappings between the TOE summary specification and the TOE security requirements. The various analyses that collectively form the ST rationale are thus performed by the ST evaluator rather than the ST author.