Re: PD 0133: Level of Detail in SFRs

["Observation Decisions Review Board" <faigin@aero.org>]

The ODRB thanks Jim Arnold and the other contributors to this
discussion. You have brought to our attention that this PD needs to be
completely rewritten to better capture what is required, and the
rationale behind the decision. It is hoped that the following rewrite
does this: 

PD#: 0133
 
PD Title: Level of Detail in SFRs

SANITIZED 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? 
 
PD 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.  

PD 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.  

PD History

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] 
2007-02-22:
    PD Created. [February 2007 ODRB Agenda Item 3.a.iv]