Re: FMT_MSA.3: Restrictive/Permissive Default Values

["Dr.Ir. D.J. Out" <out@itsef.tno.nl>]

Arnold, James L. Jr. wrote:
> 
>>The goal of FMT_MSA.3 is that it is used in conjunction with 
>>a TSP model
>>  (it has an indirect dependency on SPM through its 
>>dependency on MSA.1) and that this model would explain what 
>>"permissive" and "restrictive" 
>>means.
> 
> 
> I find it difficult to accept that concepts such as these can be defined in
> a security policy model. 
> 
> First, this requirement has no dependency on such a model and it can
> certainly be used with EALs that do not require a security policy model
> (e.g., EAL2). Note that neither FMT_MSA.3 nor FMT_MSA.1 have any model
> dependency in CC version 2.2.
> 
> Second, given that a ST user quite likely will never see any model they
> would not necessarily know what the requirement means. The ST needs to stand
> by itself and should not really on other documents, especially non-public
> documents, for coherence.

I could not be more in agreement. Note that I also said in my mail that 
most Europeans I know (including me) do not have a clear idea on what a 
Security Policy Model is other than "something that is supposed to 
address this otherwise there wouldn't be a dependency"

> Third and similarly, a PP author wouldn't normally have a security policy
> model and I believe there are historical instances where these terms have
> been used without further clarification. Hence, my earlier question about
> what these terms mean - apparently some individuals have opinions about the
> meaning of these terms. Consider the case where a PP author simply indicates
> 'restrictive' - it seems wrong to allow basically any solution so long as
> the security policy model defines what ever is provided as 'restrictive'.

I have never considered the interaction between PPs and SPM. One more 
nail into the SPM coffin.

> Fourth, some CCEVS validators have taken to criticizing requirements that
> are too vague (for example indicating that an access control list must grant
> the requested access needs to be clarified to explain the specific rules
> involved, despite addition of detail in the TOE Summary Specification). This
> issue has been presented as a problem with determining compliance. I
> definitely think the use of these terms seem to qualify as being very
> non-specific and to make it worse they are encouraged as they are offered as
> CC selections. 
> 
> The bottom line is that either these terms need to have a well
> defined/understood meaning within the CC itself or they should be stricken.
> Note that I believe that rather than indicating simply 'permissive' or
> 'restrictive', however defined, the requirement should have an operation to
> explain the rules or formula for assigning default values - these rules
> could be null, very simply, or extremely complex.

Because the concept SFP is to be removed from Part 2 (in three years 
nobody has been able to explain what an SFP is so we probably don't need 
it), MSA.3 will be touched during editing for CC3.0. This will probably 
be a good time to remove these restrictive/permissive choice and go to 
some sort of:
[selection:
    [assignment: default value],
    [assignment: set of rules to determine default value]
]
construction, which will be much more explicit.

But this will take time.

DJ
-- 
TNO ITSEF BV
P.O. Box 96864          tel +31 70 374 0304
2509 JG The Hague       fax +31 70 374 0651
The Netherlands         www.commoncriteria.nl