Re: I-0382: TSF Architectural Protections Are Really Assurances
- Subject: Re: I-0382: TSF Architectural Protections Are Really Assurances
- From: "Interpretations Working Group" <iwg@gibraltar.ncsc.mil>
- Date: Thu, 1 Mar 2001 15:26:16 -0800
- Content-transfer-encoding: 7BIT
- Content-type: text/plain; charset=US-ASCII
- Priority: normal
Jim Arnold wrote:
> The primary difference, as I see it, between functional requirements and
> assurance requirements is whether the TOE actually implements a function
> to satisfy the requirement. Assurances, on the other hand, are
> mechanisms geared toward determination of whether the functions are
> implemented properly. Hence, things like RVM and SEP are clearly
> functional in nature. [...]
> The background argument about testing is not very good. All but the
> most trivial of functions cannot be verified "solely through testing".
> The CC has designed assurance requirements that allow assurance to be
> acquired through a combination of assurance mechanisms, of which testing
> is but one. Many aspects of RVM and SEP can be tested, though like all
> other functions that testing must be supported and bounded using design
> analysis. Let me reiterate, the CC does not advocate the sole use of
> testing to provide assurance for any security function. On the other
> hand, the CC does not support the notion of "testing" or even design
> analysis to provide assurance for an assurance.
The IWG agrees that the distinction between functions and assurances not
clear-cut; there has been no definitive differentiation made. The IWG also
agrees with the point made in your second paragraph -- that RVM requires
the design be analyzed because no amount of testing alone will be
sufficient.
> Moving RVM and SEP to assurances also has the down side of not being
> internationally accepted, since explicit statement of assurances is not
> subject to mutual recognition. Also, the potential benefit of this
> interpretation is not clear.
However, there seems to be a bit of confusion here as to the purpose of
I-0382. This is not a proposed interpretation to be adopted by CCEVS;
rather it is Request for Interpretation that is to be sent to the CCIMB.
(This is why there are several approaches outlined, including the somewhat
radical creation of a new Part of the CC -- neither functions nor
assurances -- for RVM and, to a lesser extent, SEP.) I-0382 was publicized
here to solicit any additional points that might have been overlooked.
Date Index |
Thread Index |
Problems or questions? Contact list-master@nist.gov