Guard (information security)

In information security, a guard is a device or system for allowing computers on otherwise separate networks to communicate, subject to configured constraints. In many respects a guard is like a firewall and guards may have similar functionality to a gateway.

Whereas a firewall is designed to limit traffic to certain services, a guard aims to control the information exchange that the network communication is supporting at the business level. Further, unlike a firewall a guard provides assurance that it is effective in providing this control even under attack and failure conditions.

A guard will typically sit between a protected network and an external network, and ensure the protected network is safe from threats posed by the external network and from leaks of sensitive information to the external network.

A guard is usually dual-homed, though guards can connect more than two networks, and acts as a full application layer proxy, engaging in separate communications on each interface. A guard will pass only the business information carried by the protocols from one network to another, and then only if the information passes configured checks which provide the required protection.

History

The development of guards began in the late 1970s with the creation of several "Secure Communications Processors" and "Guard" applications. The secure communications processors were high assurance operating systems and security kernels developed to support controlled plain-text bypasses for packet network encryption devices. The guard applications were designed to sanitise data being exported from a classified system to remove any sensitive information from it.

The Honeywell Secure Communications Processor (SCOMP) was an early guard platform. This was evaluated against the DoD Computer Security Center Orange Book evaluation criteria at level A1.

The RSRE Secure User Environment (SUE) ran on a PDP-11/34. It was very simple separation kernel designed and constructed by T4 Division of the Royal Signals and Radar Establishment (RSRE) at Malvern, England.

The Advanced Command and Control Architectural Testbed (ACCAT) guard was developed to export email from a classified system through a human review stage.

Later developments of guards addressed the problem of automatic "downgrading" of information exported from a classified system. The Secure Network Server (SNS) Mail Guard (SMG) enforced source/destination address whitelists, security label checks, attachment type filtering and digital signatures to ensure sensitive information is not released

Firewalls were a later development, arriving around 1987. Over time the functionality of firewalls have increased to provide similar capabilities to guards. The main difference remaining is that guards are built in such a way to provide assurance that they are effective at protecting the network and themselves.

The SWIPSY firewall toolkit was developed by the Defence Evaluation and Research Agency to act as a general Guard platform. SWIPSY was layered on top of Trusted Solaris 8.

Functionality

Guards were initially designed to control the release of information from classified systems, protecting the confidentiality of the sensitive information handled by the protected system. Since then their scope has been extended to cover controls over the import of data, in order to protect the integrity of information and availability of services in the protected network.

Guards generally provide the following functionality:

• source and destination address authentication
• source and destination address whitelisting
• security label checks against source and destination clearances
• data format whitelisting
• data format consistency and validity checking
• scanning data for known malware
• validation of digital signatures
• inspection of encrypted content
• checking text against a blacklist of phrases
• removal of redundant data
• generation of logs recording security relevant events
• self-test mechanisms

Assurance

Guards are functionally equivalent to a bastion host acting as an application proxy placed within a DMZ network, where the proxy imposes the necessary controls over the data that is exchanged to provide the protection against external threats and internal leaks. But they can be distinguished by the way they are constructed. A DMZ network relies on the outer packet filtering firewalls to route traffic to the bastion host. If the firewalls function incorrectly they may pass traffic through the DMZ without passing through the bastion host, so the checks imposed by the proxies are bypassed. Also, if the networking stack of the bastion host behaves incorrectly it may route traffic through the DMZ without passing through the proxies.

A guard is constructed so the software that needs to function correctly is minimised and that the work needed to demonstrate this to a third party is also minimised. That is, guards are engineered to provide assurance that they apply the appropriate checks.

Guards can use a trusted operating system to separate the security critical checker components from the less critical protocol handling components. In this way failure of the protocol handling components cannot cause data to bypass the checker. For example, Security-Enhanced Linux is used by the Nexor guards and Solaris 10 with Trusted Extensions is used by the Radiant Mercury and the ISSE Guard, and by Deep-Secure. The type enforcement controls developed for the LOCK operating system were used in Sidewinder.

Guards can also use physically separate computers to ensure that critical components are not bypassed.

Products

Government-off-the-shelf products:

• Radiant Mercury
• ISSE Guard

Commercial-off-the-shelf products:

• Rockwell Collins Guards (Rockwell Collins)
• Deep-Secure Mail Guard (Deep-Secure)
• Nexor CDS (Nexor)
• Raytheon High Speed Guard (Raytheon)
• SDoT Security Gateway (Infodas)
• Standard Automated Guard Environment (SAGE) (BAE Systems)
• SyBard::Sentry (QinetiQ)

See also

• Data Diode
• High Assurance Guard