Re: FMT_MSA.3: Restrictive/Permissive Default Values

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

>>An evaluation does two things: it examines EFFECTIVENESS, 
>>i.e. evaluates
>>whether the requirements really solve the SPD, and CORRECTNESS, i.e.
>>determines that the TOE provides a correct implementation of the
>>requirements.
>>What the evaluation does not establish is RELEVANCY - whether the SPD
>>described in the ST matches the consumer's SPD.

This completely correct. In CC v3.0 it will be clearly described that:

- Relevancy
- <need a good word here> Determining whether the actual Operational 
Environment of the consumer matches the Security Objectives for the 
Operational Environment in the ST

are Out-Of-Scope and that some sort of Risk Analysis for the first and 
Audit for the second may be appropriate.


> The ITSEC captures these two aspects very clearly - it has heirarchical
> assurance requirement levels for Correctness (E1 - E6), and non-heirarchical
> assurance requirements for Effectiveness. All the Effectiveness assurances
> are applied to a TOE, regasrdless of the target Correctness level. The only
> difference between, say E2 and E6 is the amount of evaluation evidence
> available to the evaluators for conducting the Effectiveness aspects of the
> evaluation.
> 
> 
>>Evaluators would like us to forget effectiveness and focus on 
>>correctness.
>>This is because the latter is easier to demonstrate to a 
>>given level of assurance.> 
> 
> Very true.

I tend do disagree a little. Let's build a semi-formal model (Hi Ron!)

IF (the SPD is RELEVANT

AND the ST is technically correct

AND the TOE meets the SFRs

AND the Operational Environment is compliant with the ST

AND this is determined at EAL-Infinity)

THEN the TOE in combination with the Operational Environment are 
RELEVANT and EFFECTIVE

---------------------

As we do no measure relevancy, this transmutes to:

IF ( the ST is technically correct

AND the TOE meets the SFRs

AND the Operational Environment is compliant with the ST

AND this is determined at EAL-Infinity)

THEN the TOE in combination with the Operational Environment are 
EFFECTIVE in meeting the SPD

------------------------

And as EAL-Infinity is pretty expensive:

IF ( the ST is technically correct

AND the TOE meets the SFRs and SARs

AND the Operational Environment is compliant with the ST)

THEN the TOE in combination with the Operational Environment is 
CONSIDERED TO BE EFFECTIVE in meeting the SPD


>>In CCv2.4, APE/ASE establish effectiveness, while the TOE 
>>evaluation is
>>defined as a demonstration that the TOE meets its requirements (i.e.
>>correctness). Thus the SPD is irrelevant once TOE evaluation 
>>has begun. The
>>SFRs are everything. In fact, the intention is to drop the 
>>term 'TSP' from
>>CCv3.0 and replace it with 'SFRs'. This circular definition, 
>>SFRs enforce
>>the SFRs, is a tautology. If the TOE is correct, then by definition it
>>enforces the TSP (SFRs). For EAL1, CCv2.4 even lets you skip the SPD
>>altogether and just state the requirements outright without rationale.
>>
>>Consumers care about protecting their business assets. A 
>>commendable change
>>in CCv2.4 is that the SPD is expressed in terms of business 
>>needs, assets,
>>and threats, rather than attack methods and vulnerabilities. 
>>It is the task
>>of the evaluator to determine that the demonstration that the 
>>objectives
>>solve the SPD is correct. It is the consumer's responsibility 
>>to map the
>>"solved" SPD to his own, and to determine relevancy.
>>
>>A problem that arises here is that the CC does not provide a 
>>framework for
>>proving that the system requirements (objectives) satisfy the 
>>business needs
>>(SPD). In other words, we can only provide an informal, low-assurance
>>argument that this is so. 

You want to go from a nebulous business problem to a measurable set of 
statements. This means that SOMEWHERE in that chain there will be steps 
that are:
- soft and informal or
- arbitrary (I hereby state that this formal model is a description of 
your business problem)

This is inevitable: formality does not spring out of informality. And 
the step where you go from a "less formal" to a "more formal" 
representation is inherently unprovable.


>>We had it easier in CCv2.2, because we could argue that a 
>>given objective
>>countered (or mitigated) an attack method or a vulnerability. 
>>This is a
>>mechanistic argument that is relatively straightforward. Thus a simple
>>tracing between objectives and threats provided a coherent 
>>statement of why
>>the requirements were effective. Requirements, objectives, 
>>and the SPD were
>>three abstraction layers of the TSP: these are the 
>>interactions (between
>>subjects, objects, information and operations) that are 
>>permitted, and these
>>are the interactions that are not. 

And this led to useless rehashing of identical threats, objectives and 
requirements. It also led to dangerous semantics of the ST

Threat: X gains access to the TOE by exploiting a stack overflow in the 
administrator station
Obj, REQ, yadiyadiyadi

Consumer buys TOE. Finds out that there exists an easily findable heap 
overflow in the administrator station. Tells this to lab who says "We 
know". Tells this to developer who replies "Read the ST dummy, it never 
talked about heap overflows"

