Cyber · Trackr The Free Compliance Library
⌘K
DoD Compliance · STIG

Virtual Private Network (VPN) Security Requirements Guide

V2R1 · · · Released 23 Oct 2020 · 81 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

This Security Requirements Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
Digest of Updates vs. V1R1 · 19 Jul 2019 +81 −81

Comparison against the immediately-prior release (V1R1). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.

Added rules 81

  • V-207184 Medium The VPN Gateway must ensure inbound and outbound traffic is configured with a security policy in compliance with information flow control policies.
  • V-207185 Medium 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.
  • V-207186 Medium 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.
  • V-207187 Medium The publicly accessible VPN Gateway must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.
  • V-207188 Low The VPN Gateway must notify the user, upon successful logon (access), of the number of unsuccessful logon (access) attempts since the last successful logon (access).
  • V-207189 Medium The VPN Gateway must limit the number of concurrent sessions for user accounts to 1 or to an organization-defined number.
  • V-207190 High The TLS VPN Gateway must use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data during transmission.
  • V-207191 Medium 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 remote access sessions.
  • V-207192 Medium The VPN Gateway must be configured to use IPsec with SHA-1 or greater for hashing to protect the integrity of remote access sessions.
  • V-207193 High The IPsec VPN must implement a FIPS 140-2 validated Diffie-Hellman (DH) group.
  • V-207194 Medium If the site-to-site VPN implementation uses L2TP, L2TPv3 sessions must be authenticated prior to transporting traffic.
  • V-207195 Low The VPN Gateway must generate log records containing information to establish what type of events occurred.
  • V-207196 Low The VPN Gateway must generate log records containing information to establish when (date and time) the events occurred.
  • V-207197 Medium The VPN Gateway must generate log records containing information that establishes the identity of any individual or process associated with the event.
  • V-207198 Medium The VPN Gateway must generate log records containing information to establish where the events occurred.
  • V-207199 Low The VPN Gateway must generate log records containing information to establish the source of the events.
  • V-207200 Medium The VPN Gateway must produce log records containing information to establish the outcome of the events.
  • V-207201 Low The VPN Gateway must protect log information from unauthorized read access if all or some of this data is stored locally.
  • V-207202 Medium The VPN Gateway log must protect audit information from unauthorized modification when stored locally.
  • V-207203 Medium The VPN Gateway must protect audit information from unauthorized deletion when stored locally.
  • V-207204 Medium 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.
  • V-207205 Medium The IPsec VPN Gateway must use IKEv2 for IPsec VPN security associations.
  • V-207206 Medium The Remote Access VPN Gateway must be configured to prohibit Point-to-Point Tunneling Protocol (PPTP) and L2F.
  • V-207207 Medium 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.
  • V-207208 Medium The VPN Gateway must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
  • V-207209 High The VPN Gateway must use multifactor authentication (e.g., DoD PKI) for network access to non-privileged accounts.
  • V-207210 Medium The VPN Client must implement multifactor authentication for network access to non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access.
  • V-207211 Medium The TLS VPN must be configured to use replay-resistant authentication mechanisms for network access to non-privileged accounts.
  • V-207212 Medium The IPsec VPN Gateway must use anti-replay mechanisms for security associations.
  • V-207213 Medium The VPN Gateway must uniquely identify all network-connected endpoint devices before establishing a connection.
  • V-207214 Medium 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.
  • V-207215 Medium The site-to-site VPN, when using PKI-based authentication for devices, must enforce authorized access to the corresponding private key.
  • V-207216 Medium The Remote Access VPN Gateway must use a separate authentication server (e.g., LDAP, RADIUS, TACACS+) to perform user authentication.
  • V-207217 Medium The VPN Gateway must map the authenticated identity to the user account for PKI-based authentication.
  • V-207218 Medium The VPN Gateway must use FIPS-validated SHA-1 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 (
  • V-207219 Medium The VPN Gateway must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).
  • V-207220 Medium The VPN Gateway must be configured to route sessions to an IDPS for inspection.
  • V-207221 Low The VPN Gateway must terminate all network connections associated with a communications session at the end of the session.
  • V-207222 Medium The VPN Gateway must use FIPS 140-2 compliant mechanisms for authentication to a cryptographic module.
  • V-207223 High The IPsec VPN Gateway must use Internet Key Exchange (IKE) with SHA-1 or greater to protect the authenticity of communications sessions.
  • V-207224 Medium The VPN Gateway must invalidate session identifiers upon user logoff or other session termination.
  • V-207225 Medium The VPN Gateway must recognize only system-generated session identifiers.
  • V-207226 Medium The VPN Gateway must generate unique session identifiers using FIPS-validated Random Number Generator (RNG) based on the Deterministic Random Bit Generators (DRBG) algorithm.
  • V-207227 Medium The VPN Gateway must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.
  • V-207228 Medium The VPN Gateway must be configured to perform an organization-defined action if the audit reveals unauthorized activity.
  • V-207229 Medium 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.
  • V-207230 High The IPsec VPN Gateway must use AES encryption for the Internet Key Exchange (IKE) proposal to protect confidentiality of remote access sessions.
  • V-207231 Medium The VPN Gateway must transmit organization-defined access authorization information using FIPS 140-2-validated cryptography to a compliant authentication server, which enforces access control decisions.
  • V-207232 Low The VPN Gateway must notify the user, upon successful logon (access), of the organization-defined information to be included in addition to the date and time of the last logon (access).
  • V-207233 Medium The VPN Gateway must provide centralized management and configuration of the content to be captured in log records generated by all network components.
  • V-207234 Medium The VPN Gateway must off-load audit records onto a different system or media than the system being audited.
  • V-207235 Medium 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
  • V-207236 Medium When communications with the Central Log Server is lost, the VPN Gateway must continue to queue traffic log records locally.
  • V-207237 Medium The IPsec VPN Gateway must renegotiate the security association after 8 hours or less, or an organization-defined period.
  • V-207238 Medium The VPN Gateway must renegotiate the security association after 24 hours or less or as defined by the organization.
  • V-207239 Medium The VPN Gateway must accept the Common Access Card (CAC) credential.
  • V-207240 Medium The VPN Gateway must electronically verify the Common Access Card (CAC) credential.
  • V-207241 Medium The VPN Gateway must authenticate all network-connected endpoint devices before establishing a connection.
  • V-207242 Medium The VPN Gateway must use an approved Commercial Solution for Classified (CSfC) when transporting classified traffic across an unclassified network.
  • V-207243 Medium The VPN Gateway must disable split-tunneling for remote clients VPNs.
  • V-207244 Medium The IPsec VPN Gateway must specify Perfect Forward Secrecy (PFS) during Internet Key Exchange (IKE) negotiation.
  • V-207245 High The VPN Gateway and Client must be configured to protect the confidentiality and integrity of transmitted information.
  • V-207246 Medium The IPsec VPN Gateway must 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.
  • V-207247 Medium For site-to-site VPN, for accounts using password authentication, the VPN Gateway must use FIPS-validated SHA-1 or later protocol to protect the integrity of the password authentication process.
  • V-207248 Medium The VPN Gateway must generate log records when successful and/or unsuccessful VPN connection attempts occur.
  • V-207249 Medium The VPN Gateway must use a FIPS-validated cryptographic module to generate cryptographic hashes.
  • V-207250 Medium The VPN Gateway must use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.
  • V-207251 Medium The IPsec VPN Gateway IKE must use NIST FIPS-validated cryptography to implement encryption services for unclassified VPN traffic.
  • V-207252 High The IPsec VPN Gateway must use Internet Key Exchange (IKE) for IPsec VPN Security Associations (SAs).
  • V-207253 High The VPN Gateway must not accept certificates that have been revoked when using PKI for authentication.
  • V-207254 Medium The VPN Client logout function must be configured to terminate the session on/with the VPN Gateway.
  • V-207255 Medium The VPN Client must display an explicit logout message to users indicating the reliable termination of authenticated communications sessions.
  • V-207256 Medium For site-to-site VPN Gateway must store only cryptographic representations of Pre-shared Keys (PSKs).
  • V-207257 High The IPsec VPN must use Advanced Encryption Standard (AES) encryption for the IPsec proposal to protect the confidentiality of remote access sessions.
  • V-207258 Medium 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.
  • V-207259 Medium The TLS VPN Gateway that supports citizen- or business-facing network devices must prohibit client negotiation to SSL 2.0 or SSL 3.0.
  • V-207260 Medium 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.
  • V-207261 High The VPN Gateway must use an approved High Assurance Commercial Solution for Classified (CSfC) cryptographic algorithm for remote access to a classified network.
  • V-207262 High The IPsec VPN Gateway Internet Key Exchange (IKE) must use cryptography that is compliant with Suite B parameters when transporting classified traffic across an unclassified network.
  • V-207263 Medium The VPN Gateway must validate certificates used for Transport Layer Security (TLS) functions by performing RFC 5280-compliant certification path validation.
  • V-207264 Medium The VPN Gateway must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use).

