RE: PD-0091: Dependencies of Requirements on the IT Environment

["Daniel P. Faigin" <faigin@solarium.aero.org>]

To reduce message traffic a bit, I'm going to respond to two messages in one.

On Wed, 28 Jan 2004 15:22:57 -0500 (EST), "Arnold, James L. Jr."
<JAMES.L.ARNOLD.JR@saic.com> said: 

>> I'm not sure what you mean by narrowing applicability. Those that interpret
>> requirements are simply trying to use the words as they are written. If you
>> are trying to say there is additional meaning that should be derived from
>> context, then I say to capture that meaning in the words of the
>> requirement.

> What I mean is that interpretation, in my experience, normally doesn't
> involve simply restating the same words. Rather, interpretations tend to
> limit how a requirement can be used or met and this is what I mean by
> narrowing applicability. For example, if you say FPT_UAU cannot be used when
> the TOE relies on a 3rd party smart card for authentication, I think you
> have narrowed the applicability of that requirement.

OK. Let's look at that example. I'm presuming you really mean
FIA_UAU.something. These requiements require that the TSF provide some feature
related to authentication.

Suppose the TSF requires a 3rd party smart card to do this, as Jim
suggests. Let us further presume that this 3rd party smart card is not part of
the TSF, for whatever reason (likely ACM). What do we do?

If there are no environment statements about what the smart card is presumed
to do and provide, I don't see how one can argue that the TSF meets the
requirement.

So, let's suppose that we have a good ST author here, who writes a requirement
that the smart card provides an interface for authentication to the TSF.  Is
the TSF requirement met yet? Unclear. Someone might argue that although the
interface is there, there is no guarantee it is being used.

Suppose now that the TSF requirement is refined to add "using the smart card
interface provided by the IT environment". The picture is now clear as to what
is being done.

Of course, there is an underlying assumption that the smart card works as
advertised. If I were writing the ST, I'd probably write that as an
assumption, as I can't verify it, to make it clear to the accreditor the risk
that is being assumed.

How else might this be done? If one is simply excluding the smart card due to
assurance requirements, if the threats justify it, perhaps one could make a
balanced assurance argument, as has been discussed for interpretation
I-0451. Perhaps the smart card has been separately evaluated, and that can
come into play. I'm assuming none of those factors arise.

> I agree that English is not very precise and to use it in a confusing manner
> serves to make things worse. I also tend to believe that it is not so
> important to nail down 100% a requirement in the CC when a PP or ST can
> provide context that will lend to the meaning of the requirement.

So far, I agree, which is why there are operations in the CC.

> For
> example, FPT_SEP for a monolith and for an application could potentially
> carry different meanings relative to the context of its use. Perhaps this
> could be considered an education problem.

I don't like different meanings in different contexts without changing
words. It's one of the reason I don't like using CC tags to describe
environment requirements. It confuses the end users.

End users will look at the set of requirements met, and not see the
context. If there has been sufficient change that context is required (and
refinement is insufficient to capture it), there should be a distinct tag
change to alert the consumer.

Also, foreign language translations are very poor at capturing the
implications of context.

In another message on Wed, 28 Jan 2004 15:22:45 -0500 (EST), "Arnold, James
L. Jr." <JAMES.L.ARNOLD.JR@saic.com> said: 

> I stand corrected. The actual statement was more along the lines that 'The
> TSF shall maintain' means the TSF has to 'provide that service' in response
> to a comment that the TSF should not necessarily have to implement the
> mechanism to provide the domain. Regardless, the TCSEC is irrelevant. Things
> that were included in TPEP are not always available today given the added
> non-TCSEC ACM and ALC requirements, for example.

I don't think the TCSEC is irrelevant (or even irreverant), but it needs to be
viewed as the TCSEC, not the CC.

Your example of "maintain" vs "provide" is a good example, I think, about the
sloppiness of the CC words. What is the difference in these terms? Why the
distinction? It isn't made clear; this is where interpretation comes into
play. 

> I think what is required is that the TSF maintains its domain separate from
> other domains. Note that I think this can also be accomplished by an
> assumption about being locked in a closet in conjunction with an
> architecture that doesn't offer access to other domains.

