None Computing title Virtual Private Network (VPN) Security Requirements Guide version 3 releaseinfo Release: 4 Vuln_Num V-207184 Rule_ID SV-207184r1138024_rule Severity medium Rule_Title The VPN Gateway must ensure inbound and outbound traffic is configured with a security policy in compliance with information flow control policies. Vuln_Discuss Unrestricted traffic may contain malicious traffic which poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources. VPN traffic received from another enclave with different security policy or level of trust must not bypass be inspected by the firewall before being forwarded to the private network. This requirement also applies to Zero Trust initiatives. Check_Content Verify the VPN Gateway has an inbound and outbound traffic security policy that is in compliance with information flow control policies (e.g., IPsec policy configuration). Review network device configurations and topology diagrams. Verify encapsulated or encrypted traffic received from other enclaves with different security policies terminate at the perimeter for filtering and content inspection by a firewall and IDPS before gaining access to the private network. If the IPsec VPN Gateway does not use Encapsulating Security Payload (ESP) in tunnel mode for establishing secured paths to transport traffic between the organizations sites or between a gateway and remote end-stations, this is a finding, Fix_Text Configure the VPN Gateway to ensure inbound and outbound traffic is configured with a security policy in compliance with information flow control policies (e.g., IPsec policy configuration). Also, configure the VPN gateway to forward encapsulated or encrypted traffic received from other enclaves with different security policies to the perimeter firewall and IDPS before traffic is passed to the private network. Not_Reviewed Vuln_Num V-207185 Rule_ID SV-207185r1056127_rule Severity medium Rule_Title The Remote Access VPN Gateway and/or client must display the Standard Mandatory DOD Notice and Consent Banner before granting remote access to the network. Vuln_Discuss Display of a standardized and approved use notification before granting access to the network ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. In most VPN implementations, the banner is configured in the management backplane (NDM SRG) and serves as the presentation for the VPN client connection as well as for administrator logon to the device management tool/backplane. This requirement remains applicable for Always-on. Consult the product-specific STIG or vendor documentation for specific configuration. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. This requirement applies to VPN gateways that have the concept of a user account and have the logon function residing on the VPN gateway. The banner must be formatted in accordance with applicable DOD policy. Use the following verbiage for VPN gateways that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't." Check_Content If the user/remote client connection banner is the same as the banner configured as part of the NDM SRG, this is not applicable. Determine if the network device is configured to present a DOD-approved banner that is formatted in accordance with DOD policy. If the Remote Access VPN Gateway or VPN client does not display the Standard Mandatory DOD Notice and Consent Banner before granting remote access to the network, this is a finding. Fix_Text Configure the Remote Access VPN to display the Standard Mandatory DOD Notice and Consent Banner in accordance with DOD policy before granting access to the device. Use the following verbiage for applications that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't." Not_Reviewed Vuln_Num V-207186 Rule_ID SV-207186r1056164_rule Severity medium Rule_Title The Remote Access VPN Gateway and/or client must enforce a policy to retain the Standard Mandatory DOD Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. Vuln_Discuss The user must acknowledge the banner before being allowed access to the network. This provides assurance that the user has seen the message and accepted the conditions for access. If the user does not acknowledge the consent banner, DOD will not be in compliance with system use notifications required by law. In most VPN implementations, the banner is configured in the management backplane (NDM SRG) and serves as the presentation for the VPN client connection as well as for administrator logon to the device management tool/backplane. This requirement remains applicable for Always-on. Consult the product-specific STIG or vendor documentation for specific configuration. To establish acceptance of the application usage policy, a click-through banner at application logon is required. The VPN gateway must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating "OK". This applies to gateways that have the concept of a user account and have the logon function residing on the gateway or the gateway acts as a user intermediary. Check_Content If the user/remote client connection banner is the same as the banner configured as part of the NDM SRG, this is not applicable. Verify the ALG retains the Standard Mandatory DOD-approved Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. If the Remote Access VPN Gateway and/or client does not retain the Standard Mandatory DOD-approved Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access, this is a finding. Fix_Text Configure the Remote Access VPN Gateway and/or client to retain the Standard Mandatory DOD-approved Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. Not_Reviewed Vuln_Num V-207189 Rule_ID SV-207189r608988_rule Severity medium Rule_Title The VPN Gateway must limit the number of concurrent sessions for user accounts to 1 or to an organization-defined number. Vuln_Discuss VPN gateway management includes the ability to control the number of users and user sessions that utilize a VPN gateway. Limiting the number of allowed users and sessions per user is helpful in limiting risks related to DoS attacks. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system. The intent of this policy is to ensure the number of concurrent sessions is deliberately set to a number based on the site's mission and not left unlimited. Check_Content Inspect the VPN Gateway configuration. Verify the number of concurrent sessions for user accounts to 1 or to an organization-defined number (defined in the SSP). If the VPN Gateway does not limit the number of concurrent sessions for user accounts to 1 or to an organization-defined number, this is a finding. Fix_Text Configure the VPN Gateway to limit the number of concurrent sessions for user accounts to 1 or to an organization-defined number, as documented in the SSP. Not_Reviewed Vuln_Num V-207190 Rule_ID SV-207190r803417_rule Severity high Rule_Title The TLS VPN Gateway must use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data during transmission for remote access connections. Vuln_Discuss Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. NIST SP 800-52 Rev2 provides guidance for client negotiation on either DoD-only or public-facing servers. Check_Content Verify the TLS VPN Gateway is configured to use TLS 1.2 or higher to protect the confidentiality of sensitive data during transmission. If the TLS VPN Gateway does not use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data during transmission, this is a finding. Fix_Text Configure the TLS VPN Gateway to use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data for transmission. Not_Reviewed Vuln_Num V-207191 Rule_ID SV-207191r803418_rule Severity medium Rule_Title The remote access VPN Gateway must use a digital signature generated using FIPS-validated algorithms and an approved hash function to protect the integrity of TLS remote access sessions. Vuln_Discuss Without integrity protection, unauthorized changes may be made to the log files and reliable forensic analysis and discovery of the source of malicious system activity may be degraded. Remote access (e.g., RDP) 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. Integrity checks include cryptographic checksums, digital signatures, or hash functions. Federal Information Processing Standard (FIPS) 186-4, Digital Signature Standard (DSS), specifies three NIST-approved algorithms: DSA, RSA, and ECDSA. All three are used to generate and verify digital signatures in conjunction with an approved hash function. Check_Content Verify the remote access VPN Gateway uses a digital signature generated using FIPS-validated algorithms and an approved hash function to protect the integrity of remote access sessions. If the remote access VPN Gateway does not use a digital signature generated using FIPS-validated algorithms and an approved hash function to protect the integrity of remote access sessions, this is a finding. Fix_Text Configure the remote access VPN Gateway to use a digital signature generated using FIPS-validated algorithms and an approved hash function to protect the integrity of remote access sessions. Not_Reviewed Vuln_Num V-207192 Rule_ID SV-207192r916146_rule Severity medium Rule_Title The VPN Gateway must be configured to use IPsec with SHA-2 at 384 bits or greater for hashing to protect the integrity of remote access sessions. Vuln_Discuss Without strong cryptographic integrity protections, information can be altered by unauthorized users without detection. SHA-1 is considered a compromised hashing standard and is being phased out of use by industry and government standards. DOD systems must not be configured to use SHA-1 for integrity of remote access sessions. The remote access VPN provides access to DOD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Check_Content Verify the VPN Gateway uses IPsec with SHA-2 at 384 bits or greater for hashing to protect the integrity of remote access sessions. If the VPN Gateway does not use IPsec with SHA-2 at 384 bits or greater for hashing to protect the integrity of remote access sessions, this is a finding. Fix_Text Configure the VPN Gateway to use IPsec with SHA-2 at 384 bits or greater for hashing to protect the integrity of remote access sessions. Not_Reviewed Vuln_Num V-207193 Rule_ID SV-207193r916149_rule Severity high Rule_Title The IPSec VPN must be configured to use a Diffie-Hellman (DH) Group of 16 or greater for Internet Key Exchange (IKE) Phase 1. Vuln_Discuss Use of an approved DH algorithm ensures the IKE (Phase 1) proposal uses FIPS-validated key management techniques and processes in the production, storage, and control of private/secret cryptographic keys. The security of the DH key exchange is based on the difficulty of solving the discrete logarithm from which the key was derived. Hence, the larger the modulus, the more secure the generated key is considered to be. Check_Content Verify all IKE proposals are set to use DH Group of 16 or greater for IKE Phase 1. View the IKE options dh-group option. If the IKE option is not set to use DH Group of 16 or greater for IKE Phase 1, this is a finding. Fix_Text Configure the IPsec VPN to use the DH Group of 16 or greater for IKE Phase 1. Not_Reviewed Vuln_Num V-207194 Rule_ID SV-207194r608988_rule Severity medium Rule_Title If the site-to-site VPN implementation uses L2TP, L2TPv3 sessions must be authenticated prior to transporting traffic. Vuln_Discuss L2TPv3 sessions can be used to transport layer-2 protocols across an IP backbone. These protocols were intended for link-local scope only and are therefore less defended and not as well-known. As stated in DoD IPv6 IA Guidance for MO3 (S4-C7-1), the L2TP tunnels can also carry IP packets that are very difficult to filter because of the additional encapsulation. Hence, it is imperative that L2TP sessions are authenticated prior to transporting traffic. Check_Content If L2TP communications protocol is not used, this is not applicable. Verify L2TPv3 sessions are configured to authenticate the traffic before transit. L2TPv3 sessions must be authenticated prior to transporting traffic. If L2TPv3 sessions do not require authentication, this is a finding. Fix_Text If the site-to-site VPN implementation uses L2TPv3, configure L2TPv3 sessions to authenticate the traffic before transit. Not_Reviewed Vuln_Num V-207195 Rule_ID SV-207195r608988_rule Severity low Rule_Title The VPN Gateway must generate log records containing information to establish what type of events occurred. Vuln_Discuss Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. VPN gateways often have a separate audit log for capturing VPN status and other information about the traffic (as opposed to the log capturing administrative and configuration actions). Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in the VPN gateway logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured VPN gateway. Check_Content Verify the VPN Gateway generates log records containing information to establish what type of events occurred. If the VPN Gateway does not generate log records containing information to establish what type of events occurred, this is a finding. Fix_Text Configure the VPN Gateway to generate log records containing information to establish what type of events occurred. Not_Reviewed Vuln_Num V-207196 Rule_ID SV-207196r608988_rule Severity low Rule_Title The VPN Gateway must generate log records containing information to establish when (date and time) the events occurred. Vuln_Discuss Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. VPN gateways often have a separate audit log for capturing VPN status and other information about the traffic (as opposed to the log capturing administrative and configuration actions). Associating event types with detected events in the network audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured VPN gateway. Check_Content Configure the VPN Gateway generates log records containing information to establish when (date and time) the events occurred. If the VPN Gateway does not generate log records containing information to establish when (date and time) the events occurred, this is a finding. Fix_Text Configure the VPN Gateway to generate log records containing information to establish when (date and time) the events occurred. Not_Reviewed Vuln_Num V-207197 Rule_ID SV-207197r608988_rule Severity medium Rule_Title The VPN Gateway must generate log records containing information that establishes the identity of any individual or process associated with the event. Vuln_Discuss Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event. Check_Content Verify the VPN Gateway generates log records containing information that establishes the identity of any individual or process associated with the event. If the VPN Gateway does not generate log records containing information that establishes the identity of any individual or process associated with the event, this is a finding. Fix_Text Configure the VPN Gateway to generate log records containing information that establishes the identity of any individual or process associated with the event. Not_Reviewed Vuln_Num V-207198 Rule_ID SV-207198r608988_rule Severity medium Rule_Title The VPN Gateway must generate log records containing information to establish where the events occurred. Vuln_Discuss Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment, and provide forensic analysis, it is essential for security personnel to know where events occurred, such as VPN gateway components, modules, device identifiers, node names, and functionality. Associating information about where the event occurred within the network provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured VPN gateway. Check_Content Verify the VPN Gateway generates log records containing information to establish where the events occurred. If the VPN Gateway does not generate log records containing information to establish where the events occurred, this is a finding. Fix_Text Configure the VPN Gateway to generates log records containing information to establish where the events occurred. Not_Reviewed Vuln_Num V-207199 Rule_ID SV-207199r1038960_rule Severity low Rule_Title The VPN Gateway must generate log records containing information to establish the source of the events. Vuln_Discuss Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment and provide forensic analysis, security personnel need to know the source of the event. In addition to logging where events occur within the network, the log records must also identify sources of events such as IP addresses, processes, and node or device names. Check_Content Verify the VPN Gateway generates log records containing information to establish the source of the events. If the VPN Gateway does not generate log records containing information to establish the source of the events, this is a finding. Fix_Text Configure the VPN Gateway to generate log records containing information to establish the source of the events. Not_Reviewed Vuln_Num V-207200 Rule_ID SV-207200r608988_rule Severity medium Rule_Title The VPN Gateway must produce log records containing information to establish the outcome of the events. Vuln_Discuss Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the network. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the network after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. Check_Content Examine the log configuration on the VPN Gateway or view several alert events on the organization's central audit server. Alternatively, examine the Central Log Server to see if it contains information about success or failure of client connection attempts or other events. If the traffic log entries do not include the success or failure of connection attempts and other events, this is a finding. Fix_Text Configure the VPN Gateway to generate log entries containing information to establish the outcome of the events, such as, at a minimum, the success or failure of the client connection attempts. Not_Reviewed Vuln_Num V-207201 Rule_ID SV-207201r608988_rule Severity low Rule_Title The VPN Gateway must protect log information from unauthorized read access if all or some of this data is stored locally. Vuln_Discuss Auditing and logging are key components of any security architecture. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured VPN gateway. Thus, it is imperative that the collected log data from the various VPN gateways, as well as the auditing tools, be secured and can only be accessed by authorized personnel. This requirement pertains to securing the VPN log as it is stored locally, on the box temporarily, or while being encapsulated. Check_Content Verify the VPN Gateway protects log information from unauthorized read access if all or some of this data is stored locally. If the VPN Gateway does not protect log information from unauthorized read access if all or some of this data is stored locally, this is a finding. Fix_Text Configure the VPN Gateway to protect log information from unauthorized read access if all or some of this data is stored locally. Not_Reviewed Vuln_Num V-207202 Rule_ID SV-207202r608988_rule Severity medium Rule_Title The VPN Gateway log must protect audit information from unauthorized modification when stored locally. Vuln_Discuss If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. This requirement pertains to securing the VPN log as it is stored locally, on the box temporarily, or while being encapsulated. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions, and limiting log data locations. Audit information includes all information (e.g., log records, audit settings, and audit reports) needed to successfully audit information system activity. This requirement only applies to components where this is specific to the function of the device (e.g., IDPS sensor logs, firewall logs). This does not apply to audit logs generated on behalf of the device itself (management). Check_Content Verify the VPN Gateway log is configured to protect audit information from unauthorized modification when stored locally. The VPN Gateway log must protect audit information from unauthorized modification when stored locally, this is a finding. Fix_Text Configure the VPN Gateway log to protect audit information from unauthorized modification when stored locally. The method used depends on system architecture and design. Examples: ensuring log files receive the proper file system permissions and limiting log data locations. Not_Reviewed Vuln_Num V-207203 Rule_ID SV-207203r608988_rule Severity medium Rule_Title The VPN Gateway must protect audit information from unauthorized deletion when stored locally. Vuln_Discuss If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions, and limiting log data locations. Audit information includes all information (e.g., log records, audit settings, and audit reports) needed to successfully audit information system activity. This requirement only applies to components where this is specific to the function of the device (e.g., IDPS sensor logs, firewall logs). This does not apply to audit logs generated on behalf of the device itself (management). Check_Content Verify the VPN Gateway is configured to protect audit information from unauthorized deletion when stored locally. If the VPN Gateway does not protect audit information from unauthorized deletion when stored locally, this is a finding. Fix_Text Configure the VPN Gateway to protect audit information from unauthorized deletion when stored locally. Ensure log files receive the proper file system permissions and limiting log data locations. Not_Reviewed Vuln_Num V-207204 Rule_ID SV-207204r608988_rule Severity medium Rule_Title The VPN Gateway must be configured to prohibit the use of all unnecessary and/or nonsecure functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments. Vuln_Discuss 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. DoD continually assesses the ports, protocols, and services that can be used for network communications. Some 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. The PPSM CAL and vulnerability assessments provide an authoritative source for ports, protocols, and services that are unauthorized or restricted across boundaries on DoD networks. The VPN Gateway 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. Check_Content View the configured security services. Compare the services that are enabled, including the port, services, protocols, and functions. If functions, ports, protocols, and services identified on the PPSM CAL are not disabled, this is a finding. Fix_Text Ensure functions, ports, protocols, and services identified on the PPSM CAL are not used for system services configuration. View the configured security services. Compare the services that are enabled, including the port, services, protocols, and functions. Consult the product knowledge base and configuration guides to determine the commands for disabling each port, protocols, services, or functions that is not in compliance with the PPSM CAL and vulnerability assessments. Not_Reviewed Vuln_Num V-207205 Rule_ID SV-207205r608988_rule Severity medium Rule_Title The IPsec VPN Gateway must use IKEv2 for IPsec VPN security associations. Vuln_Discuss 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. Use of IKEv2 leverages DoS protections because of improved bandwidth management and leverages more secure encryption algorithms. Check_Content Verify the IPsec VPN Gateway uses IKEv2 for IPsec VPN security associations. If the IPsec VPN Gateway must use IKEv2 for IPsec VPN security associations, this is a finding. Fix_Text Configure the IPsec VPN Gateway to use IKEv2 for IPsec VPN security associations. Not_Reviewed Vuln_Num V-207206 Rule_ID SV-207206r608988_rule Severity medium Rule_Title The Remote Access VPN Gateway must be configured to prohibit Point-to-Point Tunneling Protocol (PPTP) and L2F. Vuln_Discuss The PPTP and L2F are obsolete method for implementing virtual private networks. Both protocols may be easy to use and readily available, but they have many well-known security issues and exploits. Encryption and authentication are both weak. Check_Content Verify the VPN Gateway is configured to prohibit PPTP and L2F. If the VPN Gateway does not be configured to prohibit PPTP and L2F, this is a finding. Fix_Text Configure the VPN Gateway to prohibit PPTP and L2F. Not_Reviewed Vuln_Num V-207207 Rule_ID SV-207207r608988_rule Severity medium Rule_Title For site-to-site VPN implementations, the L2TP protocol must be blocked or denied at the security boundary with the private network so unencrypted L2TP packets cannot traverse into the private network of the enclave. Vuln_Discuss Unlike GRE (a simple encapsulating header) L2TP is a full-fledged communications protocol with control channel, data channels, and a robust command structure. In addition to PPP, other link layer types (called pseudowires) can be and are defined for delivery in L2TP by separate RFC documents. Further complexity is created by the capability to define vender-specific parameters beyond those defined in the L2TP specifications. The endpoint devices of an L2TP connection can be an L2TP Access Concentrator (LAC) in which case it inputs/outputs the layer 2 protocol to/from the L2TP tunnel. Otherwise, it is an L2TP Network Server (LNS), in which case it inputs/outputs the layer 3 (IP) protocol to/from the L2TP tunnel. The specifications describe three reference models: LAC-LNS, LAC-LAC, and LNS-LNS, the first of which is the most common case. The LAC-LNS model allows a remote access user to reach his home network or ISP from a remote location. The remote access user connects to a LAC device which tunnels his connection home to an awaiting LNS. The LAC could also be located on the remote user's laptop, which connects to an LNS at home using some generic internet connection. The other reference models may be used for more obscure scenarios. Although the L2TP protocol does not contain encryption capability, it can be operated over IPsec, which would provide authentication and confidentiality. A remote user in the LAC-LNS model would most likely obtain a dynamically assigned IP address from the home network to ultimately use through the tunnel back to the home network. Secondly, the outer IP source address used to send the L2TP tunnel packet to the home network is likely to be unknown or highly variable. Thirdly, since the LNS provides the remote user with a dynamic IP address to use, the firewall at the home network would have to be dynamically updated to accept this address in conjunction with the outer tunnel address. Finally, there is also the issue of authentication of the remote user prior to divulging an acceptable IP address. Because of all of these complications, the strict filtering rules applied to the IP-in-IP and GRE tunneling cases will likely not be possible in the L2TP scenario. In addition to the difficulty of enforcing addresses and endpoints (as explained above), the L2TP protocol itself is a security concern if allowed through a security boundary. In particular: 1) L2TP potentially allows link layer protocols to be delivered from afar. These protocols were intended for link-local scope only, are less defended, and not as well-known, 2) The L2TP tunnels can carry IP packets that are very difficult to see and filter because of the additional layer 2 overhead, 3) L2TP is highly complex and variable (vender-specific variability) and therefore would be a viable target that is difficult to defend. It is better left outside of the main firewall where less damage occurs if the L2TP-processing node is compromised, 4) Filtering cannot be used to detect and prevent other unintended layer 2 protocols from being tunneled. The strength of the application layer code would have to be relied on to achieve this task, 5) Regardless of whether the L2TP is handled inside or outside of the main network, a secondary layer of IP filtering is required; therefore bringing it inside does not save resources. Therefore, it is not recommended to allow unencrypted L2TP packets across the security boundary into the network's protected areas. Reference the Backbone Transport STIG for additional L2TP guidance and use. Check_Content If L2TP communications protocol is not used, this is not applicable. Verify the VPN Gateway or another network element (e.g., firewall) is configure to block or deny L2TP packets with a destination address within the private network of the enclave. If L2TP communications are allowed to cross the security boundary into the private network of the enclave, this is a finding. Fix_Text If L2TP is used for encapsulation, configure the VPN Gateway or other network element to block or deny this communications protocol unencrypted L2TP packets across the security boundary and into the private network of the enclave. Not_Reviewed Vuln_Num V-207208 Rule_ID SV-207208r608988_rule Severity medium Rule_Title The VPN Gateway must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). Vuln_Discuss To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and any processes acting on behalf of users) must be uniquely identified and authenticated for all accesses except the following. (i) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and (ii) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals' in-group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN or proxy capability). This does not apply to authentication for the purpose of configuring the device itself (i.e., device management). Check_Content Verify the VPN Gateway is configured to uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). If the VPN Gateway does not uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users), this is a finding. Fix_Text Configure the VPN Gateway to uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). Not_Reviewed Vuln_Num V-207209 Rule_ID SV-207209r954210_rule Severity high Rule_Title The VPN Gateway must use multifactor authentication (e.g., DoD PKI) for network access to non-privileged accounts. Vuln_Discuss To assure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication uses two or more factors to achieve authentication. Use of password for user remote access for non-privileged account is not authorized. Factors include: (i) Something you know (e.g., password/PIN); (ii) Something you have (e.g., cryptographic identification device, token); or (iii) Something you are (e.g., biometric). A non-privileged account is any information system account with authorizations of a non-privileged user. Network access is any access to a network element by a user (or a process acting on behalf of a user) communicating through a network. The DoD CAC with DoD-approved PKI is an example of multifactor authentication. Check_Content Verify the VPN Gateway uses multifactor authentication (e.g., DoD PKI) for network access to non-privileged accounts. If the VPN Gateway does not use multifactor authentication (e.g., DoD PKI) for network access to non-privileged accounts, this is a finding. Fix_Text Configure the VPN Gateway to use multifactor authentication (e.g., DoD PKI) for network access to non-privileged accounts. Not_Reviewed Vuln_Num V-207210 Rule_ID SV-207210r984299_rule Severity medium Rule_Title The VPN Client must implement multifactor authentication for network access to nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access. Vuln_Discuss Using an authentication device, such as a common access card (CAC) or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DOD CAC. A nonprivileged account is any information system account with authorizations of a nonprivileged user. Network access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection. This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (i.e., device management). Check_Content Verify the VPN Client implements multifactor authentication for network access to nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access. If the VPN Client does not implement multifactor authentication for network access to nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access, this is a finding. Fix_Text Configure the VPN Client to implement multifactor authentication for network access to nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access. Not_Reviewed Vuln_Num V-207211 Rule_ID SV-207211r984302_rule Severity medium Rule_Title The TLS VPN must be configured to use replay-resistant authentication mechanisms for network access to nonprivileged accounts. Vuln_Discuss A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. A nonprivileged account is any operating system account with authorizations of a nonprivileged user. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators. This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (i.e., device management). Check_Content Verify the TLS VPN Gateway is configured to use replay-resistant authentication mechanisms for network access to nonprivileged accounts. If the TLS VPN is not configured to use replay-resistant authentication mechanisms for network access to nonprivileged accounts, this is a finding. Fix_Text Configure the TLS VPN Gateway to use replay-resistant authentication mechanisms for network access to nonprivileged accounts. Not_Reviewed Vuln_Num V-207212 Rule_ID SV-207212r984303_rule Severity medium Rule_Title The IPsec VPN Gateway must use anti-replay mechanisms for security associations. Vuln_Discuss Anti-replay is an IPsec security mechanism at a packet level, which helps to avoid unwanted users from intercepting and modifying an ESP packet. Check_Content Verify the IPsec VPN Gateway uses anti-replay mechanisms for security associations. If the IPsec VPN Gateway does not use anti-replay mechanisms for security associations, this is a finding. Fix_Text Configure the IPsec VPN Gateway to use anti-replay mechanisms for security associations. Not_Reviewed Vuln_Num V-207213 Rule_ID SV-207213r608988_rule Severity medium Rule_Title The VPN Gateway must uniquely identify all network-connected endpoint devices before establishing a connection. Vuln_Discuss Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions. This requirement applies to applications that connect either locally, remotely, or through a network to an endpoint device (including, but not limited to, workstations, printers, servers (outside a datacenter), VoIP Phones, and VTC CODECs). Gateways and SOA applications are examples of where this requirement would apply. Check_Content Verify the VPN Gateway uniquely identifies all network-connected endpoint devices before establishing a connection. If the VPN Gateway does not uniquely identify all network-connected endpoint devices before establishing a connection, this is a finding. Fix_Text Configure the VPN Gateway to uniquely identify all network-connected endpoint devices before establishing a connection. Not_Reviewed Vuln_Num V-207214 Rule_ID SV-207214r608988_rule Severity medium Rule_Title The VPN Gateway, when utilizing PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Vuln_Discuss Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. To meet this requirement, the information system must create trusted channels between itself and remote trusted authorized IT product (e.g., syslog server) entities that protect the confidentiality and integrity of communications. The information system must create trusted paths between itself and remote administrators and users that protect the confidentiality and integrity of communications. A trust anchor is an authoritative entity represented via a public key and associated data. It is most often used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. However, applications that do not use a trusted path are not approved for non-local and remote management of DoD information systems. Use of SSHv2 to establish a trusted channel is approved. Use of FTP, TELNET, HTTP, and SNMPV1 is not approved since they violate the trusted channel rule set. Use of web management tools that are not validated by common criteria may also violate the trusted channel rule set. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement. Check_Content Verify the VPN Gateway to use PKI-based authentication that validates certificates by constructing a certification path (which includes status information) to an accepted trust anchor. If PKI-based authentication does not validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor, this is a finding. Fix_Text Configure the VPN Gateway to use PKI-based authentication that validates certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Not_Reviewed Vuln_Num V-207215 Rule_ID SV-207215r608988_rule Severity medium Rule_Title The site-to-site VPN, when using PKI-based authentication for devices, must enforce authorized access to the corresponding private key. Vuln_Discuss If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to authenticate to network devices. Check_Content If PKI-based authentication is not being used for device authentication, this is not applicable. Verify the site-to-site VPN that uses certificate-based device authentication uses a FIPS-compliant key management process. If the site-to-site VPN that uses certificate-based device authentication does not use a FIPS-compliant key management process, this is a finding. Fix_Text Configure the site-to-site VPN that uses certificate-based device authentication to use a FIPS-compliant key management process. Not_Reviewed Vuln_Num V-207216 Rule_ID SV-207216r608988_rule Severity medium Rule_Title The Remote Access VPN Gateway must use a separate authentication server (e.g., LDAP, RADIUS, TACACS+) to perform user authentication. Vuln_Discuss The VPN interacts directly with public networks and devices and should not contain user authentication information for all users. AAA network security services provide the primary framework through which a network administrator can set up access control and authorization on network points of entry or network access servers. It is not advisable to configure access control on the VPN gateway or remote access server. Separation of services provides added assurance to the network if the access control server is compromised. Check_Content Verify the Remote Access VPN Gateway is configured to use a physically separate authentication server (e.g., LDAP, RADIUS, TACACS+) to perform user authentication. If the Remote Access VPN Gateway does not use a separate authentication server (e.g., LDAP, RADIUS, TACACS+) to perform user authentication, this is a finding. Fix_Text Configure the Remote Access VPN Gateway to use a separate authentication server (e.g., LDAP, RADIUS, TACACS+) to perform user authentication. Not_Reviewed Vuln_Num V-207217 Rule_ID SV-207217r608988_rule Severity medium Rule_Title The VPN Gateway must map the authenticated identity to the user account for PKI-based authentication. Vuln_Discuss Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. This requirement only applies to components where this is specific to the function of the device or has the concept of a user (e.g., VPN or ALG. This does not apply to authentication for the purpose of configuring the device itself (i.e., device management). Check_Content Verify the VPN Gateway maps the authenticated identity to the user account for PKI-based authentication. If the VPN Gateway does not map the authenticated identity to the user account for PKI-based authentication, this is a finding. Fix_Text Configure the VPN Gateway to map the authenticated identity to the user account for PKI-based authentication. Not_Reviewed Vuln_Num V-207218 Rule_ID SV-207218r803427_rule Severity medium Rule_Title The VPN Gateway must use FIPS-validated SHA-2 or higher hash function to protect the integrity of hash message authentication code (HMAC), Key Derivation Functions (KDFs), Random Bit Generation, hash-only applications, and digital signature verification. Vuln_Discuss Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Although allowed by SP800-131Ar2 for some applications, SHA-1 is considered a compromised hashing standard and is being phased out of use by industry and Government standards. Unless required for legacy use, DoD systems should not be configured to use SHA-2 for integrity of remote access sessions. Check_Content Verify the VPN Gateway uses FIPS-validated SHA-2 or higher. If the VPN Gateway does not use FIPS-validated SHA-2 or higher hash function to protect the integrity of hash message authentication code (HMAC), Key Derivation Functions (KDFs), Random Bit Generation, hash-only applications, and digital signature verification, this is a finding. Fix_Text Configure the VPN Gateway to use FIPS-validated SHA-2 or higher hash function to protect the integrity of hash message authentication code (HMAC), Key Derivation Functions (KDFs), Random Bit Generation, hash-only applications, and digital signature verification. Not_Reviewed Vuln_Num V-207219 Rule_ID SV-207219r608988_rule Severity medium Rule_Title The VPN Gateway must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users). Vuln_Discuss Lack of authentication and identification enables non-organizational users to gain access to the network or possibly a VPN gateway that provides opportunity for intruders to compromise resources within the network infrastructure. This requirement only applies to components where this is specific to the function of the device or has the concept of a non-organizational user. Check_Content Configure the VPN Gateway to uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users). If the VPN Gateway does not uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users), this is a finding. Fix_Text Configure the VPN Gateway to uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users). Not_Reviewed Vuln_Num V-207220 Rule_ID SV-207220r608988_rule Severity medium Rule_Title The VPN Gateway must be configured to route sessions to an IDPS for inspection. Vuln_Discuss Remote access devices, such as those providing remote access to network devices and information systems, which lack automated, capabilities increase risk and makes remote user access management difficult at best. Remote access is access to DoD non-public information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Automated monitoring of remote access sessions allows organizations to detect cyber attacks and ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities, from a variety of information system components (e.g., servers, workstations, notebook computers, smart phones, and tablets). Check_Content Verify the VPN Gateway routes sessions to an IDPS for inspection. If the VPN Gateway is not configured to route sessions to an IDPS for inspection, this is a finding. Fix_Text Configure the VPN Gateway to route sessions to an IDPS for inspection. Not_Reviewed Vuln_Num V-207221 Rule_ID SV-207221r971530_rule Severity low Rule_Title The VPN Gateway must terminate all network connections associated with a communications session at the end of the session. Vuln_Discuss Idle TCP sessions can be susceptible to unauthorized access and hijacking attacks. By default, routers do not continually test whether a previously connected TCP endpoint is still reachable. If one end of a TCP connection idles out or terminates abnormally, the opposite end of the connection may still believe the session is available. These “orphaned” sessions use up valuable router resources and can be hijacked by an attacker. To mitigate this risk, routers must be configured to send periodic keep alive messages to check that the remote end of a session is still connected. If the remote device fails to respond to the TCP keep alive message, the sending router will clear the connection and free resources allocated to the session. Check_Content Verify the VPN Gateway terminates all network connections associated with a communications session at the end of the session. If the VPN Gateway does not terminate all network connections associated with a communications session at the end of the session, this is a finding. Fix_Text Configure the VPN Gateway to terminate all network connections associated with a communications session at the end of the session. Not_Reviewed Vuln_Num V-207222 Rule_ID SV-207222r608988_rule Severity medium Rule_Title The VPN Gateway must use FIPS 140-2 compliant mechanisms for authentication to a cryptographic module. Vuln_Discuss Unapproved mechanisms that are used for authentication to the cryptographic module are not verified, and therefore cannot be relied upon to provide confidentiality or integrity and DoD data may be compromised. VPN gateways utilizing encryption are required to use FIPS compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. Check_Content Verify the VPN Gateway uses FIPS 140-2 compliant mechanisms for authentication to a cryptographic module. If the VPN Gateway does not use FIPS 140-2 compliant mechanisms for authentication to a cryptographic module, this is a finding. Fix_Text Configure the VPN Gateway to use FIPS 140-2 compliant mechanisms for authentication to a cryptographic module. Not_Reviewed Vuln_Num V-207223 Rule_ID SV-207223r916152_rule Severity high Rule_Title The IPSec VPN must be configured to use FIPS-validated SHA-2 at 384 bits or higher for Internet Key Exchange (IKE). Vuln_Discuss Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Although allowed by SP800-131Ar2 for some applications, SHA-1 is considered a compromised hashing standard and is being phased out of use by industry and government standards. Unless required for legacy use, DOD systems should not be configured to use SHA-2 for integrity of remote access sessions. This requirement is applicable to the configuration of IKE Phase 1 and Phase 2. Check_Content Verify the IPsec VPN Gateway uses IKE with SHA-2 at 384 bits or greater to protect the authenticity of communications sessions. If the IPsec VPN Gateway is not configured to use IKE with SHA-2 at 384 bits or greater to protect the authenticity of communications sessions, this is a finding. Fix_Text Configure the IPsec VPN Gateway to use IKE with SHA-2 at 384 bits or greater to protect the authenticity of communications sessions. Not_Reviewed Vuln_Num V-207224 Rule_ID SV-207224r608988_rule Severity medium Rule_Title The VPN Gateway must invalidate session identifiers upon user logoff or other session termination. Vuln_Discuss Captured sessions can be reused in "replay" attacks. This requirement limits the ability of adversaries from capturing and continuing to employ previously valid session IDs. Session IDs are tokens generated by web applications to uniquely identify an application user's session. Unique session identifiers or IDs are the opposite of sequentially generated session IDs, which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. When a user logs out, or when any other session termination event occurs, the VPN gateway must terminate the user session to minimize the potential for an attacker to hijack that particular user session. This requirement focuses on communications protection for the application session rather than for the network packet. This requirement applies only to any VPN gateway that is an intermediary of individual sessions (e.g., proxy, ALG, or SSL VPN). This requirement focuses on communications protection at the application session, versus network packet level. Check_Content Verify the VPN Gateway invalidates session identifiers upon user logoff or other session termination. If the VPN Gateway does not invalidate session identifiers upon user logoff or other session termination, this is a finding. Fix_Text Configure the VPN Gateway to invalidate session identifiers upon user logoff or other session termination. Not_Reviewed Vuln_Num V-207225 Rule_ID SV-207225r608988_rule Severity medium Rule_Title The VPN Gateway must recognize only system-generated session identifiers. Vuln_Discuss VPN gateways (depending on function) utilize sessions and session identifiers to control application behavior and user access. If an attacker can guess the session identifier, or can inject or manually insert session information, the valid user's application session can be compromised. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. This requirement focuses on communications protection for the application session rather than for the network packet. This requirement applies to any VPN gateway that is an intermediary of individual sessions (e.g., proxy, ALG, TLS VPN). VPN gateways that perform these functions must be able to identify which session identifiers were generated when the sessions were established. Check_Content Verify the VPN Gateway recognizes only system-generated session identifiers. If the VPN Gateway does not recognize only system-generated session identifiers, this is a finding. Fix_Text Configure the VPN Gateway to recognize only system-generated session identifiers. Not_Reviewed Vuln_Num V-207226 Rule_ID SV-207226r803431_rule Severity medium Rule_Title The VPN Gateway must generate unique session identifiers using FIPS-validated Random Number Generator (RNG) based on the Deterministic Random Bit Generators (DRBG) algorithm. Vuln_Discuss Both IPsec and TLS gateways use the RNG to strengthen the security of the protocols. Using a weak RNG will weaken the protocol and make it more vulnerable. Check_Content Verify the VPN Gateway generates unique session identifiers using FIPS-validated Random Number Generator (RNG) based on the Deterministic Random Bit Generators (DRBG) algorithm. If the VPN Gateway does not generate unique session identifiers using FIPS-validated Random Number Generator (RNG) based on the Deterministic Random Bit Generators (DRBG) algorithm, this is a finding. Fix_Text Configure the VPN Gateway to generate unique session identifiers using FIPS-validated Random Number Generator (RNG) based on the Deterministic Random Bit Generators (DRBG) algorithm. Not_Reviewed Vuln_Num V-207227 Rule_ID SV-207227r608988_rule Severity medium Rule_Title The VPN Gateway must fail to a secure state if system initialization fails, shutdown fails, or aborts fail. Vuln_Discuss Failure to a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. VPN gateways that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection capability. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption to mission-essential processes. Abort refers to stopping a program or function before it has finished naturally. The term abort refers to both requested and unexpected terminations. Check_Content Verify the VPN Gateway is configured to fail to a secure state if system initialization fails, shutdown fails, or aborts fail. If the VPN Gateway does not fail to a secure state if system initialization fails, shutdown fails, or aborts fail, this is a finding. Fix_Text Configure the VPN Gateway to fail to a secure state if system initialization fails, shutdown fails, or aborts fail. Not_Reviewed Vuln_Num V-207228 Rule_ID SV-207228r856701_rule Severity medium Rule_Title The VPN Gateway must be configured to perform an organization-defined action if the audit reveals unauthorized activity. Vuln_Discuss Remote access devices, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and makes remote user access management difficult at best. 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, for example, dial-up, broadband, and wireless. Remote access functionality, such as remote access servers, VPN concentrators, and IDS/IPS devices, must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smart phones, and tablets). Check_Content Verify the VPN Gateway is configured to perform an organization-defined action if the audit reveals unauthorized activity. If the VPN Gateway does not be configured to perform an organization-defined action if the audit reveals unauthorized activity, this is a finding. Fix_Text Configure the VPN Gateway to be configured to perform an organization-defined action if the audit reveals unauthorized activity. Not_Reviewed Vuln_Num V-207229 Rule_ID SV-207229r856702_rule Severity medium Rule_Title The VPN Gateway administrator accounts or security policy must be configured to allow the system administrator to immediately disconnect or disable remote access to devices and/or users when needed. Vuln_Discuss Without the ability to immediately disconnect or disable remote access, an attack or other compromise taking progress would not be immediately stopped. Remote access functionality must have the capability to immediately disconnect current users remotely accessing the information system and/or disable further remote access. The speed of disconnect or disablement varies based on the criticality of mission functions and the need to eliminate immediate or future remote access to organizational information systems. The remote access functionality (e.g., VPN, ALG, and RAS) may implement features, such as automatic disconnect (or user-initiated disconnect) in case of adverse information based on an indicator of compromise or attack. Check_Content Configure the VPN Gateway for functionality, such as automatic disconnect (or user-initiated disconnect) in case of adverse information based on an indicator of compromise or attack. Configure authorized system administrator accounts to allow them to disconnect or disable remote access to remove user under circumstances defined in the VPN SSP. If the VPN Gateway administrator accounts or security policy is not configured to allow the system administrator to immediately disconnect or disable remote access to devices and/or users when needed, this is a finding. Fix_Text Configure the VPN Gateway for functionality, such as automatic disconnect (or user-initiated disconnect) in case of adverse information based on an indicator of compromise or attack. Configure authorized system administrator accounts to allow them to disconnect or disable remote access to remove user under circumstances defined in the VPN SSP. Not_Reviewed Vuln_Num V-207230 Rule_ID SV-207230r987747_rule Severity high Rule_Title The IPsec VPN Gateway must use AES encryption for the Internet Key Exchange (IKE) proposal to protect confidentiality of remote access sessions. Vuln_Discuss Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD non-public information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. AES is the FIPS-validated cipher block cryptographic algorithm approved for use in DoD. For an algorithm implementation to be listed on a FIPS 140-2 cryptographic module validation certificate as an approved security function, the algorithm implementation must meet all the requirements of FIPS 140-2 and must successfully complete the cryptographic algorithm validation process. Currently, NIST has approved the following confidentiality modes to be used with approved block ciphers in a series of special publications: ECB, CBC, OFB, CFB, CTR, XTS-AES, FF1, FF3, CCM, GCM, KW, KWP, and TKW. Check_Content Verify all IKE proposals are set to use the AES encryption algorithm. View the value of the encryption algorithm for each defined proposal. If the value of the encryption algorithm for any IKE proposal is not set to use an AES algorithm, this is a finding. Fix_Text Configure the IPsec Gateway to use AES with IKE. The option on the IKE Phase 1 proposal may also be configured to use the aes-128-cbc, aes-192-cbc, or aes-256-cbc algorithms. Not_Reviewed Vuln_Num V-207234 Rule_ID SV-207234r856706_rule Severity medium Rule_Title The VPN Gateway must off-load audit records onto a different system or media than the system being audited. Vuln_Discuss Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. This requirement only applies to components where this is specific to the function of the device (e.g., IDPS sensor logs, firewall logs). This does not apply to audit logs generated on behalf of the device itself (management). Check_Content Verify the VPN Gateway off-loads log records onto a different system or media than the system being audited. If the VPN Gateway does not off-load audit records onto a different system or media than the system being audited, this is a finding. Fix_Text Configure the VPN Gateway to off-load audit records onto a different system or media than the system being audited. Not_Reviewed Vuln_Num V-207235 Rule_ID SV-207235r878129_rule Severity medium Rule_Title The VPN Gateway must generate a log record or an SNMP trap that can be forwarded as an alert to, at a minimum, the SCA and ISSO, of all log failure events where the detection and/or prevention function is unable to write events to either local storage or the centralized server. Vuln_Discuss It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Alerts provide organizations with urgent messages. Automated alerts can be conveyed in a variety of ways, including, for example, telephonically, via electronic mail, via text message, or via websites. Log processing failures include software/hardware errors, failures in the log capturing mechanisms, and log storage capacity being reached or exceeded. While this requirement also applies to the event monitoring system (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers), the VPN Gateway must also be configured to generate a message to the administrator console. The VPN daemon facility and log facility are messages in the log, which capture actions performed or errors encountered by system processes. Check_Content Verify the VPN Gateway generates a log record or an SNMP trap that can be forwarded as an alert to, at a minimum, the SCA and ISSO, of all log failure events where the detection and/or prevention function is unable to write events to either local storage or the centralized server. If the VPN Gateway does not generate a log record or an SNMP trap that can be forwarded as an alert to, at a minimum, the SCA and ISSO, of all log failure events where the detection and/or prevention function is unable to write events to either local storage or the centralized server, this is a finding. Fix_Text Configure the VPN Gateway to generate a log record or an SNMP trap that can be forwarded as an alert to, at a minimum, the SCA and ISSO, of all log failure events where the detection and/or prevention function is unable to write events to either local storage or the centralized server. Not_Reviewed Vuln_Num V-207237 Rule_ID SV-207237r987783_rule Severity medium Rule_Title The VPN Gateway must renegotiate the IPsec security association (SA) after eight hours or less. Vuln_Discuss The IPsec SA and its corresponding key will expire either after the number of seconds or amount of traffic volume has exceeded the configured limit. A new SA is negotiated before the lifetime threshold of the existing SA is reached to ensure that a new SA is ready for use when the old one expires. The longer the lifetime of the IPsec SA, the longer the lifetime of the session key used to protect IP traffic. The SA is less secure with a longer lifetime because an attacker has a greater opportunity to collect traffic encrypted by the same key and subject it to cryptanalysis. However, a shorter lifetime causes IPsec peers to renegotiate Phase II more often, resulting in the expenditure of additional resources. Check_Content Verify the VPN Gateway renegotiates the IPsec security association after eight hours or less. Fix_Text Configure the VPN Gateway to renegotiate the IPsec security association after eight hours or less. Not_Reviewed Vuln_Num V-207238 Rule_ID SV-207238r987783_rule Severity medium Rule_Title The VPN Gateway must renegotiate the IKE security association (SA) after eight hours or less. Vuln_Discuss When a VPN gateway creates an IPsec SA, resources must be allocated to maintain the SA. These resources are wasted during periods of IPsec endpoint inactivity, which could result in the gateway’s inability to create new SAs for other endpoints, thereby preventing new sessions from connecting. The Internet Key Exchange (IKE) idle timeout may also be set to allow SAs associated with inactive endpoints to be deleted before the SA lifetime has expired, although this setting is not recommended. Check_Content Verify the VPN Gateway renegotiates the IKE security association after eight hours or less. If the VPN Gateway does not renegotiate the IKE security association after eight hours or less, this is a finding. Fix_Text Configure the VPN Gateway to renegotiate the IKE security association after eight hours or less. Not_Reviewed Vuln_Num V-207239 Rule_ID SV-207239r856712_rule Severity medium Rule_Title The VPN Gateway must accept the Common Access Card (CAC) credential. Vuln_Discuss The use of Personal Identity Verification (PIV) credentials facilitates standardization and reduces the risk of unauthorized access. DoD has mandated the use of the CAC as the PIV credential to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems. Check_Content Verify the VPN Gateway accepts PIV credentials. If the VPN Gateway does not accept the CAC credential, this is a finding. Fix_Text Configure the VPN Gateway to accept the CAC credential. Not_Reviewed Vuln_Num V-207240 Rule_ID SV-207240r856714_rule Severity medium Rule_Title The VPN Gateway must electronically verify the Common Access Card (CAC) credential. Vuln_Discuss DoD has mandated the use of the CAC as the Personal Identity Verification (PIV) credential to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems. Check_Content Verify the VPN Gateway electronically verifies the CAC credential. If the VPN Gateway does not electronically verify Personal Identity Verification (PIV) credentials, this is a finding. Fix_Text Configure the VPN Gateway to electronically verify the CAC credential. Not_Reviewed Vuln_Num V-207241 Rule_ID SV-207241r856715_rule Severity medium Rule_Title The VPN Gateway must authenticate all network-connected endpoint devices before establishing a connection. Vuln_Discuss Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of authentication claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide authentication decisions (as opposed to the actual authenticators) to the services that need to act on those decisions. This requirement applies to applications that connect either locally, remotely, or through a network to an endpoint device (including, but not limited to, workstations, printers, servers (outside a datacenter), VoIP Phones, and VTC CODECs). Gateways and SOA applications are examples of where this requirement would apply. Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices can access the system. Check_Content Verity the VPN Gateway authenticates all network-connected endpoint devices before establishing a connection. If the VPN Gateway does not authenticate all network-connected endpoint devices before establishing a connection, this is a finding. Fix_Text Configure the VPN Gateway to authenticate all network-connected endpoint devices before establishing a connection. Not_Reviewed Vuln_Num V-207242 Rule_ID SV-207242r1138028_rule Severity medium Rule_Title The VPN Gateway must use an approved Commercial Solution for Classified (CSfC) when transporting classified traffic across an unclassified network. Vuln_Discuss Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. The National Security Agency/Central Security Service's (NSA/CSS) CSfC Program enables commercial products to be used in layered solutions to protect classified National Security Systems (NSS) data. Currently, Suite B cryptographic algorithms are specified by NIST and are used by NSA's Information Assurance Directorate in solutions approved for protecting classified and unclassified NSS. However, quantum resistant algorithms will be required for future required Suite B implementations. This requirement also applies to Zero Trust initiatives. Check_Content Verify the VPN Gateway uses an approved CSfC when transporting classified traffic across an unclassified network. If the VPN Gateway does not use an approved CSfC when transporting classified traffic across an unclassified network, this is a finding. Fix_Text Configure the VPN Gateway to use an approved CSfC when transporting classified traffic across an unclassified network. Not_Reviewed Vuln_Num V-207243 Rule_ID SV-207243r1005432_rule Severity medium Rule_Title The VPN Gateway must disable split-tunneling for remote clients VPNs. Vuln_Discuss Split tunneling would in effect allow unauthorized external connections, making the system more vulnerable to attack and to exfiltration of organizational information. A VPN hardware or software client with split tunneling enabled provides an unsecured backdoor to the enclave from the Internet. With split tunneling enabled, a remote client has access to the Internet while at the same time has established a secured path to the enclave via an IPsec tunnel. A remote client connected to the Internet that has been compromised by an attacker in the Internet, provides an attack base to the enclave’s private network via the IPsec tunnel. Hence, it is imperative that the VPN gateway enforces a no split-tunneling policy to all remote clients. Check_Content Verify the VPN Gateway disables split-tunneling for remote clients VPNs. If the VPN Gateway does not disable split-tunneling for remote clients VPNs, this is a finding. Note: Certain cloud products require direct connectivity to operate correctly. These items may be excluded from the split tunneling restriction if documented and approved. If split-tunneling for remote client VPNs is enabled by the above exception, verify only authorized external destinations are excluded from tunneling as shown in the example below: Webvpn anyconnect-custom-attr dynamic-split-exclude-domains description DoD IL5 Authorized Destinations anyconnect-custom-data dynamic-split-exclude-domains DoD-IL5 dod.teams.microsoft.us,azureedge.net,core.usgovcloudapi.net,streaming.media.usgovcloudapi.net,wvd.azure.us,cdn.office365.us anyconnect-custom dynamic-split-exclude-domains value DoD-IL5 If any unauthorized exempted connections exist, this is a finding. Fix_Text Configure the VPN Gateway to disable split-tunneling for remote clients VPNs. Not_Reviewed Vuln_Num V-207244 Rule_ID SV-207244r916233_rule Severity high Rule_Title The IPsec VPN Gateway must specify Perfect Forward Secrecy (PFS) during Internet Key Exchange (IKE) negotiation. Vuln_Discuss PFS generates each new encryption key independently from the previous key. Without PFS, compromise of one key will compromise all communications. The phase 2 (Quick Mode) Security Association (SA) is used to create an IPsec session key. Hence, its rekey or key regeneration procedure is very important. The phase 2 rekey can be performed with or without PFS. With PFS, every time a new IPsec Security Association is negotiated during the Quick Mode, a new Diffie-Hellman (DH) exchange occurs. The new DH shared secret will be included with original keying material (SYKEID_d, initiator nonce, and responder nonce) from phase 1 for generating a new IPsec session key. If PFS is not used, the IPsec session key will always be completely dependent on the original keying material from the Phase-1. Hence, if an older key is compromised at any time, it is possible that all new keys may be compromised. The DH exchange is performed in the same manner as was done in phase 1 (Main or Aggressive Mode). However, the phase 2 exchange is protected by encrypting the phase 2 packets with the key derived from the phase 1 negotiation. Because DH negotiations during phase 2 are encrypted, the new IPsec session key has an added element of secrecy. Check_Content Verify the IPsec VPN Gateway specifies PFS during IKE negotiation. If the IPsec VPN Gateway does not specify PFS during IKE negotiation, this is a finding. Fix_Text Configure the IPsec VPN Gateway to specify PFS during IKE negotiation. Not_Reviewed Vuln_Num V-207245 Rule_ID SV-207245r856719_rule Severity high Rule_Title The VPN Gateway and Client must be configured to protect the confidentiality and integrity of transmitted information. Vuln_Discuss Without protection of the transmitted information, confidentiality and integrity may be compromised as unprotected communications can be intercepted and either read or altered. This requirement also applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. For example, configure all ISAKMP policies to use AES for Internet Key Exchange (IKE) cryptographic encryption operations and SHA-2 to protect data integrity. Check_Content Verify the VPN Gateway and the remote access client are configured to protect the confidentiality and integrity of transmitted information. If VPN Gateway and Client does not protect the confidentiality and integrity of transmitted information, this is a finding. Fix_Text Configure the VPN Gateway and the remote access client to protect the confidentiality and integrity of transmitted information. Not_Reviewed Vuln_Num V-207247 Rule_ID SV-207247r916235_rule Severity medium Rule_Title For accounts using password authentication, the site-to-site VPN Gateway must use SHA-2 or later protocol to protect the integrity of the password authentication process. Vuln_Discuss Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Use of passwords for authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Although allowed by SP800-131Ar2 for some applications, SHA-1 is considered a compromised hashing standard and is being phased out of use by industry and Government standards. Unless required for legacy use, DoD systems should not be configured to use SHA-2 for integrity of remote access sessions. The information system must specify the hash algorithm used for authenticating passwords. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. Pre-shared key cipher suites may only be used in networks where both the client and server belong to the same organization. Cipher suites using pre-shared keys shall not be used with TLS 1.0 or 1.1 and shall not be used with TLS 1.2 when a Government client or server communicates with non-government systems. Check_Content For accounts using password authentication, verify the VPN Gateway uses SHA-2 or later protocol to protect the integrity of the password authentication process. For accounts using password authentication, if the VPN Gateway does not use SHA-2 or later protocol to protect the integrity of the password authentication process, this is a finding. Fix_Text For accounts using password authentication, configure the VPN Gateway to use SHA-2 or later protocol to protect the integrity of the password authentication process. Not_Reviewed Vuln_Num V-207248 Rule_ID SV-207248r608988_rule Severity medium Rule_Title The VPN Gateway must generate log records when successful and/or unsuccessful VPN connection attempts occur. Vuln_Discuss Without generating log records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Log records can be generated from various components within the information system (e.g., module or policy filter). This requirement only applies to components where this is specific to the function of the device, such as application layer gateway (ALG), which provides these access control and auditing functions on behalf of an application. This does not apply to audit logs generated on behalf of the device itself (management). Check_Content Verify the VPN Gateway generates log records when successful and/or unsuccessful VPN connection attempts occur. If the VPN Gateway does not generate log records when successful and/or unsuccessful VPN connection attempts occur, this is a finding. Fix_Text Configure the VPN Gateway to generate log records when successful and/or unsuccessful VPN connection attempts occur. Not_Reviewed Vuln_Num V-207249 Rule_ID SV-207249r1138029_rule Severity medium Rule_Title The VPN Gateway must use a FIPS-validated cryptographic module to generate cryptographic hashes. Vuln_Discuss FIPS 140-2/FIPS 140-3 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plain text. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2/FIPS 140-3 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2/FIPS 140-3 standard. The cryptographic module used must have at least one validated hash algorithm. This validated hash algorithm must be used to generate cryptographic hashes for all cryptographic security function within the product being evaluated. This requirement also applies to Zero Trust initiatives. Check_Content Verify the VPN Gateway uses a FIPS-validated cryptographic module to generate cryptographic hashes. If the VPN Gateway does not use a FIPS-validated cryptographic module to generate cryptographic hashes, this is a finding. Fix_Text Configure the VPN Gateway to use a FIPS-validated cryptographic module to generate cryptographic hashes. Not_Reviewed Vuln_Num V-207250 Rule_ID SV-207250r1138030_rule Severity medium Rule_Title The VPN Gateway must use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality. Vuln_Discuss FIPS 140-2/FIPS 140-3 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plain text. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2/FIPS 140-3 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2/FIPS 140-3 standard. The cryptographic module used must have one FIPS-validated encryption algorithm (i.e., validated Advanced Encryption Standard [AES]). This validated algorithm must be used for encryption for cryptographic security function within the product being evaluated. This requirement also applies to Zero Trust initiatives. Check_Content Verify the VPN Gateway uses a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality. If the VPN Gateway does not use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality, this is a finding. Fix_Text Configure the VPN Gateway to use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality. Not_Reviewed Vuln_Num V-207251 Rule_ID SV-207251r1138031_rule Severity medium Rule_Title The IPsec VPN Gateway IKE must use NIST FIPS-validated cryptography to implement encryption services for unclassified VPN traffic. Vuln_Discuss Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The VPN gateway must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. This requirement also applies to Zero Trust initiatives. Check_Content Verify the IPsec VPN Gateway IKE uses a NIST FIPS-validated cryptography to implement encryption services for unclassified VPN traffic. If the IPsec VPN Gateway IKE does not use NIST FIPS-validated cryptography to implement encryption services for unclassified VPN traffic, this is a finding. Fix_Text Configure the IPsec VPN Gateway IKE to use NIST FIPS-validated cryptography to implement encryption services for unclassified VPN traffic. Not_Reviewed Vuln_Num V-207252 Rule_ID SV-207252r608988_rule Severity high Rule_Title The IPsec VPN Gateway must use Internet Key Exchange (IKE) for IPsec VPN Security Associations (SAs). Vuln_Discuss Without IKE, the SPI is manually specified for each security association. IKE peers will negotiate the encryption algorithm and authentication or hashing methods as well as generate the encryption keys. An IPsec SA is established using either Internet Key Exchange (IKE) or manual configuration. When using IKE, the security associations are established when needed and expire after a period of time or volume of traffic threshold. If manually configured, they are established as soon as the configuration is complete at both end points and they do not expire. When using IKE, the Security Parameter Index (SPI) for each security association is a pseudo-randomly derived number. With manual configuration of the IPsec security association, both the cipher key and authentication key are static. Hence, if the keys are compromised, the traffic being protected by the current IPsec tunnel can be decrypted as well as traffic in any future tunnels established by this SA. Furthermore, the peers are not authenticated prior to establishing the SA, which could result in a rogue device establishing an IPsec SA with either of the VPN end points. IKE provides primary authentication to verify the identity of the remote system before negotiation begins. This feature is lost when the IPsec security associations are manually configured, which results in a non-terminating session using static pre-shared keys. Check_Content Verify the IKE protocol is specified for all IPsec VPNs. If the IKE protocol is not specified as an option on all VPN gateways, this is a finding. Fix_Text Configure the IPsec VPN Gateway to use IKE and IPsec VPN SAs. Not_Reviewed Vuln_Num V-207254 Rule_ID SV-207254r856725_rule Severity medium Rule_Title The VPN Client logout function must be configured to terminate the session on/with the VPN Gateway. Vuln_Discuss If a user cannot explicitly end a session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. However, for some types of interactive sessions including, for example, remote login, information systems typically send logout messages as final messages prior to terminating sessions. This applies to VPN gateways that have the concept of a user account and have the login function residing on the VPN gateway. Check_Content Verify the VPN Client logout function is configured to terminate the session on/with the VPN Gateway. If the VPN Client logout function does not terminate the session on/with the VPN Gateway, this is a finding. Fix_Text Configure the VPN Client logout log out function must be configured to terminate the session on/with the VPN Gateway. Not_Reviewed Vuln_Num V-207255 Rule_ID SV-207255r856726_rule Severity medium Rule_Title The VPN Client must display an explicit logout message to users indicating the reliable termination of authenticated communications sessions. Vuln_Discuss If a user cannot explicitly end a session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Users need to be aware of whether or not the session has been terminated. Logout messages for access, for example, can be displayed after authenticated sessions have been terminated. However, for some types of interactive sessions including, for example, remote login, information systems typically send logout messages as final messages prior to terminating sessions. This applies to VPN gateways that have the concept of a user account and have the login function residing on the VPN gateway. Check_Content Verify the VPN Client displays an explicit logout message to users indicating the reliable termination of authenticated communications sessions. If the VPN Client does not display an explicit logout message to users indicating the reliable termination of authenticated communications sessions, this is a finding. Fix_Text Configure the VPN Client to display an explicit logout message to users indicating the reliable termination of authenticated communications sessions. Not_Reviewed Vuln_Num V-207256 Rule_ID SV-207256r984307_rule Severity medium Rule_Title For site-to-site, VPN Gateway must be configured to store only cryptographic representations of pre-shared Keys (PSKs). Vuln_Discuss PSKs need to be protected at all times, and encryption is the standard method for protecting passwords. If PSKs are not encrypted, they can be plainly read and easily compromised. Use of passwords for authentication is intended only for limited situations and must not be used as a replacement for two-factor CAC-enabled authentication. NIST SP 800-52 Rev 2 provides guidance for using pre-shared keys with VPN gateways. PSKs may only be used in networks where both the client and server belong to the same organization. PSKs used for site-to-site VPNs are considered by the SRG as a type of password. If this shared secret is already encrypted and not in plaintext, this meets this requirement. This requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. This method uses a one-way hashing encryption algorithm with a salt value to validate a user's password without having to store the actual password. Performance and time required to access are factors that must be considered, and the one-way hash is the most feasible means of securing the password and providing an acceptable measure of password security. Use a keyed hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key. Check_Content Verify the VPN Gateway stores only cryptographic representations of the PSK. If the VPN Gateway does not store only cryptographic representations of the PSK, this is a finding. Fix_Text Configure the VPN Gateway to store only cryptographic representations of the PSK. Not_Reviewed Vuln_Num V-207257 Rule_ID SV-207257r916158_rule Severity high Rule_Title The IPsec VPN must use AES256 or greater encryption for the IPsec proposal to protect the confidentiality of remote access sessions. Vuln_Discuss 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. A block cipher mode is an algorithm that features the use of a symmetric key block cipher algorithm to provide an information service, such as confidentiality or authentication. AES is the FIPS-validated cipher block cryptographic algorithm approved for use in DOD. For an algorithm implementation to be listed on a FIPS 140-2/140-3 cryptographic module validation certificate as an approved security function, the algorithm implementation must meet all the requirements of FIPS 140-2/140-3 and must successfully complete the cryptographic algorithm validation process. Currently, NIST has approved the following confidentiality modes to be used with approved block ciphers in a series of special publications: ECB, CBC, OFB, CFB, CTR, XTS-AES, FF1, FF3, CCM, GCM, KW, KWP, and TKW. Check_Content Verify all Internet Key Exchange (IKE) proposals are set to use the AES256 or greater encryption algorithm. View the value of the encryption algorithm for each defined proposal. If the value of the encryption algorithm for any IPsec proposal is not set to use an AES256 or greater algorithm, this is a finding. Fix_Text Configure the IPsec Gateway to use AES256 or greater for the IPsec proposal. Not_Reviewed Vuln_Num V-207258 Rule_ID SV-207258r608988_rule Severity medium Rule_Title The TLS VPN Gateway that supports Government-only services must prohibit client negotiation to TLS 1.1, TLS 1.0, SSL 2.0, or SSL 3.0. Vuln_Discuss Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. This requirement applies to TLS gateways (also known as SSL gateways), web servers, and web applications. Application protocols such as HTTPS and DNSSEC use TLS as the underlying security protocol and thus are in scope for this requirement. NIST SP 800-52 provides guidance for client negotiation on either DoD-only or public-facing servers. Check_Content Verify the TLS VPN Gateway that supports Government-only services prohibits client negotiation to TLS 1.1, TLS 1.0, SSL 2.0, or SSL 3.0. If the TLS VPN Gateway that supports Government-only services does not prohibit client negotiation to TLS 1.1, TLS 1.0, SSL 2.0, or SSL 3.0, this is a finding. Fix_Text Configure the TLS VPN Gateway that supports Government-only services to prohibit client negotiation to TLS 1.1, TLS 1.0, SSL 2.0, or SSL 3.0. Not_Reviewed Vuln_Num V-207259 Rule_ID SV-207259r608988_rule Severity medium Rule_Title The TLS VPN Gateway that supports citizen- or business-facing network devices must prohibit client negotiation to SSL 2.0 or SSL 3.0. Vuln_Discuss Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. This requirement applies to public-facing or external-facing devices such as TLS gateways (also known as SSL gateways), web servers, and web applications. Application protocols such as HTTPS and DNSSEC use TLS as the underlying security protocol and thus are in scope for this requirement. NIST SP 800-52 provides guidance. The minimum TLS version required by DoD is 1.2. However, devices and applications may allow client negotiation for systems supporting citizen- and business-facing applications. These devices may be configured to support TLS version 1.1 and 1.0 to enable interaction with citizens and businesses. These devices must not support SSL version 3.0 or earlier. Check_Content Verify the TLS VPN Gateway that supports citizen- or business-facing network devices prohibits client negotiation to SSL 2.0 or SSL 3.0. If the TLS VPN Gateway that supports citizen- or business-facing network devices does not prohibit client negotiation to SSL 2.0 or SSL 3.0, this is a finding. Fix_Text Configure the TLS VPN Gateway that supports citizen- or business-facing network devices to prohibit client negotiation to SSL 2.0 or SSL 3.0. Not_Reviewed Vuln_Num V-207260 Rule_ID SV-207260r878130_rule Severity medium Rule_Title The VPN Gateway that provides a Simple Network Management Protocol (SNMP) Network Management System (NMS) must configure SNMPv3 to use FIPS-validated AES cipher block algorithm. Vuln_Discuss Without device-to-device authentication, communications with malicious devices may be established. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. SNMPv3 supports authentication, authorization, access control, and privacy, while previous versions of the protocol contained well-known security weaknesses, which were easily exploited. SNMPv3 can be configured for identification and bidirectional, cryptographically based authentication. A typical SNMP implementation includes three components: managed device, SNMP agent, and NMS. The SNMP agent is the SNMP process that resides on the managed device and communicates with the network management system. The NMS is a combination of hardware and software that is used to monitor and administer a network. The SNMP data is stored in a highly structured, hierarchical format known as a management information base (MIB). The SNMP manager collects information about network connectivity, activity, and events by polling managed devices. SNMPv3 defines a user-based security model (USM), and a view-based access control model (VACM). SNMPv3 USM provides data integrity, data origin authentication, message replay protection, and protection against disclosure of the message payload. SNMPv3 VACM provides access control to determine whether a specific type of access (read or write) to the management information is allowed. Implement both VACM and USM for full protection. SNMPv3 server services must not be configured on products whose primary purpose is not to provide SNMP services. SNMP client services may be configured on the VPN gateway, application, or operating system to allow limited monitoring or querying of the device from by an SNMP server for management purposes. SNMP of any version will not be used to make configuration changes to the device. SNMPv3 must be disabled by default and enabled only if used. SNMP v3 provides security feature enhancements to SNMP, including encryption and message authentication. Currently, the AES cipher block algorithm can be used for both applying cryptographic protection (e.g., encryption) and removing or verifying the protection that was previously applied (e.g., decryption) in DoD. The use of FIPS-approved algorithms for both cryptographic mechanisms is required. If any version of SNMP is used for remote administration, default SNMP community strings such as "public" and "private" should be removed before real community strings are put into place. If the defaults are not removed, an attacker could retrieve real community strings from the device using the default string. Check_Content Verify the VPN Gateway that provides a SNMP NMS is configured to use SNMPv3 to use FIPS-validated AES cipher block algorithm. If the VPN Gateway that provides a SNMP NMS does not configure SNMPv3 to use FIPS-validated AES cipher block algorithm, this is a finding. Fix_Text For the VPN Gateway that provides a SNMP NMS, configure SNMPv3 to use FIPS-validated AES cipher block algorithm. Not_Reviewed Vuln_Num V-207261 Rule_ID SV-207261r1138034_rule Severity high Rule_Title The VPN remote access server must be configured use cryptographic algorithms approved by NSA to protect NSS for remote access to a classified network. Vuln_Discuss Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The VPN gateway must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. NIST cryptographic algorithms approved by NSA to protect NSS. Based on an analysis of the impact of quantum computing, cryptographic algorithms specified by CNSSP-15 and approved for use in products in the CSfC program, the approved algorithms have been changed to more stringent protocols configure with increased bit sizes and other secure characteristics to protect against quantum computing threats. The Commercial National Security Algorithm Suite (CNSA Suite) replaces Suite B. This requirement also applies to Zero Trust initiatives. Check_Content Verify the VPN gateway is configured to use cryptography compliant with NSA/CSS parameters to protect NSS for remote access to a classified network. If the VPN gateway is not configured to use cryptography compliant with NSA/CSS parameters to protect NSS for remote access to a classified network, this is a finding. Fix_Text Configure the IPsec VPN Gateway to use cryptography compliant with NSA/CSS parameters to protect NSS for remote access to a classified network. Not_Reviewed Vuln_Num V-207262 Rule_ID SV-207262r1138037_rule Severity high Rule_Title The VPN gateway must use cryptographic algorithms approved by NSA to protect NSS when transporting classified traffic across an unclassified network. Vuln_Discuss Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The VPN gateway must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. NIST cryptographic algorithms approved by NSA to protect NSS. Based on an analysis of the impact of quantum computing, cryptographic algorithms specified by CNSSP-15 and approved for use in products in the Commercial Solution for Classified (CSfC) program, the approved algorithms have been changed to more stringent protocols configure with increased bit sizes and other secure characteristics to protect against quantum computing threats. The Commercial National Security Algorithm Suite (CNSA Suite) replaces Suite B. This requirement also applies to Zero Trust initiatives. Check_Content Verify the VPN gateway Internet Key Exchange (IKE) Phase 1 and Phase 2 are configured to use cryptography compliant with NSA/CSS parameters when transporting classified traffic across an unclassified network. If the VPN gateway is not configured to use cryptography compliant with NSA/CSS parameters when transporting classified traffic across an unclassified network, this is a finding. Fix_Text Configure the IPsec VPN Gateway IKE to use cryptography compliant with NSA/CSS parameters when transporting classified traffic across an unclassified network. Not_Reviewed Vuln_Num V-207263 Rule_ID SV-207263r608988_rule Severity medium Rule_Title The VPN Gateway must validate certificates used for Transport Layer Security (TLS) functions by performing RFC 5280-compliant certification path validation. Vuln_Discuss 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. Check_Content Verify the VPN Gateway validates TLS certificates by performing RFC 5280-compliant certification path validation. If the VPN Gateway does not validate certificates used for TLS functions by performing RFC 5280-compliant certification path validation, this is a finding. Fix_Text Configure the VPN Gateway to validate certificates used for TLS functions by performing RFC 5280-compliant certification path validation. Not_Reviewed Vuln_Num V-251044 Rule_ID SV-251044r971530_rule Severity medium Rule_Title The Remote Access VPN Gateway must terminate remote access network connections after an organization-defined time period. Vuln_Discuss This SRG requirement is in response to the DoD OIG Audit of Maintaining Cybersecurity in the Coronavirus Disease-2019 Telework Environment. Best practice is to terminate inactive user sessions after a period; however, when setting timeouts to any VPN connection, the organization must take into consideration the risk to the mission and the purpose of the VPN. VPN connections that provide user access to the network are the prime candidates for VPN session termination and are the primary focus of this requirement. To determine if and when the VPN connections warrant termination, the organization must perform a risk assessment to identify the use case for the VPN and determine if periodic VPN session termination puts the mission at significant risk. The organization must document the results and the determination of the risk assessment in the VPN section of the SSP. The organization must also configure VPN session terminations in accordance with the risk assessment. Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, and de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system level network connection. This requirement applies to any network element that tracks individual sessions (e.g., stateful inspection firewall, ALG, or VPN). Check_Content This SRG requirement is in response to the DoD OIG Audit of Maintaining Cybersecurity in the Coronavirus Disease-2019 Telework Environment. VPN connections that provide user access to the network are the prime candidates for VPN session termination and are the primary focus of this requirement. Review the system security plan. Verify the VPN gateway session termination is configured in accordance with the value specified in the SSP. If a risk assessment has not been conducted and an organization-defined session termination period is not addressed/documented in the SSP, this is a finding. If the VPN gateway is not configured to terminate all remote access network connections in accordance with the values defined in the SSP, this is a finding. Fix_Text This SRG requirement is in response to the DoD OIG Audit of Maintaining Cybersecurity in the Coronavirus Disease-2019 Telework Environment. VPN connections that provide user access to the network are the prime candidates for VPN session termination and are the primary focus of this requirement. Conduct a risk assessment to identify the use case for the VPN and determine if periodic VPN session termination puts the mission at risk of failure. Identify the organizations' VPN session termination periodic value based on the risk assessment. Add the results of the risk assessment and the session termination values to the site's SSP documents. Configure the VPN gateway to periodically terminate all remote network connections in accordance with the values defined in the SSP. Not_Reviewed Vuln_Num V-264328 Rule_ID SV-264328r984313_rule Severity medium Rule_Title The VPN Gateway must employ organization-defined controls by type of denial of service (DoS) to achieve the DoS objective. Vuln_Discuss DoS events may occur due to a variety of internal and external causes, such as an attack by an adversary or a lack of planning to support organizational needs with respect to capacity and bandwidth. Such attacks can occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of technologies are available to limit or eliminate the origination and effects of DoS events. For example, boundary protection devices can filter certain types of packets to protect system components on internal networks from being directly affected by or the source of DoS attacks. Employing increased network capacity and bandwidth combined with service redundancy also reduces the susceptibility to DoS events. Check_Content Verify the VPN Gateway is configured to employ organization-defined controls by type of DoS to achieve the DoS objective. If the VPN Gateway is not configured to employ organization-defined controls by type of DoS to achieve the DoS objective, this is a finding. Fix_Text Configure the VPN Gateway to employ organization-defined controls by type of DoS to achieve the DoS objective. Not_Reviewed Vuln_Num V-264329 Rule_ID SV-264329r1138038_rule Severity medium Rule_Title The VPN Gateway must implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions. Vuln_Discuss Separating critical system components and functions from other noncritical system components and functions through separate subnetworks may be necessary to reduce susceptibility to a catastrophic or debilitating breach or compromise that results in system failure. For example, physically separating the command and control function from the in-flight entertainment function through separate subnetworks in a commercial aircraft provides an increased level of assurance in the trustworthiness of critical system functions. This requirement also applies to Zero Trust initiatives. Check_Content Verify the VPN Gateway is configured to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions. If the VPN Gateway is not configured to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions, this is a finding. Fix_Text Configure the VPN Gateway to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions. Not_Reviewed Vuln_Num V-264330 Rule_ID SV-264330r984319_rule Severity medium Rule_Title The VPN Gateway must establish organization-defined alternate communications paths for system operations organizational command and control. Vuln_Discuss An incident, whether adversarial- or nonadversarial-based, can disrupt established communications paths used for system operations and organizational command and control. Alternate communications paths reduce the risk of all communications paths being affected by the same incident. To compound the problem, the inability of organizational officials to obtain timely information about disruptions or to provide timely direction to operational elements after a communications path incident, can impact the ability of the organization to respond to such incidents in a timely manner. Establishing alternate communications paths for command and control purposes, including designating alternative decision makers if primary decision makers are unavailable and establishing the extent and limitations of their actions, can greatly facilitate the organization's ability to continue to operate and take appropriate actions during an incident. Check_Content Verify the VPN Gateway is configured to establish organization-defined alternate communications paths for system operations organizational command and control. If the VPN Gateway is not configured to establish organization-defined alternate communications paths for system operations organizational command and control, this is a finding. Fix_Text Configure the VPN Gateway to establish organization-defined alternate communications paths for system operations organizational command and control. Not_Reviewed Vuln_Num V-264331 Rule_ID SV-264331r984329_rule Severity medium Rule_Title The VPN Gateway must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network. Vuln_Discuss Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates). This requirement only applies to components where this is specific to the function of the device or has the concept of a user (e.g., VPN or proxy capability). This does not apply to authentication for the purpose of configuring the device itself (i.e., device management). Check_Content If the VPN does not provide PKI-based user authentication intermediary services, this is not applicable. Verify the VPN implements a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network. If the VPN does not implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network, this is a finding. Fix_Text If PKI-based user authentication intermediary services are provided, configure the VPN to implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network. Not_Reviewed Vuln_Num V-264332 Rule_ID SV-264332r984332_rule Severity medium Rule_Title The VPN Gateway must configure OCSP to ensure revoked user certificates are prohibited from establishing an allowed session. Vuln_Discuss Situations may arise in which the certificate issued by a Certificate Authority (CA) may need to be revoked before the lifetime of the certificate expires. One example is if the certificate is known to have been compromised. When an incoming Internet Key Exchange (IKE) session is initiated for a remote client or peer whose certificate is revoked, the revocation list configured for use by the VPN server is checked to see if the certificate is valid. If the certificate is revoked, IKE will fail and an IPsec security association will not be established for the remote endpoint. Check_Content Verify the VPN Gateway rejects user certificates that have been revoked when using DOD PKI for authentication. If the VPN Gateway does not configure OCSP and/or CRL to reject revoked user credentials that are prohibited from establishing an allowed session, this is a finding. Fix_Text Configure the VPN Gateway to reject user certificates that have been revoked when using DOD PKI for authentication. Not_Reviewed Vuln_Num V-264333 Rule_ID SV-264333r984335_rule Severity medium Rule_Title The VPN Gateway must configure OCSP to ensure revoked machine certificates are prohibited from establishing an allowed session. Vuln_Discuss Situations may arise in which the certificate issued by a Certificate Authority (CA) may need to be revoked before the lifetime of the certificate expires. For example, the certificate is known to have been compromised. When an incoming Internet Key Exchange (IKE) session is initiated for a remote client or peer whose certificate is revoked, the revocation list configured for use by the VPN server is checked to see if the certificate is valid. If the certificate is revoked, IKE will fail and an IPsec security association will not be established for the remote endpoint. Check_Content Verify the VPN Gateway rejects machine certificates that have been revoked when using DOD PKI for authentication. If the VPN Gateway does not configure OCSP and/or CRL to reject revoked machine credentials that are prohibited from establishing an allowed session, this is a finding. Fix_Text Configure the VPN Gateway to reject machine certificates that have been revoked when using DOD PKI for authentication. Not_Reviewed Vuln_Num V-264334 Rule_ID SV-264334r984338_rule Severity medium Rule_Title The VPN Gateway providing authentication intermediary services must only accept end entity certificates (user or machine) issued by DOD PKI or DOD-approved PKI Certification Authorities (CAs) for the establishment of VPN sessions. Vuln_Discuss Untrusted Certificate Authorities (CAs) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DOD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DOD-approved CA, trust of this CA has not been established. The DOD will only accept PKI certificates obtained from a DOD-approved internal or external Certificate Authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of TLS certificates. Reliance on CAs for the establishment of secure sessions includes, for example, the use of Internet Key Exchange (IKE). This requirement focuses on communications protection for the application session rather than for the network packet. VPN gateways that perform these functions must be able to identify which session identifiers were generated when the sessions were established. Certificates for both user and machines must be validated. Check_Content If the VPN Gateway does not provide PKI-based user authentication intermediary services, this is not applicable. Verify the VPN Gateway only allows the use of DOD PKI-established CA for verification when establishing VPN sessions. Verify both user and machine certificates are being validated when establishing VPN sessions. If the VPN Gateway does not validate user and machine certificates using DOD PKI-established certificate authorities, this is a finding. Fix_Text Configure the VPN Gateway to only allow the use of DOD PKI-established CAs for the establishment of VPN sessions. Configure validation for both the user and machine certificates. Not_Reviewed Vuln_Num V-264335 Rule_ID SV-264335r1138025_rule Severity medium Rule_Title The TLS VPN must be configured to limit authenticated client sessions to initial session source IP. Vuln_Discuss Limiting authenticated client sessions to the initial session source IP for TLS VPNs is a safeguard against session hijacking, replay, and man-in-the-middle attacks, maintaining integrity and confidentiality of communication between clients and servers. This requirement also applies to Zero Trust initiatives. Check_Content Verify the TLS VPN Gateway limits authenticated client sessions to initial session source IP. If the TLS VPN Gateway does not limit authenticated client sessions to initial session source IP, this is a finding. Fix_Text Configure the TLS VPN Gateway to limit authenticated client sessions to initial session source IP. Not_Reviewed Vuln_Num V-264336 Rule_ID SV-264336r1056131_rule Severity medium Rule_Title The VPN Gateway must use Always On VPN connections for remote computing. Vuln_Discuss Allowing remote users to manually toggle a VPN connection can create critical security risks. With Always On VPN, if a secured connection to the gateway is lost, hybrid-working users will be disconnected from the internet until the issue is solved. "Always On" is a term that describes a VPN connection that is secure and always on after the initial connection is established. An Always On VPN deployment automatically establishes a VPN connection with the client at startup. The remote client must not be able to access the internet without first establishing a VPN session with a DOD site. Note that device compliance checks, including the banner presentation, are still required prior to connecting to DOD resources. Although out of scope for this requirement, the connection process must ensure remote devices meet security standards before accessing DOD resources. Devices that fail to meet compliance requirements can be denied access, reducing the risk of compromised endpoints. Check_Content Verify that the VPN Gateway uses an Always On VPN connection for remote computing. If the VPN Gateway does not use an Always On VPN connection for remote computing, this is a finding. Fix_Text Configure the VPN Gateway to enable Always On VPN connections for all remote users. The remote client must not be able to access the internet without first establishing a VPN session with a DOD site. Not_Reviewed Vuln_Num V-279018 Rule_ID SV-279018r1138041_rule Severity medium Rule_Title The VPN Gateway must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Vuln_Discuss To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DOD-approved PKIs, all DOD systems (e.g., networks, web servers, and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the information system. This requirement also applies to Zero Trust initiatives. Check_Content Determine if the VPN Gateway enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. If the VPN Gateway does not enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies, this is a finding. Fix_Text Configure the VPN Gateway to enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Not_Reviewed Vuln_Num V-279019 Rule_ID SV-279019r1138044_rule Severity medium Rule_Title The VPN Gateway must enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies. Vuln_Discuss Information flow control regulates where information is allowed to travel within a network and between interconnected networks. The flow of all network traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the internet, and blocking information marked as classified that is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems. Enforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, and firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet filtering capability based on header information, or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics). This requirement also applies to Zero Trust initiatives. Check_Content Determine if the VPN Gateway enforces approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies.. If the VPN Gateway transmits but does not enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies, this is a finding. Fix_Text Configure the VPN Gateway to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies. Not_Reviewed Vuln_Num V-279020 Rule_ID SV-279020r1138047_rule Severity medium Rule_Title The VPN Gateway must use organization-defined security attributes associated with organization-defined information, source, and destination objects to enforce organization-defined information flow control policies as a basis for flow control decisions. Vuln_Discuss A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. Security attributes may be used to manage information flow control. Information flow enforcement mechanisms compare security attributes associated with information (data content and data structure) and source/destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not allowed by information flow policies. For example, an information object labeled Secret would be allowed to flow to a destination object labeled Secret, but an information object labeled Top Secret would not be allowed to flow to a destination object labeled Secret. Security attributes can also include, for example, source and destination addresses employed in traffic filter firewalls. Flow enforcement using security attributes can be used, for example, to control the release of certain types of information. This requirement also applies to Zero Trust initiatives. Check_Content Determine if the VPN Gateway uses organization-defined security attributes associated with organization-defined information, source, and destination objects to enforce organization-defined information flow control policies as a basis for flow control decisions. If the VPN Gateway does not use organization-defined security attributes associated with organization-defined information, source, and destination objects to enforce organization-defined information flow control policies as a basis for flow control decisions, this is a finding. Fix_Text Configure the VPN Gateway to use organization-defined security attributes associated with organization-defined information, source, and destination objects to enforce organization-defined information flow control policies as a basis for flow control decisions. Not_Reviewed Vuln_Num V-279021 Rule_ID SV-279021r1138050_rule Severity medium Rule_Title The VPN Gateway must uniquely identify and authenticate source by organization, system, application, and/or individual for information transfer. Vuln_Discuss Attribution is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in information systems, allows the forensic reconstruction of events when required, and encourages policy compliance by attributing policy violations to specific organizations/individuals. Successful domain authentication requires that information system labels distinguish among systems, organizations, and individuals involved in preparing, sending, receiving, or disseminating information. This requirement applies to VPN Gateways that transfer information between different security domains (e.g., cross-domain solutions). This requirement also applies to Zero Trust initiatives. Check_Content Determine if the VPN Gateway uniquely identifies and authenticates source by organization, system, application, and/or individual for information transfer. If the VPN Gateway does not uniquely identify and authenticate source by organization, system, application, and/or individual for information transfer, this is a finding. Fix_Text Configure the VPN Gateway to uniquely identify and authenticate source by organization, system, application, and/or individual for information transfer. Not_Reviewed Vuln_Num V-279022 Rule_ID SV-279022r1138053_rule Severity medium Rule_Title The VPN Gateway must uniquely identify and authenticate destination by organization, system, application, and/or individual for information transfer. Vuln_Discuss Attribution is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in information systems, allows the forensic reconstruction of events when required, and encourages policy compliance by attributing policy violations to specific organizations/individuals. Successful domain authentication requires that information system labels distinguish among systems, organizations, and individuals involved in preparing, sending, receiving, or disseminating information. This requirement applies to VPN Gateways that transfer information between different security domains (e.g., cross-domain solutions). This requirement also applies to Zero Trust initiatives. Check_Content Determine if the VPN Gateway uniquely identifies and authenticates destination by organization, system, application, and/or individual for information transfer. If the VPN Gateway does not uniquely identify and authenticate destination by organization, system, application, and/or individual for information transfer, this is a finding. Fix_Text Configure the VPN Gateway to uniquely identify and authenticate destination by organization, system, application, and/or individual for information transfer. Not_Reviewed Vuln_Num V-279023 Rule_ID SV-279023r1138056_rule Severity medium Rule_Title The VPN Gateway, when transferring information between different security domains, must apply the same security policy filtering to metadata as it applies to data payloads. Vuln_Discuss Subjecting metadata to the same filtering and inspection policies as payload data avoids the potential for data compromise through covert channels and the bypass of security policy filtering. This requirement applies to VPN Gateways that transfer information between different security domains (e.g., cross-domain solutions). This requirement also applies to Zero Trust initiatives. Check_Content Determine if the VPN Gateway, when transferring information between different security domains, applies the same security policy filtering to metadata as it applies to data payloads. If the VPN Gateway does not apply the same security policy filtering to metadata as it applies to data payloads, when transferring information between different security domains, this is a finding. Fix_Text Configure the VPN Gateway to apply the same security policy filtering to metadata as it applies to data payloads, when transferring information between different security domains. Not_Reviewed Vuln_Num V-279024 Rule_ID SV-279024r1138059_rule Severity medium Rule_Title The VPN Gateway must implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission. Vuln_Discuss Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, VPN Gateways need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPSEC. This requirement also applies to Zero Trust initiatives. Check_Content Determine if the VPN Gateway implements cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission. If the VPN Gateway does not implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission, this is a finding. Fix_Text Configure the VPN Gateway to implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission. Not_Reviewed Vuln_Num V-279025 Rule_ID SV-279025r1138062_rule Severity medium Rule_Title The VPN Gateway must dynamically associate security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined. Vuln_Discuss If the VPN Gateway does not dynamically reconfigure the data security attributes as data is created and combined, there is the possibility that the security attributes will not correctly reflect the data with which they are associated. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., data records, buffers, and files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Organizations define the security attributes of their data (e.g., classified and CUI). Security labels for packets may include traffic flow information (e.g., source, destination, protocol combination); traffic classification based on QoS markings for preferred treatment; and VLAN identification. When data is created and/or combined, data security attributes defined by organizational policy must be dynamically created and/or updated to reflect the potential change in data sensitivity and characteristics. Dynamic association of security attributes is appropriate whenever the security characteristics of information changes over time. Security attributes may change due to information aggregation issues (i.e., the security characteristics of individual information elements are different from the combined elements); changes in individual access authorizations (i.e., privileges); or changes in the security category of information. This requirement also applies to Zero Trust initiatives. Check_Content Determine if the VPN Gateway dynamically associates security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined. If the VPN Gateway does not dynamically associate security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined, this is a finding. Fix_Text Configure the VPN Gateway to dynamically associate security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined. Not_Reviewed Vuln_Num V-279026 Rule_ID SV-279026r1138065_rule Severity medium Rule_Title The VPN Gateway must use a FIPS-validated cryptographic module to provision digital signatures. Vuln_Discuss FIPS 140-2/FIPS 140-3 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plain text. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2/FIPS 140-3 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2/FIPS 140-3 standard. The cryptographic module used must have at least one validated digital signature function. This validated hashing algorithm must be used to generate digital signatures for all cryptographic security function within the product being evaluated. Federal Information Processing Standard (FIPS) 186-4, Digital Signature Standard (DSS), specifies three NIST-approved algorithms: DSA, RSA, and ECDSA. These algorithms are used to generate and verify digital signatures in conjunction with an approved hash function. This requirement also applies to Zero Trust initiatives. Check_Content Determine if the VPN Gateway use a FIPS-validated cryptographic module to provision digital signatures. If the VPN Gateway does not use a FIPS-validated cryptographic module to provision digital signatures, this is a finding. Fix_Text Configure the VPN Gateway to use a FIPS-validated cryptographic module to provision digital signatures. Not_Reviewed Vuln_Num V-279027 Rule_ID SV-279027r1138068_rule Severity medium Rule_Title The VPN Gateway must use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality. Vuln_Discuss FIPS 140-2/FIPS 140-3 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plain text. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2/FIPS 140-3 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2/FIPS 140-3 standard. The cryptographic module used must have one FIPS-validated encryption algorithm (i.e., validated Advanced Encryption Standard [AES]). This validated algorithm must be used for encryption for cryptographic security function within the product being evaluated. This requirement also applies to Zero Trust initiatives. Check_Content Determine if the VPN Gateway uses a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality. If the VPN Gateway does not use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality, this is a finding. Fix_Text Configure the VPN Gateway to use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality. Not_Reviewed