RE: PD 0133: Level of Detail in SFRs

["Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>]

While I have already commented on the validity of this draft PD, I have
come to an additional realization. Specifically, that the draft PD 133
oversteps the documented authority of PDs in general.

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

It is clear from this statement that, except where PPs are involved,
that PDs are only advisory and do not serve as a replacement for
interpretations nor do they serve to override the CC itself.

This draft PD 133 clearly oversteps the purpose of PDs - while it offers
some opinions and suggestions, it goes too far in requiring that
implementation-specific details must necessarily find their way into
SFRs. There is no basis in the CC from which to draw that conclusion and
the specific SFR examples actually serve as good counter-examples for
this draft 'precedent'. Examination of STs and PPs, even those validated
within the past year, shows many examples where
non-implementation-specific roles and rules are articulated in the form
of SFR operations. As such, this is clearly a change in direction and
not indicative of some long-term historical practice.

Worse, is the fact that while this is a draft precedent, presumably
stemming from a seeming bad decision for one or more evaluations, we are
already seeing validation issues dictating that implementation-specific
roles and rules must be presented in STs. In effect, this means that
this draft PD is being treated, even now, as though it is an
interpretation that has fundamentally changed the CC itself. 

Worse still, is the fact that evaluations are being held hostage (i.e.,
they can't formally enter into evaluation) until the validator-presented
issues (such as this) are resolved in the favor of the validator. PDs
are supposed to serve as evaluation-related guidance and not as another
source of CCEVS policies.

As such, this PD needs to be recast to offer opinion and
recommendations, but not to suggest anything mandatory in any sense.


Comments on the draft resolution:

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

Actually, the CC indicates that SFRs document measurable requirements
the
TOE must satisfy and the TSS must summarize how the TOE satisfies those
SFRs. The CC certainly allows SFRs to be cast in the same way, despite
the
contrary opinion above, though those with operations must be completed
but
not necessarily in an implementation-specific manner.

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

This whole concept of heterogeneous SFRs seems to reflect some new
theory
(opinion) and is not reflected in the CC beyond SFRs with operations and
those without and SFRs vs. SARs. It is not clear why it is VITAL to
differentiate SFRs - an unsubstantiated opinion. While it is true that
all
requirements cannot be treated in the same way - in the CC this means
only
that some requirements must have operations completed and SFRs and SARs
are
addressed via different means. No requirements in the CC contain 'almost
implementation-specific' details. That is simply a false statement.
Whether
operations are completed with implementation-specific details, in every
case, is a matter of choice and not requirement. 

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

This is where the PD clearly oversteps its bounds.

Relative to the CC, this is quite simply a false statement. Perhaps this
is an attempt to offer the opinion that implementation-specific details
should find their way into these requirements. Regardless, there are
quite a number of historical STs and PPs that complete the applicable
operations in generic and non-implementation-specific ways. This
promotes comparability, which is one of the goals of the CC, and doesn't
degrade the evaluation result. It is arguably better to express more
abstract requirements - this promotes comparability and can even make
the evaluation better since more analysis would likely be required to
ensure the abstract claim is satisfied vice some specific claim that
could allow otherwise security relevant details (e.g., an object or
access mode not in the SFR list) to be overlooked.

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

I'm thinking 'implementation-specific' is being used to mean different
things. While a PP might enumerate specific role names, for example,
those names do not have to be used in each corresponding TOE, though
there would necessarily need to be some correlation (presumably in the
TSS). I think that unless a PP actually names a specific TOE, it would
never have SFRs that I would consider, strictly speaking, to be
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.

This paragraph is mostly an expression of opinion. It is not clear that
the complexity of a given solution has anything to do with the
complexity of the SFRs it claims to fulfill. It is also not clear
specifically why the CCEVS finds implementation-specific details to be
important for these two specific SFRs. Nor is it clear why they would
find them important only after several years of accepting
non-implementation-specific details for these very SFRs. Regardless, PDs
are not an appropriate place for the CCEVS to change the CC nor to
implement policies for entry into evaluation.


Some additional comments:

1) FMT_SMR.1 is about security management roles. That does not seem to
be well understood given the recurring recommendations to include all
possible (and actual) roles. Policy letter #10 seems to require that
only security management roles (i.e., those referenced in other SFRs)
CAN be included in FMT_SMR.1, lest the ST (SFRs) be found inconsistent.

2) Requirements indicating that 'XXX shall be limited to role YYY' do
not necessarily mean that all instances of YYY can actually do XXX nor
perhaps even that YYY can do XXX at all. The point of the applicable
SFRs to ensure that certain functions are appropriately restricted. Like
all SFRs, the TOE is allowed to exceed the SFR. For example, it could
not offer a function as a means of restricting it. Note that that this
also doesn't seem to be well understood - requirements that impose
restrictions can be exceeded by imposing additional restrictions and
requirements that offer provisions can be exceeded by providing more
functions or providing them to additional users, although all
requirements have to be simultaneously satisfied.