But in locking the TOE in a closet, does the TSF have any part in doing the
maintenance, or is it just a bystander. If the requriement says that the "TSF
maintains", then the TSF should actively do something. Otherwise, how can one
claim it is met by the TSF?

>> It is not "interpretation" because the NIB saw no reason to make changes
>> in
>> the actual words of the criteria; it felt that the words were clear
>> enough. Of
>> course, the CCIMB, when reviewing the statement, might choose to clarify
>> the
>> words of the criteria.

> I think my problem is that the 'interpretation' seems to represent the
> general rule and seems more suited as a 'precedent' if there is one since
> there is no actual interpretation. 

Perhaps. What you are seeing is an artifact of the former IWG being split into
the NIB and ODRB, with the plan that the NIB will have CCTL participation at
some point, and thus be non-proprietary. Thus, the NIB cannot issue PDs (and
the ODRB cannot issue interpretations). The ODRB will throw interpretation
requests over the fence to the NIB when interpretations are necessary,
sanitizing them as appropriate. The NIB, when it sees discussion on cc-cmt not
related to an existing OD, can only issue guidance "interpretations". I think
you should view "guidance" as a varient of a PD.

[In fact, I'll note that this entire chain has created a dilemma for me as the
NIB/ODRB recordkeeper. The discussion is on cc-cmt, which is normally
collected for the NIB to review. Yet, the discussion (originally) related to a
PD, which is ODRB provance. Right now, the membership of the two groups is the
same, giving me some leeway, but I guess logically, if the NIB reviews it and
thinks there should be a PD change, it should either issue guidance which may?
supersede the PD (we have no procedures for that), or throw it back over the
fence to the ODRB to correct the PD. Ack!]

>> > Furthermore, it is not even a good opinion since hardware is crucial to
>> > self-protection primarily in cases where general user computing services
>> > (i.e., the ability to write programs) are offered.
>> 
>> So everyone has context, this is what I-0463 says (it has been sent to
>> management for approval, but management has been slow to approve stuff):
>> 
>> [...]
>> 

> Sorry, the hardware aspect is only implied and was more prevalent in the
> earlier discussion and the examples that are often put forth in relation to
> this issue.

In the last cycle, based on public comment, the guidance was reworked to be
much less specific about hardware. See, we do listen.

>> Perhaps Jim is alluding to a software-only TOE that attempts to put the
>> hardware in the environment, but has a requirement for FPT_SEP on the
>> TOE. Said TOE might depend on the hardware for a ring mechanism and
>> address
>> space separation.
>> 
>> If that TOE has FPT_SEP, then the requirement states that the TSF must
>> provide the protection. Not the environment. If the author had meant the
>> environment to provide it, they would have written it on the
>> environment. Now, since self-protection (i.e., the ring mechanisms and
>> address space separation) is provided by the environment in the example, we
>> can't say the TSF is meeting the requirement.

> Note that the protection in this example is only partially provided by the
> environment. I have yet to see a ring mechanism that can protect an OS or
> separate users without being specifically directed how to do so by some
> software.

Concur. That is why there need to be aspects expressed in both the IT
environment AND the TSF requirement.

> Sorry, I still don't get it. What if my hardware doesn't have a ring
> mechanism? I have a firewall on DOS on an 8086 in a physically secure closet
> that claims to protect itself. Just what does the 8086 or DOS lend to the
> argument of self-protection? Can I not claim that the TOE protects itself
> from its subjects if I claim DOS and 8086 as part of the environment for
> which I have no security requirements beyond they behave?

I think, if you are relying solely on physical protection, you can't claim the
TSF does it, because there is no specific mechanism in place. It would be
equivalent to saying you meet identification requirement if you have a guard
at the door of the building checking password. Yes, the system is protected,
but the issue of the CC is the assurance of protection provided by information
technology, not physical or procedural mechanisms.

> Now let's say I have an OS TOE, but choose to exclude the hardware since I
> don't know how Motorola does configuration management and they are unwilling
> to be subjected to an audit. I could try to put the FPT_SEP requirement on
> the hardware, but the hardware doesn't even know what a security domain is,
> what processes are, or which memory to protect. Rather, only when the OS
> makes effective and correct use of the available hardware features (in
> combination with software features) can the OS protect itself from its own
> users. So, I say, what is wrong with claiming FPT_SEP for the OS? What if
> the OS developer can produce the necessary hardware information upon which
> they based their design, but they are still left only with assumptions about
> the existence and accuracy of the hardware against that information?

