Re: PD-0101: Level of Detail Necessary for Assurance Requirements on Third Party Products

[Magosányi Árpád <mag@bunuel.tii.matav.hu>]

A levelezőm azt hiszi, hogy Dr.Ir. D.J. Out a következőeket írta:
> 
> >As a side note I would like to point out that for me the source code
> >_is_ the TOE, and compiling or interpreting it is just some
> >uninteresting detail:) This side note has nothing to do with any of
> >the ideas expressed here. Or does have?
> 
> There have been vast discussions on TOE-ness over the years. The current 
> TOE concept (a bunch of executable IT plus its manuals) was chosen to 
> accomodate certification. Somehow, the certificate as applied to the TOE 
> must mean something to the consumers.

This is why I said it is a side note. I agree that the TOE should mean
something to the consumer. However this fact should not detract us from
taking a viewpoint where we can handle the problems. If we could handle
the problems we are just trying to blur now, it would deliver meaningful
results for the customer too.

Binding the TOE boundaries to the implementation representation should
not mean that we call the implementation representation the TOE. Just
call the implementation representation implementation representation,
and call TOE the TOE derived from it. But it helps us a lot to
understand exactly how the TOE derived from the implementation
representation when we try to figure out what assurance measures to
be used against the TOE and the tools used to generate it.

> 
> The TOE is roughly speaking that which gets delivered to the consumer 
> and the certificate applies to that.  (It lies more subtle but I won't 
> go into that).

Well. This definition fits with my definition, if you keep the
interpretation about third party products in consideration.

What is actually delivered is a bunch of items which are transformed
from the implementation representation, plus some evaluation evidences
supporting it, plus some third party items which should be identified
if we don't want to mislead costumers.

> 
> If you certify the TOE (Source-code compiled into stuff) a consumer can 
> attach semantics to it. This TOE does what its ST says. I can use it for 
> X but not for Y.
> 
> If you certify the source-code, a consumer cannot.

Of course you should certify the actual TOE, not the source code.
But knowing where the TOE ends and the supporting things begin makes
it easier to use the results of the interpretation.
It is not meaningful to have products certified on one instance of
hardware, etc, and it is not meaningful to have one instance of HSMs
certified. This is what the CC currently does, and gives no guidance
at all on how these evaluation results can be used in real world.

I hope no one is serious about that I have to use an age-old version
of trusted solaris and an equally outdated trusted oracle running
on the actual hardware used for the evaluation, all of them way over
their product life cycle, loaded with well-known vulnerabilities
if I want to have an IT system I can trust. (And I did not even
talk about the fact that I want to run actual applications, not
just use the OS and the rdbms).

> >The compiler is contributes somethingto the TOE just like the underlying
> >abstract machine does it. The compiler is arguably outside the scope
> >of TOE, hence:
> >	-the fact that anything which cannot be found in the
> >	implementation representaion is outside the scope of the
> >	TOE still holds
> >	-the fact that anything within the TOE should receive correct
> >	assurance still holds (because it does not mean that entities
> >	outside it should not).
> 
> This is just repeating your own definition. I can define the TOE to be a 
> bunch of bananas or an intelligent shade ofthe color blue if I want.
> 
> What semantics does your certificate on this TOE definition have?

The certificate is still about the trustability of the actual system,
but the evaluation evidence gives you precious input for your risk
management decisions when you want to apply the product in a real
world environment.

> 
> The difference IMO between a complier and an OS is that:
> 
> The implementation representation is compiled into the TOE. The 
> "compiler added stuff" can therefore never be extricated from the TOE 
> again. Consumers cannot acquire the TOE apart from it. It is therefore 
> not meaningful to them to separate it.

This view is not meaningful, as:
	-you can get rid of "compiler and added stuff" in the TOE by
	simply recompiling it, hence replacing it with another
	"compiler and added stuff".
	-it is therefore makes harder to attach any meaning to the
	acronym AMA
