The CEM for ADV_SPM.1 defines the evaluator actions for the evaluation of the Informal TOE Security Policy Model (ISPM). It remains unclear what additional material is needed to meet this requirement over and above that supplied in the ST. Similarly, it is unclear what actions beyond those required by ASE are needed to meet the ADV_SPM requirements.

The requirement for an ISPM is met by a clear statement of the security policy. The need for a separate ISPM is not absolute, since for very straightforward policies, or those very clearly expressed in the ST, there may be no need for a separate ISPM. While the activities required by ASE and ADV_SPM are related (and may, in fact, be performed in concert), they are distinct.

Specific Changes

In the CEM the following paragraphs are added after paragraph 1473:

Assurance is to be gained from an explicit and general statement of the policies underlying the TOE security functional requirements. The assurance gained is two-fold: collecting the description of each security policy into a concise whole aids in understanding the details of the policies being enforced. Additionally, such a collected description makes it much easier to see any gaps or inconsistencies (which must be sought as part of the ADV_SPM.*.3C element), and provides a clear characterisation of secure states (sought as part of the ADV_SPM.*.2C element).

The requirement for an Informal Security Policy Model (ISPM) is met by a clear statement of the security policy. The need for a separate ISPM is not absolute, since for very straightforward policies, or those very clearly expressed in the ST, there may be no need for a separate ISPM. In such cases, different sections of the ST (e.g. security requirements, TOE summary specification) may combine together to provide a sufficient level of detail for the security policy. However, this is often not the case. For example, audit requirements may be spread throughout the statement of TOE security functional requirements, which may not provide a clear model of the overall policy. Unless another section of the ST (perhaps the TOE summary specification) pulls together the audit requirements into a cohesive whole, then having a separate ISPM would be necessary in order to allow for the detection of inconsistencies within the ST requirements that may otherwise pass undetected.

Where a developer claims that the ISPM requirements for some or all of the security policies are met by the ST, the evaluator needs to determine that this is the case by applying the requirements of the ADV_SPM.1 component: determining that the policy is clearly expressed, and that the model is consistent with the remainder of the ST. As part of the ISPM rationale, it is likely that, in cases where the developer claims that the ISPM is met entirely by the ST, that the rationale will reference the demonstrations of suitability and correspondence between portions of the ST. When evaluating this work-unit, the evaluator may draw upon the results of the ST evaluation in this area.

In the CEM the following paragraph is added after paragraph 1475:

Where a developer claims that the ISPM requirements for some or all of the security policies are met by the ST, the evaluator needs to determine that this is the case by applying the requirements of the ADV_SPM.1 component: determining that the policy is clearly expressed, and that the model is complete with respect to the remainder of the ST. When evaluating this work-unit, the evaluator may draw upon the results of the evaluation of the completeness of the various portions of the ST.

A well-formed ST does not automatically meet the ADV_SPM requirements, because the ASE requirements are not a superset of the ADV_SPM requirements (for example, there is no ASE requirement that the ST describe the rules and characteristics of the policy).

The ADV_SPM requirements merely call for a description of the TOE security policy. If such a description is available in other deliverables, such as the ST, there is no need for the developer to provide separate evidence.