Removed rules 81

  • V-97041 Medium The VPN Gateway must ensure inbound and outbound traffic is configured with a security policy in compliance with information flow control policies.
  • V-97043 Medium 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.
  • V-97045 Medium 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.
  • V-97047 Medium The publicly accessible VPN Gateway must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.
  • V-97049 Low The VPN Gateway must notify the user, upon successful logon (access), of the number of unsuccessful logon (access) attempts since the last successful logon (access).
  • V-97051 Medium The VPN Gateway must limit the number of concurrent sessions for user accounts to 1 or to an organization-defined number.
  • V-97053 High The TLS VPN Gateway must use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data during transmission.
  • V-97055 Medium 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 remote access sessions.
  • V-97057 Medium The VPN Gateway must be configured to use IPsec with SHA-1 or greater for hashing to protect the integrity of remote access sessions.
  • V-97059 High The IPsec VPN must implement a FIPS 140-2 validated Diffie-Hellman (DH) group.
  • V-97061 Low The VPN Gateway must generate log records containing information to establish what type of events occurred.
  • V-97063 Low The VPN Gateway must generate log records containing information to establish when (date and time) the events occurred.
  • V-97065 Medium The VPN Gateway must generate log records containing information that establishes the identity of any individual or process associated with the event.
  • V-97067 Medium The VPN Gateway must generate log records containing information to establish where the events occurred.
  • V-97069 Low The VPN Gateway must generate log records containing information to establish the source of the events.
  • V-97071 Medium The VPN Gateway must produce log records containing information to establish the outcome of the events.
  • V-97073 Low The VPN Gateway must protect log information from unauthorized read access if all or some of this data is stored locally.
  • V-97075 Medium The VPN Gateway log must protect audit information from unauthorized modification when stored locally.
  • V-97077 Medium The VPN Gateway must protect audit information from unauthorized deletion when stored locally.
  • V-97079 Medium 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.
  • V-97081 Medium The IPsec VPN Gateway must use IKEv2 for IPsec VPN security associations.
  • V-97083 Medium The Remote Access VPN Gateway must be configured to prohibit Point-to-Point Tunneling Protocol (PPTP) and L2F.
  • V-97085 Medium 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.
  • V-97087 Medium The VPN Gateway must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
  • V-97089 High The VPN Gateway must use multifactor authentication (e.g., DoD PKI) for network access to non-privileged accounts.
  • V-97091 Medium The VPN Client must implement multifactor authentication for network access to non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access.
  • V-97093 Medium The TLS VPN must be configured to use replay-resistant authentication mechanisms for network access to non-privileged accounts.
  • V-97095 Medium The IPsec VPN Gateway must use anti-replay mechanisms for security associations.
  • V-97097 Medium The VPN Gateway must uniquely identify all network-connected endpoint devices before establishing a connection.
  • V-97099 Medium 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.
  • V-97101 Medium The site-to-site VPN, when using PKI-based authentication for devices, must enforce authorized access to the corresponding private key.
  • V-97103 Medium The Remote Access VPN Gateway must use a separate authentication server (e.g., LDAP, RADIUS, TACACS+) to perform user authentication.
  • V-97113 Medium The VPN Gateway must map the authenticated identity to the user account for PKI-based authentication.
  • V-97115 Medium The VPN Gateway must use FIPS-validated SHA-1 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 (legacy use only).
  • V-97117 Medium The VPN Gateway must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).
  • V-97119 Medium The VPN Gateway must be configured to route sessions to an IDPS for inspection.
  • V-97121 Low The VPN Gateway must terminate all network connections associated with a communications session at the end of the session.
  • V-97123 Medium The VPN Gateway must use FIPS 140-2 compliant mechanisms for authentication to a cryptographic module.
  • V-97125 High The IPsec VPN Gateway must use Internet Key Exchange (IKE) with SHA-1 or greater to protect the authenticity of communications sessions.
  • V-97127 Medium The VPN Gateway must invalidate session identifiers upon user logoff or other session termination.
  • V-97129 Medium The VPN Gateway must recognize only system-generated session identifiers.
  • V-97131 Medium The VPN Gateway must generate unique session identifiers using FIPS-validated Random Number Generator (RNG) based on the Deterministic Random Bit Generators (DRBG) algorithm.
  • V-97133 Medium The VPN Gateway must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.
  • V-97135 Medium The VPN Gateway must be configured to perform an organization-defined action if the audit reveals unauthorized activity.
  • V-97137 Medium 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.
  • V-97139 High The IPsec VPN Gateway must use AES encryption for the Internet Key Exchange (IKE) proposal to protect confidentiality of remote access sessions.
  • V-97141 Medium The VPN Gateway must transmit organization-defined access authorization information using FIPS 140-2-validated cryptography to a compliant authentication server, which enforces access control decisions.
  • V-97143 Low The VPN Gateway must notify the user, upon successful logon (access), of the organization-defined information to be included in addition to the date and time of the last logon (access).
  • V-97145 Medium The VPN Gateway must provide centralized management and configuration of the content to be captured in log records generated by all network components.
  • V-97147 Medium The VPN Gateway must off-load audit records onto a different system or media than the system being audited.
  • V-97149 Medium 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.
  • V-97151 Medium When communications with the Central Log Server is lost, the VPN Gateway must continue to queue traffic log records locally.
  • V-97153 Medium The IPsec VPN Gateway must renegotiate the security association after 8 hours or less, or an organization-defined period.
  • V-97155 Medium The VPN Gateway must renegotiate the security association after 24 hours or less or as defined by the organization.
  • V-97157 Medium The VPN Gateway must accept Personal Identity Verification (PIV) credentials.
  • V-97159 Medium The VPN Gateway must electronically verify Personal Identity Verification (PIV) credentials.
  • V-97177 Medium The VPN Gateway must authenticate all network-connected endpoint devices before establishing a connection.
  • V-97179 Medium The VPN Gateway must use an approved Commercial Solution for Classified (CSfC) when transporting classified traffic across an unclassified network.
  • V-97181 Medium The VPN Gateway must disable split-tunneling for remote clients VPNs.
  • V-97183 Medium The IPsec VPN Gateway must specify Perfect Forward Secrecy (PFS) during Internet Key Exchange (IKE) negotiation.
  • V-97185 High The VPN Gateway and Client must be configured to protect the confidentiality and integrity of transmitted information.
  • V-97187 Medium The IPsec VPN Gateway must 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.
  • V-97189 Medium For site-to-site VPN, for accounts using password authentication, the VPN Gateway must use FIPS-validated SHA-1 or later protocol to protect the integrity of the password authentication process.
  • V-97191 Medium The VPN Gateway must generate log records when successful and/or unsuccessful VPN connection attempts occur.
  • V-97193 Medium The VPN Gateway must use a FIPS-validated cryptographic module to generate cryptographic hashes.
  • V-97195 Medium The VPN Gateway must use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.
  • V-97197 Medium The IPsec VPN Gateway IKE must use NIST FIPS-validated cryptography to implement encryption services for unclassified VPN traffic.
  • V-97199 High The IPsec VPN Gateway must use Internet Key Exchange (IKE) for IPsec VPN Security Associations (SAs).
  • V-97201 High The VPN Gateway must not accept certificates that have been revoked when using PKI for authentication.
  • V-97203 Medium The VPN Client logout function must be configured to terminate the session on/with the VPN Gateway.
  • V-97205 Medium The VPN Client must display an explicit logout message to users indicating the reliable termination of authenticated communications sessions.
  • V-97207 Medium For site-to-site VPN Gateway must store only cryptographic representations of Pre-shared Keys (PSKs).
  • V-97209 High The IPsec VPN must use Advanced Encryption Standard (AES) encryption for the IPsec proposal to protect the confidentiality of remote access sessions.
  • V-97211 Medium 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.
  • V-97213 Medium The TLS VPN Gateway that supports citizen- or business-facing network devices must prohibit client negotiation to SSL 2.0 or SSL 3.0.
  • V-97215 Medium 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.
  • V-97217 High The VPN Gateway must use an approved High Assurance Commercial Solution for Classified (CSfC) cryptographic algorithm for remote access to a classified network.
  • V-97219 High The IPsec VPN Gateway Internet Key Exchange (IKE) must use cryptography that is compliant with Suite B parameters when transporting classified traffic across an unclassified network.
  • V-97221 Medium The VPN Gateway must validate certificates used for Transport Layer Security (TLS) functions by performing RFC 5280-compliant certification path validation.
  • V-97223 Medium The VPN Gateway must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use).
  • V-97225 Medium If the site-to-site VPN implementation uses L2TP, L2TPv3 sessions must be authenticated prior to transporting traffic.
Sort by
b
The VPN Gateway must ensure inbound and outbound traffic is configured with a security policy in compliance with information flow control policies.
AC-4 - Medium - CCI-001414 - V-207184 - SV-207184r561344_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001414
Version
SRG-NET-000019-VPN-000040
Vuln IDs
  • V-207184
  • V-97041
Rule IDs
  • SV-207184r561344_rule
  • SV-106179
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.
Checks: C-7444r378173_chk

Verify the VPN Gateway has an inbound and outbound traffic security policy which 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 VPN Gateway does not ensure inbound and outbound traffic is configured with a security policy in compliance with information flow control policies, this is a finding.

Fix: F-7444r378174_fix

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.

b
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.
AC-8 - Medium - CCI-000048 - V-207185 - SV-207185r561344_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
SRG-NET-000041-VPN-000110
Vuln IDs
  • V-207185
  • V-97043
Rule IDs
  • SV-207185r561344_rule
  • SV-106181
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. 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."
Checks: C-7445r378176_chk

If the user/remote client connection banner is the same as the banner configured as part of the NDM SRG, then 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: F-7445r378177_fix

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."

b
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.
AC-8 - Medium - CCI-000050 - V-207186 - SV-207186r561344_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000050
Version
SRG-NET-000042-VPN-000120
Vuln IDs
  • V-207186
  • V-97045
Rule IDs
  • SV-207186r561344_rule
  • SV-106183
