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

Ivanti Policy Secure AAA Services Security Technical Implementation Guide

V1R1 · · · Released 29 Jun 2026 · 4 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

This Security Technical Implementation Guide is published as a tool to improve the security of Department of War (DoW) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
Supporting documents DISA companion ZIP · 2.1 MB 4 PDFs

Bundled by DISA alongside this STIG release: overview, revision history, and readme files. Download the full archive or open an individual PDF.

Download full ZIP U_Ivanti_Policy_Secure_Y26M06_STIG.zip
Sort by
b
The Ivanti Policy Secure must be configured to use secure Extensible Authentication Protocol (EAP).
CM-6 - Medium - CCI-000366 - V-284441 - SV-284441r1244816_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
IVPS-AA-000024
Vuln IDs
  • V-284441
Rule IDs
  • SV-284441r1244816_rule
Several methods exist to secure 802.1x communications. EAP is a framework supporting multiple methods (e.g., EAP-TLS, EAP-TTLS, LEAP). PEAP is a specific, widely used EAP method that encapsulates other methods within a TLS tunnel. EAP methods, like EAP-TLS, use digital certificates for authentication while PEAP typically uses username/password credentials (PEAP-MSCHAPv2). EAP-TLS is considered superior because it eliminates password-based risks like phishing. PEAP is easier to deploy as it only requires a certificate on the server side. EAP-TLS requires a PKI to manage certificates for every device. Lightweight EAP (LEAP) is a Cisco proprietary protocol providing an easy-to-deploy, one-password authentication. LEAP is vulnerable to dictionary attacks. A "man in the middle" can capture traffic, identify a password, and then use it to access a network. LEAP is inappropriate and does not provide sufficient security for use on DoW networks. EAP-MD5 is functionally similar to CHAP and is susceptible to eavesdropping because the password credentials are sent as a hash (not encrypted). In addition, server administrators would be required to store unencrypted passwords on their servers, thus violating other security policies. EAP-MD5 is inappropriate and does not provide sufficient security for use on DoW networks. EAP-TLS is the most secure, and the preferred method in the DoW. EAP-TTLS only uses certificates on the server side and should be avoided. PEAP was previously the preferred EAP type used in DoW for its ability to support a greater number of operating systems but should also be avoided in favor of EAP-TLS.
Checks: C-89006r1244535_chk

1. In the Web UI, navigate to Signing In >> Authentication Protocol Sets. 2. View the protocol sets for 802.1X and Cert Auth. If an EAP method is listed other than EAP-TLS, this is a finding.

Fix: F-88911r1244536_fix

1. In the Web UI, navigate to Signing In >> Authentication Protocol Sets. 2. From the global view, view the protocol sets for 802.1X and Cert Auth. 3. Configure EAP-TLS.

b
The Ivanti Policy Secure must be configured to use a unique shared secret for RADIUS clients requesting authentication services.
CM-6 - Medium - CCI-000366 - V-284442 - SV-284442r1244818_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
IVPS-AA-000026
Vuln IDs
  • V-284442
Rule IDs
  • SV-284442r1244818_rule
Using standardized authentication protocols such as RADIUS, TACACS+, and Kerberos provides centralized and robust authentication services for the management of network components. An authentication server is very scalable as it supports many user accounts and authentication sessions with the network components.
Checks: C-89007r1244630_chk

1. In the Web UI, navigate to Endpoint Policy >> Radius Client. 2. Review the configuration for each RADIUS Client. 3. Verify "Shared Secret" is set as a required field. If "Shared Secret" is not set for all defined RADIUS Clients, this is a finding.

Fix: F-88912r1244631_fix

1. In the Web UI, navigate to Endpoint Policy >> Radius Client. 2. Enter "Shared Secret" for each defined RADIUS client.

b
The Ivanti Policy Secure must be configured to use IP segments separate from the production VLAN when NAC policy assessment and remediation are used.
CM-6 - Medium - CCI-000366 - V-284443 - SV-284443r1244819_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
IVPS-AA-000027
Vuln IDs
  • V-284443
Rule IDs
  • SV-284443r1244819_rule
When policy assessment and remediation have been implemented and the advanced AAA server dynamic VLAN is misconfigured, logical separation of the production VLAN may not be ensured. Nontrusted resources are not authenticated in a NAC solution and only implement the authentication component of NAC. Nontrusted resources could become resources that have been authenticated but have not had a successful policy assessment when the automated policy assessment component has been implemented.
Checks: C-89008r1244541_chk

1. In the Web UI, navigate to Network >> Internal >> Settings. 2. Verify the IP address for the "Internal Interface" is set to an IP address of a separate network segment rather than the production network. If Ivanti Policy Secure is not configured for network separation from the trusted network segments, this is a finding.

Fix: F-88913r1244542_fix

1. In the Web UI, navigate to Network >> Internal >> Settings. 2. Set the IP address for the "Internal Interface" to the address of a network segment separate from the production network (this network may have services such as AD, web servers, etc.).

c
The Ivanti Policy Secure must be configured to uniquely identify and authenticate organizational users.
IA-2 - High - CCI-000764 - V-284444 - SV-284444r1244802_rule
RMF Control
IA-2
Severity
H
CCI
CCI-000764
Version
IVPS-AA-000010
Vuln IDs
  • V-284444
Rule IDs
  • SV-284444r1244802_rule
To ensure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and any processes acting on behalf of users) must be uniquely identified and authenticated for all accesses, except the following. (i) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and (ii) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity.
Checks: C-89009r1244544_chk

1. Navigate the URL(s) used for users to login. 2. Verify users are prompted for their credentials upon signing in and cannot bypass the sign-in process. If the device does not require users be individually authenticated, this is a finding.

Fix: F-88914r1244623_fix

Create the User Role to define what actions the user can perform once logged in. 1. Navigate to Users >> User Roles. 2. Click "New Role" and give it a name. 3. Under "Access Features", check the boxes for the services needed (e.g., VPN Tunneling or Web). Configure the Authentication Server so the credentials can be verified. 1. Navigate to Authentication >> Auth. Servers. 2. Select the server type from the dropdown and click "New Server". 3. Enter the server details and click "Save". Create the User Realm to connect the user to the authentication server and the role. 1. Navigate to Users >> User Realms. 2. Click "New Realm" and give it a name. 3. Authentication: Select the server created previously. 4. Directory/Attribute: Select the same server to look up group memberships for role mapping. 5. Click "Save Changes". Set up Role Mapping Rules to map the user to a group in the LDAP server. 1. While still in the new Realm, click the "Role Mapping" tab. 2. Click "New Rule". 3. Rule based on: Select Group Membership (if using AD) or Custom Expression. 4. Condition: Select the AD group the nonadministrative users belong to. 5. Assign Role: Select the role created in a previous step. 6. Click "Save Changes". Create a Sign-In Policy to provide a URL for the users to log in. 1. Navigate to Authentication >> Signing In >> Sign-in Policies. 2. Click "New URL". 3. User type: Select Users (not Administrators). 4. Sign-in URL: Specify a path (e.g., */staff-login). 5. Authentication Realm: Select "Corporate_Network_Realm". 6. Click "Save Changes".