NSA : High Assurance Guard PP
This High Assurance Guard Protection Profile (PP) was written by CygnaCom and
revised by Sparta and CygnaCom.
This Protection Profile (PP) specifies the information security requirements for DoD Mail Guards for High Robustness Environments. The Mail Guard specified in this PP sits between two protected networks at different classification levels, controlling the flow of electronic messages sent between the two networks. The protection approach employs various processing, filtering, and data-blocking techniques in an attempt to provide data sanitization (e.g., downgrade) or separation between networks. Besides enforcing an information flow policy and providing services for confidentiality and integrity of mail messages, the Mail Guard provides identification and authentication, trusted path and audit capabilities and has been designed with a high degree of assurance. The specific functional and assurance requirements are contained in Section 5 of this document.
The DoD Mail Guard for High Robustness Environments, hereafter referred to as the Target Of Evaluation (TOE), has the ability to separate networks of different classifications, assuring that the only electronic mail traffic allowed to pass between networks is that allowed by a site-defined security policy. As shown in Figure 1, the TOE stands between two classified networks where the security levels (i.e., CLASSIFICATION A and CLASSIFICATION B) are not the same. The TOE supports X.400 and Simple Mail Transfer Protocol (SMTP), as specified in RFC 821, electronic messaging as well as X.500 directory services, as specified in RFC 1943.
The TOE is configurable to support various message release policies from a protected enclave and admittance of messages into a protected enclave. Specifically, the TOE allows each enclave to control the flow of X.400 and SMTP messages, and X.500 directory data transfers into and out of the enclave in accordance with a set of release and admittance policies. Filter options include host, sender and receiver access control lists; use of encryption; security level; allowable attachment types; plain text string search; and human review of attachments. The TOE supports enforcement of the DoD Mandatory Access Control policy by limiting flows at different classification levels to those that are consistent with the overall system policy.
Typical flows for messages and directory information are as follows. When an inbound Mail Transfer Agent (MTA) receives a message, the message is forwarded, according to the messaging protocol used and the outbound MTA for which it is intended, to a set of X.400 or SMTP security policy filters appropriate for that data flow. The filters check all relevant message characteristics - envelope, header, encryption, details, content, and disposition - against the associated rules in the site-defined X.400 or SMTP security policy that was configured in the TOE for that particular data flow. If validated by the filter set, the message is then reclassified and sent to an outbound MTA at the level of the intended recipient. The outbound MTA then routes the message to the destination User Agent (UA) or to the next MTA in the routing chain. If not validated by the filter set, an audit record is generated and the TOE deletes the message.
When an inbound Directory Service Agent (DSA) receives a request over the TOE-connected network at the same classification level, it first authenticates itself and the requesting Directory User Agent (DUA) or DSA. The type of authentication must be strong authentication using X.509 Version 3 certificates. Once the request is authenticated, the inbound DSA passes the request through its X.500 security policy filters. The security policy filters ensure that the message conforms to the release policy configured for the directory data flow between the requesting DUA or DSA and the responding DSA. If the request passes the security filter checks, the inbound DSA reclassifies the message and sends it to the filtering application's DSA at the new classification level (i.e., the level of the destination network). The outbound DSA establishes a connection between itself and the destination DSA, authenticating that connection using strong authentication. It then sends the message to the destination DSA.
In addition to supporting a flow control policy, the TOE provides user identification and authentication, trusted path to and from the cryptographic module, trusted facility management (i.e., separate Guard Application and Authorized Administrator functions), and trusted recovery. Authorized Administrators and Guard Application Administrators must authenticate themselves to the TOE. Technologies used by the TOE to authenticate the Authorized Administrator and Guard Application Administrator to the TOE include, but are not limited to, one-time passwords, digital certificates or biometrics. Authorized Administrators and Guard Application Administrators must administer the TOE locally via a physically protected direct connection to a console port. The Authorized Administrator is responsible for administering the TOE (i.e., operating system) security parameters. The Guard Application Administrator is responsible for administering the security parameters of the guard application (i.e., filter settings).
The TOE audits all message traffic; use of identification and authentication mechanisms; actions taken by the Authorized Administrator and/or Guard Application Administrator; changes made to the TOE's security policy rules and data; and changes made to the TOE's date and time; and the use of other security functions. The decision to record auditable events will be made in accordance with the organizational security policy and will be implemented by the Authorized Administrator. The TOE will be able to include or exclude auditable events recorded based on a set of attributes (at a minimum IP address, type of service (SMTP or X.400), security level, named sender, named recipient, type of attachment, encrypted/unencrypted messages). Audit trail data is stamped with a dependable date and time when recorded. If the audit trail becomes full then the only auditable events that are recorded are those performed by the Authorized Administrator. The TOE will take action to notify the Authorized Administrator when the audit trail reaches 90% capacity.
TOEs meeting this PP shall verify digital signatures according to the Digital Signature Algorithm (as specified in FIPS PUB 186), perform encryption/decryption using an NSA-certified high robustness algorithm, and compute a secure hash using Secure Hash Algorithm (SHA-1) (as specified in FIPS PUB 180-1).
The TOE assurance requirements are designed to provide a high degree of confidence that the Mail Guard functions as designed, is tamper-proof and non-bypassable. Therefore, the PP specifies assurance requirements greater than Evaluation Assurance Level 4 (EAL4). Specifically, the TOE must satisfy the configuration management and delivery and operation assurance requirements at EAL4 to ensure that modifications during delivery are detected and tracking of changes and security flaws are reported. The TOE must meet the Development assurance requirements up to EAL6 to ensure that the high-level and low-level design are described in a semi-formal manner and are supported by a semi-formal security policy model. The Guidance Documents and Life Cycle Support requirements must satisfy at least the EAL4 requirements; additionally, the TOE must be developed by a controlled process. The Testing and Vulnerability Assessment must meet the EAL6 requirements to ensure that the functional testing, covert channel analysis, and a thorough analysis for vulnerabilities are performed. The specific assurance requirements for the TOE are documented in Section 5.