The banner must be acknowledged by the user prior to allowing the user access to the network. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law. The banner is usually configured in NDM for client presentation as well as local logon. 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 login function residing on the gateway or the gateway acts as a user intermediary.
Checks: C-7446r378179_chk

If the user/remote client connection banner is the same as the banner configured as part of the NDM SRG, then 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 takes 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: F-7446r378180_fix

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.

b
The publicly accessible VPN Gateway must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.
AC-8 - Medium - CCI-001384 - V-207187 - SV-207187r561344_rule
RMF Control
AC-8
Severity
M
CCI
CCI-001384
Version
SRG-NET-000043-VPN-000130
Vuln IDs
  • V-207187
  • V-97047
Rule IDs
  • SV-207187r561344_rule
  • SV-106185
Display of a standardized and approved use notification before granting access to the publicly accessible VPN gateway ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. 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 DTM-08-060. 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."
Checks: C-7447r378182_chk

Verify the publicly accessible VPN Gateway displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for network elements 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." If the publicly accessible VPN Gateway does not display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system, this is a finding.

Fix: F-7447r378183_fix

Configure the publicly accessible VPN Gateway to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.

a
The VPN Gateway must notify the user, upon successful logon (access), of the number of unsuccessful logon (access) attempts since the last successful logon (access).
AC-9 - Low - CCI-000053 - V-207188 - SV-207188r561344_rule
RMF Control
AC-9
Severity
L
CCI
CCI-000053
Version
SRG-NET-000049-VPN-000150
Vuln IDs
  • V-207188
  • V-97049
Rule IDs
  • SV-207188r561344_rule
  • SV-106187
Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. This applies to gateways that have the concept of a user account and have the login function residing on the gateway or the gateway acts as a user intermediary.
Checks: C-7448r378185_chk

Determine if the VPN Gateway is either configured to notify the administrator of the number of unsuccessful login attempts since the last successful login or configured to use an authentication server which would perform this function. If the administrator is not notified of the number of unsuccessful login attempts since the last successful login, this is a finding. If the VPN Gateway does not notify the user, upon successful logon (access), of the number of unsuccessful logon (access) attempts since the last successful logon (access), this is a finding.

Fix: F-7448r378186_fix

Configure the VPN Gateway to notify the user, upon successful logon (access), of the number of unsuccessful logon (access) attempts since the last successful logon (access).

b
The VPN Gateway must limit the number of concurrent sessions for user accounts to 1 or to an organization-defined number.
AC-10 - Medium - CCI-000054 - V-207189 - SV-207189r561344_rule
RMF Control
AC-10
Severity
M
CCI
CCI-000054
Version
SRG-NET-000053-VPN-000170
Vuln IDs
  • V-207189
  • V-97051
Rule IDs
  • SV-207189r561344_rule
  • SV-106189
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.
Checks: C-7449r378188_chk

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: F-7449r378189_fix

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.

c
The TLS VPN Gateway must use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data during transmission.
AC-17 - High - CCI-000068 - V-207190 - SV-207190r561344_rule
RMF Control
AC-17
Severity
H
CCI
CCI-000068
Version
SRG-NET-000062-VPN-000200
Vuln IDs
  • V-207190
  • V-97053
Rule IDs
  • SV-207190r561344_rule
  • SV-106191
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 provides guidance for client negotiation on either DoD-only or public-facing servers.
Checks: C-7450r378191_chk

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: F-7450r378192_fix

Configure the TLS VPN Gateway to use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data for transmission.

b
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 remote access sessions.
AC-17 - Medium - CCI-001453 - V-207191 - SV-207191r561344_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001453
Version
SRG-NET-000063-VPN-000210
Vuln IDs
  • V-207191
  • V-97055
Rule IDs
  • SV-207191r561344_rule
  • SV-106193
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.
Checks: C-7451r378194_chk

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: F-7451r378195_fix

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.

b
The VPN Gateway must be configured to use IPsec with SHA-1 or greater for hashing to protect the integrity of remote access sessions.
AC-17 - Medium - CCI-001453 - V-207192 - SV-207192r561344_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001453
Version
SRG-NET-000063-VPN-000220
Vuln IDs
  • V-207192
  • V-97057
Rule IDs
  • SV-207192r561344_rule
  • SV-106195
Without strong cryptographic integrity protections, information can be altered by unauthorized users without detection. Although allowed by SP800-131Ar1 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-1 for integrity of remote access sessions. For digital signature verification, SHA-1 is allowed for legacy-use. For all other hash function applications (e.g., HMAC, KDFs, RBG, password hashing, checksum integrity checks), the use of SHA-1 is acceptable, but discouraged in DoD. The remote access VPN provides access to DoD non-public information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network.
Checks: C-7452r378197_chk

Verify the VPN Gateway uses IPsec with SHA-1 or greater for hashing to protect the integrity of remote access sessions. If the VPN Gateway does not use IPsec with SHA-1 or greater for hashing to protect the integrity of remote access sessions, this is a finding.

Fix: F-7452r378198_fix

Configure the VPN Gateway to use IPsec with SHA-1 or greater for hashing to protect the integrity of remote access sessions.

c
The IPsec VPN must implement a FIPS 140-2 validated Diffie-Hellman (DH) group.
AC-17 - High - CCI-000068 - V-207193 - SV-207193r561344_rule
RMF Control
AC-17
Severity
H
CCI
CCI-000068
Version
SRG-NET-000074-VPN-000250
Vuln IDs
  • V-207193
  • V-97059
Rule IDs
  • SV-207193r561344_rule
  • SV-106197
Use of an approved DH algorithm ensures the Internet Key Exchange (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 in which the key was derived from. Hence, the larger the modulus, the more secure the generated key is considered to be.
Checks: C-7453r378200_chk

Verify all IKE proposals are set to use a FIPS-validated dh-group. View the IKE options dh-group option. If the IKE option is not set to a FIPS 140-2 validated dh-group, this is a finding.

Fix: F-7453r378201_fix

Configure the IPsec VPN to us the FIPS 140-2 DH group. The following command is an example of how to configure the IKE (phase 1) proposals. The following groups are allowed for use in DoD: DH Groups 14 (2048-bit MODP) - 19 (256-bit Random ECP), 20 (384-bit Random ECP), 5 (1536-bit MODP), 24 (2048-bit MODP with 256-bit POS).

b
If the site-to-site VPN implementation uses L2TP, L2TPv3 sessions must be authenticated prior to transporting traffic.
AC-17 - Medium - CCI-000068 - V-207194 - SV-207194r561344_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000068
Version
SRG-NET-000075-VPN-000260
Vuln IDs
  • V-207194
  • V-97225
Rule IDs
  • SV-207194r561344_rule
  • SV-106363
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.
Checks: C-7454r378203_chk

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: F-7454r378204_fix

If the site-to-site VPN implementation uses L2TPv3, configure L2TPv3 sessions to authenticate the traffic before transit.

a
The VPN Gateway must generate log records containing information to establish what type of events occurred.
AU-3 - Low - CCI-000130 - V-207195 - SV-207195r561344_rule
RMF Control
AU-3
Severity
L
CCI
CCI-000130
Version
SRG-NET-000077-VPN-000280
Vuln IDs
  • V-207195
  • V-97061
Rule IDs
  • SV-207195r561344_rule
  • SV-106199
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.
Checks: C-7455r378206_chk

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: F-7455r378207_fix

Configure the VPN Gateway to generate log records containing information to establish what type of events occurred.

a
The VPN Gateway must generate log records containing information to establish when (date and time) the events occurred.
AU-3 - Low - CCI-000131 - V-207196 - SV-207196r561344_rule
RMF Control
AU-3
Severity
L
CCI
CCI-000131
Version
SRG-NET-000078-VPN-000290
Vuln IDs
  • V-207196
  • V-97063
Rule IDs
  • SV-207196r561344_rule
  • SV-106201
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.
Checks: C-7456r378209_chk

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: F-7456r378210_fix

Configure the VPN Gateway to generate log records containing information to establish when (date and time) the events occurred.

b
The VPN Gateway must generate log records containing information that establishes the identity of any individual or process associated with the event.
AU-3 - Medium - CCI-001487 - V-207197 - SV-207197r561344_rule
RMF Control
AU-3
Severity
M
CCI
CCI-001487
Version
SRG-NET-000079-VPN-000300
Vuln IDs
  • V-207197
  • V-97065
Rule IDs
  • SV-207197r561344_rule
  • SV-106203
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.
Checks: C-7457r378212_chk

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: F-7457r378213_fix

Configure the VPN Gateway to generate log records containing information that establishes the identity of any individual or process associated with the event.

b
The VPN Gateway must generate log records containing information to establish where the events occurred.
AU-3 - Medium - CCI-000132 - V-207198 - SV-207198r561344_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000132
Version
SRG-NET-000088-VPN-000310
Vuln IDs
  • V-207198
  • V-97067
Rule IDs
  • SV-207198r561344_rule
  • SV-106205
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.
Checks: C-7458r378215_chk

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: F-7458r378216_fix

Configure the VPN Gateway to generates log records containing information to establish where the events occurred.

a
The VPN Gateway must generate log records containing information to establish the source of the events.
AU-3 - Low - CCI-000133 - V-207199 - SV-207199r561344_rule
RMF Control
AU-3
Severity
L
CCI
CCI-000133
Version
SRG-NET-000089-VPN-000330
Vuln IDs
  • V-207199
  • V-97069
Rule IDs
  • SV-207199r561344_rule
  • SV-106207
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.
Checks: C-7459r378218_chk

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: F-7459r378219_fix

Configure the VPN Gateway to generate log records containing information to establish the source of the events.

b
The VPN Gateway must produce log records containing information to establish the outcome of the events.
AU-3 - Medium - CCI-000134 - V-207200 - SV-207200r561344_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000134
Version
SRG-NET-000091-VPN-000350
Vuln IDs
  • V-207200
  • V-97071
Rule IDs
  • SV-207200r561344_rule
  • SV-106209
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.
Checks: C-7460r378221_chk

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: F-7460r378222_fix

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.

a
The VPN Gateway must protect log information from unauthorized read access if all or some of this data is stored locally.
AU-9 - Low - CCI-000162 - V-207201 - SV-207201r561344_rule
RMF Control
AU-9
Severity
L
CCI
CCI-000162
Version
SRG-NET-000098-VPN-000370
Vuln IDs
  • V-207201
  • V-97073
Rule IDs
  • SV-207201r561344_rule
  • SV-106211
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.
Checks: C-7461r378224_chk

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: F-7461r378225_fix

Configure the VPN Gateway to protect log information from unauthorized read access if all or some of this data is stored locally.

b
The VPN Gateway log must protect audit information from unauthorized modification when stored locally.
AU-9 - Medium - CCI-000163 - V-207202 - SV-207202r561344_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000163
Version
SRG-NET-000099-VPN-000380
Vuln IDs
  • V-207202
  • V-97075
Rule IDs
  • SV-207202r561344_rule
  • SV-106213
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).
Checks: C-7462r378227_chk

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: F-7462r378228_fix

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.

