Re: PD-0101: Level of Detail Necessary for Assurance Requirements on Third Party Products
Magosányi Árpád wrote:
> I don't like this approach as it still have the concept of
> underlying abstract machine blurred, which should be made
> clear to allow further development of TOE composition.
The USer Note in part 2 Para 1175 defines the abstract machine to be
outside the TOE while these components are in.
So, let's start subdividing the universe to be sure that we have everything:
I have two entities:
- The TOE: the thing that is under evaluation
- The operational environment: the rest of the universe
The TOE can be said to consist of two sets:
- Major components: the full assurance is applied on these
- Libraries: less assurance is applied on these: ALC_TAT and AVA address
them, but ADV, ATE, ALC, ADO and ACM do not.
The operational environment can be said to consist of four sets:
- non-relevant entities (the Andromeda Galaxy is a good example for most
- non-IT entities (not relevant to this discussion)
- 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
- No assurance at all is applied to it since it is outside the TOE.
- A TOE meeting FMT_AMT does testing on it during operation but that is
> Regarding the development tools -which is a newly brought
> in point of view for me, nonetheless a valid one-:
> The adequateness of the development tools is assured by the
> outcome of the tests conducted in the evaluation: if the
> development tools have some shortcomings, it should come
> out there theoretically.
It will not come out in ATE. As ADV is not applied to libraries, they
won't show up in ATE_COV or ATE_DPT to be tested.
It might roll out by accident during ATE, or AVA might find a buffer
overflow in a library but that's it.
> Note that the libraries used are not part of the development
> tools; they are part of the underlying abstract machine, and
> should be handled accordingly.
See above for my thoughts on it. It is possible to define "libraries" as
part of the abstract machine instead of the TOE, but I'd like to hear
some definite advantages of it.
> I guess we should have clearly defined concepts of underlying
> abstract machine, development tool, and physical part, if we
> want the TOE boundaries and its interdependencies with other
> TOEs to be tractable.
> Your approach acts against this, this is I don't like it.
How about the above?
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 email@example.com