In the simplest terms, a Trusted Guard is a software
application that automates the job now performed by
human review-and-release officers. The Guard enforces
some one or more security policy rules that enable it to
determine whether a piece of information should be
allowed to be released from the enclave (system,
domain, or network) to another enclave at a different
(lower or higher) sensitivity level (e.g., a different
classification or need-to-know). In this way, the Guard
replaces the “air gap” between the two enclaves. The
Guard, in short, is designed to ensure that no
information flows out of an enclave that is not allowed
to flow out of that enclave.
Some Guards also enforce admittance policies
governing what information may flow into an enclave
(or domain), in essence protecting that enclave from the
outside world. Like a firewall, this type of Guard is
designed to protect the “inside” network from “outside”
networks beyond its control. Unlike a firewall, a Guard
achieves this protection by ensuring that only carefully
vetted pieces of information flow into the protected
enclave/domain.
At a superficial level, Trusted Guards seem to share
characteristics with firewalls. The “inside/outside”
paradigm applies for both types of systems. Both
systems are meant to control the connection between
two networks that would otherwise probably not be
allowed to be connected. But this is where the similarity
ends. While a firewall controls connections, either by
opening or not opening a connection based on the
source and destination IP address/ port number (in some
cases authenticated, in others not) and the
communications protocol being used, a Guard controls
the content sent over a particular connection.
A SAGE Guard achieves this control in the context of
the trusted and highly evaluated STOP operating
system, which is much less likely to contain any
operating system level security flaw and is far less
susceptible to attack than the typical firewall platform.
The Guard’s communications paradigm is virtually
always connectionless. A Guard does not simply open
up a pipe and scan bits going over that pipe. Instead, it
enables and controls the transaction-oriented flow of
individual pieces of information - e-mail messages, data
files, protocol data units, or other discrete units of data.
The transaction-oriented, connectionless nature of the
Guard helps minimize potential covert timing channels
that may be opened when mediating the connection
between two enclaves at different sensitivity levels.
Unlike a firewall, a Guard is usually expected to
enforce a more complex and granular content-oriented
set of security policy rules governing the releasability
or admissibility of discrete pieces of information. A
Guard may parse the header and body of data files or
e-mail messages, scanning each data element in the
header and body to ensure its conformance with a
programmed set of rules that define the characteristics
that make that type of data element permissible to
release (or admit). These data element characteristics
may have to do with identification, authentication, and
authorization/permissions of the sender and/or recipient
of the information (based, for example, on a digital
signature and X.509 certificate). The Guard may check
for the correct encryption of the information, or the
format of the content.
For example, the Guard may parse each data field in a
fixed format data file to ensure that the data in every
field conforms with the specific formatting rule
governing that field (e.g., “data in field #3 must be
alphanumeric”), whether any numbers it contains fall
within certain high/ low thresholds, or whether any text
strings it contains include “dirty words” (e.g., sensitive
“code words”); dirty word scans can also be performed
on free text files such as e-mail messages.
In this way, a Guard can enforce a complex
combination of security policy enforcement processes
that may include scanning the header and content of
every file, message, attachment or protocol data unit
(PDU) sent from or to the inside enclave to ensure that
this piece of information satisfies all criteria by which
the Guard may be permit it to flow to/from the outside
enclave.
The trusted operating system used by the Guard is
another aspect that sets it apart from a firewall. While
both systems implement the idea of “inside” and
“outside”, with the “inside” being inherently more
sensitive than the “outside”, the Guard uses a multilevel
secure (MLS) trusted operating system (STOP), which
enforces a mandatory access control policy. This means
that the notion of the higher and lower sensitivity of the
“inside” vs. the “outside” is enforced in fact by the
Guard’s operating system, and not just in theory (as on
a firewall).