In message <Pine.BSD/ .
3 .
91 .
951121094832 .
5248A-100000 @
main .
geminisecure .
com>
Leonard Miyata writes:
> Unfortunatly, at this time, there exists no 'Official' criteria defining
> the functionality of a 'Guard'. I have heard that there is a organization
> (NIST?) that is working on one. As it is now, there is some confusion
> between a 'Guard' and a 'Firewall' as there is some overlap in functionality.
I think general wisdom has it that a Firewall is a security device that makes
security decisions pertaining to allowing or disallowing certain types of
*connections* (determined by IP address and/or comms protocol), while a Guard is
a security device that makes security decisions pertaining to the data being
transmitted, either based on addressing information, digital signature, or
content.
A practical example would be the difference between a firewall that either
allowed or disallowed certain e-mail connections and a guard that mediate e-mail
message traffic:
FIREWALL: Internal user "X" can send mail to/receive mail from Internet address
"Y" using SMTP, but cannot send mail to/receive mail from Internet address "Z"
using SMTP.
GUARD: Mail received by "X" from Internet address "Y" will be checked for a
valid digital signature; it's content will be scanned for viruses; it will only
be allowed if the digital signature is valid and it is virus-free. Mail sent by
"X" to "Y" is also checked for a valid digital signature before being released.
Furthermore, a guard is most likely to be used in an environment with a security
policy that defines at least separate communities-of-interest (based on
need-to-know information) and at most a multilevel secure environment made up of
multiple single-level communities of interest operating at difference levels of
security classification. This isn't to say a guard wouldn't be useful in other
environments, but at the very least an idea of "communities of interest" (even
if it's just an "Us" community and a "Them" community) is necessary to define
guard policy. Even in such a loosely-defined environment the ability to scan an
incoming file for a virus, or to determine the file's type (e.g., ASCII vs.
BINARY), for example, when added to a firewall, arguably makes that firewall
into something more...i.e., a guard.
In a multilevel secure environment, a guard may be used to enable a network
connection that would otherwise be impossible, or require human mediation (a
review-and-release function). A guard, in this environment, essentially
automates some or all of that human review-and-release function, providing a
privileged (some people call it "trusted") software function that can perform an
explicit "downgrade" of the security classification of a file originating from a
higher classified (e.g., TOP SECRET) system-high network or host (based on a set
of security policy rules that can range from fairly simple to very complex)
before it is released to a lower classified (e.g., SECRET) system-high network
or host. Conversely, the same or a different guard can "upgrade" a file coming
into the TOP SECRET environment from the SECRET; in this case, the re-grading of
the file is implicit (no security policy rules really apply, as the
Bell-LaPadula security model is not being violated; of course, if a different
security model applies, it may well be violated by anything but same
level-to-same level transfers, or even by low-to-high transfers); the guard
works mainly to keep the two networks separate, and to prevent the
illicit/unintentional release of TOP SECRET data to the SECRET network).
Criteria for re-grading data range from accepting the security label on the data
to actually scanning the contents "dirty words" (or, given a sophisticated
rules-based natural language processor, the full content and contextual meaning
of the data).
Being a simple GO/NO-GO device, no firewall has the privileged software function
(or, alternately, the human reviewer "escape" capability) to enable this kind of
security downgrade. Security downgrades are usually based on one of three types
of logic:
Simple: "GO *IF* or NO-GO"
More Complex: "GO *IF* or NO-GO AND FORWARD TO HUMAN REVIEWER *IF*"
Even More Complex: "GO *IF* or MODIFY AND GO *IF* or NO-GO AND TRASH *IF* logic
(the "MODIFY", for example, might be a blanking out of dirty words in a text
file, or a truncating of decimal places in a fixed-format numeric file).
Most Complex: "GO *IF* or MODIFY AND GO *IF* or NO-GO AND FORWARD TO HUMAN
REVIEWER *IF* logic.
In any case, the set of rules (and associated processing steps for enforcing
those rules) required by a guard are usually (not always; there are simple
one-way "low-to-high" diodes that do nothing more than authenticate source and
destination addresses and security labels) more sophisticated than those
required by a firewall.
Another feature of guards is the more sophisticated auditing they provide,
usually due to the additional types of events they support, and also to the fact
that they generally run on trusted computing bases (TCBs) evaluated at the B1
level or above (i.e., multilevel secure devices), and the operating system
auditing of these TCBs is more sophisticated and trustworthy than that of C2 and
below systems.
Karen Goertzel
Manager, International Programmes
Secure Systems and Services Operation
Wang Federal, Inc.
7900 Westpark Drive - MS 700
McLean, Virginia 22102-4299
TEL: 703-827 3914
FAX: 703-827 3161
Internet: goertzek @
wangfed .
com
+-----------------------------------------+
| Human history becomes more and more a |
| race between education and catastrophe. |
| - H.G. Wells |
+-----------------------------------------+
|
|