b
The VPN Gateway must protect audit information from unauthorized deletion when stored locally.
AU-9 - Medium - CCI-000164 - V-207203 - SV-207203r561344_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000164
Version
SRG-NET-000100-VPN-000390
Vuln IDs
  • V-207203
  • V-97077
Rule IDs
  • SV-207203r561344_rule
  • SV-106215
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).
Checks: C-7463r378230_chk

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: F-7463r378231_fix

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.

b
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.
CM-7 - Medium - CCI-000382 - V-207204 - SV-207204r561344_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000382
Version
SRG-NET-000132-VPN-000450
Vuln IDs
  • V-207204
  • V-97079
Rule IDs
  • SV-207204r561344_rule
  • SV-106217
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.
Checks: C-7464r378233_chk

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: F-7464r378234_fix

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.

b
The IPsec VPN Gateway must use IKEv2 for IPsec VPN security associations.
CM-7 - Medium - CCI-000382 - V-207205 - SV-207205r561344_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000382
Version
SRG-NET-000132-VPN-000460
Vuln IDs
  • V-207205
  • V-97081
Rule IDs
  • SV-207205r561344_rule
  • SV-106219
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.
Checks: C-7465r378236_chk

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: F-7465r378237_fix

Configure the IPsec VPN Gateway to use IKEv2 for IPsec VPN security associations.

b
The Remote Access VPN Gateway must be configured to prohibit Point-to-Point Tunneling Protocol (PPTP) and L2F.
CM-7 - Medium - CCI-000382 - V-207206 - SV-207206r561344_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000382
Version
SRG-NET-000132-VPN-000470
Vuln IDs
  • V-207206
  • V-97083
Rule IDs
  • SV-207206r561344_rule
  • SV-106221
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.
Checks: C-7466r378239_chk

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: F-7466r378240_fix

Configure the VPN Gateway to prohibit PPTP and L2F.

b
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.
CM-7 - Medium - CCI-000382 - V-207207 - SV-207207r561344_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000382
Version
SRG-NET-000132-VPN-000480
Vuln IDs
  • V-207207
  • V-97085
Rule IDs
  • SV-207207r561344_rule
  • SV-106223
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.
Checks: C-7467r378242_chk

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: F-7467r378243_fix

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.

b
The VPN Gateway must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
IA-2 - Medium - CCI-000764 - V-207208 - SV-207208r561344_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000764
Version
SRG-NET-000138-VPN-000490
Vuln IDs
  • V-207208
  • V-97087
Rule IDs
  • SV-207208r561344_rule
  • SV-106225
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).
Checks: C-7468r378245_chk

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: F-7468r378246_fix

Configure the VPN Gateway to uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).

c
The VPN Gateway must use multifactor authentication (e.g., DoD PKI) for network access to non-privileged accounts.
IA-2 - High - CCI-000766 - V-207209 - SV-207209r561344_rule
RMF Control
IA-2
Severity
H
CCI
CCI-000766
Version
SRG-NET-000140-VPN-000500
Vuln IDs
  • V-207209
  • V-97089
Rule IDs
  • SV-207209r561344_rule
  • SV-106227
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.
Checks: C-7469r378248_chk

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: F-7469r378249_fix

Configure the VPN Gateway to use multifactor authentication (e.g., DoD PKI) for network access to non-privileged accounts.

b
The VPN Client must implement multifactor authentication for network access to non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access.
IA-2 - Medium - CCI-001939 - V-207210 - SV-207210r561344_rule
RMF Control
IA-2
Severity
M
CCI
CCI-001939
Version
SRG-NET-000145-VPN-000510
Vuln IDs
  • V-207210
  • V-97091
Rule IDs
  • SV-207210r561344_rule
  • SV-106229
Using an authentication device, such as a 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 common access card. A non-privileged account is any information system account with authorizations of a non-privileged 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).
Checks: C-7470r378251_chk

Verify the VPN Client implements multifactor authentication for network access to non-privileged 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 non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access, this is a finding.

Fix: F-7470r378252_fix

Configure the VPN Client to implement multifactor authentication for network access to non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access.

b
The TLS VPN must be configured to use replay-resistant authentication mechanisms for network access to non-privileged accounts.
IA-2 - Medium - CCI-001942 - V-207211 - SV-207211r561344_rule
RMF Control
IA-2
Severity
M
CCI
CCI-001942
Version
SRG-NET-000147-VPN-000520
Vuln IDs
  • V-207211
  • V-97093
Rule IDs
  • SV-207211r561344_rule
  • SV-106231
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 non-privileged account is any operating system account with authorizations of a non-privileged 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).
Checks: C-7471r378254_chk

Verify the TLS VPN Gateway is configured to use replay-resistant authentication mechanisms for network access to non-privileged accounts. If the TLS VPN is not configured to use replay-resistant authentication mechanisms for network access to non-privileged accounts, this is a finding.

Fix: F-7471r378255_fix

Configure the TLS VPN Gateway to use replay-resistant authentication mechanisms for network access to non-privileged accounts.

b
The IPsec VPN Gateway must use anti-replay mechanisms for security associations.
IA-2 - Medium - CCI-001942 - V-207212 - SV-207212r561344_rule
RMF Control
IA-2
Severity
M
CCI
CCI-001942
Version
SRG-NET-000147-VPN-000530
Vuln IDs
  • V-207212
  • V-97095
Rule IDs
  • SV-207212r561344_rule
  • SV-106233
Anti-replay is an IPsec security mechanism at a packet level, which helps to avoid unwanted users from intercepting and modifying an ESP packet.
Checks: C-7472r378257_chk

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: F-7472r378258_fix

Configure the IPsec VPN Gateway to use anti-replay mechanisms for security associations.

b
The VPN Gateway must uniquely identify all network-connected endpoint devices before establishing a connection.
IA-3 - Medium - CCI-000778 - V-207213 - SV-207213r561344_rule
RMF Control
IA-3
Severity
M
CCI
CCI-000778
Version
SRG-NET-000148-VPN-000540
Vuln IDs
  • V-207213
  • V-97097
Rule IDs
  • SV-207213r561344_rule
  • SV-106235
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.
Checks: C-7473r378260_chk

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: F-7473r378261_fix

Configure the VPN Gateway to uniquely identify all network-connected endpoint devices before establishing a connection.

b
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.
IA-5 - Medium - CCI-000185 - V-207214 - SV-207214r561344_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000185
Version
SRG-NET-000164-VPN-000560
Vuln IDs
  • V-207214
  • V-97099
Rule IDs
  • SV-207214r561344_rule
  • SV-106237
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.
Checks: C-7474r378263_chk

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: F-7474r378264_fix

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.

b
The site-to-site VPN, when using PKI-based authentication for devices, must enforce authorized access to the corresponding private key.
IA-5 - Medium - CCI-000186 - V-207215 - SV-207215r561344_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000186
Version
SRG-NET-000165-VPN-000570
Vuln IDs
  • V-207215
  • V-97101
Rule IDs
  • SV-207215r561344_rule
  • SV-106239
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.
Checks: C-7475r378266_chk

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: F-7475r378267_fix

Configure the site-to-site VPN that uses certificate-based device authentication to use a FIPS-compliant key management process.

b
The Remote Access VPN Gateway must use a separate authentication server (e.g., LDAP, RADIUS, TACACS+) to perform user authentication.
IA-5 - Medium - CCI-000187 - V-207216 - SV-207216r561344_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000187
Version
SRG-NET-000166-VPN-000580
Vuln IDs
  • V-207216
  • V-97103
Rule IDs
  • SV-207216r561344_rule
  • SV-106241
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.
Checks: C-7476r378269_chk

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: F-7476r378270_fix

Configure the Remote Access VPN Gateway to use a separate authentication server (e.g., LDAP, RADIUS, TACACS+) to perform user authentication.

b
The VPN Gateway must map the authenticated identity to the user account for PKI-based authentication.
IA-5 - Medium - CCI-000187 - V-207217 - SV-207217r561344_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000187
Version
SRG-NET-000166-VPN-000590
Vuln IDs
  • V-207217
  • V-97113
