>
> Hi,
>
> > So you can have a C2 TCSEC eval or C2 TNI eval or a C2 TDI eval. We are
> > in a B2 TNI eval and our partner is in a B2 TDI eval on top of ours. And
> > yes, I believe that C2 NT includes IP, but does not include the floppy disk
> > and lots of other real world things.
>
> Since C2 doesnt require verifying the code (which is nearly impossible
> anyway), C2 only covers how it 'should' ork, not how it 'does' work. This
> means buffer overruns, shell escape and all that stuff introduced by bugs
> will not be covered from C2 Certification.
>
> I thin B recommendation are slightly more detailed in verifying
> implementations, right?
>
> Greetings
> Bernd
This is a bit long, but as short as I could make it and still have some
meaningful information content. :-)
FIrst off, just to let you know where this is coming from, I am the
Security Architect for our B2/E4 DG/UX system. So far, we have been at it
for about 6 years, plus 5 years before I came to DG where the staff wrote
their own kernel from scratch using high assurance techniques. Our
standard product and B2/E4 product are built from the same source code
without #ifdefs - it's in the linking and is table driven. It was the only
way we could afford to maintain the trusted product and keep it in sync
with the standard product.
B1 is not much more than C2 in terms of assurance (i.e., do I know that it
works?). The hard part of B1 is adding a new security policy (Mandatory
Access Control - MAC). For the record, MAC is used by all real commercial
enterprises. You have unrestricted information, company confidential,
company confidential restricted, etc (hierarchies). And only a few people
are authorized to see payroll or personel information, only a few can
see strategic marketing plans, etc (categories). But that is an entirely
different discussion!
B1 code is not looked at. A RM (see below) is not needed. The code can be
spaghetti code. Not all objects must be protected by the system. The info
below for B2 is all above and beyond B1 requirements (and E3 requirements
for the ITSEC).
B2 is where the first real jump in assurance comes. ALL security relevant
code, and in a full comercial OS there is a ton of this, must be modular,
coded to a single coding standard (well, one standard for the kernel,
another for layered code), no unused or dangling or obtuse code, all
completely documented, all with detailed and high level design specs that
match each other and that match the user and administrative documentation.
There must be both an informal and a formal model for the security policy.
There must be a reference monitor (RM) - a single piece of code that handles
ALL accesses to ALL objects by ALL subjects. The RM must be small enough
to be verified correct, must be tamperproof, and must ALWAYS be invoked -
ya gotta prove this. (We also are formally proving our formal model and
tracing all claims throughout the code, design and model.)
There must be a covert storage channel analysis done of the system, looking
for "covert channels." A covert channel is a method of bypassing the
security policy by using normal approved system mechanisms (huh????).
The best example of this is the base MAC policy that says information can
only flow upward (e.g., from unclassified to secret is OK, but not the
other way around). This seems reasonable. So you should be able to open a
file with a "higher" classification for writing. Information only flows
upward - right? Well, not right. You see, the problem is that when you do
a write, you get a return code - it succeeded or failed. If someone is
manipulating the permission bits on the file, then you could succeed (a
"one bit") and then fail (a "zero bit"). By this manipulation, the secret
user could signal information to the unclassified user and the system would
never know it. This is a covert channel. All covert channels must be
limited to less than 100 bits/minute, and must be auditable if over 10
bits/minute. Any covert channel over 100 bits/minute must be closed. It
can be closed by slowing it down or by eliminating it. This can take a LOT
of interfaces out of the system and/or really slow the system down
if some new approach to covert channels isn't used (we have such an
approach - but again, this is not the forum for that discussion).
EVERYTHING must be tested from every angle. The NSA folks do a several
month penetration study (they try to break in having the source code at
their disposal). There is a lot more as well. Actually getting the system
to run is a very small part of the B2 evaluation (about 5%).
THEN, on top of all this, your development process has to be such that you
can keep this same high level of assurance for any modifications you make
to the OS (patches, new releases) or the new system loses its rating. This
is called RAMP (RAtings Maintenance Phase). NSA can and does perform
random audits of anything in the OS. Every change must be documented and
approved and monitored for security relevance. If a change is made in a
user doc, it must be traceable from the change in the doc to the place in
the code or whatever that generated the change. And vice versa.
WHen a new release of the OS is proposed, all changes must be approved by
NSA and the changes must be defended in from of a panel of NSA experts
(many are actually from private industry, since they pay more than the
gov't). You better have done it all correctly! If NSA discovers any
messup in following the RAMP planm (which they must approve) they can
remove your B2 rating from any of the releases or prior releases that may
have been affected. And if NSA discovers that you have been negligent or
tried to sneak one by them, well I don't want to scare the weak at heart.
BUT ..... there is a major payoff from this. Although you pay a high up
front cost, the quality that results from high assurance is astounding!
Back in 1970, Dykstra, Hoare, et al published "STructured Programming".
Since then, lots of lip service (watch out for the drool!) has been given
to these concepts, but when the rubber meets the road it goes out the
window. Our experience shows a tremendous payoff in MTBF and other things.
So, that's B2. :-)
--
Jon F. Spencer spencerj @
rtp .
dg .
com (uunet!rtp.dg.com!spencerj)
Data General Corp. Phone : (919)248-6246
62 T.W. Alexander Dr, MS #119 FAX : (919)248-6108
Research Triangle Park, NC 27709 Office RTP 121/9
Reality is an illusion - perception is what counts.
No success can compensate for failure at home.
President David O. McKay
***** UCC 1-207 ********
References:
|
|
