RE: FPT_SEP in an Application TOE (does mutual recognition work?)

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

While I am certainly a proponent of truth in advertising, I do not agree
with the statement that SFRs must be tailored to capture only what the TOE
does (without support from its environment). I have said it before and I
will say it again, the CC clearly supports the notion of TOE dependencies on
its environment. 

My observation that there are validated STs that exclude critical components
- critical in that the TSSs in those STs make it very clear that certain
SFRs are largely addressed by the excluded components - has been answered
with a claim that commodity hardware cannot be evaluated as part of a TOE. 

It is interesting that it is being argued that hardware cannot reasonably be
included in a given TOE due to CC design documentation requirements, but
(presumably) the result of that opinion is that hardware has simply been
excluded from the TOE. However, it seems that it is fairly widely argued
that the SFRs should have changed as a result, which would jeopardized PP
conformance (and that presumably was not acceptable). But to further
complicate things, the PP is a US PP where the US Scheme has been pretty
clear in stating that certain SFRs (e.g., FPT_STM) require hardware (in
fact, this has caused a number of IDS products to be not PP conformant) and
essentially every US evaluation against the PP and its documented
predecessor (the TCSEC) for the past 20+ years has included hardware.

I don't know who is right and who is wrong, but I wonder about inter-Scheme
discrepancies such as this and what is being done now or in the future to
mitigate them.

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

> I basically agree with Gary on his comments on "truth in 
> advertising". 
> No CC-scheme should allow to make false claims about what was 
> included and what was excluded from the evaluation. Including 
> the hardware and its security functions to provide separation 
> should require that those functions are evaluated in the same 
> way as the software functions that use those hardware features.

I generally agree that the TSF should be evaluated in a consistent, or at
least acceptable, manner regardless of its composition.

> As a consequence of this at an EAL4 assurance level the 
> evaluator needs to have access to the high-level design, the 
> low-level design, a subset of the implementation 
> representation and the developer tests of the security 
> functions that provide the separation features in the 
> underlying hardware/firmware. If he does not have access to 
> this information, the evaluator has to fail the evaluation.

EAL 4 requires design documentation including a 'subset' of the
implementation for the TSF, as opposed to parts of the TSF. As such, it is
possible that hardware, in the example above, may be considered a 'module'
or 'subsystem' but it is certainly not always the entire TSF.

> The information normally provided by hardware vendors to 
> software developers on their processors and chipsets is 
> actually not sufficient to satisfy the requirements of a 
> high-level design or a low-level design of the separation 
> functions. This information normally consists of a (quite 
> detailed) interface specification and an architecture 
> description. When you look into the manuals provided by Intel 
> on their processors you can clearly see that this is what 
> they provide. Any evaluation that claims to include the 
> hardware and which is based just on this documentation needs 
> to fail. But as far as I know this has been the only 
> information used in some (successful) evaluations at the EAL4 
> level which claim to have the hardware included as part of the TOE. 
> "Truth in advertising" demands that you do not claim more 
> than you actually provide!

I believe that the observation, in this example, that readily available
hardware documentation is not adequate is highly subjective. Hardware may be
only a piece of the entire TSF. The requirements for modules and subsystems
basically require a description of what the module or subsystem does and an
interface specification (along with some correspondence analysis and such).
So, it is not clear how it can be predetermined that a TOE including an
Intel processor must fail.

> While the treatment of the hardware may be a matter of scheme 
> interpretation, the following statement taken from the 
> Windows 2000 Security Target clearly overstretches the 
> "flexibility" of the Common Criteria and would not have been 
> accepted in the German scheme:
> 
> > FPT_AMT.1 requires there be a suite of test available to demonstrate 
> > the correct operation of the security assumptions provided by the 
> > abstract machine that underlies the TSF. Typically, the term 
> > "underlying abstract machine" refers to the hardware components upon 
> > which the TSF has been implemented. This requirement is only 
> > applicable to a TOE if the TOE relies upon security assumptions of the 
> > underlying abstract machine. This ST does not include any assumptions 
> > on an abstract machine. The TOE described in this ST includes the 
> > hardware components. Therefore, this requirement is not applicable to 
> > this TOE. Given this, the objective the CAPP identifies is supported 
> > by FPT_AMT.1 (O.Enforcement) is totally satisfied in this ST by the 
> > TOE meeting FPT_RVM.1 and FPT_SEP.1. Additionally, there are no 
> > requirements in the CAPP that are dependent upon FPT_AMT.1.

This is an interesting observation. The CC defines FPT_AMT.1 to apply to the
'underlying' abstract machine upon which the TSF relies. This reasonably
means something not part of the TSF. It further indicates that it could be
hardware or hardware/software, but it does not explicitly address the case
where there is nothing outside the TSF upon which the TSF relies - the CC
certainly is not a comprehensive document. As such, I think it quite a
stretch to claim this is an unacceptable interpretation of the CC
requirement. Especially, given that the HLD requirements also talk about the
underlying abstract machine in the context of describing interfaces to the
environment of the TOE. So, while I think any Scheme is certainly free to
interpret things more narrowly, I think it is unreasonable to impose those
interpretations on other Schemes except through the International
Interpretation process.

