<!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>> Needless to say, your response is very thought-provoking.
A<BR>> better-phrased answer to your question about targetting the B1 feature
set</DIV>
<DIV>> is that the B1 feature set meets the needs of a number of environments
I<BR>> have been working in--in particular the electronic commerce web
host<BR>> environment wherein sharing of hardware and software resources is
required<BR>> for cost-effective operation (which is really the goal of web
hosting),</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>It sounds like what you want is an OS that can
effectivly support a <EM>domain separation policy</EM>. And the only thing
that comes close is B1. I think you'd want to not drag in all the baggage
that B1 brings with it. You DON'T need every object labelled, as you get
in B1. You DON'T need Mandatory Access Control for every object in a
domain if the domains are effectivly (I try to never use the word "securely")
separated from each other.</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>Please don't fall in the "it's easy to just grab the B1
requirements and use them" trap!</FONT></DIV>
<DIV> </DIV>
<DIV><BR>> but the system administrator wishes to provide improved
discretionary<BR>> access control handling, as well as impose mandatory
integrity and privacy<BR>> policies on the environment, both for the purposes
of protecting customers<BR>> and for enforcing internal management structure
(which imposes hierarchy<BR>> beyond that which pure partitioning
addresses).</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>It sounds like you are trying to state your security
requirements in the terms of B1, instead of stating your requirements, and
seeing what B1 does and doesn't offer. Note: there are no integrity
policies enforced in B1.</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>When you talk about "management structure" you're
talking business requirements, not B1 provided Mandatory Access Control ...
big difference!</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>The hardest thing in security is specifying
requirements. The source of requirements should be from your target market
(i.e., "customers"). The problem is that security is hard ... and most
customers want to talk about business functionality ("what kind of reports can I
get") rather than security functionality ("what should I audit"), and no one
ever wants to talk about assurance ("how can I be sure that I've implemented
security correctly")!</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>>Similarly, the auditing<BR>> requirements of the B1 environment
provide many of the same services in an<BR>> electronic commerce environment:
accountability, as well as being useful<BR>> for intrusion detection.
It's easy to imagine commercial applications<BR>> requiring subsets of the
so-called B1 feature set for a variety of reasons<BR>> (organizational
divisions, etc).</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>Auditing is good. However you don't get much more
from a B1 OS auditing requirements-wise than a C2 OS, except a audit trail that
captures sensitivity labels. I can "imagine" may different usefull
subsets, however <EM>what is required</EM>? ... that's the hard
part! AND, <EM>who requires it? </EM>(hopefully someone with money!
;-)</FONT></DIV>
<DIV> </DIV>
<DIV><BR>> Given the CC as a more flexible superset and description
environment for<BR>> trusted systems, it makes sense to transpose the
description of these<BR>> features from ``B1'' to appropriate CC categories
and levels. Based on my<BR>> first few passes through the document over
the last couple of weeks, it<BR>> appears that EAL3 and EAL4 are the feasible
maximum for an existing OS<BR>> being ``hardened''.</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>No offence, but "hardened" is another one of those
"squishy words", such as "secure", which is essentially meaningless! Yes,
the assurance level EAL4 roughly provides the same assurance as B1, and EAL3 is
roughly the same as C2. So what? What does the market
want?</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>Assurance levels mean NOTHING unless you have the
product evaluated. Let me say that again: <EM>Assurance levels mean
NOTHING unless you have the product evaluated! </EM>That's what they are
there for! If the product is not evaluated, then your assurance level is:
"Trust Me, I built it good" ... the <EM>dreaded vendor assurance
claim</EM>!</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>I've found that most of the market would probably be
very satisfied with a richer security feature set at a lower (say EAL2 or EAL3)
assurance level. Considering that everyone is now working with,
essentially, "EAL0" systems, any assurance would be an improvement!</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR>> I think it continues to be accurate to describe TrustedBSD as
targeting<BR>> the B1 criteria, as the features described in the B1 criteria
are<BR>> markedly similar to those being implemented. That said, I
would agree<BR>> that expressing these requirements in the CC vocabulary is a
useful goal,<BR>> and would help clarify the goals of the project, and put
the project in a<BR>> more appropriate place with regards to current
standards processes.</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>I think that you might have missed my points.
Don't use B1 as your basis of requirements ... period. The set of B1
requirements represent an attempt by the U.S. Government to specify their
security requirements for operating systems of 15 years ago! That market
never materialzed. They are, for all intents and purposes,
worthless! They might be a good academic starting point to discuss what
requirements might be needed by the developers of Trusted BSD, but those
requirements should be codified in another language (e.g., CC).</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>Even if the TBSD isn't evaluated, the security
requirements should be thought out a bit more than "let's just do a B1
system". Start by looking at the CC document "Guide for the Production of
PPs and STs", specifically section 4, which guides you on identifying the
Assumptions, Threats you're trying to counter, and Organisational Security
Policies that you're trying to enforce. Then, section 5 shows how to
specify the Security Objectives. THEN, you can start specifying security
requirements to counter the threats and support the objectives!</FONT></DIV>
<DIV> </DIV>
<DIV><BR>> One thing that would be extremely useful is some sort of executive
summary<BR>> of feature requirements for the various categories the CC
defines for<BR>> secure systems.</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>I used to teach an "intro to CC" course, but I left all
my slides at Oracle. I'll try to get you a copy.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>> Another thing that would be helpful is a text-based<BR>> version of
the CC requirements, which would allow easier discussion and<BR>> analysis in
purely text-based forums (such as mailing lists). I've only<BR>>
managed to find the CC in PDF format, which is substantially less
useful.<BR></DIV>
<DIV><FONT color=#0000ff>I have a FrameMaker5 version of the CC if you
like. I could "save as text", but it would make it even harder to read, as
there is a LOT of emphasis by bold and italics, as well as paragraph
formatting. NSA or CESG should be able to get you different formats if you
ask nicely! ;-)</FONT></DIV>
<DIV> </DIV>
<DIV><EM>-jeff-</EM></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>> </DIV></BODY></HTML>