Leonard Miyata <leonard @
geminisecure .
com> writes:
>>Besides Boing's secure network, Gemini Computer's GEMSOS kernal, and of
>>course the original Honeywell Multics, what other "A-1" systems are out
>>there to gain experiance on?
>mjr replied: Why? Are you interested in software archeology?
> Most of the A1 systems out there were obsolete before anyone
>even started coding them. One of the problems with the higher orange
>book classifications is that the evaluation is tied to a hardware
>platform. So - if your system is evaluated on an 80286 (remember
>them!?) that's the official platform for that evaluation. Add a
>card, change a CPU, use a different box, and you have to (theoretically)
>go through a whole new round of testing in a process called RAMP in
>which you laboriously prove that that differences don't affect the
>security of the system.
> By the time it's all said and done, the software is an
>ancient crusty version of something nobody but a dinosaur would
>touch (I've used MULTICS, and it makes MUMPS look sleek and
>polished in comparison) and it costs not one arm, but both, and
>at least one leg.
> There are still orange book systems out there, and there
>are still people working on them, but that's really part of the
>government's typical inability to terminate an unsuccessful
>program.
An A1 system user once commented to me that his system had to be secure
because it was so bloody unfriendly even he had difficulty getting into it.
There is much truth in mjr's comments. The higher levels of secure system
criteria are very difficult to achieve without developing a system from
ground up and that takes time. Therefore, the IT industry has moved on
several generations even before the product can be submitted for evaluation.
That evaluation takes time and makes the system even more historic
technologically. Some users feel the need to go through this process but
because they are few in number, the resulting high level systems are not
only archeology, but very expensive. There may also be such heavy
concentration on assurance issues that the system functions poorly as an
information system.
ITSEC allows much more flexibility than TCSEC in permitting hardware changes
and it also measures assurance and functionality as two subject areas. The
Common Criteria may prove to offer even greater flexibility and may cater
for vendor self-certification at least in the lower levels. It remains to be
seen if that is an advantage and certainly introduces the risk that a vendor
may claim, or encourage others to claim, a level of achievement which is
much greater than reality. An example of this could be claims circulating
that Windows NT is a B2 product. It doesnt much matter if those claims come
from the vendor or from someone else, the confusion will be considerable and
some people may procure a system in the belief that it offers a level of
protection which it is incapable of providing. That is one clear
justification for having a system of evaluation by a third party, government
or commercial. However, it does not resolve the issues of creating a
criteria which is both independent and meaningful.
Experience shows that however much time is spent attempting to produce a
reliable criteria which meets security attainment needs and still allows
modern functionality, the basic problem is that the IT industry is geared to
proving new sexy products with poor quality control. It is not unusual for
the development of a trusted system to spend more time wringing out basic
bugs in popular base products then it does in introducing specific assurance
techniques. As long as customers are influenced primarily by low prices and
sexy new gismos, vendors will address those perceived requirements rather
than produce well engineered and documented products.
Ian J-B
|
|
