RE: PD-0091: Dependencies of Requirements on the IT Environment
- Subject: RE: PD-0091: Dependencies of Requirements on the IT Environment
- From: "Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>
- Date: Wed, 28 Jan 2004 13:15:04 -0500
- Content-Type: text/plain
> [JLA] I think the CC was intended to address such TOE architectures and
> hence I believe that refinement should not be necessary as I think the
> requirements should implicitly apply only within the TSC.
I do not understand the use of TSC here:
TSC = defined as the set of interactions with or within the TOE subject
to the TSP (Part 1, para 69).
TSP = loosely defined as being expressed the set of SFRs for the TOE
(Part 3 para 302).
So this statement translates to: SFRs apply only to those interactions
with or within the TOE that are subject to the SFRs for the TOE.
According to the definitions:
- if the environment corrupts the TOE that is an interaction with the TOE.
- if FPT_SEP is an SFR for the TOE in the ST, this interaction is in the TSC
- Therefore, if FPT_SEP is an SFR for the TOE in the ST, the environment
corrupting the TOE, is in the TSC.
This boils down to: you cannot generally use FPT_SEP in unmodified form
in a software-only TOE as the CC is currently written.
Work is ongoing in- and outside the CCIMB to rectify this. But in v2.1
(and v2.2) you will be stuck with this.
[JLA] I actually meant the TOE Scope of Control as in the things under the
control of the TOE. Obviously the environment is not able to control its
environment. Note that your argument leads to the conclusion that FPT_SEP
cannot be met by ANY TOE. In the case of a monolithic operating system, a
TOE generally cannot protect itself from physical assaults. I am unable to
explain why I keep seeing claims that an application TOE cannot FULLY
protect itself while this is obviously for the vast majority of TOEs that
have historically, seemingly met this requirement.
> Regardless, the
> TSS should be looked to to determine exactly how the TOE meets the
> requirements within its intended environment.
But in order to find out whether that was done correctly, I need to know
what the requirement means in the first place. With this scenario I
might as well go the ITSEC route and completely dispense with SFRs.
And then you get straight into the ITSEC troubles: where I think that I
clearly wrote down the functions in my ST, you may differ. One goal of
having the SFRs in the CC in Part 2 language is to help define the exact
meaning of the security functions, not the other way around.
[JLA] Given the repeated recommendations that explicit SFRs need to be
created for most real circumstances, I'm not really sure what difference it
would make. I tend to disagree that you need to understand 100% what a
requirement means from the requirement itself. Rather, requirements are
somewhat defined by the circumstances of their application. In particular,
assumptions should be useable to constrain the meaning of a claimed SFR.
> [JLA] I think the proposed new ASE removed IT environment requirements,
> I also think it was rejected by the powers that be. In any case, my
> statement applies to the current ASE.
The exact status is that they have been removed and that this removal
has been agreed to, but a open study item is to find out how STs can
support composition. This may or may not reintroduce SFRs for the
[JLA] Thanks for the info, the status was somewhat unclear at the last ICCC
and it has been a long time since the draft was put out for review...
> This stems from two things you want to do with Part 2 that conflict here:
> 1) If you want to make sure people do exactly what is in your PP, the
> contents of this PP need to be very strictly defined
> 2) If you want to write an ST not based on a PP, you want to be able to
> be a little bit more flexible
> [JLA] I disagree that there is a conflict in my statement. I think the
> requirements should have broad applicability as presented by the CC. If a
> author is concerned that the possible set of TOEs could, as a result, be
> broad, they are free to use operations (e.g., refinement) to narrow the
> scope of conformance. I think such narrowing is less important for an ST
> the TSS should provide some narrowing of scope to help users better
> understand the TOE.
Its not a conflict in your statement (I did not formulate well): it
comes from two groups of people wanting to do two things.
Your opinion: I want to write STs with "broad" SFRs, and if a PP author
has problems, he should modify the SFRs (use refinements)
The US Scheme appears to have the opinion: we want to write PPs and
therefore we make the SFRs themselves more narrow in Part 2. If an ST
writer has a problem with that, he should modify them (use refinements
[JLA] Actually, I don't care if ST SFRs are broad or not, so long as the
whole story is in the ST. I believe that the CC SFRs should be broadly
applicable, and I think interpretations and decisions (particularly in the
U.S.) have shown a trend of narrowing applicability of the base CC
requirements. Hence, I tend to agree with your statement essentially that
the U.S. is biased by its own PP development and is changing the CC to meets
its specific desires. Note that the unfortunate results is that the ST
writer cannot generally use refinements to overcome these changes, rather
they must use explicit extensions - which brings us back to the ITSEC
scenario I guess.
Date Index |
Thread Index |
Problems or questions? Contact email@example.com