Common Criteria?

[Jeff DeMello]

> The quick answer is that the B1 feature set is targetted as it covers
> relatively concisely the set of features currently under development (a
> sort of cyclic arrangement).

Unfortunately, IMHO, that is a very bad answer.  The B1 market is dead.  Why design and build a product for a dead market?



> I have been reviewing the CC requirements for the past couple of weeks but
> find that they are fairly broad and provide a lot less direction than the
> original evaluation criterion.  I have been doing some work to try and
> classify the current design/implementation goals in the vocabulary of the
> CC, but the CC is fairly heavy-going on the acronym/terminology side :-). 

WRT "provide a lot less direction" ... that is exactly what the CC is supposed to do!

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 "C2 by '92", but there was never 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.

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 does not mandate groupings of requirements, such as the TCSEC, but provides *a common language* 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.

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 Protection Profile or Security Target 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.

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!



> That said, I agree the reclassifying the goals of the project in the CC
> vocabulary and scope may make sense--the CC certainly goes into more
> detail as to teh requirements and covers a wider range of security
> features (many introduced after the release of the Orange Book).  As you
> appear to have a stronger working experience with the CC requirements,
> would you be interested in helping to congeal the vast CC documentation
> into a more concise and useful format for discussion in the context of a
> single-host operating system, or for loose clustering based on network
> file systems such as NFS and AFS? 

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!

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.  



> I know of other active projects aspiring to the Orange Book evaluation
> criteria, and was wondering if you could comment further on why they are
> still doing so in light of your claim that only the CC makes sense at this
> point? 

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".

If I were producing a product to be evaluated the only logical choice is a CC evaluation.  Why?  It's not free anymore:  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:  Products evaluated under the CC are formally mutually recognized in the United States, Canada, France, Germany, the United Kingdom, Australia, New Zealand, Finland, Italy, Norway, Netherlands, Sweden, Switzerland, and informally elsewhere.  Why pay for an evaluation that is only usable in one country, when you can do one that is usable in 13+ countries?  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!



> Given that currently the TrustedBSD project does not have much in
> the way of funding and support, evaluation is not being planned for,
> although it is being designed and documented with that in mind.  Now would
> be the time to retarget evaluation criteria, if necessary.

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.

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!").

END SOAPBOX   ;-)


I hope that helps!

-jeff-




>   Robert N M Watson 
> 
> robert at fledge.watson.org              http://www.watson.org/~robert/
> PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
> TIS Labs at Network Associates, Safeport Network Services
> 
> 
> 
> To Unsubscribe: send mail to majordomo at trustedbsd.org
> with "unsubscribe trustedbsd-discuss" in the body of the message
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebsd.org/pipermail/trustedbsd-discuss/attachments/20000418/d1ee43d4/attachment.html