PD 0133: Level of Detail in SFRs

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

During its February 2007 meeting, the ODRB issued the following PD:

PD 0133
TITLE 
Level of Detail in SFRs

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?

For example, the FDP_ACF and FMT_SMR requirements contain assignments
asking for a list of subjects and objects and a list of roles,
respectively, as well as other lists and items.  Must these assignments
be filled-in with the actual names of the subjects, objects, and roles?

The contention is that SFRs need to contain specific product details so
that they can be adequately verified via testing. For example, consider
an access control rule SFR that states

    "A subject must have a username that is assigned the privilege (per
    the access control list) corresponding to the requested operation of
    the target object in order to succeed in performing the requested
    operation."

In an ST this SFR would be supplemented with further explanation in the
TSS. Regardless, the SFR should enumerate a separate rule for each
database object identifying its possible set of permissions (privileges
in this case). For example:

(1) to access a database, a subject must have dba, resource, or
    connect privileges as requested.  

(2) to access a table a subject must have alter, delete, index, insert,
    reference, select, and update permissions as requested 

    ...and so on. 

In this example the TSS would serve only to repeat the SFR since all of the 
detail would be in the SFR.  

The reasoning is:

1. The SFRs in the ST need to describe the specific security claims for
   the described TOE. Security functionality needs to tie to the SFRs
   rather than discussed solely as a narrative in the TSS, because
   security relevance is tied to the SFRs that are claimed in the ST. 

2. Specific product details (i.e., implementation) need not be captured,
   but specific and clear security rules need to be captured in terms
   of specific product subjects and objects. 

3. The focus of the decomposition of the design and the coverage
   analysis for testing are the SFRs. Thus, in order to ensure a claimed
   behavior is tested, it must be captured in the SFRs. 

The opposing view is that the SFRs in a ST need only contain general
representations of the claims being made, so long as they represent a
measurable, evaluatable claim when used in conjunction with the
additional details in the TSS or the design documentation.

This position is supported by the following reasoning:

1. Testing is not directly based on the text of the SFRs, but on TSFIs
   and "security functions" The vendor is responsible for ensuring that
   all of the TSFI are tested and that the security functions are
   completely tested (as defined in the TSS). Testing of the TSS is a
   superset of the SFR testing since the TSS may contain additional
   information not represented in the SFRs. The evaluation team is
   responsible for mapping the vendor tests to SFRs as part of its team
   testing, but the ATE requirements never address SFRs in any aspect.  

2. It is divergent from past and current CCEVS decisions, as captured by
   TOPs and VORs, as well as in numerous validated protection profiles
   with validation dates ranging from 1999 through 2006. 

3. The CC indicates that the SFRs are not required to be product
   specific and are intended to facilitate some measure of comparability
   between similar evaluated products. Comparability is not relegated
   exclusively to PPs.  

RESOLUTION

There are two issues relevant to this OD. The first is the
TSS-versus-SFR issue. The SFR is supposed to say what the TOE does; the
TSS is supposed to tell how the TOE does it. Where the SFR is
implementation-specific, the two are pretty much the same. Stating the
details in both the SFR and in the TSS is not necessary. However it is
not the case that all SFRs should therefore be free of details, which
would require the premise that all SFRs are cast the same way (which is
an incorrect premise).

This leads to the second issue: the heterogeneity of the SFRs. It is
vital that SFRs are differentiated. Because of the variances in the way
in which they are expressed, they cannot all be treated the same. 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 two SFRs in question (FDP_ACF and FMT_SMR) both have assignments
(the rules of access and the roles/conditions, respectively). For these
SFRs, the assignments must be filled in with product-specific details
that describe the capabilities of the TOE.

Note that PP compliance may play a role: if the PP refines an SFR, it
adds details about how the requirement is to be met. This might (though
need not) make an implementation-independent SFR become
implementation-specific.

The detail required within SFRs is dependent upon the complexity of both
the product's functions and its implementation of those functions. The
level of detail in the SFRs should be comparable to the description
found in the TSS, and adequately convey the complexity inherent in the
product. Meaning, if the ST talks about particular entities (roles,
objects, attributes, rules, etc.) in the TSS, those entities should be
discussed in the SFRs.  However, the TSS may contain more detail than
the SFRs on how those entities are implemented. The determination of
whether an ST successfully accomplishes this, unfortunately can be
somewhat subjective in nature. Granted, the likelihood of successful
testing does not fully depend upon the level of detail in the SFRs, but
more importantly upon the combination of the SFRs, TSS and TSFI
adequately providing the necessary detail. However, in this specific
case the issue relates to the assignment of privileges to the respective
roles of database users. The scheme feels the security importance of
those assignments warrants inclusion in the SFRs.

RATIONALE

It is important to capture an adequate level of detail in the SFRs for
both product understanding and testing.  Someone reading the ST should
be able to understand all of the products security functions in terms of
policy and role restrictions without having to read the TSS.  This also
ensures that these issues will be sufficiently addressed in testing. As
described in the resolution, this may mean that for some SFRs the level
of detail is equivalent to that in the TSS (especially for those SFRs
with associated refinements), however this is not necessarily the case
for all SFRs.