> Date: Thu, 24 Jul 1997 10:32:18 -0700 (PDT)
> From: Leonard Miyata <leonard @
geminisecure .
com>
>
> The TNI 'Red Book' extends the 'Orange Book' security definitions
> to the context of a single isolated unit. By unit, they include
> all the components of the network (workstations, routers, Servers
> etc) Unlike a physical serial connection to a dumb terminial,
> network connections may not be direct physical connections, but
> indirect connections via a router, or routing host. Without a
> method to ensure a trusted connection (encyption with data labeling)
> the possiblity exists of data being tampered with between the sender
> and receiver, as the network itself is considered outside of
> physical security control and is insecure.
>
> The moment you add a network card to a host, your outside the
> definitions of the 'Orange Book' and must now consider the
> 'Red Book' security of the entire network and all of its components.
> To receive a Red Book rating, all of the 'Orange Book' definitions
> (DAC, MAC, I&A, Audit) must be extended to cover the entire network.
> Individual components may have a 'Orange Book' rating less then the
> rating of the Network, as long as some other network component is
> responsible for enforcing the policy.
Actually, you don't need encryption on the network. You can (and we
have, twice now) gotten a B1/E3 and C2/E3 evaluation on Solaris 2.x
with 4 hosts connected over a network, some on SPARCs and some on x86,
each in a different configuration of HW and security level. What you
have to do is to clearly state that the physical security of the network
is outside the scope of the evaluation, and that without physical security
of the data packets, the security may be compromised.
You are correct that you must extend the Orange Book security to the
network. This means that the network protocols must be extended to
include security attributes. Once you've done this (such as with the
TSIX(RE) protocols) then they become available for routers, gateways,
and firewalls. With this in place, you can have your packet filtering
done on a dozen or more attributes, not just addresses, port numbers,
and ACKs. Imagine a packet filter that can see the UID, GID, ACL,
process ID, MAC label, clearance, privilege set(s), discretionary
label (CMW IL), and capability sets of the process that sent the packet.
When you start getting to this stuff, you can build some pretty fancy
firewall enhancements and can really do a lot to prevent traffic from
leaking out of sensitive networks onto public/uncontrolled networks.
I know a lot of people consider Orange Book type security irrelevant
to firewalls, but aside from the assurances, hardening, and access
controls, there really is a lot that can be done if the product has
been built with the right features all the way from the file system
to the network stack.
Several months ago someone was trying to figure out how to make a
web site "read only" so that it couldn't be trashed by buggy daemons
or clever hackers. Believe me, you can do it with high-end security
products built into the OS. We have banks and financial groups with
multiple network connections on a single system, some to an internal
net and some to a public network. Any process on the system that can
read a packet from the public network will see 99% percent of the file
system as read-only, with no override possible. The administrator can
choose how much and what on the system can be read-only, write-only,
or non-executable. This is true even though the httpd and ftpd are
running as root and not chroot'ed. It's true even if there is a stack
overwrite bug in the daemon. You can even do it with telnet and publish
your root password on the net...
And if these products are built right, you can throw any firewall
on top that you want. They are independent of the application.
I don't know much about Jon Spencer's DG product, but they are in
evaluation for B2 (I've heard). Other companies may have stuff
like this out there, such as DEC, Sequent, and HP. We work mainly
with Solaris (2.4, 2.5.1, and we already have 2.6 ported), but we are
working with other Unix versions (e.g., Linux) and with NT. I believe
C2 is just about worthless as a statement about security. C2 is 1975
security. B1 is 1985 security. You need a lot more, and there's a lot
more commercially available if you look around.
Naturally, I can take our most secure product set and configure it
down to be as full of holes as Swiss cheese, but everyone on this list
already knows that a good administrator with primitive tools is better
than an ignorant administrator with fantastic tools. That's why the
never-ending NT vs UNIX debate always ends up in a screaming match.
We always end up comparing NT+administrator to UNIX+administrator and
that goes beyond the scope of any real technical debate.
paul
---------------------------------------------------------
Paul McNabb Argus Systems Group, Inc.
Vice President and CTO 1809 Woodfield Drive
mcnabb @
argus-systems .
com Savoy, IL 61874 USA
TEL 217-355-6308
FAX 217-355-1433 "Securing the Future"
---------------------------------------------------------
|
|