Rule IDs
  • SV-207217r561344_rule
  • SV-106251
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).
Checks: C-7477r378272_chk

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: F-7477r378273_fix

Configure the VPN Gateway to map the authenticated identity to the user account for PKI-based authentication.

b
The VPN Gateway must use FIPS-validated SHA-1 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 (
IA-7 - Medium - CCI-000803 - V-207218 - SV-207218r561344_rule
RMF Control
IA-7
Severity
M
CCI
CCI-000803
Version
SRG-NET-000168-VPN-000600
Vuln IDs
  • V-207218
  • V-97115
Rule IDs
  • SV-207218r561344_rule
  • SV-106253
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Although allowed by SP800-131Ar1 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-1 for integrity of remote access sessions. For digital signature verification, SHA-1 is allowed for legacy-use. For all other hash function applications (e.g., HMAC, KDFs, RBG, password hashing, checksum integrity checks), the use of SHA-1 is acceptable, but discouraged in DoD. Nonlocal maintenance and diagnostic activities are activities conducted by individuals communicating through either an external network (e.g., the Internet) or an internal network. To protect the integrity of the authenticator and authentication mechanism used for the cryptographic module used by the network device, the application, operating system, or protocol must be configured to use one of the following hash functions for hashing the password or other authenticator in accordance with SP 800-131Ar1: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3-384, and SHA3-512. Applications also include HMAC, KDFs, Random Bit Generation, and hash-only applications (e.g., hashing passwords and using SHA-1 or higher to compute a checksum). For digital signature verification, SP800-131Ar1 allows SHA-1 for legacy use where needed. Separate requirements for configuring applications and protocols used by each product (e.g., SNMPv3, SSH, NTP, and other protocols and applications that require server/client authentication) are required to implement this requirement.
Checks: C-7478r378275_chk

Verify the VPN Gateway uses FIPS-validated SHA-1 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 (legacy use only). If the VPN Gateway does not use FIPS-validated SHA-1 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 (legacy use only), this is a finding.

Fix: F-7478r378276_fix

Configure the VPN Gateway to use FIPS-validated SHA-1 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 (legacy use only).

b
The VPN Gateway must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).
IA-8 - Medium - CCI-000804 - V-207219 - SV-207219r561344_rule
RMF Control
IA-8
Severity
M
CCI
CCI-000804
Version
SRG-NET-000169-VPN-000610
Vuln IDs
  • V-207219
  • V-97117
Rule IDs
  • SV-207219r561344_rule
  • SV-106255
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.
Checks: C-7479r378278_chk

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: F-7479r378279_fix

Configure the VPN Gateway to uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).

b
The VPN Gateway must be configured to route sessions to an IDPS for inspection.
SC-7 - Medium - CCI-001097 - V-207220 - SV-207220r561344_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001097
Version
SRG-NET-000205-VPN-000710
Vuln IDs
  • V-207220
  • V-97119
Rule IDs
  • SV-207220r561344_rule
  • SV-106257
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).
Checks: C-7480r378281_chk

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: F-7480r378282_fix

Configure the VPN Gateway to route sessions to an IDPS for inspection.

a
The VPN Gateway must terminate all network connections associated with a communications session at the end of the session.
SC-10 - Low - CCI-001133 - V-207221 - SV-207221r561344_rule
RMF Control
SC-10
Severity
L
CCI
CCI-001133
Version
SRG-NET-000213-VPN-000720
Vuln IDs
  • V-207221
  • V-97121
Rule IDs
  • SV-207221r561344_rule
  • SV-106259
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.
Checks: C-7481r378284_chk

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: F-7481r378285_fix

Configure the VPN Gateway to terminate all network connections associated with a communications session at the end of the session.

b
The VPN Gateway must use FIPS 140-2 compliant mechanisms for authentication to a cryptographic module.
SC-23 - Medium - CCI-001184 - V-207222 - SV-207222r561344_rule
RMF Control
SC-23
Severity
M
CCI
CCI-001184
Version
SRG-NET-000230-VPN-000770
Vuln IDs
  • V-207222
  • V-97123
Rule IDs
  • SV-207222r561344_rule
  • SV-106261
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.
Checks: C-7482r378287_chk

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: F-7482r378288_fix

Configure the VPN Gateway to use FIPS 140-2 compliant mechanisms for authentication to a cryptographic module.

c
The IPsec VPN Gateway must use Internet Key Exchange (IKE) with SHA-1 or greater to protect the authenticity of communications sessions.
SC-23 - High - CCI-001184 - V-207223 - SV-207223r561344_rule
RMF Control
SC-23
Severity
H
CCI
CCI-001184
Version
SRG-NET-000230-VPN-000780
Vuln IDs
  • V-207223
  • V-97125
Rule IDs
  • SV-207223r561344_rule
  • SV-106263
Authenticity protection provides protection against man-in-the-middle attacks/session hijacking and the insertion of false information into sessions. Although allowed by SP800-131Ar1 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-1 for integrity of remote access sessions. For digital signature verification, SHA-1 is allowed for legacy-use. For all other hash function applications (e.g., HMAC, KDFs, RBG, password hashing, checksum integrity checks), the use of SHA-1 is acceptable, but discouraged in DoD. This requirement focuses on communications protection for the application session rather than for the network packet and establishes grounds for confidence at both ends of communications sessions in ongoing identities of other parties and in the validity of information transmitted. Depending on the required degree of confidentiality and integrity, web services/SOA will require the use of mutual authentication (two-way/bidirectional). An IPsec Security Associations (SA) is established using either IKE or manual configuration.
Checks: C-7483r378290_chk

Verify the IPsec VPN Gateway uses IKE with SHA1 or greater to protect the authenticity of communications sessions. If the IPsec VPN Gateway is not configured to use IKE with SHA1 or greater to protect the authenticity of communications sessions, this is a finding.

Fix: F-7483r378291_fix

Configure the IPsec VPN Gateway to use IKE with SHA1 or greater to protect the authenticity of communications sessions.

b
The VPN Gateway must invalidate session identifiers upon user logoff or other session termination.
SC-23 - Medium - CCI-001185 - V-207224 - SV-207224r561344_rule
RMF Control
SC-23
Severity
M
CCI
CCI-001185
Version
SRG-NET-000231-VPN-000790
Vuln IDs
  • V-207224
  • V-97127
Rule IDs
  • SV-207224r561344_rule
  • SV-106265
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.
Checks: C-7484r378293_chk

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: F-7484r378294_fix

Configure the VPN Gateway to invalidate session identifiers upon user logoff or other session termination.

b
The VPN Gateway must recognize only system-generated session identifiers.
SC-23 - Medium - CCI-001664 - V-207225 - SV-207225r561344_rule
RMF Control
SC-23
Severity
M
CCI
CCI-001664
Version
SRG-NET-000233-VPN-000800
Vuln IDs
  • V-207225
  • V-97129
Rule IDs
  • SV-207225r561344_rule
  • SV-106267
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.
Checks: C-7485r378296_chk

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: F-7485r378297_fix

Configure the VPN Gateway to recognize only system-generated session identifiers.

b
The VPN Gateway must generate unique session identifiers using FIPS-validated Random Number Generator (RNG) based on the Deterministic Random Bit Generators (DRBG) algorithm.
SC-23 - Medium - CCI-001188 - V-207226 - SV-207226r561344_rule
RMF Control
SC-23
Severity
M
CCI
CCI-001188
Version
SRG-NET-000234-VPN-000810
Vuln IDs
  • V-207226
  • V-97131
Rule IDs
  • SV-207226r561344_rule
  • SV-106269
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. Use of a FIPS validated RNG that is not DRGB mitigates to a CAT III.
Checks: C-7486r378299_chk

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: F-7486r378300_fix

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.

b
The VPN Gateway must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.
SC-24 - Medium - CCI-001190 - V-207227 - SV-207227r561344_rule
RMF Control
SC-24
Severity
M
CCI
CCI-001190
Version
SRG-NET-000235-VPN-000820
Vuln IDs
  • V-207227
  • V-97133
Rule IDs
  • SV-207227r561344_rule
  • SV-106271
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.
Checks: C-7487r378302_chk

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: F-7487r378303_fix

Configure the VPN Gateway to fail to a secure state if system initialization fails, shutdown fails, or aborts fail.

b
The VPN Gateway must be configured to perform an organization-defined action if the audit reveals unauthorized activity.
AC-17 - Medium - CCI-002314 - V-207228 - SV-207228r561344_rule
RMF Control
AC-17
Severity
M
CCI
CCI-002314
Version
SRG-NET-000313-VPN-001050
Vuln IDs
  • V-207228
  • V-97135
Rule IDs
  • SV-207228r561344_rule
  • SV-106273
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).
Checks: C-7488r378305_chk

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: F-7488r378306_fix

Configure the VPN Gateway to be configured to perform an organization-defined action if the audit reveals unauthorized activity.

b
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.
AC-17 - Medium - CCI-002322 - V-207229 - SV-207229r561344_rule
RMF Control
AC-17
Severity
M
CCI
CCI-002322
Version
SRG-NET-000314-VPN-001060
Vuln IDs
  • V-207229
  • V-97137
Rule IDs
  • SV-207229r561344_rule
  • SV-106275
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.
Checks: C-7489r378308_chk

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: F-7489r378309_fix

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.

c
The IPsec VPN Gateway must use AES encryption for the Internet Key Exchange (IKE) proposal to protect confidentiality of remote access sessions.
AC-17 - High - CCI-000068 - V-207230 - SV-207230r561344_rule
RMF Control
AC-17
Severity
H
CCI
CCI-000068
Version
SRG-NET-000317-VPN-001090
Vuln IDs
  • V-207230
  • V-97139
