[E-Lang] Learning about assurance

[Jonathan S. Shapiro]

I see now why I deleted MarkM's note without seeing it. The subject line was
useless, and the Migration and Una discussion wasn't useful to me. Most of
us try to be pretty good about this, but a gentle reminder that some of us
get 100+ messages a day, and filter aggressively. Subject lines matter.

> Is [TSF] just a relabelling, or does it have a different definition?

I think it's just a relabeling, but the relabeling was done because a great
deal of confusion had been generated by the term TCB concerning what was
(not) included, so the term was abandoned. However, one of the differences
is that when considering the term TSF there is now recognition that the TSF
depends on one's point of view, and that TSF's may be layered. E.g. the EROS
TSF includes the space bank, but the EROS kernel without the space bank is a
potentially useful TSF for implementing a many-worlds object system.

Also, a distinction is made between the security-enforcing and the
security-relevant portions of a system (this is a nit probably not relevant
to you). The security-enforcing parts are the parts that implement the
security policy. The security-relevant parts are any other code used by the
security-enforcing parts. For example, the qsort routine becomes
security-relevant if some security-enforcing component uses it to keep a
list somewhere.


>>The deeper I get into assurance the more
>>convinced I become that fundamental work is needed in this area.
>
>Sounds interesting.  What do you have in mind?

Work on threat modeling -- how do you know you are comprehensive enough?
Work on OO systems -- how to you structure system descriptions when there
are multiple instances of things and when the primordial arrangements
matter -- somechint not considered by CC
Work on design capture -- how can we characterize better what is really
needed in the documents that capture high level and component-level (what CC
calls "low level") design? Once again, what is missing when the system is OO
structured?

> What should one read to learn the perspectives of the assurance community?

There really isn't much from the developer point of view. The Common
Evaluation Method provides guidance for evaluators doing low assurance
evaluation. One can invert the expectations to derive requirements on
developers. There exists no equivalent guideline for high assurance
evaluation. It is not clear why. This is also an open research area.

csrc.nist.gov/cc has various documents and various protection profiles
(requirements documents). As you read them, remember that this is all in the
early stages, and that it is still more art than science. In general, there
is a need for rigor throughout and a more modern perspective from the
assurance community, but things are groping after a reasonable goal. Very
little science in all this to date, however.


Jonathan