PD-0133: Level of Detail in SFRs

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

What level and depth of detail is required of the SFRs within an ST? More to the point, are specific product details required to adequately state the complete, specific security claims for the TOE being described?

Resolution

The specification of the Security Functional Requirements in an ST must be of sufficient detail to define the security functions provided and the security rules enforced by the TOE being specified, to a level of detail that clearly defines the intended security services, and provides measurable and verifiable claims.

Specifically, this means that:

1. Access Control SFRs must clearly articulate the access control rules enforced in terms of the types of subjects, objects, operations, information (and the attributes thereof) provided by this TOE.

2. Management SFRs must clearly specify the pre-defined management roles in the system, and their rights and restrictions.

3. Identification and Authentication SFRs must specify any authentication-related decision rules.

Note that the focus is specification of capabilities provided and rules enforced. It is not the capture of the mechanics of implementation. The high-level description of the mechanisms implementing these rules/capabilities is the province of the TSS.

Support

The basic distinction between the definition of the Security Functional Requirements (SFRs) and the TOE Summary Specification (TSS) is that the SFRs specify *what* the TOE does/must do, and the TSS specifies *how* the TOE does it. The issue rased here regards the level of detail of the SFRs; the issue of the level of detail of the TSS is addressed in PD 0063.

CC v2 is relatively silent on the level of detail required in SFRs. The CEM does note that the objective of the SFRs is to "provide an adequate basis for development of a TOE that will achieve its security objectives". It is clear (we hope) that some levels of specification are too high-level to do this (e.g., "The TOE shall provide an access control policy."); it is equally clear that some levels of specification are too low-level to do this (e.g., "The TOE shall examine the GZORGUMPLATZ bit, and if it is set..."). But CCv2 formally does not mandate what the acceptable middle boundaries are--it leaves it to common sense.

It is also worth noting that the Part 2 SFRs are inconsistent in their level of detail. Some are phrased such that they contain details that are almost implementation-specific, while others are more general or implementation-independent. It is therefore inappropriate to treat both kinds identically. The focus of this PD are those SFRs that include assignment of details--the goal is to provide guidance on the needed level of detail for those assignments.

CCv3 provides some clarification. ASE_REQ.1-3 requires that all subjects, objects, operations, security attributes, external entities, and other terms be defined. But this is still a weak definition of the level of detail required.

Based on this, one might argue that "anything goes"--and this might be true, in a general sense. However, products are evaluated by approved schemes, and schemes are not obligated under the CCRA to accept every submitted product for evaluation. Schemes have the ability to define the rules for what products they accept in order to manage their resources and serve their sponsors.

In the US, CCEVS has issued Policy Letter 10, which requires that products submitted for evaluation clearly define their intended security services, and that SFRs clearly articulate the security claims being made to a degree that they can be measured or otherwise verified. It requires that management actions be specified in the applicable SFRs.

The goal of this PD is to clarify that policy. It requires that, in order for an ST to be accepted for evaluation:

1. The access control rules are captured in the SFRs, defined in terms of the defined (FDP_ACC, FDP_IFC) types of subjects, objects, operations, information, and attributes. For example, if a traditional DAC policy with ACLs, users, and groups is provided, the SFRs must detail the high-level decision algorithm.

2. Management SFRs must capture all the pre-defined management roles and their restrictions. It is unacceptable to treat distinct pre-defined management roles as a single administrator.

3. If the I&A policy is more involved than entering an appropriate authenticator, then the rules that govern system access decisions must be described.

Note that the focus here is on rules enforced and capabilities provided. It is not on the specifics of implementation: interfaces, calls, components, data structures. Implementation details, at a high-level, are the "how" captured in the TSS.

Within CCEVS, it is felt that the additional details required under Policy 10 are needed to create a common and clear understanding between the vendor, evaluator, validators, consumers, integrators, and accreditors regarding the specific rules and capabilities provided by the specific TOE defined by the ST.

Modification History:

2007-02-22:

PD Created. [February 2007 ODRB Agenda Item 3.a.iv]

2007-03-22:

PD completely rewritten to better specify the details required in SFRs, and to provide a stronger supporting position based on CCEVS Policy Letter 10. [March 2007 ODRB Agenda Item 4.d.iii]

References:

• None

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0258