Riverbed SteelHead CX v8 ALG Security Technical Implementation Guide

Protecting the end-to-end security of TLS is required to ensure integrity and confidentiality of the data in transit. Signed SMB and encrypted MAPI traffic use techniques to protect against unauthorized man-in-the-middle devices from making modifications to their exchanged data. Additionally, encrypted MAPI traffic and encrypted SMB3 traffic ensure data confidentiality by transmitting data with protection across the network. To securely optimize this traffic, a properly configured client and server-side SteelHead appliance with the SteelHead WAN optimization platform must: - decrypt and remove signatures on received LAN side data from the client or server. - perform bandwidth and application layer optimization. - use the secure inner channel feature to maintain data integrity and confidentiality of data transmitted over the WAN. - convert the received optimized data back to its native form. - encrypt and apply signatures for LAN side transmission of data to the client or server. To query the Windows domain controller for the necessary cryptographic information to optimize this traffic, the server-side SteelHead appliance must join a Windows domain. The SteelHead appliance can require other configurations, both on the SteelHead appliance, and in the Windows domain. This cryptographic information is only useful for the lifetime of an individual connection or session. The information is obtained at the beginning of a connection, and transferred to the client-side SteelHead appliance as needed, using the secure inner channel feature. You must configure the secure inner channel to ensure maximum security. Only the server-side SteelHead appliance is required to join the domain, and it does so using a machine account in the same way that a Windows device joins the domain using a machine account. The SteelHead appliance joins the domain this way to obtain a client user session key (CUSK) or server user session key (SUSK), which allows the SteelHead appliance to sign and/or decrypt MAPI on behalf of the Windows user that is establishing the relevant session. The server-side SteelHead appliance must join a domain that is either: - the user domain. The domain must have a trust with the domains that include the application servers (file server, Exchange server, and so on) you want to optimize. - A domain with a bi-directional trust with the user domain. The domain might include some or all of the Windows application servers (file server, Exchange server) for SteelHead appliance optimization. Production deployments can have multiple combinations of client and server Windows operating system versions, and can include different configuration settings for signed SMB and encrypted MAPI. NTLM is not approved for use for DoD implementations. Therefore it is possible that the security authentication between clients and servers can use Kerberos, or a combination of the two.

Automated monitoring of remote access traffic allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by inspecting connection activities of remote access capabilities. Remote access methods include both unencrypted and encrypted traffic. Inbound traffic must be inspected prior to being allowed on the enclave's trusted networks. Outbound traffic inspection must occur prior to being forwarded to destinations outside of the enclave. Optimally, the SteelHead must be architecturally placed at the perimeter in front of the perimeter router. Thus, traffic is directed for firewall and IDPS inspection for inbound and outbound traffic in compliance with DoD policy. Additionally, from an operational perspective, this architecture avoids the need to open many ports and services in the firewall to accommodate TCP options 76 and 78 and ports 7800, 7810, and 7870. Some other configurations may involve even more ports and services.

Protecting the end-to-end security of TLS is required to ensure integrity and confidentiality of the data in transit. The Riverbed Optimization System TLS optimization solution accelerates data transfers that are encrypted using TLS, provided SteelHead appliances that are deployed locally to both the client-side and server-side of the network. All of the same optimized connections that are applied to normal non-encrypted TCP traffic can also apply to encrypted TLS traffic. SteelHead appliances with RiOS accomplish this without compromising end-to-end security and the established trust model. Private keys remain in the data center and are not exposed in remote locations where they might be compromised. The RiOS TLS optimization solution starts with SteelHead appliances that have a configured trust relationship, enabling them to exchange information securely over their own dedicated TLS connection. Each client uses unchanged server addresses and each server uses unchanged client addresses; no application changes or explicit proxy configuration is required. RiOS uses a unique technique to split the TLS handshake. The handshake is the sequence of message exchanges at the start of a TLS connection. In an ordinary TLS handshake, the client and server first establish identity using public-key cryptography, and then negotiate a symmetric session key to use for data transfer. When using RiOS TLS acceleration, the initial TLS message exchanges take place between the client application (for example, a Web browser) and the server side SteelHead appliance. SteelHead WAN optimization platform works to ensure that TLS acceleration delivers the following: - sensitive cryptographic information is kept in the secure vault - a separate, encrypted store on the disk. - built-in support for popular Certificate Authorities (CAs) such as VeriSign, Thawte, Entrust, and GlobalSign. In addition, SteelHead appliances allow the installation of other commercial or privately operated CAs. - import of server proxy certificates and keys in PEM, PKCS12, or DER formats. SteelHead appliances also support the generation of new keys and self-signed certificates. If your certificates and keys are in another format, you must first convert them to a supported format before you can import them into the SteelHead appliance. - separate control of cipher suites for client connections, server connections, and peer connections. - bulk export or bulk import server configurations (including keys and certificates) from or to, respectively, the server-side SteelHead appliance.

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD-nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include broadband and wireless connections. Remote access methods include, for example, proxied remote encrypted traffic (e.g., TLS gateways, web content filters, and webmail proxies). Encryption provides a means to secure the remote connection so as to prevent unauthorized access to the data traversing the remote access connection, thereby providing a degree of confidentiality. The encryption strength of the mechanism is selected based on the security categorization of the information. This requirement applies to ALGs providing remote access proxy services as part of its intermediary services (e.g., OWA or TLS gateway).

