[754] in WWW Security List Archive
Re: Extending Trust...
daemon@ATHENA.MIT.EDU (Spence Minear)
Wed Jun 28 13:51:11 1995
Date: Wed, 28 Jun 1995 08:37:49 -0500
From: Spence Minear <minear@sctc.com>
To: www-security@ns2.rutgers.edu
CC: zurko@osf.org, sroussey@balboa.eng.uci.edu
Errors-To: owner-www-security@ns2.rutgers.edu
> In thinking about trust, I've found it useful to break the concept
> down into two components; amount of trust, and trust for
> what. Following your example, I would expect SuperWorriedParents to be
> much better vetters of toy ads than software integrity. While it's
> fairly easy to think of a variety of algorithms that might do
> something useful with "amount of trust", figuring out the types of
> "for what" is harder. You might start by answering "What will this be
> used for?".
In looking at secure systems I think that there are at least 3 types
of "for what" or "What will this be used for" classifications that
stick out quite clearly. They are in order of importance to security:
1 Security Decision Software
Software that is aware of security labels and embodies the
system's security policy.
2 Security Critical Software
Software that has access to security critical data, but whose
role in security is to maintain the integrity of the data not
interpret or make decision based on its content. An example
is a device driver that must transfer data of between memory
and a device. Different parts of the data streams may have
different security labels, but that is of little consequence to
the actual device driver.
3 Operationally Critical Software
Software whose correct operation is critical to the system
being able to complete its mission but has no direct control
over or responsibility for security critical data. Another
way to characterize this software is that the identical
function would be a critical element of a reliable unsecured
operating system. For example process context switching
software.
The issue of assigning trust levels may be easier once this kind of
"what for" information is in hand. I suggest, however, that actual
assignment of trust levels should be driven by an assessment of system
failure modes and/or attack scenarios. Once you understand the impact
of a particular failure in a particular system element you start to
understand how much trust you are placing in that system element.
Another place to look for understanding of trust levels is in the
design and development of safety critical systems. Traditionally the
two areas may have taken different approaches to assurance, used
different terminology, and have a bit different focus, but the
underlying issues fundamentally the same.
Spence Minear
Secure Computing Corp.
