Re: PD-0101: Level of Detail Necessary for Assurance Requirements on Third Party Products
> 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.
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).
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.
In the CC, we use implementation representation for your concept.
This is a choice. It is not a mathemathical imperative.
> 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 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.
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.
But this is different than forcing everybody to have this.
> 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.
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)
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
> 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:
> -web server, and "appication server"
> -operating system
> -subject security attribute management system
> -audit management system
> 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"?
> Also in most cases it would be hard to define how the TOE is a subject
> of some elements of the underlying abstract machine. Sometimes, maybe
> in the majority of the cases this holds. Sometimes some TOE subject
> (or object) have some corresponding object or subject in the underlying
> abstract machine. Sometimes the correspondence is even more vague:
> you might find that your whole TOE is represented in some rules of
> the firewall, but each of these rules are for other TOEs too (not as if
> I would allow such a lazy configuration: I consider firewalls as very
> important but yet uncapable devices in enforcing information flow
> control SFP in enterprise level).
That is because you are defining "abstract machine" differently than I
am. You can therefore not apply the same rules to it than I am.
> You are true except that my statement is untrue. The transformation is
> actually defined by the operands _and_ the operator, but its result is
> nevertheless a result of the transformation:)
> Note that I have given up this approach for a more concise and
> politically correct one above:)
> 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
Example: my PC relies on the correct functioning of the Dutch power
system. Are the IT parts of this system now part of my abstract machine?
TNO ITSEF BV
P.O. Box 96864 tel +31 70 374 0304
2509 JG The Hague fax +31 70 374 0651
The Netherlands www.commoncriteria.nl
Date Index |
Thread Index |
Problems or questions? Contact firstname.lastname@example.org