Now try to do this with business problems.

>>In CCv2.4, SPD and requirements are representations of 
>>DIFFERENT things,
>>i.e. business needs and system requirements, respectively. I 
>>would claim
>>that a consequence of the CCv2.4 model is that APE/ASE alone 
>>is insufficient
>>to effectively demonstrate effectiveness. 

> AVA is a much more holistic
>>assurance activity that can (and does) unearth flaws in all of the
>>abstraction levels of the TOE, INCLUDING its requirements. 

This is a question of definition. AVA is currently *defined* not do that.

> Binding seems to be addressed only by the requirement on the ST that the set
> of IT security requirements forms a mutually supportive and internally
> consistent whole, and by the Representation Correspondence (RCR)
> requirements.

Mutually supportive was removed as nobody could tell me what it was. Is 
one SFR mutually supportive? Are two completely independent SFRs 
mutually supportive? When would you fail something for being "not 
mutually supportive"?

I also have never seen a real good definition of "binding" (but I'm no 
ITSEC guru).

Probably (but it is a guess) this is meant to "force inclusion" of 
various FPT requirements and perhaps FAU. The CEM now specifically 
addresses these and tells the evaluator: Will it meet the objectives 
without these present?

> Also, the Vulnerability analyses did not differ in their application at
> different evaluation levels, only in what was available (in terms of
> evidence) for analysis. Compare this with the AVA_VLA components, which are
> levelled on the basis of the resisatance of the TOE to different attack
> potentials. The situation at EAL4, in particular, seems ludicrous. The
> evaluators have access to the functional spec, high-level and low-level
> designs, and a subset (at least) of the implementation; the developer has a
> comprehensive, tool-supported configuration management system, a documented
> development life-cycle, well-defined development tools, an acceptably secure
> development environment, and delivery procedures that provide for detection
> of integrity attacks on the TOE in transit; the TOE is subjected to an
> independent search for vulnerabilities and penetration testing that builds
> on all the evidence available to the evaluators and, at the end of the day,
> what have you shown (according to the requirements) - the TOE is resistant
> to attackers with LOW attack potential. 

I'm in total and absolute agreement here. And LOW is LOW...I mean 
kiddie-stuff. I shudder to think that there are probably EAL4 TOEs out 
there where developer, lab, and scheme KNOW that there are 10 point 
attacks possible.....

>>So which is the TSP? SFRs, or SPD? I tend to the latter: the 
>>SFRs enforce
>>the TSP iff the SPD is solved. It's harder on the evaluator, 
>>it's harder on
>>the developer, but is it not "what the author intended"?

Once again Nir: the TSP is the *TOE* Security Policy. While the SPD also 
describes things that may be solved in the Operational Environment. If 
you want to go this way, the Security Objectives for the TOE would be 
the TSP. In 2.4 the SFRs are intended to be a more-or-less translation 
of the Security Objectives for the TOE. Hence the choice.

> I'm not sure I agree. The TSP is a response to the SPD. The SFRs are a
> specification of an instantiation of the TSP. The TOE is an implementation
> of the SFRs, i.e., an implementation of an instantiation of a response to
> the SPD.

The current leaning for 3.0 is: The TSP will be *defined* as the set of 
SFRs. This was done because we had no answer to:

You have done an EAL7+ evaluation of a TOE. You have all the 
documentation needed for this. Where is the TSP in this documentation?

We got some answers that this was "an abstract entity" and didn't want 
to have some Platonic set of unwritten rules hanging around of which we 
evaluator-mortals could only see a faint representation (the SFRs). So 
TSP is now a nice abbreviation of all SFRs in the ST.

> And by the way, I can't see what the grief is about "informal security
> policy model" (apart from the obvious contradiction in terms). The security
> policy model defines the subjects, objects/information, and allowed
> operations by subjects on objects/information. Those operations may be
> constrained by particular attributes of the subject, object, or information,
> which the policy also defines.

Shall we say FDP_AC*?

  The policy could define specific roles that
> have specific rights (or are denied specific rights) within the context of
> the policy. 

Shall we say FMT_*

> The policy could define what operations or events need to be
> recorded. 

Shall we say FAU_*

> If you write out these definitions and descriptions in natural
> language, you have an informal model. If you include a few diagrams, graphs
> or matrices, you probably have a semi-formal model. if you use a specific
> mathematical notation, you have a formal model. My only issue is the degree
> of usefulness provided by an informal security policy model - given
> everything else that needs to be provided by way of specification and
> description, by the time you get to EAL4, the informal model is likely to
> just be repeating information in the ST - it doesn't provide any added
> value. The CEM recognises this.

The current leaning is:

SPM.1 and .2 will likely be removed. The set of SFRs are the TSP (see 
above). Anything is a model of itself. As the SFRs are semi-formal, they 
are a semi-formal model of themselves therefore the SFRs meet SPM.2. QED.

SPM.3 is useful, as the SFRs are not formal. A formal representation of 
the SFRs would add value.

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