I would like to point out that actual products come out on a plurality
of platforms, have a plurality of versions (of which the actually
certified ones are often unacceptable because of their age), and
have dependencies which also come out in a plurality of versions
and on a plurality of platforms, and a plurality of configurations.

As CCIMB clearly stated, it is a configuration management nightmare.
But just saying that it is a nightmare and you refuse to deal with it,
won't help us, the customer too much.

> 
> Having said all that, what you want is possible in the CC. You *can* 
> have a TOE consisting of source-code. The G part of ADO_IGS was 
> specifically written to handle this.

Even in this case you would certify an actual instance of the TOE
with all of its dependencies, compiler and added stuff. Because
it is the tractable way of it. Which does not mean that you should
push your head into the sand and forget about that stuff pretending
it does not exists. It may be a good defence against the Big Bugblaster
of Traal, but the real bugs will not eat it:)

> >You have two approaches to the compiler:
> >1. It is part of the underlying abstract machine, just like the
> >interpreter and processor which runs the code is. The compiler
> >is the abstract machine which makes it possible for the lesser
> >abstract machine to underly the TOE:)
> >This approach have the benefit of being conceptually clear,
> >and politically correct (if you would call RMSisms politically
> >correct:). It also have the drawback that we have an entity
> >for which AMT is not actually possible in run-time (as it is
> >also problematic or at least questionable to do to static libs.)
> >
> >2. It is an operator mathematically speaking, which converts the
> >implementation representation to the implementation.
> >I deem this approach less useful than the previous, as it is
> >makes things more compex, politically incorrect ;), and
> >brings no mentionable benefits.
> 
> I repeat: 2) gives semantics to the certificate. The end user can now 
> buy this thing.

Just like with 1), where you not just can have a semantics with the
certificate, but also give useable data on how to interpret it, and
apply to each one's unique situation.

> I still haven't seen a single actual advantage of your method (apart 
> from politically correctness, of which I'm almost sure that you and I 
> mean something completely different with)

A clear vison of what is the TOE and what is not, how far the evaluation
results can be interpreted, and the ways it opens for AMA, TOE
composition, and real world usage are all advantages.

> Outside the countries of Evaluatia and Academia, nobody cares whether 
> the source code of a thing has properties. The only important thing for 
> end-users is whether the thing has properties. The CC is for certifying 
> stuff.

Just like no one rally cares about semiconductors have properties.
The only important thing to them that their digital watches show the
time exactly.

Or just like no one else outside the open source community cares about
or even interested in exactly how opennes of source leads to its
financial advantages. They are only interested in the financial
advantages.

> 
> >Your opinion show the need for looking a bit into the complex
> >interdependencies of real world IT systems. A typical application
> >in an enterprise framework depends from the following items:
> >-RDBMS
> >-web server, and "appication server"
> >-operating system
> >-firewall
> >-subject security attribute management system
> >-audit management system
> >-etc.
> >
> >I would like to call the set of these items the underlying abstract
> >machine on the ground that they all offer security functions to
> >the TOE.
> 
> What would be the difference with the "operational environment of the 
> TOE" or the "IT environment of the TOE"?

I guess that operational environment would contain non-IT elements.


> >Bottom lines follow:
> >1. The TOE boundaries should be drawn by the boundaries of its
> >implementation representation. 
> >2. The underlying abstract machine is the set of outside IT entities
> >upon which the correct functioning of the TOE (or better TSF)
> >relies. (Note that this sentence is drawn from the first sentence of
> >FPT_AMT. Our grandfathers who have created CC thought it out
> >very well.)
> 
> The CC is a bit like the bible. You can support many things from it. 
> There have also been huge discussions on what "relies" and "correct 
> functioning" mean.

I believe you:)

The question remains: whether these bottom lines are acceptable
starting points to have a possibly unambigous definition of
what the TOE is, which opens the way to talk about TOE composition
and AMA in a serious manner.

-- 
GNU GPL: csak tiszta forrásból