PD-0109: Multiple Hardware Models with Different SFRs in One Security Target

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

Is it acceptable to evaluate multiple hardware models supported by a product each with slightly different SFRs?

Resolution

When there are slight hardware related differences in SFRs that are capable of being clearly described, use of a single security target is permitted.

Support

PD-0061 says:

It is generally acceptable to accommodate multiple platforms in one ST as long as:

1. The functional and assurance requirements (including CC operations) are the same for all platforms.

2. The TOE description and all the TOE behavioral (i.e., TOE description, the initial statements explaining how the requirements are met) describe how the requirements are met for each platform.

This precedent decision removes the first of the constraints put forth. However, knowledge about STs and their contents have progressed sufficiently so that minor variations within the ST will not prove overly-confusing to readers. Note that this decision is dependent upon the clarity achievable in the description of the differences; i.e., if the differences are too complex or difficult to explain then multiple STs should be written.

For example, imagine a product that runs on two hardware platforms. Perhaps it is a very small, compact, and cheap internet access appliance. The only difference in the two hardware models is that one platform has more memory than the other. The vendor wishes to claim FTA_MCS.1.2: "The TSF shall enforce, by default, a limit of [assignment: default number] sessions per user." but would like to allow more sessions for the model with more memory. With appropriate wording in the ST this would be allowable.

In order to use this precedent, the number of models should be relatively small and the number of SFRs involved should also be small. Furthermore those SFRs must be straightforward and non-contentious. If there were many models that were claiming radically different sets of SFRs, CCEVS would very likely insist that separate STs, certificates, and VRs be produced.

At this time, a detailed set of rules for making determinations of acceptability a priori cannot be stated. At some point in the future, with more experience acquired in this arena, it may be possible to promulgate some more formal policy.

Modification History:

None

References:

• CC v2.1, Part 1
• CC v2.1, Part 2, Section 10.2
• CC v2.1, Part 2, Section 11.1

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0233