>
> Hello,
>
> Is the dg B2 firewall based on the CyberGuard Software?
>
> Thanks,
>
> Philippe Cayphas
> Sr Engineer
>
>
No. CyberGuard is a B1 firewall. (There are several people there at
CyberGuard who at one time worked here on security! Let's see, 4
people. So why did they leave here? Well, I didn't learn about my
breath problem until the exit interview of the fourth person ... :-))
First, the difference between B1 and B2 is huge. It is a COMPLETE
rewrite if you are starting with a non-B2 source base. Our
security-specific DG/UX effort started in 1990 (July 16, my first day
here). Prior to that, DG had written their own kernel to high
assurance / high quality standards intending to meet B2/B3,
requirements which is the fundamental requirement for creating a B2
system of any kind. Basically, it's taken about 12 years to do this,
certainly predating CyberGuard, and even the firewall market
phenomenon.
CyberGuard is a technology which is built on TOP of an OS. CyberGuard
does a pretty good job of creating proxies, etc. and has a good
administrative interface. CyberGuard makes some internal modifications
to the OS to gain performance and to capture network traffic at the
right place, but I have no detailed knowledge of exactly what
CyberGuard does in the kernel. Suffice it to say that this approach is
not compatible with a B2 approach.
People seem to view a "firewall" as a THING - a physical entity. Most
firewalls are actually a thing that implements a FIREWALL SERVICE. The
reasom that they must be a thing rather than just a service is that the
platform on which they are implemented is subject to attack, so the
firewall service must exist alone on the platform, enforcing the view of a
firewall as a thing.
DG's firewall technology is an integral part of the OS - it has to be
to provide its high integrity and its feature set. Note, however, that
if CyberGuard threw out their kernel hooks, the CyberGuard firewall
SERVICE could run on top of B2 DG/UX, becoming a B1 firewall service
running in a B2 environment (along with other services, such as a web
server. CyberGuard could also rewrite their layered components (e.g.,
proxy, admin interface) to meet B2 requirements, and put them on top of
B2 DG/UX, then that combination would be B2. BDM in Columbia, MD, has
created a B2 firewall by adding their own B2 layered components
(mostlyy written from scratch rather than having to rewrite existing
code).
B2 DG/UX provides an excellent base, with the ability to isolate
network requests (see below) which other firewalls do not provide. But
base DG/UX has no proxies. BDM, in its CYBERSHIELD product, has added
proxies, encryption and filters to the B2 DG/UX base. CYBERSHIELD is
in B2 evaluation for DOCKMASTER II at NSA. The switchover of
DOCKMASTER to DOCKMASTER II will occur on Oct 7 at this year's Baltimore
security conference (the NIST/NSA conference that used to be called
National Computer Security Conference, but is now called NISSC -
National Information Systems Security Conference). CYBERSHIELD is a
commercial product currently in use at commercial installations as well
as govmint sites. [See rant below! :-)]
(See http://www.cybershield.com)
As indicated above, there are several layered components required to
make a firewall work, e.g., filters, admin interface, etc. In my
earlier message I talked about the firewall base and the firewall
"appliances" on top of the base. B2 DG/UX is the base, providing B2
trusted networking, trusted path, session containment, subsession
isolation, virus prevention, and so forth. (I have included some
definitions below for those who want to understand that last sentence.
:-) Since the security enforcing components are in the highly modular
B2 system, there is no real threat of attack to those mechanisms from
any application. Thus, you can run your Web server (or whatever) on
the same system providing the firewall services. I have already listed
the advantages of this feature in my prior post.
The following are a few definitions presented in an informal manner to give
some feel for the basis of the B2 technology is. If desired, I can provide
specific examples of how this works in a firewall/web server scenario, or
any other requested scenario. Just ask.
session - when you cross the system boundary and connect to a
system, you create a "session," and you receive a
profile of the MAXIMUM authority that you can acquire
during that session based upon things like who you are
(your external user identity), how you got to the
system (ftp, telnet, http, sql, login, ...), time of
day/date, your physical location, type of data you want
to access (e.g., public, confidential, R&D, finance,
source code, ...). Thereafter, no mater what you do,
what passwords you know, what smartcards you possess,
you can never exceed the authority limits set when you
connected (or passed through as when used for a
firewall service). Just by looking at an external
user's account, you can easily see the limits that are
set for that user. Since the system is B2, you have a
high level of assurance that these limits will indeed
be enforced. This applies to the "anonymous" external
user as well as to named external users.
subsession - if you log in to a system, then su to another
person's DAC identity, then assume an administrative
role, these are all separate subsessions - in DG/UX
they can coexist and you can switch between the
subsessions. Each subsession will have its own containment
area - its own set of authorities, which are always a
subset of the session containment area. Processes in a
subsession cannot exceed the subsession containment in the
same manner that subsessions cannot excced session
containment (in the same manner that session containment
cannot exceed external user account containment).
subsession isolation - there is no way for the subsessions to
communicate with each other through the tty or in any
other manner unless they are in overlapping containment
areas.
[Here I get to rant a bit about one of my pet peeves. The general
view of what the military and government want vis a vis security is
one of arcane, specialized system not relevant to real human beings.
This is so far from the truth that it makes me want to puke! :-)
The fact of the matter is that the vast majority of military and
government systems are used for ..... office automation, which is
of course not relevant to the commercial space. Sigh. The
military and gov types simply are forced by law (for very good
reasons) to HAVE to keep people from accessing things they don't
have the authority to see. The same requirement exists in the
commercial world with essentially the same set of problems. Early
efforts with security were awkward, but so what? Anybody want to
go back to the IBM 1601 or 360/30 or the Intel 8080 or whatever?
Systems evolve, technology evolves. The gov wants COTS high
assurance (commercial off the shelf) so that the costs are reduced
and they can use state of the art applications. The problem is
that the reputation of security in the commercial space has been
kept intentionally bad for mainly unintentional reasons. But with
the increasing demand for highly available systems and high
integrity systems, things will change. The basis for security is
not features, it is quality (high assurance). A security feature
that is of poor quality or that can be circumvented is of little
long term value. OK, enough, rant off.]
--
Jon F. Spencer spencerj @
rtp .
dg .
com
Data General Corp. Phone : (919)248-6246
62 Alexander Drive, MS #119 FAX : (919)248-6108
Research Triangle Park, NC 27709 Office RTP 121/9
There is no such thing as a small interference with property.
Andrew J. Galambos
No success can compensate for failure in the home.
President David O. McKay
***** UCC 1-207 ********
Follow-Ups:
|
|
