PD-0007: Choice of functional components not limited by choice of assurance components

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

Some functional requirements seem inappropriate at low assurance levels. For example, it seems inconsistent to select "prevent" in FAU_STG.1.2 for a PP/ST that includes assurance components no higher than EAL2 because TOEs meeting only EAL2 may not be able to prevent audit record modification. The functional requirement FAU_STG.1.2 states:

The TSF shall be able to [selection: prevent, detect] modifications to the audit records.

A PP that includes EAL2 includes the selection "prevent"; a better choice for the selection would seem to be "detect" for such a low assurance level PP.

Resolution

In the absence of an explicit dependency, there is no a priori reason why inclusion of a particular functional requirement conflicts with a PP or ST selection of assurance requirements. That is, with the exception of the functional requirements that have dependencies on assurance requirements, any choice of functional requirement should be valid with any choice of assurance requirements.

Support

Security functional requirements in a PP or ST are selected by the author to support the objectives of the PP or ST, which in turn are chosen to meet the statement of the environment (i.e., support its organizational security policies and counter its threats). There are very few dependencies indicated in the CC between functional and assurance requirements.

The appropriateness of the combination of functional and assurance security requirements should be determined as part of a PP or ST evaluation. In the case of an ST claiming compliance to a valid PP, if the evaluator of the TOE and ST questions the appropriateness of a particular pairing of functional and assurance requirements, that question should be addressed as part of the ASE_PPC.1 evaluator activity.

The example given above concerns protection of TSF data. Protection of TSF data is a fundamental need in many TOEs. There is a wide range of methods for providing this protection, often by prohibiting non-administrator access to parts of the TOE, ranging from physical protection to file protection. This is hardly an onerous requirement, even for TOEs aiming for a low level of assurance. The confidence that one has in the level of protection, however, may vary with the assurance level.

Further, in the example given, if a TOE can detect modification of audit records, it probably has mechanisms that could be used to prevent such modifications.

Modification History:

2004-08-12

Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

References:

• TFFWPPv1.a
• ALFWPPv1.a

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0035