On Wed, 9 Jun 1999 [EMAIL PROTECTED] wrote:
> > The Common Criteria seem to me to be the ISO-9000 of evaluations.
> > Correct me if I'm wrong, but under ITSEC and the CC doesn't the
> > evaluation team run tests specified/developed by the manufacturer?
>
> ITSEC evaluators do, in fact, repeat a subset of the development team's testing, but
>only to confirm that the development team was following the procedures and tests that
>they laid out in their documentation. The evaluators then do their own, completely
>seperate penetration testing, which they plan and perform themselves.
[Please bear with me, I'm trying to get a feel for the ITSEC process]
Then for ITSEC the evaluation's functionality testing is based on the
manufacturer's requirements and penetration testing is based on the team's
skillset?
My readings and re-readings of the criteria seem to indicate that only
claimed functionality is tested- and I'm trying to figure out how much of
that can be an end-run. For example, even in the traditional
certification process it's possible to document around some design
failures (but they need to be documented) - I'm just trying to figure out
if there's more wiggle room in the ITSEC/CC process for things that should
need assurance to be missed because they were omitted from the scope of
the evaluation. (This especially worries me in regard to the fact that
the NT4 eval. seems to be a RAMP of the NT3.51 eval.)
> > The gulf between C2 and B2 is far and wide and includes a source
> > code review of the Trusted Computing Base.
>
> E3 ITSEC assurance does require analysis of the trusted (security enforcing) code.
>The functionality class (C2 for NT, B1 for TSOL) is only an indication of the
>Security Enforcing Features being claimed - the E<x> is what tells you the level it
>was tested and implemented to.
B2 analyzes the entire TCB's codebase, not just the enforcement
mechanisms. That's why it's a very long process. If NT were to undergo a
traditional B2 evaluation it'd probably take about a decade given the
ammount of code running in kernel space.
Are any of the code review guidelines available? Having read most of the
Rainbow Series in a former life, the gulf between a great deal of process
level documentation for design goals and the same for
implementation of the process seemed to be its second-largest failing (the
first-largest being the time to implement an evaluation).
> My favorite excerpt from the NT certification report:
>
> ////
> The assumption that the network is secure is important since it effectively turns
>the network interface into an internal interface. Therefore, there are no
>network-based threats and no possibility of vulnerabilities to the TOE being
>introduced through the network components.
> ////
>
> Not really the sort of assumption you want to have on a firewall...
That's the whole problem with the "someone waved a dead chicken over it"
process. You need to understand the evaluation process and the results
before you can attach any significance to it. That's why most of us yawn
at C2 certifications yet some people consider it a major milestone. From
my point of view MAC and compartments are where it gets intesting - the
problem to be conquered there is to provide an easy-to-use administrative
interface. That's also why Red Book B2 means more than Orange Book B2,
including the networking portion in the evaluation is very important.
In fact, I question the validity of even having a non-network evaluation
these days.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
