None Computing title Ivanti Policy Secure NDM Security Technical Implementation Guide version 1 releaseinfo Release: 1 Vuln_Num V-284518 Rule_ID SV-284518r1244923_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to enforce the limit of three consecutive invalid logon attempts, after which time it must block any login attempt for 15 minutes. Vuln_Discuss By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Check_Content 1. In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. 2. Under the section "Account Lockout", verify "Enable Account Lockout for users" is checked. 3. Verify "Maximum wrong password attempts" is set to "3". 4. Verify "Account Lockout Period in Minutes" is set to "15". If account lockout is not configured to enforce the limit of three consecutive invalid logon attempts, after which time it must block any login attempt for 15 minutes, this is a finding. Fix_Text 1. In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. 2. Under the section "Account Lockout", check the box for "Enable Account Lockout for users". 3. Under the section "Account Lockout" set "Maximum wrong password attempts" to "3". 4. Under the section "Account Lockout" set "Account Lockout Period in Minutes" to "15". 5. Click "Save Changes". Not_Reviewed Vuln_Num V-284519 Rule_ID SV-284519r1244925_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to display the Standard Mandatory DoW Notice and Consent Banner before granting access to the device. Vuln_Discuss Display of the DoW-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. System use notifications are required only for access via logon interfaces with human users. Check_Content Determine if the DoW-approved banner is presented before accessing Policy Secure. 1. In the Web UI, navigate to Authentication >> Signing In >> Sign-In Policies. 2. Click "*/admin/" (or the custom URL used for common access card [CAC]/public key access [PKI] token admin access). Under "Configure Sign In 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. Fix_Text 1. In the Web UI, navigate to Authentication >> Signing In >> Sign-In Notifications. 2. Click "New Notification". 3. For name, type: "DOD Notice and Consent". 4. In the text box, enter the following: 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. 5. Click "Save Changes". 6. Go to Authentication >> Signing In >> Sign-In Policies. 7. Click the "*/admin/" (or the custom URL used for CAC/PKI token admin access). 8. Under "Configure Sign In Notifications", check the box for "Pre-Auth Sign-in Notification" and in the drop-down menu, assign the notification titled "DOD Notice and Consent". 9. Repeat steps 7 and 8 for each role or URL. Note: If the Use the Sign-in Notification associated to the assigned role is enabled, complete the implementation by selecting the sign-in notification on the Users >> User Roles >> Role Name >> General >> UI Options page or Administrators >> Admin Roles >> Role Name >> General >> UI Options page. Not_Reviewed Vuln_Num V-284520 Rule_ID SV-284520r1244926_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to enable "Detailed Log Note". Vuln_Discuss It is essential for security personnel to know what is being done, what was attempted, where it was done, when it was done, and by whom it was done to compile an accurate risk assessment. Associating event types with detected events in the application and audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured network device. Without this capability, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Satisfies: SRG-APP-000095-NDM-000225, SRG-APP-000096-NDM-000226, SRG-APP-000097-NDM-000227, SRG-APP-000098-NDM-000228, SRG-APP-000099-NDM-000229, SRG-APP-000101-NDM-000231 Check_Content In the Web UI, navigate to System >> Log/Monitoring >> User Access >> Settings. Under the "Select Events to Log" section, if "Detailed Log Note" is not checked, this is a finding. Fix_Text 1. In the Web UI, navigate to System >> Log/Monitoring >> User Access >> Settings. 2. Under the "Select Events to Log" section, check the box for "Detailed Log Note". 3. Click "Save Changes". Not_Reviewed Vuln_Num V-284521 Rule_ID SV-284521r1244927_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to use internal system clocks to generate time stamps for audit records. Vuln_Discuss In order to determine what is happening within the network infrastructure or to resolve and trace an attack, the network device must support the organization's capability to correlate the audit log data from multiple network devices to acquire a clear understanding of events. In order to correlate auditable events, time stamps are needed on all of the log records. If the internal clock is not used, the system may not be able to provide time stamps for log messages. Additionally, externally generated time stamps may not be accurate. Applications can use the capability of an operating system or purpose-built module for this purpose. Note: The internal clock is required to be synchronized with authoritative time sources by other requirements. Satisfies: SRG-APP-000116-NDM-000234, SRG-APP-000374-NDM-000299 Check_Content 1. In the Web UI, navigate to System >> Status >> Dashboard. 2. Click the "Overview" tab. 3. Under "Appliance Details" and "System Date and Time", select "Edit". If the "Time Zone" is not set to "(GMT) Coordinated Universal Time" this is a finding. Fix_Text 1. In the Web UI, navigate to System >> Status >> Dashboard. 2. Click the "Overview" tab. 3. Under "Appliance Details" and "System Date and Time", select "Edit". 4. Select "(GMT) Coordinated Universal Time". 5. Click "Save Changes". Not_Reviewed Vuln_Num V-284522 Rule_ID SV-284522r1244928_rule Severity high Rule_Title The Ivanti Policy Secure must be configured to map group definitions to role assignments for administrators based on access authorizations. Vuln_Discuss Changes to any software components of the network device can have significant effects on the overall security of the network. Therefore, only qualified and authorized individuals should be allowed administrative access to the network device for implementing any changes or upgrades. If the network device were to enable nonauthorized users to make changes to software libraries, audit tools, and system software, these changes could be implemented without undergoing testing, validation, and approval. Satisfies: SRG-APP-000133-NDM-000244, SRG-APP-000033-NDM-000212, SRG-APP-000038-NDM-000213, SRG-APP-000119-NDM-000236, SRG-APP-000120-NDM-000237, SRG-APP-000121-NDM-000238, SRG-APP-000122-NDM-000239, SRG-APP-000123-NDM-000240, SRG-APP-000329-NDM-000287, SRG-APP-000231-NDM-000271 Check_Content 1. In the Ivanti Policy Secure Web UI, navigate to Administrators >> Admin Realms >> Admin Realms. 2. Click the admin realm that is currently being used on the Policy Secure for CAC/PKI token administrator logins. 3. View the "Role Mapping" tab. If there are not two group definitions to Role Assignments for Admin and Read-Only, this is a finding. Fix_Text Configure the admin realm that is currently being used on the Policy Secure for CAC/PKI token administrator logins. 1. In the Ivanti Policy Secure Web UI, navigate to Administrators >> Admin Realms >> Admin Realms. 2. Select the admin realm that is currently being used on the Policy Secure for CAC/PKI token administrator logins. 3. Click "Role Mappings". 4. Click "New Rule". 5. Click "Rule Based" on Group Membership". 6. Click "Update". 7. Type a name for the admin group. 8. Under available groups, select the LDAP group for admins (e.g., "ivanti.admins.gsg"). If no groups currently exist in the window, click "Groups" and add the group from the LDAP directory window that pops up. 9. Under "Available Roles", select ".Administrators". 10. Click "Save Changes". 11. Click "New Rule". 12. Click "Rule Based" on "Group Membership". 13. Click "Update". 14. Type a name for the read-only group. 15. Under available groups, select the LDAP group for nonadmins (e.g., "ivanti.ROadmin.gsg"). If no groups currently exist in the window, click "Groups" and add the group from the LDAP directory window that pops up. 16. Under "Available Roles", select ".Read-Only Administrators". 17. Click "Save Changes". Not_Reviewed Vuln_Num V-284523 Rule_ID SV-284523r1244929_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured with only one local account to be used as the account of last resort in the event the authentication server is unavailable. Vuln_Discuss Authentication for administrative (privileged level) access to the device is required at all times. An account can be created on the device's local database for use when the authentication server is down or connectivity between the device and the authentication server is not operable. This account is referred to as the account of last resort since it is intended to be used as a last resort and when immediate administrative access is absolutely necessary. The account of last resort logon credentials must be stored in a sealed envelope and kept in a safe. The safe must be periodically audited to verify the envelope remains sealed. The signature of the auditor and the date of the audit should be added to the envelope as a record. Administrators should secure the credentials and disable the root account (if possible) when not needed for system administration functions. Check_Content 1. In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. 2. Select the "Users" tab and review the user list. If more than one local user exists, this is a finding. Fix_Text 1. In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. 2. Click the "Users" tab. 3. Create the emergency local user or click the default admin user. 4. Click "Enabled". 5. Click "Allow Console Access". 6. Click "Save Changes". Not_Reviewed Vuln_Num V-284524 Rule_ID SV-284524r1244930_rule Severity medium Rule_Title The Ivanti Policy Secure must enforce a minimum 15-character password length. Vuln_Discuss Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that must be tested before the password is compromised. Use of more characters in a password helps to increase exponentially the time and/or resources required to compromise the password. Satisfies: SRG-APP-000164-NDM-000252, SRG-APP-000860-NDM-000250, SRG-APP-000845-NDM-000220 Check_Content In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. If the minimum length is not 15 characters, this is a finding. Fix_Text 1. In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. 2. For minimum length, enter "15". 3. Click "Save Changes". Not_Reviewed Vuln_Num V-284525 Rule_ID SV-284525r1244994_rule Severity medium Rule_Title The Ivanti Policy Secure must enforce password complexity by requiring least one uppercase and at least one lowercase character be used. Vuln_Discuss Using complex passwords helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Multifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account. Satisfies: SRG-APP-000166-NDM-000254, SRG-APP-000167-NDM-000255 Check_Content In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. If "Password must have mix of UPPERCASE and lowercase letters" is not checked or "Password must have at least __ letters" is not set to "1" or more, this is a finding. Fix_Text 1. In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. 2. Select "Password must have at least __ letters". 3. In the box enter "1" or more. 4. Check the box for "Password must have mix of UPPERCASE and lowercase letters". 5. Click "Save Changes". Not_Reviewed Vuln_Num V-284526 Rule_ID SV-284526r1244932_rule Severity medium Rule_Title The Ivanti Policy Secure must enforce password complexity by requiring that at least one numeric character be used. Vuln_Discuss Using a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Multifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account. Check_Content In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. If the value for the setting for "Password must have at least __ digits" is not "1" or more, this is a finding. Fix_Text 1. In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. 2. Check the box for "Password must have at least __ digits". 3. In the box, enter "1". 4. Click "Save Changes". Not_Reviewed Vuln_Num V-284527 Rule_ID SV-284527r1244933_rule Severity medium Rule_Title The Ivanti Policy Secure must enforce password complexity by requiring that at least one special character be used. Vuln_Discuss Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Multifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account. Check_Content In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. If the value for "Password must have at least __ Special Characters" is not set to "1" or more, this is a finding. Fix_Text 1. Check the box for "Password must have at least __ Special Characters". 2. In the box, enter "1" or more. 3. Click "Save Changes". Not_Reviewed Vuln_Num V-284528 Rule_ID SV-284528r1244934_rule Severity medium Rule_Title The Ivanti Policy Secure must require that when a password is changed, the characters are changed in at least eight of the positions within the password. Vuln_Discuss Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Check_Content In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. If the setting for "new password must differ from the previous password position" and the value of "new password must differ from the previous password position" is not set to "8", this is a finding. Fix_Text 1. In the Web UI, navigate to Authentication >> Auth Servers >> Administrators. 2. Check the box for "new password must differ from the previous password position". 3. In the box, enter "8" or more. 4. Click "Save Changes". Not_Reviewed Vuln_Num V-284529 Rule_ID SV-284529r1244935_rule Severity high Rule_Title The Ivanti Policy Secure must be configured to transmit only encrypted representations of passwords. Vuln_Discuss Multifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using public key infrastructure (PKI) is not available, and for the account of last resort and root account. Check_Content 1. In the Web UI, navigate to System >> Configuration >> Inbound SSL Options. 2. Under "Allowed SSL and TLS Version", verify "Accept only TLS 1.2 (maximize security)" is selected. 3. Navigate to System >> Configuration >> Outbound SSL Options. 4. View the setting for "Allowed SSL and TLS Version". If "Accept only TLS 1.2 (maximize security)" is not checked, this is a finding. Fix_Text 1. In the Web UI, navigate to System >> Configuration >> Inbound SSL Options. 2. Under "Allowed SSL and TLS Version", check the box for "Accept only TLS 1.2 (maximize security)". 3. Click "Save Changes". 4. Click "Proceed" to accept the cipher change. 5. Navigate to System >> Configuration >> Outbound SSL Options. 6. Under "Allowed SSL and TLS Version", check the box for "Accept only TLS 1.2 (maximize security)". 7. Click "Save Changes". 8. Click "Proceed" to accept the cipher change. Not_Reviewed Vuln_Num V-284530 Rule_ID SV-284530r1244936_rule Severity high Rule_Title The Ivanti Policy Secure must be configured to terminate all network connections associated with a device management session at the end of the session, or the session must be terminated after 10 minutes of inactivity except to fulfill documented and validated mission requirements. Vuln_Discuss Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. This does not mean that the device terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session. Check_Content 1. In the Web UI, navigate to Administrators >> Admins Role >> Delegated Admin Roles. 2. Click the configured admin role being used for CAC/PKI token admin logins, by default it is ".Administrators". 3. Click the "Session Options" tab. 4. View the "Session Lifetime" section. If the idle timeout is not set to "10", this is a finding. Fix_Text 1. In the Web UI, navigate to Administrators >> Admins Role >> Delegated Admin Roles. 2. Click the configured admin role being used for CAC/PKI token admin logins, by default it is ".Administrators". 3. Click the "Session Options" tab. 4. In the "Session Lifetime" section, set the Idle Timeout to "10". 5. Click "Save Changes". Not_Reviewed Vuln_Num V-284531 Rule_ID SV-284531r1244937_rule Severity high Rule_Title The Ivanti Policy Secure must be configured to prevent nonprivileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. Vuln_Discuss Preventing nonprivileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges. Privileged functions include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Nonprivileged users are individuals that do not possess appropriate authorizations. Satisfies: SRG-APP-000340-NDM-000288, SRG-APP-000378-NDM-000302, SRG-APP-000380-NDM-000304, SRG-APP-000408-NDM-000314, SRG-APP-000491-NDM-000316, SRG-APP-000516-NDM-000341, SRG-APP-000177-NDM-000263, SRG-APP-000820-NDM-000170, SRG-APP-000825-NDM-000180, SRG-APP-000875-NDM-000280 Check_Content Verify realms and roles are configured as needed to meet mission requirements. 1. In the Web UI, navigate to Administrators >> Admin Realms >> Admin Realms. 2. Click the admin realm that is currently being used on the Policy Secure for administrator logins. By default, it is "Admin Users". 3. In the "General" tab, under Servers >> Directory/Attribute, verify "none" are listed. 4. In the "Role Mapping" tab, under "when users meet these conditions" set the following: - "Group" must be used, and the local site's administrator active directory group must be selected and assigned to the ".Administrators" role. Note: This role could be different if using something other than the default ".Administrators" role. If a realm or role mapping is not configured to prevent nonprivileged users from executing privileged functions, this is a finding. Fix_Text Configure realms and roles as needed to meet mission requirements. The ".Administrators" role is a default role name, but other administrator role names can be used. Groups must be used; separate usernames or an allow-all username of * is not acceptable. 1. In the Web UI, navigate to Administrators >> Admin Realms >> Admin Realms. 2. Click the admin realm that is used on the Policy Secure for administrator logins. By default, it is "Admin Users". 3. In the "General" tab, under Servers >> Directory/Attribute, select the previously configured LDAP Directory. If none are configured, follow vendor supplied instructions for creating an LDAP Authentication Server. 4. In the "Role Mapping" tab, under "when users meet these conditions" select "New rule". 5. Under "Rule based on", select "Group Membership". 6. Name the rule. 7. Select "is". 8. Provide the exact group name in the text box. This name must match the "CN=" attribute name. For example, if the group is "CN=ivanti.adm.group" then add the "ivanti.adm.group" to the text box. 9. Under "then assign these roles", select the admin role used by Policy Secure for admin logins. By default, this is the ".Administrators". 10. Click "Save Changes". 11. Under "Role Mapping" if there are more roles needed for more specific role-based access to the Policy Secure, configure more of them here. 12. Click "Save Changes". Not_Reviewed Vuln_Num V-284532 Rule_ID SV-284532r1244938_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to authenticate SNMPv3 messages using a Ivanti Policy Secure-validated keyed-Hash Message Authentication Code (HMAC). Vuln_Discuss Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. A local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area or wide area network, internet). A remote connection is any connection with a device communicating through an external network (e.g., the internet). Because of the challenges of applying this requirement on a large scale, organizations are encouraged to only apply the requirement to those limited number (and type) of devices that truly need to support this capability. Check_Content If SNMP is not used, this is not applicable. 1. In the Web UI, navigate to System >> Log/Monitoring >> SNMP. 2. Under "SNMP version data", verify v2c is not selected. If any version other than v3 is selected, this is a finding. Fix_Text 1. In the Web UI, navigate to System >> Log/Monitoring >> SNMP. 2. Under "SNMP version data", select "v3". 3. Under "Agent Properties", select SNMP Queries. 4. Define the System Name. 5. Define the System Location. 6. Define the System Contact. 7. Under "SNMPv3 Configuration" and "User 1", type the username. 8. Select the "Security Level" of Auth, Priv. 9. Select "SHA" as the Auth Protocol. 10. Type the Auth password. 11. Select "CFB-AES-128" as the Priv Protocol. 12. Type the Priv password. 13. Under "Optional Traps", select "Critical" and "Major" log events. 14. Click "Save changes". Not_Reviewed Vuln_Num V-284533 Rule_ID SV-284533r1244995_rule Severity medium Rule_Title The Ivanti Policy Secure must use an NTP service that is hosted by a trusted source or a DoW-compliant enterprise or local NTP server. Vuln_Discuss If a trusted time source is not used, an attacker can introduce a rogue NTP server. This rogue server can then be used to send incorrect time information to network devices, which will make log timestamps inaccurate which may hide attacks or result in inaccurate forensic analysis. The recommended solution is that the application or endpoint is configured to point to an enterprise or site-owned time server that is DoW-compliant (instead of directly to an NTP source as implied by the current wording of the requirement). Most products are unable to meet the requirement, but DISA can mitigate the risk by using a trusted time source. So, the requirement should state that NTPS is used with USNO NTP as an alternative mitigation for this to be considered not a finding. More information can be found at https://www.cnmoc.usff.navy.mil/Our-Commands/United-States-Naval-Observatory/Precise-Time-Department/Network-Time-Protocol-NTP/DOD-Customer-Servers/. DoW users should not use tick, tock, or ntp2. There are instructions for obtaining authenticated NTP at the site listed above. Satisfies: SRG-APP-000395-NDM-000347, SRG-APP-000920-NDM-000320, SRG-APP-000925-NDM-000330 Check_Content 1. In the Web UI, navigate to System >> Status >> Dashboard. 2. Click the "Overview" tab. 3. Under "Appliance Details" and "System Date and Time", select "Edit". 4. Verify "Use Pool of NTP servers" is checked. 5. Verify at least two NTP servers are configured. 6. Verify a key is configured. If Policy Secure is not configured to use redundant NTP services that is hosted by a trusted source or a DoW-compliant enterprise or local NTP server, this is a finding. Fix_Text 1. In the Web UI, navigate to System >> Status >> Dashboard. 2. Click the "Overview" tab. 3. Under "Appliance Details" and "System Date and Time", select "Edit". 4. Select "(GMT) Coordinated Universal Time". 5. Select "Use Pool of NTP servers". 6. Enter the IP/hostname of each NTP server in the "NTP Server 1", "NTP Server 2", etc. 7. Under the key section, input the key in the following format: <keynumber> <algorithm> <key>. Note: There must be a space between each section of <keynumber> <algorithm> <key>. 8. Click "Save changes". Not_Reviewed Vuln_Num V-284534 Rule_ID SV-284534r1244941_rule Severity high Rule_Title The Ivanti Policy Secure must be configured to connect to the management network if used to authenticate privileged users for device management. Vuln_Discuss Unapproved mechanisms used for authentication to the cryptographic module are not verified and therefore, cannot be relied upon to provide confidentiality or integrity, and DoW data may be compromised. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Currently, HMAC is the only FIPS-approved algorithm for generating and verifying message/data authentication codes in accordance with FIPS 198-1. Products that are FIPS 140-2/140-3-validated will have an HMAC that meets specification; however, the option must be configured for use as the only message authentication code used for authentication to cryptographic modules. Separate requirements for configuring applications and protocols used by each application (e.g., SNMPv3, SSHv2, NTP, HTTPS, and other protocols and applications that require server/client authentication) are required to implement this requirement. Where SSH is used, the SSHv2 protocol suite is required because it includes layer 7 protocols such as SCP and SFTP, which can be used for secure file transfers. Check_Content 1. In the Web UI, navigate to System >> Configuration >> Advanced Networking. 2. Verify the management interface is selected for NTP, SNMP, Syslog and Log Archiving. 1. In the Web UI, navigate to Administrators >> Admin Realms. 2. Click each Admin Authentication Realm. 3. Click on Authentication policy for each realm. 4. Verify the "Enable to sign in" check box is not checked for "Management Port". If the device is not configured to connect to the management port for NTP, SNMP, and Syslog and Log Archiving communications, this is a finding. Fix_Text Enable and configure alternative protocols and the admins to login to the Management port as well as the default URL port. 1. In the Web UI, navigate to Network >> Management >> Settings. 2. Check the box for "Use Port" to enable. 3. Add an IPv4 Address, Netmask, and GW. 4. Check the box to enable IPv6. 5. Add an IP Address, Prefix, and GW. 1. In the Web UI, navigate to System >> Configuration >> Advanced Networking. 2. Select the management interface for NTP, SNMP, Syslog & Log Archive (this should be selected by default). 3. Click "Save". 1. In the Web UI, navigate to Administrators >> Admin Realms. 2. Click each Admin Authentication Realm. 3. Click on Authentication policy. 4. Select each realm and select "Enable administrators to sign in on the Management port". This should be the only port checked. Not_Reviewed Vuln_Num V-284535 Rule_ID SV-284535r1244943_rule Severity high Rule_Title The Ivanti Policy Secure must enable IPS, JITC, and NDcPP compliance modes to ensure only FIPS 140-2/140-3 algorithms are used. Vuln_Discuss Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoW data may be compromised. This requires the use of secure protocols instead of their unsecured counterparts, such as SSH instead of telnet, SCP instead of FTP, and HTTPS instead of HTTP. If unsecured protocols (lacking cryptographic mechanisms) are used for sessions, the contents of those sessions will be susceptible to eavesdropping, potentially putting sensitive data (including administrator passwords) at risk of compromise and potentially allowing hijacking of maintenance sessions. Satisfies: SRG-APP-000412-NDM-000331, SRG-APP-000142-NDM-000245, SRG-APP-000156-NDM-000250, SRG-APP-000179-NDM-000265, SRG-APP-000224-NDM-000270, SRG-APP-000435-NDM-000315, SRG-APP-000516-NDM-000317 Check_Content 1. In the Web UI, navigate to System >> Configuration >> Security >> Inbound SSL Options. 2. Verify the "Turn on JITC mode" checkbox is not checked. 3. Verify the "Turn on NDcPP mode" checkbox is not checked. 4. Verify the "Turn on FIPS mode" checkbox is not checked. If JITC and NDcPP compliance modes are not configured, this is a finding. Fix_Text 1. In the Web UI, navigate to System >> Configuration >> Security >> Inbound SSL Options. 2. Under the DoW Certification option, enable "Turn on JITC mode" to enable the JITC mode security features. 3. Under SSL NDcPP Mode Option, enable "Turn on NDcPP mode" to enable the NDcPP mode security features. 4. Under SSL FIPS Mode Option, check enable "Turn on FIPS mode" to enable the FIPS mode security features. 5. Click "Save changes" and confirm after the web UI asks for SSL cipher configuration changes. Not_Reviewed Vuln_Num V-284536 Rule_ID SV-284536r1244945_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to send the user access events audit log records to a centralized syslog server. Vuln_Discuss Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Satisfies: SRG-APP-000516-NDM-000350 Check_Content 1. In the Web UI, navigate to System >> Log/Monitoring >> User Access >> Settings. 2. Verify "Select Events to Log" is configured to log all items. 3. Verify "Syslog Servers" is configured with a remote syslog server name/IP address. 4. Verify TSL is selected. If user access events log audit records are not configured to be sent to a remote centralized syslog server, this is a finding. Fix_Text 1. In the Web UI, navigate to System >> Log/Monitoring >> User Access >> Settings. 2. Under "Select Events to Log", check all items. 3. Under "syslog Servers" add an IP address/server name/IP. 4. Set the facility to LOCAL0. 5. Set type to TLS. 6. Optionally, only if a client certificate is required for the syslog server, select the client certificate to use for the syslog traffic. If none exists, import the DoW-signed client key pair to the Policy Secure under System >> Configuration >> Certificates >> Client Auth Certificates. 7. Set the standard filer. 8. Set the source interface as either the management or internal interface. 9. Click "Add". 10. Click "Save Changes". Not_Reviewed Vuln_Num V-284537 Rule_ID SV-284537r1244947_rule Severity medium Rule_Title The Ivanti Policy Secure must send events audit log records to a centralized syslog server. Vuln_Discuss Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Satisfies: SRG-APP-000516-NDM-000350 Check_Content 1. In the Web UI, navigate to System >> Log/Monitoring >> Events >> Settings. 2. Verify "Select Events to Log" is configured to log all items. 3. Verify "Syslog Servers" is configured with a remote syslog server name/IP address. 4. Verify "TSL" is selected. If events access log audit records are not configured to be sent to a remote centralized syslog server, this is a finding. Fix_Text 1. In the Web UI, navigate to System >> Log/Monitoring >> User Access >> Settings. 2. Under "Select Events to Log", check all items. 3. Under "syslog Servers" add an IP address/server name/IP. 4. Set the facility to "LOCAL0". 5. Set type to "TLS". 6. Optionally, if only a client certificate is required for the syslog server, select the client certificate to use for the syslog traffic. If none exists, import the DoW-signed client key pair to the Policy Secure under System >> Configuration >> Certificates >> Client Auth Certificates. 7. Set the standard filer. 8. Set the source interface as either the management or internal interface. 9. Click "Add". 10. Click "Save Changes". Not_Reviewed Vuln_Num V-284538 Rule_ID SV-284538r1244948_rule Severity high Rule_Title The Ivanti Policy Secure must be configured to use at least two authentication servers for the purpose of authenticating users prior to granting administrative access. Vuln_Discuss Centralized management of authentication settings increases the security of remote and nonlocal access methods. This control is particularly important protection against the insider threat. With robust centralized management, audit records for administrator account access to the organization's network devices can be more readily analyzed for trends and anomalies. The alternative method of defining administrator accounts on each device exposes the device configuration to remote access authentication attacks and system administrators with multiple authenticators for each network device. Check_Content 1. In the Web UI, navigate to Authentication >> Auth Servers >> Authentication/Authorization Servers. 2. Select the directory service connector that was created. 3. Check to ensure a primary and backup server is configured. If a primary and backup connection is not configured, this is a finding. Fix_Text Configure at least two authentication servers. 1. In the Web UI, navigate to Administrators >> Auth Servers. 2. Click "New Servers", under "Server type", select "Certificate Server", then click "New Server". 3. Type a Name, then under "User Name template", type: <certAttr.altname.UPN>. 4. Click "Save changes". 5. Navigate to Administrators >> Auth Servers. 6. Click "New Servers", under "Server type", select "LDAP Server", then click "New Server". 7. Type a name for the primary LDAP server domain. 8. 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). 9. LDAP port: 636. 10. 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). 11. Backup LDAP Port1: 636. 12. If a third LDAP server is needed, add this and the port info under Backup LDAP Server2 and Backup LDAP Port2. 13. LDAP Server Type: Active Directory. 14. Connection: LDAPS. 15. Ensure "Validate Server Certificate" is checked. 16. Connection Timeout: 15. 17. Search Timeout: 60. 18. Scroll down to the bottom and click "Save changes", then click "Test Settings" to ensure valid communications are possible. Note: If there are failures in this testing, ensure the step for Device Certificates and Trusted Server CAs were completed. If not, this will cause LDAPS certificate issues. 19. Under "authentication required", click the box for "Authentication required to search LDAP". 20. Enter the service account's Admin DN using this as an example format: CN=PCS.SVC,OU=IVANTI,DC=dod,DC=mil. 21. Enter the service account's password. 22. Under "Finding user entries", add the base DN of the domain using this as an example format: DC=dod,DC=mil. 23. Under "filter", use this specific attribute configuration: userPrincipalName=<USER>. 24. Under "group membership", add the base DN where admin users will access, using this as an example format: OU=IVANTI,DC=dod,DC=mil. 25. Under "filter", use the following: cn=<GROUPNAME>. 26. Under "member attribute", use the following: member. 27. Click "Save Changes". 28. At the LDAP server configuration screen, scroll down and click the "Server Catalog" hyperlink. 29. Under attributes, click "New", type "userPrincipalName", then click "Save Changes". 30. Under groups, click "Search". In the search box, type the group name used for admin logins. 31. Check the box next to the group that is found and click "Add Selected". 32. Repeat these steps for all various groups needed for various roles on the Policy Secure system. For example, groups for auditors, ISSOs, NOC, SOC, Viewer, etc. 33. Click "Save Changes". Not_Reviewed Vuln_Num V-284539 Rule_ID SV-284539r1244949_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to conduct backups of system level information contained in the information system when changes occur or weekly, whichever is sooner. Vuln_Discuss System-level information includes default and customized settings and security attributes, including ACLs that relate to the network device configuration, as well as software required for the execution and operation of the device. Information system backup is a critical step in ensuring system integrity and availability. If the system fails and there is no backup of the system-level information, a denial of service condition is possible for all who use this critical network component. This control requires the network device to support the organizational central backup process for system-level information associated with the network device. This function may be provided by the network device itself; however, the preferred best practice is a centralized backup rather than each network device performing discrete backups. Check_Content 1. In the Ivanti Policy Secure Web UI, navigate to Maintenance >> Archiving >> Archive Servers. 2. Review the archive schedule to verify the configuration is configured to backup weekly, at a minimum. 3. Review the backup log to verify the backup is kicked off manually when system configuration occurs. If backups of system level information are not scheduled for at least weekly, this is a finding. Fix_Text 1. In the Ivanti Policy Secure Web UI, navigate to Maintenance >> Archiving >> Archive Servers. 2. Click "SCP" if using an SFTP/SCP server, other mechanisms may not be allowed due to local security policy. Check with the information system security manager (ISSM) before configuring anything other than SCP. 3. Under "Archive Server", type the host name or IPv4/IPv6 address. 4. In "Destination Directory", type the path of the backup (e.g., "/backupfolder/ics/"). 5. In the "Username" field, type the username with SCP/SFTP permissions on the backup server. 6. In the "Password" field, type the password. 7. Under "Archive Schedule" select "Archive System Configuration", then click the day of the week and time when the backup should be sent. 8. Under "Archive System Configuration", ensure a password is given to encrypt the backup. 9. Under "Archive Schedule", select "Archive User Accounts", then click the day of the week and time when the backup should be sent. 10. Under "Archive User Accounts", ensure a password is given to encrypt the backup. 11. Click "Save Changes". Not_Reviewed Vuln_Num V-284540 Rule_ID SV-284540r1244952_rule Severity medium Rule_Title The Ivanti Policy Secure must obtain its public key certificates from an appropriate certificate policy through an approved service provider. Vuln_Discuss For user certificates, each organization obtains certificates from an approved, shared service provider, as required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority (CA) will suffice. Check_Content 1. In the Web UI, navigate to System >> Configuration >> Certificates >> Device Certificates. 2. View the certificate to verify it is signed by a valid DoW CA. 3. Verify the certificate is the only one present and configured for use on interfaces. If a DoW CA certificate is not used, this is a finding. Fix_Text 1. In the Web UI, navigate to System >> Configuration >> Certificates >> Device Certificates. 2. Click "New CSR". 3. Add a Common Name in FQDN format. 4. Add a Country code of US. 5. Under "Key type", if using RSA, select "RSA". If using ECC, select "ECC". 6. Under "Key length", if using RSA, select at least 2048. If using ECC, select "P-384". 7. Enter in random data in the text field. 8. Click "Create CSR". 9. Copy the Base 64/PEM encoded certificate request shown on the screen and paste it to a text file. Ensure the file has the file suffix of .csr. 10. Complete the local RA process for DoW web server certificate requests. Ensure that SANs are added to the certificate by the issuing CA to include the host name, cluster names, and all FQDNs. 11. Once the certificate is provided by the CA, go to System >> Configuration >> Certificates >> Device Certificates. 12. Click "Browse" and select the certificate file issued by the CA, then click "Import". 13. Click "Save Changes". 14. Click on the imported certificate. 15. On the internal port, click add for the cluster internal VIP and <Internal Port>. 16. On the external port, click add for the cluster external VIP and <External Port>. 17. Check the box for "Management Port". 18. Under "Certificate Status Checking", click the box for "Use CRLs". 19. Click "Save Changes". Not_Reviewed Vuln_Num V-284541 Rule_ID SV-284541r1244953_rule Severity medium Rule_Title The Ivanti Policy Secure must limit the number of concurrent sessions to one for each administrator account/or administrator type. Vuln_Discuss Device management includes the ability to control the number of administrators and management sessions that manage a device. Limiting the number of allowed administrators and sessions per administrator based on account type, role, or access type is helpful in limiting risks related to denial-of-service (DoS) attacks. This requirement addresses concurrent sessions for administrative accounts and does not address concurrent sessions by a single administrator via multiple administrative accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system. At a minimum, limits must be set for SSH, HTTPS, account of last resort, and root account sessions. Check_Content 1. In the Web UI, navigate to Administrators >> Admins Realms >> Admin Realms. 2. Click the configured admin realm being used for CAC/PKI token admin logins. 3. Click the "Authentication Policy" tab, then click "Limits". If the "Maximum number of sessions per user" field shows any value other than "1", this is a finding. Fix_Text 1. In the Web UI, navigate to Administrators >> Admins Realms >> Admin Realms. 2. Click the configured admin realm being used for CAC/PKI token admin logins. 3. Click the "Authentication Policy" tab, then click "Limits". 4. In "Maximum number of sessions per user", enter "1". 5. Click "Save Changes". Not_Reviewed Vuln_Num V-284542 Rule_ID SV-284542r1244955_rule Severity high Rule_Title The Ivanti Policy Secure must be configured to use DoW public key infrastructure (PKI) as multifactor authentication (MFA) for administrator login via the sign-in URL. Vuln_Discuss Once issued by a DoW certificate authority (CA), PKI certificates are typically valid for three years or fewer within the DoW. However, there are many reasons a certificate may become invalid before the prescribed expiration date. For example, an employee may leave or be terminated and still possess the smartcard on which the PKI certificates were stored. Another example is that a smartcard containing PKI certificates may become lost or stolen. A more serious issue could be that the CA or server which issued the PKI certificates has become compromised, thereby jeopardizing every certificate keypair that was issued by the CA. These examples of revocation use cases and many more can be researched further using internet cybersecurity resources. PKI user certificates presented as part of the identification and authentication criteria (e.g., DoW PKI as MFA) must be checked for validity by network devices. For example, valid PKI certificates are digitally signed by a trusted DoW CA. Additionally, valid PKI certificates are not expired, and valid certificates have not been revoked by a DoW CA. Network devices can verify the validity of PKI certificates by checking with an authoritative CA. One method of checking the status of PKI certificates is to query databases referred to as certificate revocation lists (CRL). These are lists which are published, updated, and maintained by authoritative DoW CAs. For example, once certificates are expired or revoked, issuing CAs place the certificates on a CRL. Organizations can download these lists periodically (i.e., daily or weekly) and store them locally on the devices themselves or even onto another nearby local enclave resource. Storing them locally ensures revocation status can be checked even if internet connectivity is severed at the enclave's point of presence (PoP). However, CRLs can be rather large in storage size and further, the use of CRLs can be rather taxing on some computing resources. Another method of validating certificate status is to use the online certificate status protocol (OCSP). Using OCSP, a requestor (i.e., the network device which the user is trying to authenticate to) sends a request to an authoritative CA challenging the validity of a certificate that has been presented for identification and authentication. The CA receives the request and sends a digitally signed response indicating the status of the user's certificate as valid, revoked, or unknown. Network devices must only allow access for responses that indicate the certificates presented by the user were considered valid by an approved DoW CA. OCSP is the preferred method because it is fast, provides the most current status, and is lightweight. Satisfies: SRG-APP-000149-NDM-000247, SRG-APP-000153-NDM-000249, SRG-APP-000910-NDM-000300 Check_Content Verify the admin realm is configured for certificate authentication. 1. In the Web UI, navigate to Administrators >> Admin Realms. 2. View the configuration for the admin realm used for administrator sign-in (this is called "Admin Users" by default). 3. Authentication: View the certificate authentication server name. 4. Verify the box for "Enable dynamic policy evaluation" is checked. 5. Verify the box for "Refresh roles" and "refresh resource policies" is checked. Verify the certificate authentication server is configured to use DoW PKI. 1. Navigate to Administrators >> Auth. Servers. 2. Select Certificate from the list, then select the name of the certificate authentication server name that was used for the admin realm. 3. Verify the username template is set to <certAttr.altname.UPN>. If Ivanti Policy Secure is not configured to use DoW PKI as MFA for admin logins, this is a finding. Fix_Text Create a certificate authentication server with the "Certificate" server type to handle the common access card (CAC)/PKI handshake. 1. In the Web UI, navigate to Administrators >> Auth. Servers. 2. Select "Certificate" from the list and click "New Server". 3. Enter a name. 4. Under "User Name Template", type <certAttr.altname.UPN>. 5. Click "Save Changes". Configure the Admin Realm to tie the certificate authentication and the LDAP lookup together. 1. Navigate to Administrators >> Admin Realms. 2. Click the admin realm being used. "Admin Users" is defined by default. 3. Authentication: Select the certificate authentication server created previously that included the User Name Template <certAttr.altname.UPN>. 4. Directory/Attribute: Select the LDAP server with the admin accounts. 5. Check the box for "Enable dynamic policy evaluation". 6. Check both "Refresh roles" and "Refresh resource policies". 7. Click "Save Changes". Note: Role Mappings: Created rules that map users to the "Administrator" role based on LDAP groups. Update the Admin Sign-in Policy by configuring the admin sign-in URL to use this realm. 1. In the Web UI, navigate to Authentication >> Signing In >> Sign-in Policies. 2. Create a new URL or edit the "*/admin/" URL, depending on the site. Note: 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. 3. Under "Authentication Realm", click the "User picks from a list of authentication realms". 4. Click "Save Changes". Not_Reviewed Vuln_Num V-284543 Rule_ID SV-284543r1244956_rule Severity high Rule_Title The Ivanti Policy Secure must be configured to use DoW-approved online certificate status protocol (OCSP) responders or certificate revocation lists (CRLs) to validate certificates used for public key infrastructure (PKI)-based authentication. Vuln_Discuss Once issued by a DoW certificate authority (CA), PKI certificates are typically valid for three years or fewer within the DoW. However, there are many reasons a certificate may become invalid before the prescribed expiration date. For example, an employee may leave or be terminated and still possess the smartcard on which the PKI certificates were stored. Another example is that a smartcard containing PKI certificates may become lost or stolen. A more serious issue could be that the CA or server which issued the PKI certificates has become compromised, thereby jeopardizing every certificate keypair that was issued by the CA. These examples of revocation use cases and many more can be researched further using internet cybersecurity resources. PKI user certificates presented as part of the identification and authentication criteria (e.g., DoW PKI as multifactor authentication [MFA]) must be checked for validity by network devices. For example, valid PKI certificates are digitally signed by a trusted DoW CA. Additionally, valid PKI certificates are not expired, and valid certificates have not been revoked by a DoW CA. Satisfies: SRG-APP-000175-NDM-000262, SRG-APP-000875-NDM-000280 Check_Content 1. In the ICS Web UI, navigate to System >> Configuration >> Certificates >> Trusted Client CAs. 2. Click each DoW client CA. 3. Verify that under "Client certificate status checking", "OCSP", "CRL", or both are checked. Example: "Use OCSP with CRL fallback" is selected under the "Client certificate status checking" setting. If the ICS is not configured to use DoW approved OCSP responders and/or CRLs to validate certificates used for PKI-based authentication, this is a finding. Fix_Text 1. In the ICS Web UI, navigate to System >> Configuration >> Certificates >> Trusted Client CAs. 2. Click the first DoW client CA. 3. If OCSP only is used, under "Client certificate status checking", select "Use OCSP". 4. If CRL is used, under "Client certificate status checking", select "Use CRL" option. Note: The recommended option is "Use OCSP with CRL fallback" option under "Client certificate status checking". 5. Repeat these steps for every other client certificate CA. Not_Reviewed Vuln_Num V-284544 Rule_ID SV-284544r1244957_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to protect nonlocal maintenance sessions by separating the maintenance session from other network sessions with the system by logically separated communications paths. Vuln_Discuss Nonlocal maintenance and diagnostic activities are conducted by individuals who communicate through either an external or internal network. Communications paths can be logically separated using encryption. Check_Content 1. In the Web UI, navigate to Administrators >> Admins Realms >> Admin Users >> Authentication Policy. 2. Click the configured admin realm being used for common access card (CAC)/public key infrastructure (PKI) token admin logins. 3. Click the "Authentication Policy" tab, then click "Source IP". In "Administrator Sign in Port" if there are any ports selected for "Administrator Sign in" other than "Management Port", this is a finding. Fix_Text 1. In the Web UI, navigate to Administrators >> Admins Realms >> Admin Users >> Authentication Policy. 2. Click the configured admin realm used for CAC/PKI token admin logins. 3. Click the "Authentication Policy" tab, then click "Source IP". 4. In "Administrator Sign in Port" under Administrator Sign in Ports Select only the "Management Port". Not_Reviewed Vuln_Num V-284545 Rule_ID SV-284545r1244958_rule Severity medium Rule_Title The Ivanti Policy Secure must enable the admin access audit log. Vuln_Discuss Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat. Satisfies: SRG-APP-000343-NDM-000289, SRG-APP-000027-NDM-000209, SRG-APP-000028-NDM-000210, SRG-APP-000029-NDM-000211, SRG-APP-000080-NDM-000220, SRG-APP-000091-NDM-000223, SRG-APP-000100-NDM-000230, SRG-APP-000319-NDM-000283 Check_Content In the Web UI, navigate to System >> Log/Monitoring >> Admin Access >> Settings. Under the section "Select Events to Log", if "Administrator changes" is not checked, this is a finding. Fix_Text 1. In the Web UI, navigate to Administrators >> Admin Realms >> Admin Realms. 2. Check the box for "Administrator changes" under the section "Select Events to Log". 3. Click "Save Changes". Not_Reviewed Vuln_Num V-284546 Rule_ID SV-284546r1244959_rule Severity medium Rule_Title The Ivanti Policy Secure must install software updates within 30 days from publication. Vuln_Discuss Security flaws with software are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates. Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously. Check_Content 1. Check the vendor portal to obtain the version and release dates for the latest releases. 2. Navigate to Maintenance >> System >> Platform to inspect the version number of the installed release. If software updates are not being installed within 30 days from publication, this is a finding. Fix_Text Regularly log in to the Ivanti Success Portal to check for new maintenance releases. Back Up Configuration (Pre-Update): 1. Navigate to Maintenance >> Archiving >> Configuration Archive. 2. Select "Save Config As..." and download the binary configuration file. 3. Export User and Admin local databases separately if there are a large number of local accounts. 4. Download and verify the image. 5. Download the appropriate .pkg or system image from Ivanti. 6. Run a SHA-256 checksum on the downloaded file and compare it against the hash provided on the Ivanti download page. Install the Update: 1. Go to Maintenance >> System >> Upgrade. 2. Under "Upload and Install System Software", click "Browse" and select the verified update file. 3. Click "Install". The appliance will automatically reboot. Note: Log the date of the update to show it was completed within the mandated 30-day window. Not_Reviewed Vuln_Num V-284547 Rule_ID SV-284547r1244960_rule Severity high Rule_Title The Ivanti Policy Secure must be configured to use a version supported by the vendor. Vuln_Discuss Unsupported software and systems should not be used because fixes to newly identified bugs will not be implemented by the vendor. The lack of support can result in potential vulnerabilities. Software and systems at unsupported servicing levels or releases will not receive security updates for new vulnerabilities, which leaves them subject to exploitation. When maintenance updates and patches are no longer available, software is no longer considered supported and should be upgraded or decommissioned. Check_Content Check the software version installed against the vendor supported version. 1. Navigate to the System Status page from other admin console pages by selecting System >> Status. 2. Click the "System Version Download Package" link to download the software version running on the system. If the software version is not a version supported by the vendor, this is a finding. Fix_Text Upgrade the system software to a vendor supported version. 1. Select Maintenance >> System >> Upgrade/Downgrade to display the system software maintenance page. 2. Under "Install Service Package", select one of the following options to proceed: a. From "File", use the "Browse" button to locate and select the service package file. b. From "Staged Package", select the service package file that was previously uploaded. Note: Do not select the "Deletes" option when upgrading software. This option is available to support downgrading software. 3. Click "Install". Not_Reviewed Vuln_Num V-284638 Rule_ID SV-284638r1244993_rule Severity medium Rule_Title The Ivanti Policy Secure must send admin access audit log records to a centralized syslog server. Vuln_Discuss Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Satisfies: SRG-APP-000516-NDM-000350 Check_Content 1. In the Web UI, navigate to System >> Log/Monitoring >> Admin Access >> Settings. 2. Verify "Select Events to Log" is configured to log all items. 3. Verify "Syslog Servers" is configured with a remote syslog server name/IP address. 4. Verify TSL is selected. If admin access events log audit records are not configured to be sent to a remote centralized syslog server, this is a finding. Fix_Text 1. In the Web UI, navigate to System >> Log/Monitoring >> Admin Access >> Settings. 2. Under "Select Events to Log", check all items. 3. Under "syslog Servers", add an IP address/server name/IP. 4. Set the facility to LOCAL0. 5. Set type to TLS. 6. (Optionally, only 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 DoW-signed client key pair to the Policy Secure under System >> Configuration >> Certificates >> Client Auth Certificates. 7. Set the standard filer. 8. Set the source interface as either the management or internal interface. 9. Click Add. 10. Click save changes. Not_Reviewed