Private key data is used to prove that the entity presenting a public key certificate is the certificate's rightful owner. Compromise of private key data allows an adversary to impersonate the key holder. Private key data associated with software certificates, including those issued to an ALG, is required to be generated and protected in at least a FIPS 140-2 Level 1 validated cryptographic module. The Riverbed RiOS secure vault contains sensitive information from your SteelHead appliance configuration, including SSL private keys and the data store encryption key. These configuration settings are encrypted on the disk using AES 256-bit encryption. The secure vault always runs in FIPS mode.

SP 800-52 provides guidance on using the most secure version and configuration of the TLS/SSL protocol. Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks which exploit vulnerabilities in this protocol. This requirement applies to TLS gateways (also known as SSL gateways) and is not applicable to VPN devices. Application protocols such as HTTPS and DNSSEC use TLS as the underlying security protocol thus are in scope for this requirement. NIS SP 800-52 provides guidance. SP 800-52 sets TLS version 1.1 as a minimum version, thus all versions of SSL are not allowed (including for client negotiation) either on DoD-only or on public facing servers.

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access is access to DoD-nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include broadband and wireless connections. Remote access methods include, for example, proxied remote encrypted traffic (e.g., TLS gateways, web content filters, and webmail proxies). Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. This requirement applies to ALGs providing remote access proxy services as part of its intermediary services (e.g., OWA or TLS gateway).

Because Wan Optimization is optimally installed in the architecture at the perimeter, installation of unnecessary functions and services on the same host increases the risk by implementing these functions before the network inspection functions and excessive open ports on the firewall for these functions and services to operation. Loading functions that are outside the scope and unrelated to the WAN optimization function is unauthorized and may create an attack vector. Related services include content filtering, traffic analysis, decryption, caching, and traffic inspection tools (e.g., firewall, IDS), unrelated services include email, DNS, web server. When the solution is implemented using a Steelhead CX hardware appliance implementation consisting of the RiOS installed on the SteelHead, administrators are not able to install any software that is not part of a Riverbed upgrade. RiOS enforces this by performing a validity check when an upgrade is attempted. However, the RiOS application suite is available in a virtual appliance version which can be installed on an organization-provided host. This type of implementation adds risk because more ports may need to be opened in the firewall if placed in the recommended logical position in the architecture after the router and before the firewall and IDS. The traffic should then be routed for inspection after traversing the wan optimizer.

Unrelated or unneeded proxy services increase the attack vector and add excessive complexity to the securing of Riverbed Optimization System (RiOS) version 8.x.x. Multiple application proxies can be installed on many ALGs. However, proxy types must be limited to related functions. At a minimum, the web and email gateway represent different security domains/trust levels. Organizations should also consider separation of gateways that service the DMZ and the trusted network.

In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types); organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. ALGs are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. DoD continually assesses the ports, protocols, and services that can be used for network communications. Some ports, protocols or services have known exploits or security weaknesses. Network traffic using these ports, protocols, and services must be prohibited or restricted in accordance with DoD policy. Riverbed Optimization System (RiOS) is a key network element for preventing these non-compliant ports, protocols, and services from causing harm to DoD information systems. The network ALG must be configured to prevent or restrict the use of prohibited ports, protocols, and services throughout the network by filtering the network traffic and disallowing or redirecting traffic as necessary. Default and updated policy filters from the vendors will disallow older version of protocols and applications and will address most known non-secure ports, protocols, and/or services. However, sources for further policy filters are the IAVMs and the PPSM requirements.

A certificate's certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate. Certification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses.

Authenticity protection provides protection against man-in-the-middle attacks/session hijacking and the insertion of false information into sessions. This authenticity protection control focuses on communications protection for the application session rather than for the network packet and establishes grounds for confidence at both ends of communications sessions in ongoing identities of other parties and in the validity of information transmitted. Depending on the required degree of confidentiality and integrity, web services/SOA will require the use of mutual authentication (two-way/bidirectional).