RE: PD 0133: Level of Detail in SFRs

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

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

I think the CC already answers this. SFRs are required to be measurable
and be stated in a manner where compliance can be determined and
demonstrated. (ref. ASE_SRE.1.5C). As such, specific product details
would almost certainly never be required to accomplish that.

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

I think the answer is quite clearly no within the context of the CC. The
SFRs are intended to be an abstract presentation of requirements
designed to address the cited objectives for the TOE. While the CC
offers that the SFRs are allowed to be TOE-specific, it doesn't require
any TOE or product specific details at this level of specification
abstraction.

> The contention is that SFRs need to contain specific product 
> details so that they can be adequately verified via testing. 

Test coverage is clearly about addressing security functions primarily
as presented in the functional specification (and lower design
abstractions). (ref. ATE_COV) There doesn't seem to be any real basis
for arguing that test adequacy is related to the specific degree of
abstraction of the SFR presentation.

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

This seems to be simply an assertion of opinion. One could easily argue
that an ST reader would more readily understand a rule that says to read
you must have read permission and to write you must have write
permission - where the TSS must elaborate by mapping real permissions to
the abstract notions of read and write - rather than inundating the user
with acronyms and terms that may require some expertise or a more
critical read of the entire ST in order to come to a more general
understanding of what is intended.

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

This point isn't especially clear. I think we would all agree that the
SFRs need to convey the security claims that the TOE is making. The CC
model ties the security functions directly to the SFRs by virtue of the
TSS-SFR correspondence. Requiring TOE-specific details in the SFRs would
be akin to eliminating the TSS correspondingly. The point of the TSS is
to provide a TOE-specific interpretation of the SFRs, explaining how
those more generally presented requirements are actually realized.

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

I'm not sure where the distinction is. If product-specific details need
not be captured, why does the example above specifically identify the
actual, product-specific permissions? There are plenty of PPs out there
that provide completed operations, such as information flow and access
rules, that are fairly abstract and generic. There is no reason this
should be allowed only in the context of a PP and, as indicated above,
it may be preferable to help convey meaning to the ST reader.

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

