RE: Re: Trusted OS...

["Starkey, Kyle" <Kyle.Starkey () msdw com>]

Todd...
I am with you on the fact that the TOS certification is a little much for
the corporate standard, but I can not accept the fact that there is any
other way to certify that the OS is truly tursted.  The OS and ALL of it
subcomponents must be broken down and mathematically proven to adhere to the
security structure that the OS was designed for.  Most of us have no time to
read through 4000 pages of mathematical proofs, but to be a TOS you must be
able to provide this document before I will accept that certification.

Tha being said, a TOS like that would be a PIA to work with in the corporate
environment and is a little too restrictive for everyday business, but may
be better suited for the NSA and other such agencies with 3 letter acronyms
for names.

Just my .02 on old school Orange Book Guidlines versus that which is used
today....

-Kyle
___________________________________________________
Kyle R. Starkey
Information Security
Web:            www.online.msdw.com
E-mail: mailto:kyle.starkey () online msdw com
Morgan Stanley Dean Witter Online  


-----Original Message-----
From: Bennett Todd [mailto:bet () rahul net]
Sent: Wednesday, March 29, 2000 8:51 AM
To: Ryan Russell
Cc: Marcus J. Ranum; Paul McNabb; firewall-wizards () nfr net
Subject: [fw-wiz] Re: Trusted OS...


To add a smigeon to the comments that have before, I think much of
the discussion here has stemmed from two different definitions of
"Trusted OS".

There's the old-school definition (which I confess to favouring
myself, just because I think it makes me sound like a grizzled old
security stud:-) that a trusted OS is one that has passed the TPEP
or one of its bastard children. This means not only posessing some
cool features for expressing controls and restrictions, but also
(particularly at higher levels) posessing design documentation that
reflects a concern for security that tracks back to the start of
implementation, and some amount of documentation and perhaps code
review to help ensure that the product meets the claims.

Then there's a newer school, that likes to use the term Trusted
OS to describe an OS posessing the features --- mandatory or
discretionary access control, domain type enforcement, whatever ---
that allow more fine-grained control over processes and the
resources they're permitted to access than the traditional OS
permissions system. These speakers disregard the certification part,
and just use the "Trusted OS" tag to refer to the presense of the OS
features.

Since many, perhaps most of us using the first definition actually
don't have a whole lot of respect for the demonstrated consequences
of the certification programs, there's an interesting twist: the
folks with the apparently more casual definition of "Trusted OS"
seem to be more enthusiastic about them.

But when you shed the different use of terminology, what I'm seeing
is that nearly everyone participating in this thread thinks that
these sorts of OS features are dead sexy, we want 'em in all our
OSes yesterday for crissakes, but we aren't in general nearly as
enthusiastic about the formal certification processes.

Though personally, I must admit from what I've seen recently on
the firewalls list in the thread "Common Criteria", it sounds like
the certification thing is moving in a healthy direction. The way
they've decomposed the process into building a Security Target,
using a menu of options from the common criteria, getting that
security target sanity-checked against a consistency rulebase, then
getting your product evaluated against that target, that sounds like
some sound engineering.

I'm still not completely convinced that the certification will be
as valuable as some are trying to claim, but I'm getting less
skeptical the more I read.

-Bennett