Rule IDs
  • SV-207230r561344_rule
  • SV-106277
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.
Checks: C-7490r378311_chk

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: F-7490r378312_fix

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.

b
The VPN Gateway must transmit organization-defined access authorization information using FIPS 140-2-validated cryptography to a compliant authentication server, which enforces access control decisions.
AC-24 - Medium - CCI-002353 - V-207231 - SV-207231r561344_rule
RMF Control
AC-24
Severity
M
CCI
CCI-002353
Version
SRG-NET-000320-VPN-001120
Vuln IDs
  • V-207231
  • V-97141
Rule IDs
  • SV-207231r561344_rule
  • SV-106279
Protecting authentication communications between the client, the VPN Gateway, and the authentication server keeps this critical information from being exploited. In distributed information systems, authorization processes and access control decisions may occur in separate parts of the systems. In such instances, authorization information is transmitted securely so timely access control decisions can be enforced at the appropriate locations. To support the access control decisions, it may be necessary to transmit as part of the access authorization information, supporting security attributes. This is due to the fact that in distributed information systems, there are various access control decisions that need to be made and different entities (e.g., services) make these decisions in a serial fashion, each requiring some security attributes to make the decisions. This applies to VPN gateways that have the concept of a user account and have the login function residing on the VPN gateway.
Checks: C-7491r378314_chk

Verify the VPN Gateway transmits organization-defined access authorization information using FIPS 140-2-validated cryptography to a compliant authentication server, which enforces access control decisions. If the VPN Gateway does not transmit organization-defined access authorization information using FIPS 140-2-validated cryptography to a compliant authentication server, which enforces access control decisions, this is a finding.

Fix: F-7491r378315_fix

Configure the VPN Gateway to transmit organization-defined access authorization information using FIPS 140-2-validated cryptography to a compliant authentication server, which enforces access control decisions.

a
The VPN Gateway must notify the user, upon successful logon (access), of the organization-defined information to be included in addition to the date and time of the last logon (access).
AC-9 - Low - CCI-002250 - V-207232 - SV-207232r561344_rule
RMF Control
AC-9
Severity
L
CCI
CCI-002250
Version
SRG-NET-000330-VPN-001220
Vuln IDs
  • V-207232
  • V-97143
Rule IDs
  • SV-207232r561344_rule
  • SV-106281
Users need to be aware of activity that occurs regarding their account. Providing users with information deemed important by the organization may aid in the discovery of unauthorized access or thwart a potential attacker. Organizations should consider the risks to the specific information system being accessed and the threats presented by the device to the environment when configuring this option. An excessive or unnecessary amount of information presented to the user at logon is not recommended. This requirement applies to VPN gateways that have the concept of a user account and have the login function residing on the VPN gateway.
Checks: C-7492r378317_chk

Verity the VPN Gateway notifies the user, upon successful logon (access), of the organization-defined information to be included in addition to the date and time of the last logon (access). If the VPN Gateway does not notify the user, upon successful logon (access), of the organization-defined information to be included in addition to the date and time of the last logon (access), this is a finding.

Fix: F-7492r378318_fix

Configure the VPN Gateway to notify the user, upon successful logon (access), of the organization-defined information to be included in addition to the date and time of the last logon (access).

b
The VPN Gateway must provide centralized management and configuration of the content to be captured in log records generated by all network components.
AU-3 - Medium - CCI-001844 - V-207233 - SV-207233r561344_rule
RMF Control
AU-3
Severity
M
CCI
CCI-001844
Version
SRG-NET-000333-VPN-001250
Vuln IDs
  • V-207233
  • V-97145
Rule IDs
  • SV-207233r561344_rule
  • SV-106283
Without the ability to centrally manage the content captured in the log records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The content captured in log records must be managed from a central location (necessitating automation). Centralized management of log records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Network components requiring centralized audit log management must have the capability to support centralized management. The DoD requires centralized management of all network component audit record content. 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).
Checks: C-7493r378320_chk

Verify the VPN Gateway provides centralized management and configuration of the content to be captured in log records generated by all network components. If the VPN Gateway does not provide centralized management and configuration of the content to be captured in log records generated by all network components, this is a finding.

Fix: F-7493r378321_fix

Configure the VPN Gateway to provide centralized management and configuration of the content to be captured in log records generated by all network components.

b
The VPN Gateway must off-load audit records onto a different system or media than the system being audited.
AU-4 - Medium - CCI-001851 - V-207234 - SV-207234r561344_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001851
Version
SRG-NET-000334-VPN-001260
Vuln IDs
  • V-207234
  • V-97147
Rule IDs
  • SV-207234r561344_rule
  • SV-106285
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).
Checks: C-7494r378323_chk

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: F-7494r378324_fix

Configure the VPN Gateway to off-load audit records onto a different system or media than the system being audited.

b
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
AU-5 - Medium - CCI-001858 - V-207235 - SV-207235r561344_rule
RMF Control
AU-5
Severity
M
CCI
CCI-001858
Version
SRG-NET-000335-VPN-001270
Vuln IDs
  • V-207235
  • V-97149
Rule IDs
  • SV-207235r561344_rule
  • SV-106287
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.
Checks: C-7495r378326_chk

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: F-7495r378327_fix

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.

b
When communications with the Central Log Server is lost, the VPN Gateway must continue to queue traffic log records locally.
AU-5 - Medium - CCI-001861 - V-207236 - SV-207236r561344_rule
RMF Control
AU-5
Severity
M
CCI
CCI-001861
Version
SRG-NET-000336-VPN-001280
Vuln IDs
  • V-207236
  • V-97151
Rule IDs
  • SV-207236r561344_rule
  • SV-106289
If the system were to continue processing after audit failure, actions can be taken on the system that cannot be tracked and recorded for later forensic analysis. Because of the importance of ensuring mission/business continuity, organizations may determine that the nature of the audit failure is not so severe that it warrants a complete shutdown of the application supporting the core organizational missions/business operations. In those instances, partial application shutdowns or operating in a degraded mode with reduced capability may be viable alternatives. 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).
Checks: C-7496r378329_chk

Verify that in the event that communications with the Central Log Server is lost, the VPN Gateway is configured to continue to queue traffic log records locally. If the VPN Gateway does not continue to queue traffic log records locally when communications with the Central Log Server is lost, this is a finding.

Fix: F-7496r378330_fix

Configure the VPN Gateway to continue to queue traffic log records locally when communications with the Central Log Server is lost.

b
The IPsec VPN Gateway must renegotiate the security association after 8 hours or less, or an organization-defined period.
IA-11 - Medium - CCI-002038 - V-207237 - SV-207237r561344_rule
RMF Control
IA-11
Severity
M
CCI
CCI-002038
Version
SRG-NET-000337-VPN-001290
Vuln IDs
  • V-207237
  • V-97153
Rule IDs
  • SV-207237r561344_rule
  • SV-106291
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. Specify the lifetime (in seconds) of an Internet Key Exchange (IKE) security association (SA). When the SA expires, it is replaced by a new SA, the security parameter index (SPI), or terminated if the peer cannot be contacted for renegotiation.
Checks: C-7497r378332_chk

Verify the IPsec VPN Gateway renegotiates the security association after 8 hours or less, or an organization-defined period. If the IPsec VPN Gateway does not renegotiate the security association after 8 hours or less, or an organization-defined period, this is a finding.

Fix: F-7497r378333_fix

Configure the IPsec VPN Gateway to renegotiate the security association after 8 hours or less, or an organization-defined period.

b
The VPN Gateway must renegotiate the security association after 24 hours or less or as defined by the organization.
IA-11 - Medium - CCI-002038 - V-207238 - SV-207238r561344_rule
RMF Control
IA-11
Severity
M
CCI
CCI-002038
Version
SRG-NET-000337-VPN-001300
Vuln IDs
  • V-207238
  • V-97155
Rule IDs
  • SV-207238r561344_rule
  • SV-106293
