<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4030.2400" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>> The quick answer is that the B1 feature set is targetted as it
covers<BR>> relatively concisely the set of features currently under
development (a<BR>> sort of cyclic arrangement).</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>Unfortunately, IMHO, that is a very bad answer.
The B1 market is dead. Why design and build a product for a dead
market?</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>> I have been reviewing the CC requirements for the past couple of weeks
but<BR>> find that they are fairly broad and provide a lot less direction
than the<BR>> original evaluation criterion. I have been doing some
work to try and<BR>> classify the current design/implementation goals in the
vocabulary of the<BR>> CC, but the CC is fairly heavy-going on the
acronym/terminology side :-). </DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>WRT "provide a lot less direction" ... that is
exactly what the CC is supposed to do!</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>The TCSEC classes (e.g., B1) specified requirements for
U.S. Government systems. The USG basically said "build and evaluate
systems that meet these requirements and we will buy them". I don't know
if any of you remember the mantra "<STRONG>C2 by '92</STRONG>", but there was
<EM>never </EM>a mandate to purchase C2 systems, let alone B1 systems.
I've worked with all the producers of B1 systems, and we all agree ... there is
NO market! The few remaining stragglers in the B1 arena are serviced by
Trusted Solaris and Trusted Oracle, the only products being maintained at that
level. And from what I understand, both TS and TO are being evaluated
against the CC, not the TCSEC.</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>As far as the "less direction" aspect: the CC was
designed to help two sets of people: 1) the people specifying & buying
systems and products with security requirements, and 2) the people building
systems and products with security. The CC <EM>does not mandate groupings
of requirements</EM>, such as the TCSEC, but provides *<EM>a common
language</EM>* to specify the security products that customers would want, and
vendors would build. It doesn't mandate the security of the products to be
evaluated, it mandates a common language in which to specify them.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>Unfortunately, the downside is that the Orange Book is
thin and lightweight, and the CC is thick and heavy! Again the CC
describes the common language. What you really need to compare is a
specific <EM>Protection Profil</EM>e or <EM>Security Target </EM>against the
Orange Book. A PP or ST is much smaller than the Orange Book and it
completly specifies the requirements for a given system/product, such as the
Orange Book.</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>In my dealings with trying to educate people about the
CC (and in security in general), people specifying systems / products tend to
use the general requirement "and must be secure", and don't want to bother with
what the word "secure" means! If you want a "secure" system/product, it
will only be as secure as 1) you specify it in requirements, and 2) your testing
of the product against the requirements. If you don't specify it correcty,
it will not be built correctly. AND, it's even worse if you specify and
build it correctly, but there is no market for it ... such as B1
systems!</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><BR>> That said, I agree the reclassifying the goals of the project in
the CC<BR>> vocabulary and scope may make sense--the CC certainly goes into
more<BR>> detail as to teh requirements and covers a wider range of
security<BR>> features (many introduced after the release of the Orange
Book). As you<BR>> appear to have a stronger working experience with
the CC requirements,<BR>> would you be interested in helping to congeal the
vast CC documentation<BR>> into a more concise and useful format for
discussion in the context of a<BR>> single-host operating system, or for
loose clustering based on network<BR>> file systems such as NFS and AFS?
</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>I've worked with the Orange Book for 15 years, and the
CC for about 5 years, so I speak with a bit of experience! I would love
to (and hate to) help congeal the CC requirements for TBSD ... it
would be a fun project, but IMHO a waste of time (the hate part), unless the
TBSD market is better defined!</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>Unfortunately (just like everyone else in Silicon
Valley) I'm overcommitted to my personal time as it is, and my current
employer doesn't have the discretionary income (such as Oracle) to allow me to
participate in such activities during the day! I'd be happy to review work
by others, though. </FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR>> I know of other active projects aspiring to the Orange Book
evaluation<BR>> criteria, and was wondering if you could comment further on
why they are<BR>> still doing so in light of your claim that only the CC
makes sense at this<BR>> point? </DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>God only knows why anyone would do an Orange Book
evaluation. When I led the security evaluations team at Oracle we asked
ourselves that question many times! And the answer was always, "do no more
TCSEC" evaluations".</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>If I were producing a product to be evaluated the
only logical choice is a CC evaluation. Why<EM>? It's not free
anymore: </EM>NSA doesn't perform free evaluations anymore, they are done
by NSA licensed evaluation firms, such as Arca Systems, and you must pay for
them! If you had to pay for an evaluation, why not pay for a CC
evaluation, and reap the benefits. What are the benefits:
<EM>Products evaluated under the CC are formally mutually recognized </EM>in the
United States, Canada, France, Germany, the United Kingdom, Australia, New
Zealand, Finland, Italy, Norway, Netherlands, Sweden, Switzerland, and
informally elsewhere. <EM>Why pay for an evaluation that is only usable in
one country, when you can do one that is usable in 13+ countries?</EM>
Finally, the TCSEC was written with monolithic, non-distributed, operating
systems in mind (Can you say "Windows NT 3.51, standalone, no floppy
drive"?!!). The extentions for databases ("Lavender Book") and networks
("Red Book") were good academic exercizes, but total flops in the market
place. The CC provides a modern language to express requirements for
today's needs, and is extensible to cover new technologies!</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>> Given that currently the TrustedBSD project does not have much
in<BR>> the way of funding and support, evaluation is not being planned
for,<BR>> although it is being designed and documented with that in
mind. Now would<BR>> be the time to retarget evaluation criteria, if
necessary.<BR></DIV>
<DIV><FONT color=#0000ff>Given my statements above, I still have the
question. Why is Trusted BSD being designed and documented with the Orange
Book in mind? It makes no sense! If TBSD is targeted to actually be
used then: 1) find out the business requirements of the market you want to
address, 2) express those requirements in a clear and succenct manner (maybe
using CC language to help), 3) get confirmation of those business requirements
from you market and THEN 4) build it.</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>The "if you build it they will buy it" mentality might
work for PDA's and network enabled cell phones, but I guarentee you it does not
work for the "B1" market, because there is no B1 market! ("Those who do
not remember the past, are doomed to repeat it!").</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><STRONG>END SOAPBOX </STRONG>;-)</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>I hope that helps!</DIV>
<DIV> </DIV>
<DIV><EM>-jeff-</EM></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR>> Robert N M Watson <BR>> <BR>> <A
href="mailto:robert@fledge.watson.org">robert@fledge.watson.org</A>
<A
href="http://www.watson.org/~robert/">http://www.watson.org/~robert/</A><BR>>
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A
B1<BR>> TIS Labs at Network Associates, Safeport Network Services<BR>>
<BR>> <BR>> <BR>> To Unsubscribe: send mail to <A
href="mailto:majordomo@trustedbsd.org">majordomo@trustedbsd.org</A><BR>> with
"unsubscribe trustedbsd-discuss" in the body of the message<BR>>
</DIV></BODY></HTML>