|
Hi all,
There has always been an implicit difference of opinion between CC Project certificate producers over how to address things like 'reasonable'.
The US position, I believe (it was while I was on the CCIMB :-), has been that if more or less is to be 'enough' depending on 'circumstances', then an explicit evaluation decision/interpretation is needed to do other than what that which results from a direct reading of the CC text. (And where the CC text is ambiguous, that is a problem that needs to be addressed, not a feature to be exploited. :-)
At least one other scheme appears to freely read 'as appropriate' or 'as is cost-effective' throughout the entire CC and the application of those phrases in most any instance does not require any explicit decision/interpretation to be recorded.
In dialog with an author of portions of CC v3.0, there was the concept coming from him that a CC requirement is applied with the rigor corresponding with the level of assurance called out in the ST. But since there is no defined 'level of assurance' this seems pretty wishy-washy to me. :-) (EALs are hierarchal to one another, but do not provide a distinct 'assurance level'. And the set of assurance components in an ST does not have to be an exact EAL or even comparable to any EAL, making a decision about the 'assurance level' in a given evaluation quite problematic.)
Two examples where having some internalization of this evaluation's 'assurance level' will be essential are:
Assurance: There is only one component (not a hierarchy) for domain separation and non-bypassability (ADV_ARC.1). So apparently whether an implementation meets this requirement in a given instance depends on the other requirements in the ST. ADV_ARC.1 has no concept within itself of degrees of effectiveness nor of the effectiveness of a given implementation being highly dependent on what threats are claimed to be countered.
Function: (issue not new to v3.0) FDP_ACC.1.1 "The TSF shall [selection: allow, disallow] an operation of a subject on an object [selection: if, if and only if] ...". Whether the implementation of this function is good enough depends on what good means, and that varies depending on the security context within which the ST claims this function operates.
With CC v2 we had the level of threat determinators captured in AVA_VLA.3 and .4 to apply across the board with respect to all the other requirements. This was accomplished with the broad determination in AVA_VLA.3/4.5E:
"The evaluator shall determine that the TOE is resistant to penetration attacks performed by an attacker possessing a moderate/high attack potential."
This is a bottom line, comprehensive determination stating the overall state of the TOE. It is instructive to note that this is not unlike the bottom line determination that went along with B2, B3, and A1. And it is important to note that at a CCIMB meeting several years ago, several of the other certificate producing countries explicitly disagreed that such a determination could be made - despite the US doing so for many years.
CCv3.0 takes away this comprehensive determination, replacing it with:
AVA_VAN.4/5.4E The evaluator shall conduct penetration testing based on the identified potential vulnerabilities to determine that the TOE is resistant to attacks performed by an attacker possessing moderate/high attack potential.
Now the determination is the result of a red team exercise against a specific set of possible vulnerabilities. Previously the corresponding CCv2 determination was based on that and more. CCv2 corresponded to the TCSEC evaluation concept and CCv3 does not. Making a clear understanding of what we mean by 'reasonable' even more important.
Cheers, Gary
************************************************************************ * Opinions are not intended to reflect an official position of JHU/APL * ************************************************************************ * Gary Stoneburner * * Johns Hopkins University Applied Physics Laboratory * * 11100 Johns Hopkins Road, MS 17-N406 * * Laurel, MD 20723-6099 * * Phone: 240-228-2628 (WA DC), 443-778-2628 (Baltimore) * * Fax: 240-228-6391 (WA DC), 443-778-6391 (Baltimore) * * Gary.Stoneburner@jhuapl.edu * ************************************************************************ -----Original Message-----
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.
|