{"stig":{"title":"Ivanti Connect Secure VPN Security Technical Implementation Guide","version":"2","release":"2"},"checks":[{"vulnId":"V-258583","ruleId":"SV-258583r1117237_rule","severity":"medium","ruleTitle":"The ICS must be configured to ensure inbound and outbound traffic is configured with a security policy in compliance with information flow control policies.","description":"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.\n\nVPN 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.","checkContent":"In the ICS Web UI, navigate to Users >> Resource Policies >> VPN Tunneling >> Access Control.\n1. Verify that an Access Control Policy exists.\n2. Verify the Access Control Policy is not configured to allows all IPv4/IPv6 addresses or all TCP/UDP ports.\n\nIf the ICS does not use one or more Access Control Policies to restrict inbound and outbound traffic compliance with the sites documented information flow control policy, this is a finding.","fixText":"Establish Access Control policy in accordance with the site's system security plan. Policies will vary based on security policies and architecture.\n\nIn the ICS Web UI, navigate to Users >> Resource Policies >> VPN Tunneling >> Access Control.\n1. Click \"New Policy\".\n2. Enter a name.\n3. Under IPv4 Resources, add all allowed ports and protocols required for users. Examples provided below:\n- For ICMP configure the following: icmp://10.0.0.0/255.255.255.0 to allow ICMP communications for the 10.0.0.0/24 subnet.\n- For TCP configure the following: tcp://*:80,443 to allow TCP communications for all IPv4 addresses going to TCP port 80 and 443 (web traffic).\n- For UDP configure the following: udp://10.0.0.0/255.255.255.0:53,123 to allow UDP communications for the 10.0.0.0/24 IPv4 addresses going to UDP port 53 (DNS) and 123 (NTP).\n4. Under IPv6 Resources, add all allowed ports and protocols required for users. Examples provided below:\n- For ICMP configure the following: icmpv6://[2001:db8:1::/64] to allow ICMPv6 communications for the 2001:db8:1::/64 subnet.\n- For TCP configure the following: tcp://[*]:80,443 to allow TCP communications for all IPv6 addresses going to TCP port 80 and 443 (web traffic).\n- For UDP configure the following: udp://[2001:db8:2::/64]:53,123 to allow UDP communications for the 2001:db8:2::/64 IPv6 addresses going to UDP port 53 (DNS) and 123 (NTP).\n5. For FQDN, add specific URLs to allow, if needed.\n6. Select \"Policy applies to SELECTED roles\" and select the role that remote access VPN users are assigned. If there are multiple, select each one and click \"Add\".\n7. Click \"Allow Access\".\n8. Click \"Save Changes\".","ccis":["CCI-001414"]},{"vulnId":"V-258584","ruleId":"SV-258584r1056127_rule","severity":"medium","ruleTitle":"The ICS must display the Standard Mandatory DOD Notice and Consent Banner before granting access to users.","description":"Display of the DOD-approved use notification before granting access to the network device ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSatisfies: SRG-NET-000041-VPN-000110, SRG-NET-000042-VPN-000120, SRG-NET-000043-VPN-000130","checkContent":"Determine if the network device is configured to present a DOD-approved banner that is formatted in accordance with DTM-08-060. Verify the remote access VPN user access sign-in notice is configured and displayed. This may or may not be the same as the admin portal.\n\n1. In the ICS Web UI, navigate to Authentication >> Signing In >> Sign-In Notifications.\n\nVerify the use of the following verbiage for applications that can accommodate banners of 1300 characters:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-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.\n-At any time, the USG may inspect and seize data stored on this IS.\n-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.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-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\".\n\nUse the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:\n\"I've read & consent to terms in IS user agreem't\".\n\n2. In the ICS Web UI, navigate to Authentication >> Signing In >> Sign-In Policies.\n3. Click the \"*/\" (or whatever custom URL is used for remote access VPN user access).\n\nUnder \"Configure SignIn Notifications\", if the \"Pre-Auth Sign-in Notification\" is not checked, or if the previously mentioned notification text is not assigned to this policy, this is a finding.","fixText":"Configured to present a DOD-approved banner that is formatted in accordance with DTM-08-060. Configure the remote access VPN user access sign-in notice. This may or may not be the same as the admin portal.\n\nIn the ICS Web UI, navigate to Authentication >> Signing In >> Sign-In Notifications.\n1. Click \"New Notification\".\n2. For name, type: \"DOD Notice and Consent\".\n3. In the text box type the following:\n\"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:\n- 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.\n- At any time, the USG may inspect and seize data stored on this IS.\n- 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.\n- This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.\n- 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\".\n4. Click \"Save Changes\".\n5. Go to Authentication >> Signing In >> Sign-In Policies.\n6. Click the \"*/\" (or whatever custom URL is used for remote access VPN user access).\n7. Under \"Configure SignIn Notifications\", check the box for \"Pre-Auth Sign-in Notification\" in the drop-down menu, and assign the notification titled \"DOD Notice and Consent\".","ccis":["CCI-000048","CCI-000050","CCI-001384","CCI-001385","CCI-001386","CCI-001387","CCI-001388"]},{"vulnId":"V-258585","ruleId":"SV-258585r997504_rule","severity":"medium","ruleTitle":"The ICS must be configured to limit the number of concurrent sessions for user accounts to one.","description":"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 denial-of-service (DoS) attacks.\n\nThis 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.\n\nThe 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.","checkContent":"In the ICS Web UI, navigate to Users >> User Realms >> User Realms.\n1. If using the default user realm, click \"User\". Otherwise, click the configured user realm that will be used for user remote access VPN using DOD CAC authentication.\n2. Click the \"Authentication Policy\" tab, then click \"Limits\".\n\nIf the ICS does not limit the number of concurrent sessions for user accounts to \"1\", this is a finding.","fixText":"In the ICS Web UI, navigate to Users >> User Realms >> User Realms.\n1. If using the default user realm, click \"User\". Otherwise, click the configured user realm that will be used for user remote access VPN using DOD CAC authentication.\n2. Click the \"Authentication Policy\" tab, then click \"Limits\".\n3. In \"Maximum number of sessions per user\", type the number \"1\".\n4. Click \"Save Changes\".","ccis":["CCI-000054","CCI-004866"]},{"vulnId":"V-258586","ruleId":"SV-258586r997505_rule","severity":"high","ruleTitle":"The ICS must be configured to use TLS 1.2, at a minimum.","description":"Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol.\n\nNIST SP 800-52 Rev2 provides guidance for client negotiation on either DOD-only or public-facing servers.\n\nSatisfies: SRG-NET-000062-VPN-000200, SRG-NET-000371-VPN-001650, SRG-NET-000530-VPN-002340, SRG-NET-000540-VPN-002350","checkContent":"Determine if the ICS uses TLS 1.2 to protect remote access transmissions.\n\nIn the ICS Web UI, navigate to System >> Configuration >> Inbound SSL Options.\n1. Under Allowed SSL and TLS Version, verify \"Accept only TLS 1.2 (maximize security)\" is checked.\n2. Navigate to System >> Configuration >> Outbound SSL Options.\n3. Under Allowed SSL and TLS Version, verify \"Accept only TLS 1.2 (maximize security)\" is checked.\n\nIf the ICS does not use TLS 1.2, at a minimum, this is a finding.","fixText":"Configure the ICS to uses TLS 1.2 to protect remote access transmissions.\n\nIn the ICS Web UI, navigate to System >> Configuration >> Inbound SSL Options.\n1. Under Allowed SSL and TLS Version, check the box for \"Accept only TLS 1.2 (maximize security)\".\n2. Click \"Save Changes\".\n3. Click \"Proceed\" for acceptance of Cipher Change.\n\nNavigate to System >> Configuration >> Outbound SSL Options.\n1. Under Allowed SSL and TLS Version, check the box for \"Accept only TLS 1.2 (maximize security)\".\n2. Click \"Save Changes\".\n3. Click \"Proceed\" for acceptance of Cipher Change.","ccis":["CCI-000068","CCI-001453","CCI-002418","CCI-004891"]},{"vulnId":"V-258587","ruleId":"SV-258587r930449_rule","severity":"low","ruleTitle":"The ICS must be configured to generate log records containing sufficient information about where, when, identity, source, or outcome of the events.","description":"Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nVPN 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).\n\nAssociating 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.\n\nSatisfies: SRG-NET-000078-VPN-000290, SRG-NET-000079-VPN-000300, SRG-NET-000088-VPN-000310, SRG-NET-000089-VPN-000330, SRG-NET-000091-VPN-000350, SRG-NET-000077-VPN-000280, SRG-NET-000313-VPN-001050, SRG-NET-000492-VPN-001980","checkContent":"In the ICS Web UI, navigate to System >> Log/Monitoring >> User Access >> Settings.\n\nUnder \"Select Events to Log\", verify all items are checked.\n\nIf the ICS must be configured to generate log records containing information investigate the events, this is a finding.","fixText":"In the ICS Web UI, navigate to System >> Log/Monitoring >> User Access >> Settings.\n1. Under \"Select Events to Log\", check all items.\n2. Set the standard filer.\n3. Click \"Add\".\n4. Click \"Save Changes\".\n\nNote: If the site uses SNMP, the configuration can be used in conjunction with this requirement which is recommended. By default, SNMP is disabled. The device only supports Simple Network Management Protocol version 3 (SNMPv3) in a DOD configuration. The device supports queries only, traps only, or both when enabling SNMP. Refer to SRG-NET-000335-VPN-001270 for configuration.","ccis":["CCI-000130","CCI-000131","CCI-000132","CCI-000133","CCI-000134","CCI-000172","CCI-001487","CCI-002314"]},{"vulnId":"V-258588","ruleId":"SV-258588r930452_rule","severity":"medium","ruleTitle":"The ICS must be configured to uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).","description":"To ensure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system.\n\nOrganizational 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.\n\n(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\n\n(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.\n\nThis 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).","checkContent":"In the ICS Web UI, navigate to Users >> User Realms >> User Realms.\n1. Click the user realm that is currently being used on the ICS for standard remote access VPN logins.\n2. View \"General\" tab, under Servers >> Authentication. Verify a certificate authentication server is configured.\n3. View \"General\" tab, under Servers >> Directory/Attribute. Verify there is an entry defined.\n4. View \"Role Mapping\" tab, under \"when users meet these conditions\", verify \"Group\" is used with the local user active directory group selected and assigned to the role that was created.\n\nIf the ICS does not use DOD PKI for network access to nonprivileged accounts, this is a finding.","fixText":"Configure an authentication server for the user realm.\n\nIn the ICS Web UI, navigate to Users >> User Realms >> User Realms.\n1. Click the user realm that is currently being used on the ICS for standard remote access VPN logins.\n2. In the \"General\" tab, under Servers >> Authentication.\n3. Click \"New Servers\". Under \"server type\", select Certificate Server >> New Server.\n4. Type a Name, then under User Name template type this exactly: <certAttr.altname.UPN>\n5. Click \"Save Changes\".\n6. Navigate to Authentication >> Auth Servers.\n7. Click \"New Servers\". Under \"server type\", select LDAP Server >> New Server.\n8. Type a name for the primary LDAP server domain.\n9. LDAP server: the FQDN of the server (an IP address may cause an error as the LDAP server certificate might not have an IP in the SAN field).\n10. LDAP port: 636 (this is for LDAPS).\n11. Backup LDAP Server1: the FQDN of the secondary server (an IP address may cause an error as the LDAP server certificate might not have an IP in the SAN field).\n12. Backup LDAP Port1: 636.\n13. If a third LDAP server is needed, add this and the port info under Backup LDAP Server2 and Backup LDAP Port2.\n14. LDAP Server Type: Active Directory.\n15. Connection: LDAPS.\n16. Ensure \"Validate Server Certificate\" is checked.\n17. Connection Timeout: 15.\n18. Search Timeout: 60.\n19. Scroll down to the bottom and click \"Save Changes\". Click \"Test Settings\" to ensure valid communications are possible.\nNOTE: If there are failures in this testing, ensure that the step for Device Certificates and Trusted Server CAs were completed, as this will cause LDAPS certificate issues.\n20. Under \"authentication required\", click the box for \"Authentication required\" to search LDAP.\n21. Enter the service account's Admin DN using this as an example format: CN=PCS.SVC,OU=IVANTI,DC=DOD,DC=mil\n22. Enter the service account's password.\n23. Under \"Finding user entries\", add the base DN of the domain as an example format: DC=DOD,DC=mil\n24. Under \"filter\", use this specific attribute configuration: userPrincipalName=<USER>\n25. Under \"group membership\", add the base DN of where admin users that will access, using this as an example format: OU=IVANTI,DC=DOD,DC=mil\n26. Under \"filter\", use the following: cn=<GROUPNAME>\n27. Under \"member attribute\", use the following: member.\n28. Click \"Save Changes\".\n29. In the same LDAP server configuration screen, scroll down and click the \"Server Catalog\" hyperlink.\n30. Under \"attributes\", click \"New\", Type: userPrincipalName, and click \"Save Changes\".\n31. Under \"groups\", click \"Search\". In the search box, type the group name used for user logins.\n32. Check the box next to the group that is found and click \"Add Selected\".\n33. Repeat these steps for all various groups needed for various user/computer roles on the ICS system.\n34. Click \"Save Changes\".","ccis":["CCI-000764"]},{"vulnId":"V-258589","ruleId":"SV-258589r954210_rule","severity":"high","ruleTitle":"The ICS must be configured to use multifactor authentication (e.g., DOD PKI) for network access to nonprivileged accounts.","description":"To ensure accountability and prevent unauthenticated access, nonprivileged users must use multifactor authentication to prevent potential misuse and compromise of the system.\n\nMultifactor authentication uses two or more factors to achieve authentication. Use of password for user remote access for nonprivileged account is not authorized.\n\nFactors include:\n(i) Something you know (e.g., password/PIN);\n(ii) Something you have (e.g., cryptographic identification device, token); or\n(iii) Something you are (e.g., biometric).\n\nA nonprivileged account is any information system account with authorizations of a nonprivileged user.\n\nNetwork access is any access to a network element by a user (or a process acting on behalf of a user) communicating through a network.\n\nThe DOD CAC with DOD-approved PKI is an example of multifactor authentication.\n\nSatisfies: SRG-NET-000140-VPN-000500, SRG-NET-000342-VPN-001360","checkContent":"In the ICS Web UI, navigate to Users >> User Realms >> User Realms.\n1. Click the user realm that is currently being used on the ICS for standard remote access VPN logins.\n2. View \"General\" tab, under Servers >> Authentication. Verify a certificate authentication server is configured.\n3. View \"General\" tab, under Servers >> Directory/Attribute. Verify there is an entry defined.\n4. View \"Role Mapping\" tab, under \"when users meet these conditions\", verify \"Group\" is used with the local user active directory group selected and assigned to the role that was created.\n\nIf the ICS does not use DOD PKI for network access to nonprivileged accounts, this is a finding.","fixText":"Configure the user realm to use DOD PKI and the site's authentication servers. A sign-in policy is then applied in accordance with the site's access configuration. The focus for this requirement is on the path so the installation of the device certificates is not included.\n\nIn the ICS Web UI, navigate to Authentication >> Auth Servers.\n1. Click \"New Servers\". Under \"server type\", select Certificate Server >> New Server.\n2. Type a Name. Under User Name template type this exactly: <certAttr.altname.UPN>\n3. Click \"Save Changes\".\n4. Navigate to Authentication >> Auth Servers.\n5. Click \"New Servers\". Under \"server type\", select LDAP Server >> New Server.\n6. Type a name for the primary LDAP server domain.\n7. LDAP server: the FQDN of the server (an IP address may cause an error as the LDAP server certificate might not have an IP in the SAN field).\n8. LDAP port: 636 (this is for LDAPS).\n9. Backup LDAP Server1: the FQDN of the secondary server (an IP address may cause an error as the LDAP server certificate might not have an IP in the SAN field).\n10. Backup LDAP Port1: 636.\n11. If a third LDAP server is needed, add this and the port info under Backup LDAP Server2 and Backup LDAP Port2.\n12. LDAP Server Type: Active Directory.\n13. Connection: LDAPS.\n14. Ensure Validate Server Certificate is checked.\n15. Connection Timeout: 15.\n16. Search Timeout: 60.\n17. Scroll down to the bottom and click \"Save Changes\". Click \"Test Settings\" to ensure valid communications are possible.\nNOTE: If there are failures in this testing, ensure that the step for Device Certificates and Trusted Server CAs were completed as this will cause LDAPS certificate issues.\n18. Under authentication required, click the box for Authentication required to search LDAP.\n19. Enter the service account's Admin DN using this as an example format: CN=PCS.SVC,OU=IVANTI,DC=DOD,DC=mil\n20. Enter the service account's password.\n21. Under \"Finding user entries\", add the base DN of the domain as an example format: DC=DOD,DC=mil\n22. Under \"filter\", use this specific attribute configuration: userPrincipalName=<USER>\n23. Under \"group membership\", add the base DN of where admin users that will access, using this as an example format: OU=IVANTI,DC=DOD,DC=mil\n24. Under \"filter\", use the following: cn=<GROUPNAME>\n25. Under \"member attribute\", use the following: member.\n26. Click \"Save Changes\".\n27. Now back in the same LDAP server configuration screen, scroll down and click the \"Server Catalog\" hyperlink.\n28. Under \"attributes\", click \"New\", Type: userPrincipalName, and click \"Save Changes\".\n29. Under \"groups\", click \"Search\". In the search box, type the group name used for user logins.\n30. Check the box next to the group that is found and click \"Add Selected\".\n31. Repeat these steps for all various groups needed for various user/computer roles on the ICS system.\n\nIn the ICS Web UI, navigate to Users >> Users Realms.\n1. Click the user realm being used for remote access VPN logins.\n2. Under \"servers\", go to \"Authentication\" and select the certificate authentication realm created that included the customized User template of <certAttr.altname.UPN>.\n3. Under \"Directory/Attribute\", select the previously created LDAP server.\n4. Check the box for \"Enable dynamic policy evaluation\".\n5. Check both the \"Refresh roles\" and \"refresh resource policies\".\n6. Click \"Save Changes\".\n7. Go to the \"Role Mapping\" tab.\n8. Click \"New Rule\".\n9. Select \"Rule based on Group Membership\" and click \"Update\".\n10. Type a name for this rule.\n11. Select \"is\".\n12. Type the group name exactly as it appears as the CN LDAP attribute.\n13. Select the role needed for these VPN logins.\n14. Click \"Save Changes\".","ccis":["CCI-000766","CCI-001954"]},{"vulnId":"V-258590","ruleId":"SV-258590r930458_rule","severity":"medium","ruleTitle":"The ICS, when utilizing PKI-based authentication, must be configured to validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.","description":"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.\n\nA 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 nonlocal and remote management of DOD information systems.\n\nUse 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.\n\nWhen 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.\n\nThis 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.\n\nSatisfies: SRG-NET-000164-VPN-000560, SRG-NET-000512-VPN-002230, SRG-NET-000580-VPN-002410","checkContent":"In the ICS Web UI, navigate to System >> Configuration >> Certificates >> Trusted Client CAs.\n1. Click the first DOD client CA.\n2. Verify the item \"Use OCSP with CRL fallback\" is selected under the \"Client certificate status checking\" setting.\n3. Check each client certificate CA. Verify the setting \"Use OCSP with CRL fallback\" is selected.\n\nFor PKI-based authentication, if the ICS does not validate certificates by constructing a certification path (which includes revocation status information) to an accepted trust anchor, this is a finding.","fixText":"Configure status checking on the ICS. The focus for this requirement is on the path, so the installation of the device certificates is not included.\n\nIn the ICS Web UI, navigate to System >> Configuration >> Certificates >> Trusted Client CAs.\n1. Click the first DOD client CA.\n2. Enable \"Use OCSP with CRL fallback\" under \"Client certificate status checking\".\n3. Repeat these steps for every remaining client certificate CA.","ccis":["CCI-000185","CCI-000366"]},{"vulnId":"V-258591","ruleId":"SV-258591r1136932_rule","severity":"medium","ruleTitle":"The ICS must terminate remote access network connections after 10 minutes or less.","description":"Best practice is to terminate inactive user sessions after a period; however, when setting timeouts to any VPN connection, the organization must consider the risk to the mission and purpose of the VPN. VPN connections that provide user access to the network are the prime candidates for VPN session termination and the primary focus of this requirement.\n\nTo determine if and when the VPN connections warrant termination, the organization must perform a risk assessment to identify the use case for the VPN and determine if periodic VPN session termination puts the mission at significant risk.\n\nThe organization must document the results and the determination of the risk assessment in the VPN section of the SSP. The organization must also configure VPN session terminations in accordance with the risk assessment.\n\nTerminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element.\n\nTerminating network connections associated with communications sessions includes, for example, deallocating associated TCP/IP address/port pairs at the operating system level and deallocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection.","checkContent":"Verify the user role being used for CAC/PKI token VPN client logins is configured with a session timeout.\n\nIn the ICS Web UI, navigate to Administrators >> Users Roles >> User Roles.\n1. Click the configured user role being used for CAC/PKI token VPN client logins.\n2. Click the \"Session Options\" tab.\n\nIn the \"Session Lifetime\" section, if Idle Timeout is not set to \"10\", this is a finding.","fixText":"Configure the user role being used for CAC/PKI token VPN client logins with a session timeout.\n\nIn the ICS Web UI, navigate to Administrators >> Users Roles >> User Roles.\n1. Click the configured user role being used for CAC/PKI token VPN client logins.\n2. Click the \"Session Options\" tab.\n3. In the \"Session Lifetime\" section, set the Idle Timeout to \"10\".\n4. Click \"Save Changes\".","ccis":["CCI-000057","CCI-001133"]},{"vulnId":"V-258592","ruleId":"SV-258592r930464_rule","severity":"medium","ruleTitle":"The ICS must be configured to send user traffic log data to redundant central log server.","description":"The aggregation of log data kept on a syslog server can be used to detect attacks and trigger an alert to the appropriate security personnel. The stored log data can used to detect weaknesses in security that enable the network IA team to find and address these weaknesses before breaches can occur. Reviewing these logs, whether before or after a security breach, are important in showing whether someone is an internal employee or an outside threat.\n\nThis requirement applies only 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).","checkContent":"Verify user access log events are being sent to the central log server.\n\nIn the ICS Web UI, navigate to System >> Log/Monitoring >> User Access >> Settings.\n1. Under \"Select Events to Log\", verify all items are checked.\n2. Under \"Syslog Servers\", verify redundant server name/IP address, facility of LOCAL0, type TLS, and the source interface are defined.\n\nIf the ICS must be configured to send admin log data to redundant central log server, this is a finding.","fixText":"Direct user access log events to the central log server.\n\nIn the ICS Web UI, navigate to System >> Log/Monitoring >> User Access >> Settings.\n1. Under \"Select Events to Log\", check all items.\n2. Under \"Syslog Servers\", add an IP address/server name/IP.\n3. Set the facility to \"LOCAL0\".\n4. Set type to \"TLS\".\n5. If a client cert is required for the syslog server, select the client certificate to use for the syslog traffic. If none exists, import the DOD-signed client key pair to the ICS under System >> Configuration >> Certificates >> Client Auth Certificates.\n6. Set the standard filer.\n7. Set the source interface as either the management or internal interface.\n8. Click \"Add\".\n9. Click \"Save Changes\".\n10. Repeat these steps to add a redundant syslog server for user log events.","ccis":["CCI-001851"]},{"vulnId":"V-258593","ruleId":"SV-258593r930467_rule","severity":"medium","ruleTitle":"The ICS must be configured to forward all log failure events where the detection and/or prevention function is unable to write events to local log record or send an SNMP trap that can be forwarded to the SCA and ISSO.","description":"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.\n\nAlerts 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.\n\nThe VPN daemon facility and log facility are messages in the log, which capture actions performed or errors encountered by system processes.","checkContent":"If SNMP is used, verify the configuration is compliant. If SNMP is not used, this is not a finding.\n\nIn the ICS Web UI, navigate to System >> Log/Monitoring >> SNMP.\n1. Under \"Agent Properties\", verify \"SNMP Traps\" is checked.\n2. Under \"SNMP Version data\", verify \"v3\" is selected.\n3. Under \"User 1\", verify a user configuration in AuthPriv is using at least SHA and CFB-AES-128.\n4. Verify \"Optional Traps Critical and Major Log Events\" are checked.\n5. Verify the SNMP server IPv4/IPv6 address is configured under \"SNMP Trap Servers\".\n\nIf SNMP is incorrectly configured, this is a finding.","fixText":"Event logs are also updated to local logs by default in addition to the central syslog server. However, if the site uses SNMP, the following must be configured since SNMP is disabled by default.\n\nIn the ICS Web UI, navigate to System >> Log/Monitoring >> SNMP.\n1. Under \"SNMP Version data\", select \"v3\".\n2. Under \"Agent Properties\", check \"SNMP Traps\".\n3. Under \"Agent Properties\", configure a System Name, Location, and Contact.\n4. Under \"User 1\", type in a valid username. Select \"AuthPriv\".\n- The auth protocol must be set to at least SHA. Type the Auth Password.\n- The priv protocol must be set to at least CFB-AES-128. Type in the priv password.\n5. Under \"Trap Thresholds\", ensure \"Check Frequency\" is 180 seconds, \"Log Capacity\" is 75%, \"Users\" is 100%, \"Physical Memory\" is 0%, \"Swap Memory\" is 0%, \"Disk\" is 75%, \"CPU\" is 0%, and \"Meeting Users\" is 100%.\n6. Under \"Optional Traps\", check the boxes for \"Critical and Major Log Events\".\n7. Under \"SNMP Trap Servers\", configure an IPv4/IPv6 address for the valid trap server/receiver, type in the port (default is 162), and select the user to use (use the user from step #4 above).","ccis":["CCI-001858"]},{"vulnId":"V-258594","ruleId":"SV-258594r930470_rule","severity":"medium","ruleTitle":"The ICS must be configured to authenticate all clients before establishing a connection.","description":"Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.\n\nFor ICS, user authentication uses authentication servers, realms, roles, and sign-in policies. To the device, both machine and user authentication are treated as user logins and certificates (machine certs and CAC) are supported for authentication. Although both machine and human users are considered \"users\" to the device. The system supports separating admin from user/computer authentication by duplicating auth servers and only associating a single server to an admin realm or a user realm but not both. This supports the DOD best practice of authenticating admin authentication using a separate authentication server from user authentication.","checkContent":"Verify client certificates are installed and assigned to applicable user/computer realm to enable client authentication for all remote clients.\n\nIn the Ivanti ICS Web UI, navigate to Users >> User Realms >> User Realms.\n1. Click the user realm that is currently being used on the ICS for standard remote access VPN logins.\n2. In the \"General\" tab, under Servers >> Authentication, verify it is defined with a certificate authenticate server.\n3. In the \"General\" tab, under Servers >> Directory/Attribute, verify \"none\" is not displayed.\n4. In the \"Role Mapping\" tab, under \"when users meet these conditions\", verify \"Group\" must be used, and the local site's administrator active directory group must be selected and assigned to the role that was created.\n\nIf the ICS is not configured to authenticate all client devices before establishing a connection, this is a finding.","fixText":"Configure client certificates and enable them on an appropriate user/computer realm to enable client authentication.\n\nIn the Ivanti ICS Web UI, navigate to System >> Configuration >> Certificates >> Trusted Server CAs.\n1. Click \"Import Trusted Server CAs\".\n2. Import the Active Directory root CA certificate by clicking \"Browse\", selecting the certificate file, and clicking \"Import Certificate\".\n3. Repeat these steps for the intermediate CA certificate.\nNOTE: these certificates could be DOD-signed CA certificates, or they could be internal private CA certificates. Import certificates based on the use case of the site.\n\nIn the Ivanti ICS Web UI, navigate to System >> Configuration >> Certificates >> Trusted Client CAs.\n1. Click \"Import CA Certificate\".\n2. Import the DOD Client CAC root CA certificate by clicking \"Browse\", selecting the certificate file, and clicking \"Import Certificate\" (e.g., \"DOD Root CA 3\").\n3. Repeat these steps for the intermediate/issuing CAC CA certificate (e.g., \"DOD ID CA 59\").\n4. Repeat these steps for each intermediate CAC CA certificate.\n5. Click the Root CA certificate that was imported.\n6. Under client certificate status checking, ensure the following is set:\n- Use OCSP with CRL Fallback.\n- \"Trusted for client Authentication\" must be checked.\n7. Optionally, if the network the site is in must use a local OCSP repeater/responder, go to OCSP settings. Otherwise, move on to the Device Certificates.\n8. Click \"OSCP options\". Use \"Manually Configured\" responders.\n9. Enter the URL for the primary and backup OCSP responder.\n10. Optionally, if the OCSP responder requires request signing and nonce usage, select those here.\n\nIn the Ivanti ICS Web UI, navigate to System >> Configuration >> Certificates >> Device Certificates.\n1. Click \"New CSR\".\n2. Under Common Name, ensure this has the FQDN for the ICS server, then fill out all other items.\n3. If using RSA, select \"2048\". If using ECC, select \"P-384\".\nIMPORTANT NOTE: If the remote access VPN is carrying classified data, the certificate and key being used by ICS MUST be an ECC P-384 key pair.\n4. Click \"Create CSR\". Export the CSR and import it into the DOD site's Registration Authority (RA). Ensure that Subject Alternative Names (SANs) are created for all FQDNs, server names, and cluster names on the web enrollment form.\n5. Once the certificate is approved, download it and import it in this same section of the ICS.\n\nIn the Ivanti ICS Web UI, navigate to Authentication >> Auth Servers\n1. Click \"New Servers\". Under \"server type\", select Certificate Server >> New Server.\n2. Type a Name. Under User Name template type this exactly: <certAttr.altname.UPN>\n3. Click \"Save Changes\".\n4. Navigate to Authentication >> Auth Servers.\n5. Click \"New Servers\". Under \"server type\", select LDAP Server >> New Server.\n6. Type a name for the primary LDAP server domain.\n7. LDAP server: the FQDN of the server (an IP address may cause an error as the LDAP server certificate might not have an IP in the SAN field).\n8. LDAP port: 636 (this is for LDAPS).\n9. Backup LDAP Server1: the FQDN of the secondary server (an IP address may cause an error as the LDAP server certificate might not have an IP in the SAN field).\n10. Backup LDAP Port1: 636.\n11. If a third LDAP server is needed, add this and the port info under Backup LDAP Server2 and Backup LDAP Port2.\n12. LDAP Server Type: Active Directory.\n13. Connection: LDAPS.\n14. Ensure Validate Server Certificate is checked.\n15. Connection Timeout: 15.\n16. Search Timeout: 60.\n17. Scroll down to the bottom and click \"Save Changes\". Click \"Test Settings\" to ensure valid communications are possible.\nNOTE: If there are failures in this testing ensure that the step for Device Certificates and Trusted Server CAs were completed, as this will cause LDAPS certificate issues.\n18. Under authentication required, click the box for \"Authentication required\" to search LDAP.\n19. Enter the service account's Admin DN using this as an example format: CN=PCS.SVC,OU=IVANTI,DC=DOD,DC=mil\n20. Enter the service account's password.\n21. Under \"Finding user entries\", add the base DN of the domain as an example format: DC=DOD,DC=mil\n22. Under \"filter\", use this specific attribute configuration: userPrincipalName=<USER>\n23. Under \"group membership\", add the base DN of where admin users that will access, using this as an example format: OU=IVANTI,DC=DOD,DC=mil\n24. Under \"filter\", use the following: cn=<GROUPNAME>\n25. Under \"member attribute\", use the following: member\n26. Click Save \"Changes\".\n27. Now back in the same LDAP server configuration screen, scroll down and click the \"Server Catalog\" hyperlink.\n28. Under \"attributes\", click \"New\", Type: userPrincipalName, and click \"Save Changes\".\n29. Under \"groups\", click \"Search\". In the search box, type the group name used for admin logins.\n30. Check the box next to the group that is found and click \"Add Selected\".\n31. Repeat these steps for all various groups needed for various roles on the ICS system. For example, groups for auditors, ISSOs, NOC, SOC, Viewer, etc.\n32. Click \"Save Changes\".\n\nIn the Ivanti ICS Web UI, navigate to Users >> Users Realms.\n1. Click the user realm being used for remote access VPN logins.\n2. Under \"servers\", go to \"Authentication\" and select the certificate authentication realm created that included the customized User template of <certAttr.altname.UPN>.\n3. Under \"Directory/Attribute\", select the previously created LDAP server.\n4. Check the box for \"Enable dynamic policy evaluation\".\n5. Check both the \"Refresh roles\" and \"refresh resource policies\".\n6. Click \"Save Changes\".\n7. Go to the \"Role Mapping\" tab.\n8. Click \"New Rule\".\n9. Select \"Rule based on Group Membership\" and click \"Update\".\n10. Type a name for this rule.\n11. Select \"is\".\n12. Type the group name exactly as it appears as the CN LDAP attribute.\n13. Select the role needed for these VPN logins.\n14. Click \"Save Changes\".\n\nIn the Ivanti ICS Web UI, navigate to Authentication >> Sign-in >> Sign-in Policies.\n1. Create a New URL or edit the */ URL (depending on the site).\nNOTE: it is recommended to create a new sign-in URL until this configuration is fully tested to ensure there is still web UI reachability in the troubleshooting process.\n2. Under authentication realm, click the \"User picks from a list of authentication realms\".\n3. Click \"Save Changes\".\n\nTest and verify the connection with CAC/Alt Token and LDAPS by attempting a remote access VPN web UI login using the token or CAC and entering the sign-in URL. Once successful, the user will click on the ICS client for completing the login connection.","ccis":["CCI-001958"]},{"vulnId":"V-258595","ruleId":"SV-258595r1117244_rule","severity":"medium","ruleTitle":"The ICS must be configured to use an approved Commercial Solution for Classified (CSfC) when transporting classified traffic across an unclassified network.","description":"Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data.\n\nThe 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.\n\nSatisfies: SRG-NET-000352-VPN-001460, SRG-NET-000565-VPN-002400, SRG-NET-000565-VPN-002390","checkContent":"If the ICS VPN Gateway is not being used to carry classified data (e.g., Secret, Top Secret, etc.), this is Not Applicable.\n\n1. Navigate to System >> Configuration >> Inbound SSL Options. Verify that under \"Allowed Encryption Strength\", if \"SuiteB - Accept only SuiteB ciphers\" is checked.\n2. Navigate to System >> Configuration >> Certificates >> Device Certificates. Verify the certificate being used by the ICS is an ECC P-384 Public Key.\n\nIf the ICS is not configured to use only SuiteB ciphers with ECC P-384 keys for transporting classified traffic, this is a finding.","fixText":"In the ICS Web UI, navigate to System >> Configuration >> Certificates >> Device Certificates.\n1. Click \"New CSR\".\n2. Add a Common Name in FQDN format.\n3. Add a Country code of \"US\".\n4. Under key type, select \"ECC\".\n5. Under the key length, select \"P-384\".\n6. Click \"Create CSR\".\n7. Copy the Base 64/PEM encoded certificate request that is shown on the screen and paste it to a text file. Ensure the file has the file suffix of .csr.\n8. Go through the local RA process for DOD Web Server certificate requests. Ensure that SANs are added to the certificate by the issuing CA to include the hostname, cluster names, and all FQDNs.\n9. Once the certificate is provided by the CA, go to System >> Configuration >> Certificates >> Device Certificates.\n10. Click \"Browse\" and select the certificate file issued by the CA. Then click \"Import\".\n11. Click \"Save Changes\".\n12. Click on the imported certificate.\n13. On the \"Internal Port\", click \"add\" for the cluster internal VIP and <Internal Port>.\n14. On the \"External Port\" click \"add\" for the cluster external VIP and <External Port>.\n15. Check the box for \"Management Port\".\n16. Under \"Certificate Status Checking\", click the box for \"Use CRLs\".\n17. Click \"Save Changes\".\n\nIn the ICS Web UI, navigate to System >> Configuration >> Inbound SSL Options.\n1. Under \"Allowed Encryption Strength\", click \"SuiteB - Accept only SuiteB ciphers\".\n2. Click \"Save Changes\" and accept the cipher suite changes.","ccis":["CCI-002450"]},{"vulnId":"V-258596","ruleId":"SV-258596r1005432_rule","severity":"medium","ruleTitle":"The ICS must be configured to disable split-tunneling for remote client VPNs.","description":"Split tunneling would in effect allow unauthorized external connections, making the system more vulnerable to attack and to exfiltration of organizational information.\n\nA 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 on 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.","checkContent":"In the ICS Web UI, navigate to Users >> Resource Policies >> Split Tunneling Networks.\n\nIf there are any split-tunnel network policies, this is a finding.","fixText":"In the ICS Web UI, navigate to Users >> Resource Policies >> Split Tunneling Networks.\n1. If there are any split-tunnel network policies configured, select all of them and delete them.\n2. If the split tunneling policies are needed for debugging or testing only, ensure the role being applied is only for the debugging or test group.","ccis":["CCI-002397"]},{"vulnId":"V-258597","ruleId":"SV-258597r930479_rule","severity":"medium","ruleTitle":"The ICS that provides a Simple Network Management Protocol (SNMP) Network Management System (NMS) must configure SNMPv3 to use FIPS-validated AES cipher block algorithm.","description":"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.\n\nSNMPv3 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.\n\nA 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.\n\nSNMPv3 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.\n\nSNMPv3 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.\n\nCurrently, 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.","checkContent":"In the ICS Web UI, navigate to System >> Log/Monitoring >> SNMP.\n\nUnder \"User 1\", if a user configuration in AuthPriv is not using at least SHA and CFB-AES-128, this is a finding.","fixText":"Only the relevant portion of the SNMP configuration is highlighted here.\n\nIn the ICS Web UI, navigate to System >> Log/Monitoring >> SNMP.\n1. Under \"User 1\", type in a valid username. Select \"AuthPriv\". The priv protocol must be set to at least CFB-AES-128. \n2. Type in the priv password.","ccis":["CCI-001967"]}]}