When a VPN gateway creates an IPsec Security Association (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 at this time. The value of one hour or less is a common best practice.
Checks: C-7498r378335_chk

Verify the VPN Gateway renegotiates the security association after 24 hours or less or as defined by the organization. If the VPN Gateway does not renegotiate the security association after 24 hours or less or as defined by the organization, this is a finding.

Fix: F-7498r378336_fix

Configure the VPN Gateway to renegotiate the security association after 24 hours or less or as defined by the organization.

b
The VPN Gateway must accept the Common Access Card (CAC) credential.
IA-2 - Medium - CCI-001953 - V-207239 - SV-207239r561344_rule
RMF Control
IA-2
Severity
M
CCI
CCI-001953
Version
SRG-NET-000341-VPN-001350
Vuln IDs
  • V-207239
  • V-97157
Rule IDs
  • SV-207239r561344_rule
  • SV-106295
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.
Checks: C-7499r559885_chk

Verify the VPN Gateway accepts PIV credentials. If the VPN Gateway does not accept the CAC credential, this is a finding.

Fix: F-7499r559886_fix

Configure the VPN Gateway to accept the CAC credential.

b
The VPN Gateway must electronically verify the Common Access Card (CAC) credential.
IA-2 - Medium - CCI-001954 - V-207240 - SV-207240r561344_rule
RMF Control
IA-2
Severity
M
CCI
CCI-001954
Version
SRG-NET-000342-VPN-001360
Vuln IDs
  • V-207240
  • V-97159
Rule IDs
  • SV-207240r561344_rule
  • SV-106297
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.
Checks: C-7500r559888_chk

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: F-7500r559889_fix

Configure the VPN Gateway to electronically verify the CAC credential.

b
The VPN Gateway must authenticate all network-connected endpoint devices before establishing a connection.
IA-3 - Medium - CCI-001958 - V-207241 - SV-207241r561344_rule
RMF Control
IA-3
Severity
M
CCI
CCI-001958
Version
SRG-NET-000343-VPN-001370
Vuln IDs
  • V-207241
  • V-97177
Rule IDs
  • SV-207241r561344_rule
  • SV-106315
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.
Checks: C-7501r378344_chk

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: F-7501r378345_fix

Configure the VPN Gateway to authenticate all network-connected endpoint devices before establishing a connection.

b
The VPN Gateway must use an approved Commercial Solution for Classified (CSfC) when transporting classified traffic across an unclassified network.
SC-13 - Medium - CCI-002450 - V-207242 - SV-207242r561344_rule
RMF Control
SC-13
Severity
M
CCI
CCI-002450
Version
SRG-NET-000352-VPN-001460
Vuln IDs
  • V-207242
  • V-97179
Rule IDs
  • SV-207242r561344_rule
  • SV-106317
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.
Checks: C-7502r378347_chk

Verify the VPN Gateway uses an approved Commercial Solution for Classified (CSfC) when transporting classified traffic across an unclassified network. If the VPN Gateway does not use an approved Commercial Solution for Classified (CSfC) when transporting classified traffic across an unclassified network, this is a finding.

Fix: F-7502r378348_fix

Configure the VPN Gateway to use an approved Commercial Solution for Classified (CSfC) when transporting classified traffic across an unclassified network.

b
The VPN Gateway must disable split-tunneling for remote clients VPNs.
SC-7 - Medium - CCI-002397 - V-207243 - SV-207243r561344_rule
RMF Control
SC-7
Severity
M
CCI
CCI-002397
Version
SRG-NET-000369-VPN-001620
Vuln IDs
  • V-207243
  • V-97181
Rule IDs
  • SV-207243r561344_rule
  • SV-106319
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.
Checks: C-7503r378350_chk

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.

Fix: F-7503r378351_fix

Configure the VPN Gateway to disable split-tunneling for remote clients VPNs.

b
The IPsec VPN Gateway must specify Perfect Forward Secrecy (PFS) during Internet Key Exchange (IKE) negotiation.
SC-8 - Medium - CCI-002418 - V-207244 - SV-207244r561344_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
SRG-NET-000371-VPN-001640
Vuln IDs
  • V-207244
  • V-97183
Rule IDs
  • SV-207244r561344_rule
  • SV-106321
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 Perfect Forward Secrecy (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.
Checks: C-7504r378353_chk

Verify the IPsec VPN Gateway specifies Perfect Forward Secrecy (PFS) during Internet Key Exchange (IKE) negotiation. If the IPsec VPN Gateway does not specify Perfect Forward Secrecy (PFS) during Internet Key Exchange (IKE) negotiation, this is a finding.

Fix: F-7504r378354_fix

Configure the IPsec VPN Gateway to specify Perfect Forward Secrecy (PFS) during Internet Key Exchange (IKE) negotiation.

c
The VPN Gateway and Client must be configured to protect the confidentiality and integrity of transmitted information.
SC-8 - High - CCI-002418 - V-207245 - SV-207245r561344_rule
RMF Control
SC-8
Severity
H
CCI
CCI-002418
Version
SRG-NET-000371-VPN-001650
Vuln IDs
  • V-207245
  • V-97185
Rule IDs
  • SV-207245r561344_rule
  • SV-106323
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-1 to protect data integrity.
Checks: C-7505r378356_chk

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: F-7505r378357_fix

Configure the VPN Gateway and the remote access client to protect the confidentiality and integrity of transmitted information.

b
The IPsec VPN Gateway must 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.
SC-8 - Medium - CCI-002423 - V-207246 - SV-207246r561344_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002423
Version
SRG-NET-000375-VPN-001690
Vuln IDs
  • V-207246
  • V-97187
Rule IDs
  • SV-207246r561344_rule
  • SV-106325
ESP provides confidentiality, data origin authentication, integrity, and anti-replay services within the IPsec suite of protocols. ESP in tunnel mode ensures a secure path for communications for site-to-site VPNs and gateway to endpoints, including header information. ESP can be deployed in either transport or tunnel mode. Transport mode is used to create a secured session between two hosts. It can also be used when two hosts simply want to authenticate each IP packet with IPsec authentication header (AH). With ESP transport mode, only the payload (transport layer) is encrypted, whereas with tunnel mode, the entire IP packet is encrypted and encapsulated with a new IP header. Tunnel mode is used to encrypt traffic between secure IPsec gateways or between an IPsec gateway and an end-station running IPsec software. Hence, it is the only method to provide a secured path to transport traffic between remote sites or end-stations and the central site.
Checks: C-7506r378359_chk

Verify the IPsec VPN Gateway uses 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. If the IPsec VPN Gateway must 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: F-7506r378360_fix

Configure the IPsec VPN Gateway to 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.

b
For site-to-site VPN, for accounts using password authentication, the VPN Gateway must use FIPS-validated SHA-1 or later protocol to protect the integrity of the password authentication process.
IA-5 - Medium - CCI-000197 - V-207247 - SV-207247r561344_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000197
Version
SRG-NET-000400-VPN-001940
Vuln IDs
  • V-207247
  • V-97189
Rule IDs
  • SV-207247r561344_rule
  • SV-106327
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-131Ar1 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-1 for integrity of remote access sessions. For digital signature verification, SHA-1 is allowed for legacy-use. For all other hash function applications (e.g., HMAC, KDFs, RBG, password hashing, checksum integrity checks), the use of SHA-1 is acceptable, but discouraged in DoD. 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.
Checks: C-7507r378362_chk

For accounts using password authentication, verify the VPN Gateway uses FIPS-validated SHA-1 or later protocol to protect the integrity of the password authentication process. For accounts using password authentication, if the VPN Gateway does not use FIPS-validated SHA-1 or later protocol to protect the integrity of the password authentication process, this is a finding.

Fix: F-7507r378363_fix

For accounts using password authentication, configure the VPN Gateway to use FIPS-validated SHA-1 or later protocol to protect the integrity of the password authentication process.

b
The VPN Gateway must generate log records when successful and/or unsuccessful VPN connection attempts occur.
AU-12 - Medium - CCI-000172 - V-207248 - SV-207248r561344_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
SRG-NET-000492-VPN-001980
Vuln IDs
  • V-207248
  • V-97191
Rule IDs
  • SV-207248r561344_rule
  • SV-106329
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).
Checks: C-7508r378365_chk

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: F-7508r378366_fix

Configure the VPN Gateway to generate log records when successful and/or unsuccessful VPN connection attempts occur.

b
The VPN Gateway must use a FIPS-validated cryptographic module to generate cryptographic hashes.
SC-13 - Medium - CCI-002450 - V-207249 - SV-207249r561344_rule
RMF Control
SC-13
Severity
M
CCI
CCI-002450
Version
SRG-NET-000510-VPN-002160
Vuln IDs
  • V-207249
  • V-97193
Rule IDs
  • SV-207249r561344_rule
  • SV-106331
FIPS 140-2 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 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 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.
Checks: C-7509r378368_chk

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: F-7509r378369_fix

Configure the VPN Gateway to use a FIPS-validated cryptographic module to generate cryptographic hashes.

b
The VPN Gateway must use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.
SC-13 - Medium - CCI-002450 - V-207250 - SV-207250r561344_rule
RMF Control
SC-13
Severity
M
CCI
CCI-002450
Version
SRG-NET-000510-VPN-002170
Vuln IDs
  • V-207250
  • V-97195
Rule IDs
  • SV-207250r561344_rule
  • SV-106333
FIPS 140-2 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 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 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.
Checks: C-7510r378371_chk

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: F-7510r378372_fix

Configure the VPN Gateway to use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.

b
The IPsec VPN Gateway IKE must use NIST FIPS-validated cryptography to implement encryption services for unclassified VPN traffic.
SC-13 - Medium - CCI-002450 - V-207251 - SV-207251r561344_rule
RMF Control
SC-13
Severity
M
CCI
CCI-002450
Version
SRG-NET-000510-VPN-002180
Vuln IDs
  • V-207251
  • V-97197
Rule IDs
  • SV-207251r561344_rule
  • SV-106335
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.
Checks: C-7511r378374_chk

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: F-7511r378375_fix

Configure the IPsec VPN Gateway IKE to use NIST FIPS-validated cryptography to implement encryption services for unclassified VPN traffic.

c
The IPsec VPN Gateway must use Internet Key Exchange (IKE) for IPsec VPN Security Associations (SAs).
CM-6 - High - CCI-000366 - V-207252 - SV-207252r561344_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
SRG-NET-000512-VPN-002220
Vuln IDs
  • V-207252
  • V-97199
Rule IDs
  • SV-207252r561344_rule
  • SV-106337
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.
Checks: C-7512r378377_chk

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: F-7512r378378_fix

Configure the IPsec VPN Gateway to use IKE and IPsec VPN SAs.

c
The VPN Gateway must not accept certificates that have been revoked when using PKI for authentication.
CM-6 - High - CCI-000366 - V-207253 - SV-207253r561344_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
SRG-NET-000512-VPN-002230
Vuln IDs
  • V-207253
  • V-97201
Rule IDs
  • SV-207253r561344_rule
  • SV-106339
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.
Checks: C-7513r378380_chk

Verify the VPN Gateway does not accept certificates that have been revoked when using PKI for authentication. If the VPN Gateway accepts certificates that have been revoked when using PKI for authentication, this is a finding.

Fix: F-7513r378381_fix

Configure the VPN Gateway to not accept certificates that have been revoked when using PKI for authentication.

b
The VPN Client logout function must be configured to terminate the session on/with the VPN Gateway.
AC-12 - Medium - CCI-002363 - V-207254 - SV-207254r561344_rule
RMF Control
AC-12
Severity
M
CCI
CCI-002363
Version
SRG-NET-000518-VPN-002280
Vuln IDs
  • V-207254
  • V-97203
Rule IDs
  • SV-207254r561344_rule
  • SV-106341
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.
Checks: C-7514r378383_chk

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: F-7514r378384_fix

Configure the VPN Client logout log out function must be configured to terminate the session on/with the VPN Gateway.

b
The VPN Client must display an explicit logout message to users indicating the reliable termination of authenticated communications sessions.
AC-12 - Medium - CCI-002364 - V-207255 - SV-207255r561344_rule
RMF Control
AC-12
Severity
M
CCI
CCI-002364
Version
SRG-NET-000519-VPN-002290
Vuln IDs
  • V-207255
  • V-97205
Rule IDs
  • SV-207255r561344_rule
  • SV-106343
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.
Checks: C-7515r378386_chk

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: F-7515r378387_fix

Configure the VPN Client to display an explicit logout message to users indicating the reliable termination of authenticated communications sessions.

b
For site-to-site VPN Gateway must store only cryptographic representations of Pre-shared Keys (PSKs).
IA-5 - Medium - CCI-000196 - V-207256 - SV-207256r561344_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000196
Version
SRG-NET-000522-VPN-002320
Vuln IDs
  • V-207256
  • V-97207
Rule IDs
  • SV-207256r561344_rule
  • SV-106345
Pre-shared keys 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 should not be used as a replacement for two-factor CAC-enabled authentication. 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.
Checks: C-7516r378389_chk

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: F-7516r378390_fix

Configure the VPN Gateway to store only cryptographic representations of the PSK.

c
The IPsec VPN must use Advanced Encryption Standard (AES) encryption for the IPsec proposal to protect the confidentiality of remote access sessions.
AC-17 - High - CCI-000068 - V-207257 - SV-207257r561344_rule
RMF Control
AC-17
Severity
H
CCI
CCI-000068
Version
SRG-NET-000525-VPN-002330
Vuln IDs
  • V-207257
  • V-97209
Rule IDs
  • SV-207257r561344_rule
  • SV-106347
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. 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 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.
Checks: C-7517r378392_chk

Verify all Internet Key Exchange (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 IPsec proposal is not set to use an AES algorithm, this is a finding.

Fix: F-7517r378393_fix

Configure the IPsec Gateway to use AES for the IPsec proposal. The following example commands configure the IPsec (phase 2) proposals. The option may also be configured to use the aes-128-cbc, aes-192-cbc, or aes-256-cbc algorithms.

b
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.
AC-17 - Medium - CCI-001453 - V-207258 - SV-207258r561344_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001453
Version
SRG-NET-000530-VPN-002340
Vuln IDs
  • V-207258
  • V-97211
Rule IDs
  • SV-207258r561344_rule
  • SV-106349
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.
Checks: C-7518r378395_chk

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: F-7518r378396_fix

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.

b
The TLS VPN Gateway that supports citizen- or business-facing network devices must prohibit client negotiation to SSL 2.0 or SSL 3.0.
AC-17 - Medium - CCI-001453 - V-207259 - SV-207259r561344_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001453
Version
SRG-NET-000540-VPN-002350
Vuln IDs
  • V-207259
  • V-97213
Rule IDs
  • SV-207259r561344_rule
  • SV-106351
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.
Checks: C-7519r378398_chk

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: F-7519r378399_fix

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.

b
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.
IA-3 - Medium - CCI-001967 - V-207260 - SV-207260r561344_rule
RMF Control
IA-3
Severity
M
CCI
CCI-001967
Version
SRG-NET-000550-VPN-002360
Vuln IDs
  • V-207260
  • V-97215
Rule IDs
  • SV-207260r561344_rule
  • SV-106353
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.
Checks: C-7520r378401_chk

Verify the VPN Gateway that provides a Simple Network Management Protocol (SNMP) Network Management System (NMS) is configured to use SNMPv3 to use FIPS-validated AES cipher block algorithm. If the VPN Gateway that provides a Simple Network Management Protocol (SNMP) Network Management System (NMS) does not configure SNMPv3 to use FIPS-validated AES cipher block algorithm, this is a finding.

Fix: F-7520r378402_fix

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.

c
The VPN Gateway must use an approved High Assurance Commercial Solution for Classified (CSfC) cryptographic algorithm for remote access to a classified network.
SC-13 - High - CCI-002450 - V-207261 - SV-207261r561344_rule
RMF Control
SC-13
Severity
H
CCI
CCI-002450
Version
SRG-NET-000565-VPN-002390
Vuln IDs
  • V-207261
  • V-97217
Rule IDs
  • SV-207261r561344_rule
  • SV-106355
Use of improperly configured or lower assurance equipment and solutions could compromise high-value information. 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 the National Institute of Standards and Technology (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 Suite B implementations.
Checks: C-7521r378404_chk

Verify the VPN Gateway uses an approved High Assurance Commercial Solution for Classified (CSfC) cryptographic algorithm for remote access to a classified network. If the VPN Gateway does not use an approved High Assurance Commercial Solution for Classified (CSfC) cryptographic algorithm for remote access to a classified network, this is a finding.

Fix: F-7521r378405_fix

Configure the VPN Gateway to use an approved High Assurance Commercial Solution for Classified (CSfC) cryptographic algorithm for remote access to a classified network.

c
The IPsec VPN Gateway Internet Key Exchange (IKE) must use cryptography that is compliant with Suite B parameters when transporting classified traffic across an unclassified network.
SC-13 - High - CCI-002450 - V-207262 - SV-207262r561344_rule
RMF Control
SC-13
Severity
H
CCI
CCI-002450
Version
SRG-NET-000565-VPN-002400
Vuln IDs
  • V-207262
  • V-97219
Rule IDs
  • SV-207262r561344_rule
  • SV-106357
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. RFC 6379 Suite B Cryptographic Suites for IPsec defines four cryptographic user interface suites for deploying IPsec. Each suite provides choices for Encapsulating Security Payload (ESP) and IKE. The four suites are differentiated by the choice of IKE authentication and key exchange, cryptographic algorithm strengths, and whether ESP is to provide both confidentiality and integrity or integrity only. The suite names are based on the Advanced Encryption Standard (AES) mode and AES key length specified for ESP. Two suites are defined for transporting classified information up to SECRET level—one for both confidentiality and integrity and one for integrity only. There are also two suites defined for transporting classified information up to TOP SECRET level.
Checks: C-7522r378407_chk

Verify the IPsec VPN Gateway Internet Key Exchange (IKE) uses cryptography that is compliant with Suite B parameters when transporting classified traffic across an unclassified network. If the IPsec VPN Gateway Internet Key Exchange (IKE) does not use cryptography that is compliant with Suite B parameters when transporting classified traffic across an unclassified network, this is a finding.

Fix: F-7522r378408_fix

Configure the IPsec VPN Gateway Internet Key Exchange (IKE) to use cryptography that is compliant with Suite B parameters when transporting classified traffic across an unclassified network.

b
The VPN Gateway must validate certificates used for Transport Layer Security (TLS) functions by performing RFC 5280-compliant certification path validation.
IA-5 - Medium - CCI-000185 - V-207263 - SV-207263r561344_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000185
Version
SRG-NET-000580-VPN-002410
Vuln IDs
  • V-207263
  • V-97221
Rule IDs
  • SV-207263r561344_rule
  • SV-106359
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.
Checks: C-7523r378410_chk

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: F-7523r378411_fix

Configure the VPN Gateway to validate certificates used for TLS functions by performing RFC 5280-compliant certification path validation.

b
The VPN Gateway must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use).
IA-7 - Medium - CCI-000803 - V-207264 - SV-207264r561344_rule
RMF Control
IA-7
Severity
M
CCI
CCI-000803
Version
SRG-NET-000585-VPN-002420
Vuln IDs
  • V-207264
  • V-97223
Rule IDs
  • SV-207264r561344_rule
  • SV-106361
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Use only SHA-2 for Digital signature generation applications and functions. SHA-2 is strongly preferred for use by DoD for non-signature generation functions. Although allowed by SP800-131Ar1 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-1 for integrity of remote access sessions. For digital signature verification, SHA-1 is allowed for legacy-use. For all other hash function applications (e.g., HMAC, KDFs, RBG, password hashing, checksum integrity checks), the use of SHA-1 is acceptable, but discouraged in DoD. To protect the integrity of the authenticator and authentication mechanism used for the cryptographic module used by the network device, the application, operating system, or protocol must be configured to use one of the following hash functions for hashing the password or other authenticator in accordance with SP 800-131Ar1: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3-384, and SHA3-512. For digital signature verification, SP800-131Ar1 allows SHA-1 for legacy use only if needed for business critical applications.
Checks: C-7524r378413_chk

Verify the VPN Gateway uses FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use). If the VPN Gateway does not use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use), this is a finding.

Fix: F-7524r378414_fix

Configure the VPN Gateway to use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use).