Common Criteria?

[Jeff DeMello]

> Needless to say, your response is very thought-provoking.  A
> better-phrased answer to your question about targetting the B1 feature set
> is that the B1 feature set meets the needs of a number of environments I
> have been working in--in particular the electronic commerce web host
> environment wherein sharing of hardware and software resources is required
> for cost-effective operation (which is really the goal of web hosting),

It sounds like what you want is an OS that can effectivly support a domain separation policy.  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.

Please don't fall in the "it's easy to just grab the B1 requirements and use them" trap!


> but the system administrator wishes to provide improved discretionary
> access control handling, as well as impose mandatory integrity and privacy
> policies on the environment, both for the purposes of protecting customers
> and for enforcing internal management structure (which imposes hierarchy
> beyond that which pure partitioning addresses).

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.

When you talk about "management structure" you're talking business requirements, not B1 provided Mandatory Access Control ... big difference!

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



>Similarly, the auditing
> requirements of the B1 environment provide many of the same services in an
> electronic commerce environment: accountability, as well as being useful
> for intrusion detection.  It's easy to imagine commercial applications
> requiring subsets of the so-called B1 feature set for a variety of reasons
> (organizational divisions, etc).

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 what is required? ... that's the hard part!  AND, who requires it?  (hopefully someone with money! ;-)


> Given the CC as a more flexible superset and description environment for
> trusted systems, it makes sense to transpose the description of these
> features from ``B1'' to appropriate CC categories and levels.  Based on my
> first few passes through the document over the last couple of weeks, it
> appears that EAL3 and EAL4 are the feasible maximum for an existing OS
> being ``hardened''.

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?

Assurance levels mean NOTHING unless you have the product evaluated.  Let me say that again:  Assurance levels mean NOTHING unless you have the product evaluated!  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 dreaded vendor assurance claim!

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!



> I think it continues to be accurate to describe TrustedBSD as targeting
> the B1 criteria, as the features described in the B1 criteria are
> markedly similar to those being implemented.  That said, I would agree
> that expressing these requirements in the CC vocabulary is a useful goal,
> and would help clarify the goals of the project, and put the project in a
> more appropriate place with regards to current standards processes.

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

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!


> One thing that would be extremely useful is some sort of executive summary
> of feature requirements for the various categories the CC defines for
> secure systems.

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.



> Another thing that would be helpful is a text-based
> version of the CC requirements, which would allow easier discussion and
> analysis in purely text-based forums (such as mailing lists).  I've only
> managed to find the CC in PDF format, which is substantially less useful.

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!  ;-)

-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
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebsd.org/pipermail/trustedbsd-discuss/attachments/20000418/9b022bb0/attachment.html