I-0464: Conditional Requirements

TYPE:                 Request for Interpretation
NUMBER:               I-0464
STATUS:               Submitted as Request for Interpretation/Editorial
                      Observation to CCIMB

TITLE:                Conditional Requirements

FIRST POST:            [cc-cmt 00553]


RELATED TO:           <None>

ISSUE:

Currently, the CC does not allow protection profiles to specify conditional requirements, i.e., requirements that only need to be met under a particular condition. This capability would provide useful flexibility for protection profiles that might be used in environments in which more than one security function could apply, or in which particular security functions might be non-applicable or require a slightly different solution for a particular objective.

PROPOSED RESOLUTION

A future version of the Common Criteria should allow a Protection Profile to contain conditional components as a form of operation. The approach chosen should be able to support the following cases:

Conditionals. These operations would allow a PP to contain components for a variety of potential conditions, with the ST only addressing those conditions appropriate for the actual environment in which the specific TOE is expected to operate. An example of this might include requirements related to remote authentication, which would be excluded from the ST if the TOE or the IT environment provides no remote access capability.
Alternatives. This operation would support cases for which there are multiple roughly equivalent but non-hierarchical ways to address the same objective. An example of this might be audit pre- or post-selection, where either or both would be permitted.

SPECIFIC RESOLUTION

The following is one way to implement the operations defined in this Request for Interpretation:

Conditionals

CONDITION [statement of conditions]

[single component 1]

ELSE

[single component 2]

END CONDITION

The semantics are that if the "statement of conditions" is true then "single component 1" is included. The else is optional. If there is an else construct present and "statement of conditions" is false then "single component 2" is included.

CONDITION would be an operation similar to iteration: it would need to be clearly identified as a conditional, and would operate at the level of a full component.

For any components in a PP that are expressed using the same conditional operator, the CEM would need to require the evaluator to verify the following during a PP evaluation:

That each objective mapped to the component is subject to equal conditions, or is sufficiently general for the component to apply.
That each threat or OSP mapped to the component through the objective is subject to equal conditions, or that there are sufficient other components to address the stated threat/OSP.
That for a given condition which is being applied to more than one component, the set of applicable components does not create conflicting components, internal inconsistencies, or unsatisfied dependencies.

Conditional components would only be valid in a protection profile and all conditional statements must be resolved by the time they are expressed in a security target.

The application of a CONDITION would need to be clearly indicated in an ST. This could be done through a distinct section that identifies the conditional components included and excluded, and that includes the applicable rationales.

Alternatives

ALTERNATIVES BEGIN

ALTERNATIVE [component 1]

[EXCLUSIVE] ALTERNATIVE [component 2]

...

ALTERNATIVE [component n]

END ALTERNATIVES

The semantics of the ALTERNATIVES operation are that the ST author would have to select one or more of the components in the list. EXCLUSIVE could be specified to indicate that if this alternative is chosen, no other alternatives could be chosen.

Alternatives would be an operation similar to iteration: it would need to be clearly identified as ALTERNATIVES, and would operate at the level of a full component. For any components in a PP that are expressed using the ALTERNATIVES operator, the CEM would need to require the evaluator to verify the following during a PP evaluation:

That each objective mapped to the alternative components is equally applicable to each, or is sufficiently general for all the components listed to apply.
That each threat/OSP mapped to the components through the objective is equally applicable to each, or that there are sufficient other components so as to cover the stated threat/OSP.

ALTERNATIVES components would only be valid in a protection profile. All ALTERNATIVES statements must be resolved by the time they are expressed in a security target.

The application of an ALTERNATIVES operation would need to be clearly indicated in an ST. This could be done through a distinct section that identifies the ALTERNATIVES components included and excluded, and that includes the applicable rationale(s).

SUPPORT:

When writing a general specification like a Protection Profile, the specific protocols or approaches that will be taken in the eventual implementation are often unknown, for example:

Any of a variety of cryptographic protocols might be acceptable, but depending on the protocol chosen, there might be specific standards or behavior characteristics that must be met.
Either pre- or post- selection of audit events may be acceptable.
There might be different components to address different authentication mechanisms, but the overall threat and objective are the same.

However, CC v2.1 does not support the notion of condition components. The closest it comes to having them is in the AUDIT sections of each CC Part 2 family, which suggest the actions that should be audited if the FAU_GEN Security audit data generation requirements are included in the PP/ST.

CC v2.1 does also supports iteration on components, which allow for different components to have different scopes. Conditional components are similar in that they may also affect the scope, but the narrowing occurs at the time the component is transcribed from the profile and the operation applied, not at the time of ST evaluation.

Through the use of conditional components, the expression of PPs should be simplified, and the proliferation of multiple distinct PPs for minor differences should be curtailed.

Note that this proposal does not include the notion of conditionals at the element level. This is because a key notion of the CC is that the component is the smallest selectable entity in the CC; one must continue to treat the elements in a component as a cohesive whole. As such, it would be inappropriate to allow a PP author to conditionally exclude particular elements. However, if such flexibility was desired for explicitly specified elements or for elements supplied by the CCIMB in the Part 2/Part 3 catalogs, conditional elements could be a reasonable solution.

This proposal also does not include the notion of conditional threats or objectives. Allowing threats, and thus objectives, to be conditional moves the CC more into the paradigm of risk acceptance, as opposed to evaluation of products in an environment with a fixed set of threats. Although risk acceptance is a reasonable approach (and is commonly found in what the United States calls "Certification and Accreditation"), it is not part of the current CC paradigm.