None Computing title Ivanti Policy Secure AAA Services Security Technical Implementation Guide version 1 releaseinfo Release: 1 Vuln_Num V-284441 Rule_ID SV-284441r1244816_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to use secure Extensible Authentication Protocol (EAP). Vuln_Discuss 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. Check_Content 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_Text 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. Not_Reviewed Vuln_Num V-284442 Rule_ID SV-284442r1244818_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to use a unique shared secret for RADIUS clients requesting authentication services. Vuln_Discuss 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. Check_Content 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_Text 1. In the Web UI, navigate to Endpoint Policy >> Radius Client. 2. Enter "Shared Secret" for each defined RADIUS client. Not_Reviewed Vuln_Num V-284443 Rule_ID SV-284443r1244819_rule Severity medium Rule_Title The Ivanti Policy Secure must be configured to use IP segments separate from the production VLAN when NAC policy assessment and remediation are used. Vuln_Discuss 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. Check_Content 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_Text 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.). Not_Reviewed Vuln_Num V-284444 Rule_ID SV-284444r1244802_rule Severity high Rule_Title The Ivanti Policy Secure must be configured to uniquely identify and authenticate organizational users. Vuln_Discuss 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. Check_Content 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_Text 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". Not_Reviewed