Felix wrote:
[section deleted]
> As another point : ISOCOR says one of the advantages of NT is that
> it is C2 rated. Now I think
> having read in this list, that NT is only C2 rated if NOT connected
> to any network. Can anyone
> comment on this please ? Thanks for this, too.
>
TCSEC didnt consider public network connection when it was set up. It
is only able to evaluate what is presented and requires both hardware
and software.
Therefore, not only will the evaluation report say that the OS is C2
ONLY if not connected to a network, but it will say that it is C2
ONLY if the OS is mounted on exactly the same hardware as that
provided by the vendor for evaluation. That can mean that the C2
rating cannot be easily achieved because the hardware is no longer in
production and is unavailable, or very difficult and costly to
acquire.
For those reasons, a vendor cannot present a useful sub-system
(perhaps part of a firewall application) and obtain anything other
than a D Division level with TCSEC. The only option is to present a
complete system which includes the sub-system.
That may seem a very stupid situation, but is due to the fact that
TCSEC is based on the Mil-Std 2167A methodology which depends on the
US government customer issuing a complete and detailed system
specification for what is a custom product which directly addresses
every line of that specification.
ITSEC is more flexible in that it is even possible to have a
sub-system evaluated and is based on the Target Of Evaluation
presented by the vendor, is a little different from the TCSEC system
of presntations by a certified VSA on behalf of the vendor.
The difficulty for vendors and users is that a sub-system mounted on
a different, but certified, OS, mounted on clone hardware from a
different supplier may have vulnerabilities which were not present in
the OS and hardware employed for the evluation.
For example, PC clone vendors often make various changes to their
products to reduce manufacturing costs, and which do not present any
problem for running a word processor, but introduce serious
vulnerabilities in a system running trusted OS and/or trusted
applications.
In terms of levels, C2 is pretty basic although many, including MS
staffers, have claimed that NT is now a highly secure OS because it
is C2. In Europe MS are presenting with a TOE aimed at F-C2/E3 and
that has led to some claims that this means NT is now B1, and to
other claims that it is really B2 because some ITSEC requirements at
E3 dont appear in TCSEC until B2.
That has great potential for confusion (and wild or unscrupulous
marketing claims) and has encouraged some to claim that NT is more
secure than any UNIX OS on the market.
The reality is somewhat different.
There are many B1+ ( also certified F-B1/E3 under ITSEC) trusted UNIX
OS products available and the majority of all 'untrusted' UNIX OS can
be obtained with C2 switches, or are delivered automatically with
those switches. There are also UNIX and UNIX-like OS under evaluation
at B2, F-B2/E4, and higher.
A further consideration with ITSEC is the matter of 'under
evaluation'. Many people treat a product under ITSEC evaluation in
the same way as a certified product. So far no product has failed
under ITSEC evaluation, but that does not mean that the product will
be certified without major changes to code and/or documentation. As
there is currently no time limit on the period a product can be
listed as 'under evaluation', a devious vendor could present a
product without any real intent to modify to permit certification.
The product then remains 'under evaluation' for ever and marketeers
use the 'under evaluation' status to claim that the product is
already certified bar the formality of a certificate being issued.
Not that I would suggest that MS would take such an unethical
approach.
Building a solution on a base of trusted OS, at any trust level, does
not mean that the system matches that level.
It may be macho to say you have a B2 or A1 system (based perhaps only
on the level of the OS), but that doesnt mean that you have the level
of risk management appropriate to your needs.
What often gets overlooked is what a trusted product certificate does
for a living. Essentially, it forces a vendor to think more carefully
during development and document a product adequately which doesnt
necessarily happen otherwise. An independent evaluation facility
looks at the product and the vendor claims against a
published criteria and gives an independent opinion based on that.
The result is that you can look at your requirements against a
trusted product evaluation criteria and decide what the minimum level
should be for technical elements. If you only need C2 there is little
point in buying an A1 product in most cases, unless there is some
functionality, or design criteria, which is only available in
products certified to A1 and that means you have to buy the rest of
the functionality to get what you need.
Therefore, product certification just tells you what individual
elements in your solution do. Because an independent authority has
extensively tested the product, you dont have to do that part of the
work yourself.
For example, many people spend a great deal of time and money taking
an untrusted product and introducing some capability which, say, a B1
product has to have to get certified. If you take the cost of buying
the untrusted product and add the cost of your custom engineering,
the total cost may be much greater than if you had bought a B1 OS in
the first place. It is also likely that your home built OS will not
be as strong and will cost a great deal more to maintain.
If you employ trusted elements, you still need to accredit the
resulting system and that is not just the technical elements
combined, but also the adminstration, personnel and enforcement
processes. To be able to accredit, you must have a risk policy
against which to test the system and its operation.
None of that is trivial, but it will probably be very low cost
against the cost of a major risk incident.
Unfortunately far too many senior managers demand the impossible of
total security at no cost. Again, its difficult to argue against
those attitudes unless you have a risk analysis which enable you to
present the case for risk reduction together with the merits and
weaknesses of reduction at particular levels.
Ian J-B.
References:
-
ISOCOR N-PLEX
From: Felix Meschberger <fmesch @
dial .
eunet .
ch>
|
|