> So one claims compliance with a clearly required 
> functionality which is not implemented? The argument 
> presented is: we can omit this functionality since we had the 
> hardware as part of the TOE. It should be noted that 
> FPT_AMT.1 is a requirement for the periodic testing of the 
> security functionality of the underlying abstract machine 
> (see the user application notes for FPT_AMT.1 in part 2 of 
> the CC). The requirement has been included to detect hardware 
> faults when the TOE is operated. It seems the evaluators of 
> Windows 2000 argue that due to their intensive analysis of 
> the hardware they can declare that those faults will not 
> occur during the lifetime of the TOE. On the other hand the 
> ROM software used to boot the systems (which has been subject 
> to the evaluation - or
> not?) performs some checks of the underlying hardware - but 
> obviously the information about those tests and if they test 
> the protection functions of the processor sufficiently was 
> not available to the evaluators. Otherwise they could have 
> used this functionality as an implementation of the FPT_AMT.1 
> requirement (since the Boot-ROM of the systems was part of 
> the TOE - or was it not? The ST is unclear here as it is 
> unclear about the details of the hardware).

I am confused, since FPT_AMT.1 is not claimed in the cited ST. You have
shifted from a CC conformance issue to a PP conformance issue. In this case,
I believe the CC interpretation was presented and the PP owners were
consulted and approved the situation. Right or wrong, the ST clearly
explains that FPT_AMT.1 is not claimed, so Truth in Advertising is
maintained.

> By the way, the Linux systems mentioned by Jim Arnold had a 
> tool that can be used to periodically verify the correct 
> operation of the security functions of the underlying 
> hardware, especially the memory protection features and the 
> restriction of certain instructions to processor privileges. 
> The manuals describing the hardware architecture and 
> interfaces have been assessed as part of the evaluation to 
> verify that the protection features of the hardware are 
> correctly and consistently used by the operating system to 
> protect the trusted part of the TOE as well as to protect 
> individual user address spaces from unauthorized access. This 
> is required to verify the assumptions made about the 
> underlying hardware in the Security Target. I think this 
> approach is much more in line with the intention of the CC 
> than an approach that makes claims leading to false 
> assumptions about what has been analyzed to what extent.

The Linux STs in question specifically exclude hardware and administrator
tools from the TOE and as such it must be assumed that they were analyzed
only to the extend required by the claimed assurance level. This essentially
means that the interface to the IT environment was evaluated in the context
of the high-level design. Given that hardware is not part of the TSF,
FPT_AMT.1 seems perfectly reasonable. On the other hand, it is generally
held in the US Scheme that you cannot extend the set of assumptions in a PP
since that effectively weakens the solution. So it seems another Scheme
discrepancy is identified here.

Again, the statement of false assumptions about what was analyzed seems
pretty subjective since the CC is about analyzing things to a degree
indicated in the claimed assurance level and security relevance. But I do
agree that the CC supports the notion of making claims with documented
dependencies.

> Areas like the treatment of underlying hardware / firmware 
> when FPT_SEP and FPT_RVM is claimed should be subject of a 
> common interpretation and potentially a common augmentation 
> of the CC and the CEM rather than subject to individual 
> scheme interpretations that tend to lead to a shift of the 
> criteria into different directions for each scheme. And for 
> the "truth in advertising" the scheme interpretations should 
> not attempt to demand unrealistic things like "if you claim 
> FPT_SEP you must include the hardware in the TOE". 

On this, I think we agree.

> While I 
> agree that the hardware needs to be carefully analyzed when 
> claiming high assurance levels and FPT_SEP functionality I 
> disagree that this analysis can be done in accordance with 
> the Common Criteria without having all the documentation 
> required by the CC for the target assurance level. As Gary 
> stated: "Claim in the ST only what the TOE actually does." 
> And I would like to extend this with ".. and what you are 
> going to evaluate in accordance with the claimed assurance level".

I think that the TSF has to be analyzed appropriately according to the
claimed assurance level, but the requirements apply to the TSF as a whole as
opposed to selected pieces. The CC does not specify the required degree of
decomposition and that can affect how much is know about each specific
component of the TOE and the amount of information that is necessary is
related to the degree of security relevance.

I agree that the ST should claim what the TOE does, but I disagree with the
notion that it is entirely up to the SFRs to scope what the TOE does. The
SFRs should be addressable despite dependencies, so long as those
dependencies are clearly articulated. I am unaware of any TOE that doesn't
have some sort of dependencies - be they physical protection, assumptions
about technical capabilities of users, expectation of guidance being
followed, electricity, or laws of physics - though a given ST may fail to
identify them all.