Re: I-0382: TSF Architectural Protections Are Really Assurances

[James Arnold <arnoldj1@saic.com>]

I-0382: TSF Architectural Protections Are Really Assurances

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 same argument that claims these functions
provide assurance would work for access control functions that provide
assurance that information is protected, I&A functions that provide
assurance that users are properly authenticated, etc.

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.

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.

I recommend that the interpretation be dropped, defaulting to potential
solution 1.