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
[edit]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)[1] 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.[2][3]
The Advanced Command and Control Architectural Testbed (ACCAT) guard was developed to export email from a classified system through a human review stage.[4]
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[5]
Firewalls were a later development, arriving around 1987.[6] 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
[edit]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
[edit]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.[7]
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.[8] For example, Security-Enhanced Linux is used by the Nexor guards[9] and Solaris 10 with Trusted Extensions is used by the Radiant Mercury and the ISSE Guard,[10] and by Deep-Secure. The type enforcement controls developed for the LOCK operating system[11] were used in Sidewinder.[12]
Guards can also use physically separate computers to ensure that critical components are not bypassed.[13]
Products
[edit]Government-off-the-shelf products:
- Radiant Mercury[14]
- ISSE Guard[15]
Commercial-off-the-shelf products:
- Rockwell Collins Guards[16] (Rockwell Collins)
- Deep-Secure Mail Guard[17] (Deep-Secure)
- Nexor CDS[18] (Nexor)
- Raytheon High Speed Guard[19] (Raytheon)
- SDoT Security Gateway[20] (Infodas)
- Standard Automated Guard Environment (SAGE)[21] (BAE Systems)
- SyBard::Sentry[22] (QinetiQ)
See also
[edit]References
[edit]- ^ Steven Padilla and Terry Benzel, Final Evaluation Report of SCOMP, CSC-EPL-85/001, 1985
- ^ John Rushby (1981). "Design and Verification of Secure Systems" (PDF). ACM Operating Systems Review. 15 (5). SRI International Computer Science Laboratory: 12–21. doi:10.1145/1067627.806586.
- ^ D H Barnes, Secure Communications Processor Research, Procs. 7th DoDNBS Computer Security Initiative Conference 1984
- ^ Woodward, J.P.L, Applications for multilevel secure operating systems, Proc. AFIPS 1979 Nat. Comput. Conf., June, 1979
- ^ R.E.Smith Constructing a High Assurance Mail Guard Archived 2012-06-17 at the Wayback Machine 1984
- ^ Ingham, K and Forrest S A History and Survey of Network Firewalls
- ^ Charles Maney Security Issues When Data Traverses Information Domains: Do Guards Effectively Address the Problem?
- ^ Rick Smith The Challenge of Multilevel Security, Blackhat, Oct 2003
- ^ "Nexor Sentinel 3E Filtering System Common Criteria Security Target"
- ^ Cheryl Gerber Dot-Connecting Across Domains Archived 2016-01-31 at the Wayback Machine, Military Information Technology Vol 14 Issue 1Feb 2010
- ^ Richard Smith [1] Archived 2009-01-06 at the Wayback Machine Mandatory Protection for Internet Server Software
- ^ Saydjari, Sami (May 1989). "LOCK Trek: Navigating Uncharted Space". Procs. IEEE Symp Security and Privacy.
- ^ Read "Computers at Risk: Safe Computing in the Information Age" at NAP.edu. 1991. doi:10.17226/1581. ISBN 978-0-309-04388-5.
- ^ "Radiant Mercury" (PDF).
- ^ "Imagery Support Server Environment (ISSE) Guard".
- ^ "Rockwell Collins High Assurance Guards".
- ^ "Mail Guard". Archived from the original on 2012-07-21. Retrieved 2012-08-06.
- ^ "Cross Domain Solutions".
- ^ "Metro Guards".
- ^ "SDoT Security Gateway".
- ^ Focke, Michel. "SAGE Standard Automated Guard Environment Technical Overview". CiteSeerX 10.1.1.133.4225.
{{cite web}}: Missing or empty|url=(help) - ^ "Secure cross domain solution: SyBard". Archived from the original on 2012-05-28. Retrieved 2012-07-23.