Re: C2 vs Common Criteria [was: RE: Is this mail list dead?]

[Crispin Cowan <crispin@wirex.com>]

Rick Smith at Secure Computing wrote:

> At 08:30 PM 3/16/01, Crispin Cowan wrote:
>
> >Secure:  system architected such that only proper presentation of
> >authentication
> >and authorization credentials permits access, and forging said credentials
> >requires solving intractable problems (e.g. factoring 1000 bit primes).
>
> I love this definition, but I'm skeptical about its usefulness. I think at
> most it permits the construction of toy systems. Once an OS exceeds a
> certain bulk, it becomes impossible to reliably assert that access depends
> solely on solving intractable problems.

Thanks!  I agree that it is improbable to achieve "Secure" under this definition
for non-toy systems.  The usefulness of the definition is primarily to illustrate
the difference between "Secure" and "Apparently Secure", so that all participants
can appreciate that we're really arguing about probabilities of flaws in
Apparently Secure systems.

Hopefully this will cut down on the wanking flamage about "my system is secure",
"no it isn't", "so's your momma" :-)


> >Apparently Secure:  no method is *known* to allow an attacker to violate
> >security.  Obscurity makes it hard to find such means to violate security, so
> >obscurity enhances Apparent Security(tm:-)
>
> I believe this is the best security we see in large scale systems. A really
> good system combines hard-to-crack technologies in a compelling
> architecture, and the actual implementation manages to stand up to a lot of
> hard use.

Agreed.  I think that most of the useful discussion comparing the relative
merrits of various security systems is really comparing Apparently Secure systems
with respect to the likelyhood of flaws being discovered, the criticality of such
flaws, etc.  By clearly understanding that we're really talking about Apparent
Security, we can focus on the issue that matters:  how the method or technology
mitigates potential vulnerabilities.

For instance, tight application of MAC results in a strong degree of fault
isolation through least privilege, so the amount of software that *can* manifest
a critical security vulnerability is drastically reduced.  Least privilege
management appears to be the approach taken by many of the better secure UNIX
systems, such as SELinux, Pitbull, and Immunix's SubDomain.  Even Bastille uses
it, by minimizing the services offered.

Immunix's Guardian tools (StackGuard, FormatGuard, and the soon to be released
RaceGuard) take a somewhat different approach.  These tools carve off a major
class of vulnerabilities that commonly occur in applications, and do something to
make those vulnerabilities non-exploitable.  This improves Apparent Security by
making a majority of the attack techniques ineffective.

Of course, Apparent Security is a crappy name:  no one will ever market a product
as having better Apparent Security :-)


> >Trusted:  no method is known to allow an attacker to violate security, and
> >some
> >fairly qualified people have looked really hard, and documented the places
> >they
> >looked.
> >"Trusted", as in, "some folks trust this thing because they checked it out
> >real
> >good." :-)
>
> Hopefully they not only looked, but also took sharp knives and slashed at
> it a lot.
>
> And don't forget this one:
>
> Evaluated: the vendor jumped through an expensive, government endorsed
> series of hoops. It usually indicates that someone has poked it real hard
> with a stick, and occasionally indicates even more. Of course it doesn't
> guarantee a lack of security flaws.

Hmmm ... I view "Trusted" and "Evaluated" as the same thing.  Evaluation is the
basis for the Trust, but most systems that are called "Trusted" usually have an
evaluation certificate to back up the claim.  As usual in security, this leads to
a recursive meta question of "who trusts the trusters?" :-) E.g. I don't trust
ISCA evaluations, because they work hard to pass everything they evaluate.


> Personally, I'm of two minds regarding security evaluations:
>
> On the one hand, I like the idea of having third party standards that
> systems must comply with in order to demonstrate fitness for a tough job.
>
> On the other hand, evaluations don't seem cost effective for their typical
> use, which is to provide a standardized, concise, and well understood input
> to security accreditation decisions.

Clearly there's a need for a more cost effective evaluation method.  The trick is
to find one that is valid, i.e. corresponds well to Apparent Security.


>  The accreditation process involves a
> bunch of security re-testing anyway, since the "real system" uses the
> evaluated device as a mere component. I think the real value isn't in the
> "EAL 4" stamp, but in the evaluation evidence, which describes what the
> thing is really up to. But maybe the value is that the evaluation process
> at least ensures that the assurance data is collected in a somewhat
> accessible format.

I think the "value" in formal evaluation is that its a means for people with
little or no clue to borrow some clues from people who do know something about
security.  IT boss wants a system that's secure, doesn't have the spare $2mil to
do his own evaluations, and starts looking around for valid criteria to judge the
products that are being pushed at her.  All of the products come with Breathless
Hype (tm :-) pre-installed, so reading the marketing lit. is of little use.

Crispin

--
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:                http://immunix.org

-
Securedistros: A common list for all secured Linux distributions
Archive:       http://humbolt.nl.linux.org/lists/