I don't know where this comes from. The focus of test coverage is the
functional specification, not the SFRs. Certainly SFRs correspond to
security functions which are represented and substantiated by a series
of corresponding design abstractions. It is impractical for tests to be
developed against the SFRs; SFRs could never practically contain
adequate information. I would counter that the TSS and other design
abstractions are based on the SFRs, but testing is based on the
resulting design abstractions (in particular to bring focus to
interfaces that have been cast in light of the security functions and
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.

Good point - that is indeed what the CC indicates.

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

Actually, this is not entirely correct. Testing is based on the security
functions as represented in the functional specification as opposed to
the TSS. The functional specification should represent the TSS which in
turn represents the SFRs, etc. However, the functional specification
would likely almost always have substantially more detail than either
the SFRs or TSS.

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

Note that I think PD096 also indicates that specific details need to be
presented, but rather the policy (presumably at an abstract level) needs
to be presented.

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

Here we go again with the 'what vs. how'. Those terms are all but
meaningless since they can change roles based on perspective. While I
agree that SFRs can, but don't have to, be implementation specific, I
disagree with the notion that all SFRs cannot be cast in the same way.
The CC distinguishes those that have explicit operations to be completed
and those that don't, but I don't think there is any clear indication
that SFRs with operations must be completed with implementation-specific
details. Rather, they should be completed appropriately to address the
identified objectives. Those operations could be completed in a generic
(i.e., non-implementation specific) manner in each and every case.

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

I don't follow this, perhaps it is a circular argument. Indeed, I think
you are indicating SFRs are heterogeneous because they should be treated
differently. However, there is no support offered for this argument.
>From my perspective, SFRs are heterogeneous only in that they are
different and including selection and assignment operations or not.

> 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 assertion is unsupported in the CC. In point of fact, there are
numerous PPs (and previous STs) that have elected to complete the
applicable operations in general ways. For example, 'subject' and
'object' could be used to represent subjects and objects and the TSS
could provide the TOE-specific association between those abstract things
and the actual things. Another example, 'authorized administrator' is
commonly used and promoted, perhaps unintentionally, in the CC by virtue
of being included in a number of SFRs. Again, it is up to the TSS to
explain how 'authorized administrators' is realized, even if the answer
is there are actually several administrative roles. The SFRs are
intended to be minimum requirements after all.

>From a requirements perspective, I tend to think it can be better for
the reader to reflect (using SFRs) abstract notions in relatively simple
ways and then the TSS can explain how the abstraction is realized.

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

I'm wondering where the support for this comes from. There are very
simple SFRs that could be fulfilled by exceptionally complex solutions.
There are also very complex SFRs that could be satisfied by relatively
simple solutions. I think there is not necessarily any relationship
(from security function to SFR) at all between the complexity of SFRs
and the security functions that address them. After all, the CC is based
on a top down decomposition from a security problem through some level
of design abstraction.

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

The only comparison between the SFRs and the TSS is how the TSS
satisfies the SFRs. The presentation of and amount of detail in SFRs
should not be decided based on the TSS whatsoever. There is nothing in
the CC or CEM that indicates that the evaluation of the SFRs themselves
should take into account the TSS or any other TOE-specific information.

> Meaning, if the ST talks about particular entities 
> (roles, objects, attributes, rules, etc.) in the TSS, those 
> entities should be discussed in the SFRs.  

Again, the TSS must explain how the TOE addresses the SFRs, but the SFRs
need not be developed based on any specific information about how the
TOE works.

> However, the TSS 
> may contain more detail than the SFRs on how those entities 
> are implemented. 

In fact, this is normally expected.

> The determination of whether an ST 
> successfully accomplishes this, unfortunately can be somewhat 
> subjective in nature. 

I got lost here somewhere - what are we measuring in the ST? Based on
the past few sentences, I think it is suggested that the SFRs should
have a comparable (the same?) level of detail as the TSS, that the SFRs
should use the same terms as the TSS, and that the TSS could have more
detail than the SFRs. I'm thinking these things are fairly objective,
albeit not necessarily correct (per previous comments) in the context of
the CC.

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

I'm not sure what is meant by successful testing. Testing is based on
the functional specification (and perhaps other design specifications).
I think it is probably fair to say that the more abstract the SFRs, the
more analysis and rationale would be necessary to substantiate a
conformant TSS statement and that is also true for each successive
design abstraction as well. However, I have yet to see a good argument
about how an abstract presentation of SFRs impacts the likelihood of
successful testing.

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

I find this interesting, especially since I think PDs are supposed to
record precedent as opposed to represent a wholesale change in
direction. There are a great many historical examples, including PPs
validated within the past year, where the very details used in example
here are presented in an abstract manner.

This PD offers no valid or substantive rationale as to why an abstract
presentation of access rules or security management roles is of any
particular 'security importance'.

> RATIONALE
> 
> It is important to capture an adequate level of detail in the 
> SFRs for both product understanding and testing.  

While the TOE needs to be tested as a solution for addressing a given
security problem, no valid rationale has been provided to indicate why
those details are important specifically for testing. I do agree that
SFRs should promote understanding - specifically a general understanding
of the abstract security claims being made. I think it largely at the
discretion of the ST and PP authors to promote their solutions and as
such should try to create STs/PPs accordingly. 

> 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 is correct only in a general sense. The reader should understand
the general model from the SFRs (e.g., read/write protection,
administrator vs. user) and the TOE description and TSS should serve to
provide more specific information about how those notions are realized
by that product.

> This also 
> ensures that these issues will be sufficiently addressed in 
> testing. 

Again, this has nothing to do with 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.

This is a pretty lame ending. I think we are left with no useable
guidance from this PD. It seems that sometimes SFRs need more details
and sometimes they don't. Unfortunately, I think this somewhat
indicative of current trends where the rules are poorly defined,
dictated without valid rationale, and ultimately each individual
validator gets to serve as the independent judge for the TOE-du-jour.