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:
> 
> >We have a very important, but wrongly stated point here.
> >
> >Anything which cannot be found in the implementation representation
> >is not part of the TOE. And anything which can be found there
> >should receive correct assurance.
> 
> A software implementation representation is somehow "linked together" 
> with a specific compiler. Only the combination of the two produces *the* 
> TOE that actually does something.

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?

> 
> If I use different compilers, I will have different TOEs. Therefore the 
> compiler contributes something to the TOE. Therefore the statement above 
> is not true.

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).

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.

> >>- IT entities that talk with the TOE more or less "peer-to-peer"
> >>- IT entities that have the TOE as a subject
> >>
> >>I would call the last one the "abstract machine". Becuase it is in the 
> >>environment:
> >
> >
> >I am not sure that this division is good. Does a chipcard reader
> >have an application relying on its correct operation as a subject?
> >No.
> >Is the chipcard reader is part of the abstract machine the application
> >is operating on? Yes.
> >Do they talk peer-to-peer? It depend on your interpretation.
> 
> >I think that we have no use of the notion of "subject" here, but
> >rather on the notion of dependency.
> 
> What I'm trying to express is that there are two relation TOEs can have 
> with each other:
> - they can be peers (e.g. a firewall TOE and a database TOE). These are 
> somehow "next" to another.

Wrong example. The firewall actually provides security functions for
the application, hence it is not peer, rather part of the underlying abstract machine.

A better example would be two application TOEs which exchange some
user data. (Side note: I always have to spend lot of time to explain
that "user data" is not "subject security attributes", rather
"data handled by the application". Does it warrant some terminology
change?)

> - one can be the subject of another (e.g. an OS TOE and an application 
> TOE). Now one TOE is more or less under the full control of the other.
> 
> I have no mathematical definitions of this.
> 
> I would call the second one to be the abstract machine concept.  But 
> this is my personal opinion.

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.

The subject security attribute management system (like AD, ldap, kerberos, ....)
 can include rather complex applications, and more intermediate
 steps (pdc, bdcs, ldap replicas, converters, etc). The same is the
 case for the audit management system. Which means that at first sight
 you would either forget them, or think that they talk peer-to-peer
 to the application which they don't.

The important aspects of these items are not under the control of the
TOE. I would be very unhappy to see that the TOE controls anything
in them: the developers stated in the design phase what they expect
from them, they will get it, but the control is in the hand of their
respective administrators. Just like with the microprocessor or the
chip card: you have an interface to interact with them, but the control
is in their hand: if you are not symphatic to your processor, it will
hit you with page faults, so to say.

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).

> 
> In any case as "dependency" is a reserved word in CC, I wouldn't use that.

Could you coin a synonymous term?

> >Let's try it again, keeping in mind that the TOE is a
> >transformation of its implementation representation,
> >mathematically speaking.
> 
> This statement is untrue: the TOE is a mathematical transformation of 
> the TOE implementation representation and the tool that you use to 
> transform it.
> 
> Or, better formulated: a result is defined by both its operands and the 
> operator.

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.)

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