I would say in such a case to put a requirement on the IT environment to
provide such and such services to the TOE, and to refine the TSF requirement
to explicitly make use of the services provided by the IT environment. This
makes it clear to the end user what is going on, and where the risk lies.

> Now let's look at an application operating in an OS that provides process,
> memory, and file constructs. The OS cannot protect the application from its
> subjects, especially since it doesn't really know much about the
> application. Why should the application be denied a claim that it protects
> itself in its own domain as supported by the OS and separates its subjects
> as it realizes them just because it makes use of support from the OS?
> Obviously, it would be necessary to explain the assumptions and IT
> environment requirements applicable to the OS, but the application should be
> able to make the claim nonetheless.

Same answer as above. Explicitly state what the IT environment provides, and
refine about what the TSF uses. 

In a third message, Jim writes:

> I'm not sure this is a problem of SFRs. Assumptions allow a ST writer to
> identify things that are not or cannot be addressed by the TOE and must be
> true in order for the SFR claims to be valid. Most products, for example,
> claim that the TOE must be physically protected. Given this, is it not
> reasonable to believe that the TOE doesn't fully protect itself? There are
> technologies available to provide such protection, perhaps they should be
> required in order to meet self-protection requirements. If the administrator
> doesn't set the TOE up to enforce password minimums correctly, they will not
> be enforced. Yet, it is often the case that such claims are made despite
> reliance on the administrator.

In the case of your last example, one can verify that IF the settings are made
correctly, the product will provide appropriate enforcement.

> Why cannot such assertions be made about the
> IT environment of the TOE while allowing the TOE to claim CC requirements
> without modifying them to reflect such assumptions, etc.?

I believe in specifity. If you are dependent on an external mechanism to meet
a requirement, make that explicit through refinement. This lets the accreditor
know where the risk lies. 

>> Assumptions (and IT Environment statements) are like axioms. Things that
>> are assumed to be true for proof purposes. However, if there is no IT
>> environment statement about the IT environment providing a particular
>> support to the TSF, then it falls on the TSF to meet the requirement
>> completely.

> I'm not sure what you mean. Unlike assumptions which don't seem to require
> changes to SFR language to meet the SFR, previous responses have led me to
> believe that when a TOE depends on the IT environment the SFR should either
> be assigned to the environment or the SFR should be explicitly split among
> the TOE and IT environment. Perhaps this is a point of contention because I
> think that the TOE should get credit for security functions even when help
> is needed (from users, environments, IT environments, laws of physics, etc.)
> so long as its dependencies are accurately articulated somehow.

I think there is a distinction between mechanisms provided by the IT
environment, and non-IT mechanisms. After all, this is the Common Criteria for
INFORMATION TECHNOLOGY security evaluation. We evaluate IT.

So, if the IT environment (i.e., hardware, software, firmware) upon which the
TSF depends provides a critical security function to the TOE, that should be
explicitly noted, from both sides (provision, use). The TOE can claim to meet
the requirement that has been refined to use the feature, in MY opinion.

Now, if the use of the external mechanism is not refined, then the requirement
read in isolation implies that the TSF satisfies it 100% on its
lonesome. We've all built requirement matricies: requirements get pulled out
in isolation. Thus, one must take the narrow interpretation, because one
doesn't see the context. Hence, I say verily, provide the context, my lad, in
the form of refinement.

However, for non-IT mechanisms, it doesn't work. That's analagous to saying my
DOS box is high assurance because I physically limit it to one user, who must
sign a log and pass a guard when they come in, giving me an audit trail and
I&A. That wasn't acceptable in the past, and it doesn't meet the standard for
something provided by IT. If there is a claim that the TSF does something,
then there needs to be something in the TSF that does it.

> Basically, the CC does not provide
> any useful assistance in dealing with requirements that cross TOE boundaries
> even when the boundary is only to the IT environment as opposed to the
> environment (which may be different) where the TOE offers its services.

Here you are right, and it is a problem that goes back to the earliest
criteria. We don't deal with composition and systems well.

Daniel