RE: PD 0126: Administrator-entered Code Used To Meet SFRs

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

We seem to be getting onto another track here, but perhaps it is worth
discussing.

> It is not a matter of perfection but more a matter of 
> measurability. There has to be a way of measuring whether a 
> TOE does or does not address the CC requirements. 
> Reasonableness does not offer measurability and is subject to 
> interpretation by those of which may have a specific agenda 
> in mind. If you consider reasonableness, what factors 
> constitute the proposed scenario to be or not be reasonable. 
> How many characters or lines of code are considered 
> reasonable for an administrator to type without a probable 
> cause of error?
> How perfect or imperfect is an administrator assumed to be to 
> ensure the proposed guidance is reasonable? You simply cannot 
> measure reasonableness.

There are lots of requirements in the CC that are not precisely
measurable. As a result, absolute consistency cannot be ensured. The CEM
offers some guidance for some of these things, but they are still based
on estimates, assumptions, expertise, etc. Misuse analysis is certainly
one of these areas. What I am seeing in some of the responses is that we
need to remove the potential for error by introducing additional tools
or mechanisms. This has not been the case historically and the CC
certainly doesn't indicate that it should always be the case.

> Certainly the CC requirements are not intended to result in a 
> product being perfectly secure without any doubt. However, 
> they are intended to provide as much assurance as possible so 
> that that the most obvious security concerns are addressed at 
> various levels of degree. At a minimum, they at least require 
> ensuring that the administrator has received the TOE as it 
> was evaluated in its exact form. The delivery requirements 
> (ADO_DEL) imply this.
> If you take the CEM work unit ADO_DEL.1-1 for example. This 
> work unit requires the evaluator to examine the delivery 
> documentation to ensure that it describes how security is 
> maintained when distributing the TOE.
> Furthermore, the supporting text within the CEM indicates 
> that the delivery procedures should describe how the 
> recipient of the TOE may properly identify the TOE and ensure 
> its integrity during transmission. Also, The
> ADO_DEL.1-1 work unit is required at EAL2 and higher as 
> opposed to your statement below that verifying integrity of a 
> TOE delivered at even EAL3 is not required.

ADO_DEL.1 is not intended to guarantee that the administrator ends up
with the TOE in the exact form it was evaluated. If that were true,
there would be no need for ADO_DEL.2, for example, which requires the
user to have some means to check the integrity of the TOE.
Identification of a TOE doesn't serve to demonstrate its integrity.
ADO_DEL.1 only requires that seemingly appropriate measures are taken to
get the TOE properly to the user. Note that if the TOE must then be
compiled, that is no longer an ADO_DEL topic, but rather shifts to
ADO_IGS. 

> In most cases a TOE is delivered in a pre-compiled state, 
> which means the recipient just needs to verify the integrity 
> of the binaries delivered. Yet this specific case is 
> different. While procedures may be in place to ensure that 
> the recipient has received the manual containing the source 
> code for the TOE in an unmodified state, this still does not 
> ensure that the administrator will properly generate the 
> source code for the TOE exactly as it is specified within the 
> manual. Therefore, additional measures should be in place as 
> a sanity check to ensure that the code generated by the 
> administrator is in fact an exact replica of the code 
> specified within the manual.

Actually, I'm not sure this case really is different. Most TOEs are
delivered in a state requiring some measure of installation and
configuration. The difference between typing in part of the TOE
representation, a script for example, is not meaningfully different than
entering a list of security attributes or TOE data that are also
necessary for the enforcement of the TSP.

ADO_DEL provides some measure of assurance that the administrator has
the right instructions. The CC has fairly definitive and measurable
requirements about the necessary guidance to operate on the delivered
TOE - the guidance must provide all the necessary instructions to get it
installed, generated, and started. The CC does not address, in ADO, the
potential for user error which is present in most situations.

The issue of whether additional measures, as suggested, should be in
place is entirely out of scope of ADO. Even ADO_DEL.2 only would require
that there is a means to check the delivered document and not the
resulting 'bits.'

> Additionally, ADO_IGS requires procedures that describe the 
> necessary steps for secure installation, generation, and 
> start-up of the TOE. Therefore, my additional question is how 
> can you ensure that the administrator has generated the 
> source code for the TOE exactly as it is expected to be 
> without any check for consistency and how would you consider 
> that to be secure? While I agree that an administrator is 
> also capable of not compiling, installing, or configuring the 
> TOE in accordance with the evaluated configuration. But most 
> products typically have a means by which an administrator can 
> also verify if such mistakes have occurred, such as through 
> error messages, log files, configuration status screens, etc. 
> So I would also expect that if an administrator is required 
> to manually input the source code, there should be a means by 
> which they can verify that they have correctly generated the 
> source code as it was intended.

If the instructions are 'type the following in exactly...', then all the
necessary instructions are available. ADO_DEL requires some assurance
you got what you should have gotten and ADO_IGS requires that you have
the necessary instructions to be able to get it working. These
requirements do not indicate what you are suggesting. Note that I tend
to think that most products don't actually have mechanisms to allow
administrators to readily detect (other than simple command/syntax
checking and by observing misbehavior) their own mistakes.

I think we are confusing a, perhaps, good idea with actual requirements.
However, the guidance requirements do not dictate any mechanisms.
Guidance is just guidance and the CC doesn't suggest otherwise.

> I think it doesn't make sense to go the route of assuming 
> "what if" an administrator skips certain steps or does not 
> wish to comply with the evaluated configuration guidance as 
> you would have to at least assume the administrator wishes to 
> utilize the evaluated product in the configuration that it 
> was evaluated.

Fair enough, we should avoid 'what if' scenarios just as we should avoid
enumerating the set of acceptable mechanisms and trying to make certain
guidance seem more important than others.