{"stig":{"title":"VMware NSX-T Manager NDM Security Technical Implementation Guide","version":"1","release":"3"},"checks":[{"vulnId":"V-251778","ruleId":"SV-251778r879530_rule","severity":"high","ruleTitle":"NSX-T Manager must restrict the use of configuration, administration, and the execution of privileged commands to authorized personnel based on organization-defined roles.","description":"To mitigate the risk of unauthorized access, privileged access must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. \n\nAccess control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. \n\nControls for this requirement include prevention of non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures; enforcing the use of organization-defined role-based access control policies over defined subjects and objects; and restricting access associated with changes to the system components.\n\nSatisfies: SRG-APP-000033-NDM-000212, SRG-APP-000340-NDM-000288, SRG-APP-000329-NDM-000287, SRG-APP-000340-NDM-000288","checkContent":"From the NSX-T Manager web interface, go to System >> Users and Roles >> User Role Assignment.\n\nView each user and group and verify the role assigned to it.\n\nApplication service account and user required privileges must be documented.\n\nIf any user/group or service account are assigned to roles with privileges that are beyond those assigned by the SSP, this is a finding.","fixText":"View the SSP to determine the required organization-defined roles and the least privilege policies required for each role. For example, audit administrator, crypto administrator, system administrator, etc. Assign users to roles based on SSP and least privileges. Carefully assign capabilities to each role based on SSP role assignments. To create a new role with reduced permissions, do the following:\n\nFrom the NSX-T Manager web interface, go to System >> Users and Roles >> Roles. Click \"Add Role\", provide a name and the required permissions, and then click \"Save\".\n\nTo update user or group permissions to an existing role with reduced permissions, do the following:\n\nFrom the NSX-T Manager web interface, go to System >> Users and Roles >> User Role Assignment. Click the menu dropdown next to the target user or group and select \"Edit\". Remove the existing role, select the new one, and then click \"Save\".","ccis":["CCI-000213","CCI-000366","CCI-002169","CCI-002235"]},{"vulnId":"V-251779","ruleId":"SV-251779r879546_rule","severity":"medium","ruleTitle":"The NSX-T Manager 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.","description":"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.","checkContent":"From an NSX-T Manager shell, run the following command(s):\n\n>  get auth-policy api lockout-reset-period\n\nExpected result:\n900 seconds\n\nIf the output does not match the expected result, this is a finding.\n\n>  get auth-policy api lockout-period\n\nExpected result:\n900 seconds\n\nIf the output does not match the expected result, this is a finding.\n\n>  get auth-policy api max-auth-failures\n\nExpected result:\n3\n\nIf the output does not match the expected result, this is a finding.\n\n>  get auth-policy cli lockout-period\n\nExpected result:\n900 seconds\n\nIf the output does not match the expected result, this is a finding.\n\n>  get auth-policy cli max-auth-failures\n\nExpected result:\n3\n\nIf the output does not match the expected result, this is a finding.","fixText":"From an NSX-T Manager shell, run the following command(s):\n\n> set auth-policy api lockout-reset-period 900\n> set auth-policy api lockout-period 900\n> set auth-policy api max-auth-failures 3\n> set auth-policy cli lockout-period 900\n> set auth-policy cli max-auth-failures 3","ccis":["CCI-000044"]},{"vulnId":"V-251780","ruleId":"SV-251780r919231_rule","severity":"medium","ruleTitle":"The NSX-T Manager must enforce a minimum 15-character password length.","description":"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.\n\nThe shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.","checkContent":"From an NSX-T Manager shell, run the following command(s):\n\n> get auth-policy minimum-password-length\n\nExpected result:\n15 characters\n\nIf the \"minimum-password-length\" is not set to 15 or greater, this is a finding.","fixText":"From an NSX-T Manager shell, run the following command(s):\n\n> set auth-policy minimum-password-length 15","ccis":["CCI-000205"]},{"vulnId":"V-251781","ruleId":"SV-251781r916342_rule","severity":"high","ruleTitle":"The NSX-T Manager must terminate the device management session at the end of the session or after 10 minutes of inactivity.","description":"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. \n\nTerminating 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.","checkContent":"From an NSX-T Manager shell, run the following command(s):\n\n>  get service http | find Session\n\nExpected result:\nSession timeout:  600\n\nIf the output does not match the expected result, this is a finding.\n\nFrom an NSX-T Manager shell, run the following command(s):\n\n>  get cli-timeout\n\nExpected result:\n600 seconds\n\nIf the output does not match the expected result, this is a finding.","fixText":"From an NSX-T Manager shell, run the following command(s):\n\n> set service http session-timeout 600\n> set cli-timeout 600","ccis":["CCI-001133"]},{"vulnId":"V-251782","ruleId":"SV-251782r879746_rule","severity":"medium","ruleTitle":"The NSX-T Manager must be configured to synchronize internal information system clocks using redundant authoritative time sources.","description":"The loss of connectivity to a particular authoritative time source will result in the loss of time synchronization (free-run mode) and increasingly inaccurate time stamps on audit events and other functions. \n\nMultiple time sources provide redundancy by including a secondary source. Time synchronization is usually a hierarchy; clients synchronize time to a local source while that source synchronizes its time to a more accurate source. The network device must utilize an authoritative time server and/or be configured to use redundant authoritative time sources. This requirement is related to the comparison done in CCI-001891.\n\nDoD-approved solutions consist of a combination of a primary and secondary time source using a combination or multiple instances of the following: a time server designated for the appropriate DoD network (NIPRNet/SIPRNet); United States Naval Observatory (USNO) time servers; and/or the Global Positioning System (GPS). The secondary time source must be located in a different geographic region than the primary time source.","checkContent":"From the NSX-T Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles. Click \"All NSX Nodes\" and verify the NTP servers listed.\n\nor\n\nFrom an NSX-T Manager shell, run the following command(s):\n\n> get ntp-server\n\nIf the output does not contain at least two authoritative time sources, this is a finding.\n\nIf the output contains unknown or non-authoritative time sources, this is a finding.","fixText":"To configure a profile to apply NTP servers to all NSX-T Manager nodes, do the following:\n\nFrom the NSX-T Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles. Click \"All NSX Nodes\" and then click \"Edit\".\n\nUnder NTP servers, remove any unknown or non-authoritative NTP servers, enter at least two authoritative servers, and then click \"Save\".\n\nor\n\nFrom an NSX-T Manager shell, run the following command(s):\n\n> del ntp-server <server-ip or server-name>\n> set ntp-server <server-ip or server-name>","ccis":["CCI-001893","CCI-000366"]},{"vulnId":"V-251783","ruleId":"SV-251783r879747_rule","severity":"medium","ruleTitle":"The NSX-T Manager must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC).","description":"If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis.\n\nTime stamps generated by the application include date and time. Time is commonly expressed in UTC, a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.","checkContent":"From the NSX-T Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles. Click \"All NSX Nodes\" and verify the time zone.\n\nor\n\nFrom an NSX-T Manager shell, run the following command(s):\n\n> get clock\n\nIf system clock is not configured with the UTC time zone, this is a finding.\n\nNote: This check must be run from each NSX-T Manager as they are configured individually if done from the command line.","fixText":"To configure a profile to apply NTP servers to all NSX-T Manager nodes, do the following:\n\nFrom the NSX-T Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles. Click \"All NSX Nodes\", and then click \"Edit\".\n\nIn the time zone drop-down list, select \"UTC\", and then click \"Save\".\n\nor\n\nFrom an NSX-T Manager shell, run the following command(s):\n\n> set timezone UTC\n\nNote: This fix must be run from each NSX-T Manager as they are configured individually if done from the command line.","ccis":["CCI-001890"]},{"vulnId":"V-251784","ruleId":"SV-251784r879773_rule","severity":"medium","ruleTitle":"The NSX-T Manager must prohibit the use of cached authenticators after an organization-defined time period.","description":"Some authentication implementations can be configured to use cached authenticators.\n\nIf cached authentication information is out-of-date, the validity of the authentication information may be questionable.\n\nThe organization-defined time period should be established for each device depending on the nature of the device; for example, a device with just a few administrators in a facility with spotty network connectivity may merit a longer caching time period than a device with many administrators.","checkContent":"From an NSX-T Manager shell, run the following command(s):\n\n>  get service http | find Session\n\nExpected result:\nSession timeout:                  600\n\nIf the output does not match the expected result, this is a finding.\n\nFrom an NSX-T Manager shell, run the following command(s):\n\n>  get cli-timeout\n\nExpected result:\n600 seconds\n\nIf the output does not match the expected result, this is a finding.","fixText":"From an NSX-T Manager shell, run the following command(s):\n\n> set service http session-timeout 600\n> set cli-timeout 600","ccis":["CCI-002007"]},{"vulnId":"V-251785","ruleId":"SV-251785r879806_rule","severity":"medium","ruleTitle":"The NSX-T Manager must be configured to protect against known types of denial-of-service (DoS) attacks by employing organization-defined security safeguards.","description":"DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.\n\nThis requirement addresses the configuration of network devices to mitigate the impact of DoS attacks that have occurred or are ongoing on device availability. For each network device known, potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or restricting the number of sessions the device opens at one time). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.\n\nThe security safeguards cannot be defined at the DoD level because they vary according to the capabilities of the individual network devices and the security controls applied on the adjacent networks (for example, firewalls performing packet filtering to block DoS attacks).","checkContent":"From an NSX-T Manager shell, run the following command(s):\n\n> get service http | find limit\n\nExpected result:\nClient API rate limit:            100 requests/sec\nClient API concurrency limit:     40 connections\nGlobal API concurrency limit:     199 connections\n\nIf the output does not match the expected result, this is a finding.","fixText":"From an NSX-T Manager shell, run the following command(s):\n\n> set service http client-api-rate-limit 100\n> set service http client-api-concurrency-limit 40\n> set service http global-api-concurrency-limit 199","ccis":["CCI-002385"]},{"vulnId":"V-251786","ruleId":"SV-251786r879870_rule","severity":"medium","ruleTitle":"The NSX-T Manager must generate audit records when successful/unsuccessful attempts to delete administrator privileges occur.","description":"Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.\n\nAudit records can be generated from various components within the network device (e.g., module or policy filter).","checkContent":"From an NSX-T Manager shell, run the following command(s):\n\n> get service async_replicator | find Logging\n> get service http | find Logging\n> get service manager | find Logging\n> get service policy | find Logging\n\nExpected result:\nLogging level:     info\n\nIf the output does not match the expected result, this is a finding.","fixText":"From an NSX-T Manager shell, run the following command(s):\n\n> set service async_replicator logging-level info\n> set service http logging-level info\n> set service manager logging-level info\n> set service policy logging-level info","ccis":["CCI-000172"]},{"vulnId":"V-251787","ruleId":"SV-251787r879886_rule","severity":"medium","ruleTitle":"The NSX-T Manager must be configured to send logs to a central log server.","description":"Information stored in one location is vulnerable to accidental or incidental deletion or alteration.\n\nOffloading is a common process in information systems with limited audit storage capacity.","checkContent":"From an NSX-T Manager shell, run the following command(s):\n\n> get logging-servers\n\nIf any configured logging-servers are not configured with protocol of \"tcp\", \"li-tls\", or \"tls\" and level of \"info\", this is a finding.\n\nIf no logging-servers are configured, this is a finding.\n\nNote: This check must be run from each NSX-T Manager as they are configured individually.","fixText":"(Optional) From an NSX-T Manager shell, run the following command(s) to clear any existing incorrect logging-servers:\n\n> clear logging-servers\n\nFrom an NSX-T Manager shell, run the following command(s) to configure a tcp syslog server:\n\n> set logging-server <server-ip or server-name> proto tcp level info\n\nFrom an NSX-T Manager shell, run the following command(s) to configure a tls syslog server:\n\n> set logging-server <server-ip or server-name> proto tls level info serverca ca.pem clientca ca.pem certificate cert.pem key key.pem\n\nFrom an NSX-T Manager shell, run the following command(s) to configure an li-tls syslog server:\n\n> set logging-server <server-ip or server-name> proto li-tls level info serverca root-ca.crt\n\nNote: If using the protocols TLS or LI-TLS to configure a secure connection to a log server, the server and client certificates must be stored in /image/vmware/nsx/file-store on each NSX-T Manager appliance.","ccis":["CCI-001851"]},{"vulnId":"V-251788","ruleId":"SV-251788r879887_rule","severity":"medium","ruleTitle":"The NSX-T Manager must generate log records for the info level to capture the DoD-required auditable events.","description":"Auditing and logging are key components of any security architecture. Logging the actions of specific events provides a means to investigate an attack; to recognize resource utilization or capacity thresholds; or to identify an improperly configured network device. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis.","checkContent":"From an NSX-T Manager shell, run the following command(s):\n\n> get service async_replicator | find Logging\n> get service http | find Logging\n> get service manager | find Logging\n> get service policy | find Logging\n\nExpected result:\nLogging level:     info\n\nIf the output does not match the expected result, this is a finding.","fixText":"From an NSX-T Manager shell, run the following command(s):\n\n> set service async_replicator logging-level info\n> set service http logging-level info\n> set service manager logging-level info\n> set service policy logging-level info","ccis":["CCI-000169","CCI-000366"]},{"vulnId":"V-251789","ruleId":"SV-251789r916111_rule","severity":"high","ruleTitle":"The NSX-T Manager must integrate with either VMware Identity Manager (vIDM) or VMware Workspace ONE Access.","description":"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.\n\nUse VMware Identity Manager or Workspace ONE configured to meet DoD requirements for authentication, authorization, and access control. This does not require an additional license. Configuration details of this product are not in scope beyond this requirement. Ensure the VMware Workspace ONE Access/VMware Identity Manager acts as a broker to different identity stores and providers, including Active Directory and SAML. \n\nTwo supplements are included with the VMware NSX-T STIG package that provide guidance from the vendor for configuration of VMware Identity Manager and VMware Workspace ONE Access.\n\nSatisfies: SRG-APP-000516-NDM-000336, SRG-APP-000177-NDM-000263, SRG-APP-000149-NDM-000247, SRG-APP-000080-NDM-000220","checkContent":"From the NSX-T Manager web interface, go to System >> Users and Roles >> VMware Identity Manager.\n\nIf the VMware Identity Manager integration is not enabled, this is a finding.\n\nIf the user is not redirected to VMware Identity Manager or Workspace ONE Access when attempting to log in to the NSX-T Manager web interface and prompted to select a certificate and enter a PIN, this is a finding.","fixText":"To configure NSX-T to integrate with VMware Identity Manager or Workspace ONE Access as the authentication source, do the following:\n\nFrom the NSX-T Manager web interface, go to System >> Users and Roles >> VMware Identity Manager and click \"Edit\".\n\nIf using an external load balancer for the NSX-T Management cluster, enable \"External Load Balancer Integration\". If using a cluster VIP, leave this disabled.\n\nClick the toggle button to enable \"VMware Identity Manager Integration\".\n\nEnter the VMware Identity Manager or Workspace ONE Access appliance name, OAuth Client ID, OAuth Client Secret, and certificate thumbprint as provided by the administrators.\n\nEnter the NSX Appliance FQDN. For a cluster, enter the load balancer FQDN or cluster VIP FQDN.\n\nClick \"Save\", import users and groups, and then assign them roles.\n\nEnsure the VMware Identity Manager administrators have configured the certificate authentication adapter to provide two-factor authentication.","ccis":["CCI-000370","CCI-000187","CCI-000166","CCI-000366","CCI-000764","CCI-000765"]},{"vulnId":"V-251790","ruleId":"SV-251790r916221_rule","severity":"medium","ruleTitle":"The NSX-T Manager must be configured to conduct backups on an organizationally defined schedule.","description":"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 utilize this critical network component.\n\nThis 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.","checkContent":"From the NSX-T Manager web interface, go to System >> Backup and Restore to view the backup configuration.\n\nIf backup is not configured and scheduled on a recurring frequency, this is a finding.","fixText":"To configure a backup destination, do the following:\n\nFrom the NSX-T Manager web interface, go to System >> Backup and Restore, and then click \"Edit\" next to SFTP Server.\n\nEnter the target SFTP server, Directory Path, Username, Password, SSH Fingerprint, and Passphrase, and then click \"Save\".\n\nTo configure a backup schedule do the following:\n\nFrom the NSX-T Manager web interface, go to System >> Backup and Restore, and then click \"Edit\" next to Schedule.\n\nClick the \"Recurring Backup\" toggle and configure an interval between backups. Enable \"Detect NSX configuration change\" to trigger backups on detection of configuration changes and specify an interval for detecting changes. Click \"Save\".","ccis":["CCI-000537","CCI-000366"]},{"vulnId":"V-251791","ruleId":"SV-251791r879887_rule","severity":"medium","ruleTitle":"The NSX-T Manager must support organizational requirements to conduct backups of information system documentation, including security-related documentation, when changes occur or weekly, whichever is sooner.","description":"Information system backup is a critical step in maintaining data assurance and availability. Information system and security-related documentation contains information pertaining to system configuration and security settings. If this information were not backed up, and a system failure were to occur, the security settings would be difficult to reconfigure quickly and accurately. Maintaining a backup of information system and security-related documentation provides for a quicker recovery time when system outages occur.\n\nThis control requires the network device to support the organizational central backup process for user account 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.","checkContent":"From the NSX-T Manager web interface, go to System >> Backup and Restore to view the backup configuration.\n\nIf backup is not configured and scheduled on a recurring frequency, this is a finding.","fixText":"To configure a backup destination, do the following:\n\nFrom the NSX-T Manager web interface, go to System >> Backup and Restore, and then click \"Edit\" next to SFTP Server.\n\nEnter the target SFTP server, Directory Path, Username, Password, SSH Fingerprint, and Passphrase, and then click \"Save\".\n\nTo configure a backup schedule do the following:\n\nFrom the NSX-T Manager web interface, go to System >> Backup and Restore, and then click \"Edit\" next to Schedule.\n\nClick the \"Recurring Backup\" toggle and configure an interval between backups. Enable \"Detect NSX configuration change\" to trigger backups on detection of configuration changes and specify an interval for detecting changes. Click \"Save\".","ccis":["CCI-000366","CCI-000539"]},{"vulnId":"V-251792","ruleId":"SV-251792r879887_rule","severity":"medium","ruleTitle":"The NSX-T Manager must obtain its public key certificates from an approved DoD certificate authority.","description":"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 will suffice.","checkContent":"NSX-T Manager uses a certificate for each manager and one for the cluster VIP. In some cases these are the same, but each node and cluster VIP certificate must be checked individually.\n\nBrowse to the NSX-T Manager web interface for each node and cluster VIP and view the certificate and its issuer of the website.\n\nor\n\nFrom an NSX-T Manager shell, run the following command(s):\n\n> get certificate api\n> get certificate cluster\n\nSave the output to a .cer file to examine.\n\nIf the certificate the NSX-T Manager web interface or cluster is using is not issued by an approved DoD certificate authority and is not currently valid, this is a finding.","fixText":"Obtain a certificate or certificates signed by an approved DoD certification authority. This can be done individually by generating CSRs through the NSX-T Manager web interface >> System >> Certificates >> CSRs >> Generate CSR or outside of NSX-T if a common manager and cluster certificate is desired.\n\nImport the certificate(s) into NSX-T by doing the following:\n\nFrom the NSX-T Manager web interface, go to System >> Certificates >> Import >> Import Certificate. Provide a name for the certificate and paste the certificates contents and key. Uncheck \"Service Certificate\" and click \"Import\".\n\nAfter import note the ID of the certificate(s).\n\nUsing curl or another REST API client perform the following API calls and replace the certificate IDs noted in the previous steps.\n\nTo replace a managers certificate: POST https://<nsx-mgr>/api/v1/node/services/http?action=apply_certificate&certificate_id=e61c7537-3090-4149-b2b6-19915c20504f\n\nTo replace the cluster certificate: POST https://<nsx-mgr>/api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=d60c6a07-6e59-4873-8edb-339bf75711ac\n\nNote: If an NSX Intelligence appliance is deployed with the NSX Manager cluster, update the NSX Manager node IP, certificate, and thumbprint information that is on the NSX Intelligence appliance. See VMware Knowledge Base article https://kb.vmware.com/s/article/78505 for more information.","ccis":["CCI-001159","CCI-000366"]},{"vulnId":"V-251793","ruleId":"SV-251793r916114_rule","severity":"high","ruleTitle":"The NSX-T Manager must be configured to send log data to a central log server for the purpose of forwarding alerts to the administrators and the Information System Security Officer (ISSO).","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, is important in showing whether someone is an internal employee or an outside threat.","checkContent":"From an NSX-T Manager shell, run the following command(s):\n\n> get logging-servers\n\nIf any configured logging-servers are not configured with protocol of \"tcp\", \"li-tls\", or \"tls\" and level of \"info\", this is a finding.\n\nIf no logging-servers are configured, this is a finding.\n\nNote: This check must be run from each NSX-T Manager as they are configured individually.","fixText":"(Optional) From an NSX-T Manager shell, run the following command(s) to clear any existing incorrect logging-servers:\n\n> clear logging-servers\n\nFrom an NSX-T Manager shell, run the following command(s) to configure a tcp syslog server:\n\n> set logging-server <server-ip or server-name> proto tcp level info\n\nFrom an NSX-T Manager shell, run the following command(s) to configure a tls syslog server:\n\n> set logging-server <server-ip or server-name> proto tls level info serverca ca.pem clientca ca.pem certificate cert.pem key key.pem\n\nFrom an NSX-T Manager shell, run the following command(s) to configure a li-tls syslog server:\n\n> set logging-server <server-ip or server-name> proto li-tls level info serverca root-ca.crt\n\nNote: If  using the protocols TLS or LI-TLS to configure a secure connection to a log server, the server and client certificates must be stored in /image/vmware/nsx/file-store on each NSX-T Manager appliance.","ccis":["CCI-002605"]},{"vulnId":"V-251794","ruleId":"SV-251794r879887_rule","severity":"high","ruleTitle":"The NSX-T Manager must be running a release that is currently supported by the vendor.","description":"Network devices running an unsupported operating system lack current security fixes required to mitigate the risks associated with recent vulnerabilities.","checkContent":"From the NSX-T Manager web interface, go to the System >> Upgrade.\n\nIf the NSX-T Manager current version is not the latest approved for use in DoD and supported by the vendor, this is a finding.","fixText":"To upgrade NSX-T, reference the upgrade guide in the documentation for the relevant version being upgraded. Refer to the NSX-T documentation and release notes for information on the latest releases.\n\nhttps://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html\n\nIf NSX-T is part of a VMware Cloud Foundation, refer to that documentation for latest supported versions and upgrade guidance.","ccis":["CCI-000366"]},{"vulnId":"V-251795","ruleId":"SV-251795r879588_rule","severity":"medium","ruleTitle":"The NSX-T Manager must not provide environment information to third parties.","description":"Providing technical details about an environment's infrastructure to third parties could unknowingly expose sensitive information to bad actors if intercepted.","checkContent":"From the NSX-T Manager web interface, go to System >> Customer Experience Improvement Program.\n\nIf Joined is set to \"Yes\", this is a finding.","fixText":"From the NSX-T Manager web interface, go to System >> Customer Experience Improvement Program, and then click \"Edit\".\n\nUncheck \"Join the VMware Customer Experience Improvement Program\" and click \"Save\".","ccis":["CCI-000382"]},{"vulnId":"V-251796","ruleId":"SV-251796r879588_rule","severity":"low","ruleTitle":"The NSX-T Manager must disable SSH.","description":"The NSX-T shell provides temporary access to commands essential for server maintenance. Intended primarily for use in break-fix scenarios, the NSX-T shell is well suited for checking and modifying configuration details, not always generally accessible, using the web interface. The NSX-T shell is accessible remotely using SSH. Under normal operating conditions, SSH access to the managers must be disabled as is the default. As with the NSX-T shell, SSH is also intended only for temporary use during break-fix scenarios. SSH must therefore be disabled under normal operating conditions and must only be enabled for diagnostics or troubleshooting. Remote access to the managers must therefore be limited to the web interface and API at all other times.","checkContent":"From an NSX-T Manager shell, run the following command(s):\n\n> get service ssh\n\nExpected results:\nService name:      ssh\nService state:     stopped\nStart on boot:     False\n\nIf the output does not match the expected results, this is a finding.","fixText":"From an NSX-T Manager shell, run the following command(s):\n\n> stop service ssh\n> clear service ssh start-on-boot","ccis":["CCI-000382"]},{"vulnId":"V-251797","ruleId":"SV-251797r879588_rule","severity":"medium","ruleTitle":"The NSX-T Manager must disable unused local accounts.","description":"Prior to NSX-T 3.1 and earlier, there are three local accounts: root, admin, and audit. These local accounts could not be disabled and no additional accounts could be created. Starting in NSX-T 3.1.1, there are two additional guest user accounts: guestuser1 and guestuser2. The local accounts for audit and guest users are disabled by default, but can be deactivated once active; however, admin and root accounts cannot be disabled. These accounts should remain disabled and unique non-local user accounts should be used instead.","checkContent":"If NSX-T is not at least version 3.1.1, this is not applicable.\n\nFrom the NSX-T Manager web interface, go to the System >> Users and Roles >> Local Users and view the status column.\n\nIf the audit, guestuser1, or guestuser2 local accounts are active, this is a finding.","fixText":"From the NSX-T Manager web interface, go to the System >> Users and Roles >> Local Users.\n\nSelect the menu drop down next to the user to modify and click \"Deactivate User\".","ccis":["CCI-000382"]},{"vulnId":"V-251798","ruleId":"SV-251798r879588_rule","severity":"medium","ruleTitle":"The NSX-T Manager must disable TLS 1.1 and enable TLS 1.2.","description":"TLS 1.0 and 1.1 are deprecated protocols with well-published shortcomings and vulnerabilities. TLS 1.2 must be enabled on all interfaces and TLS 1.1 and 1.0 disabled where supported.","checkContent":"Viewing TLS protocol enablement must be done via the API.\n\nExecute the following API call using curl or another REST API client:\n\nGET https://<nsx-mgr>/api/v1/cluster/api-service\n\nExpected result:\n    \"protocol_versions\": [\n        {\n            \"name\": \"TLSv1.1\",\n            \"enabled\": false\n        },\n        {\n            \"name\": \"TLSv1.2\",\n            \"enabled\": true\n        }\n    ],\n\nIf TLS 1.1 is enabled, this is a finding.","fixText":"Capture the output from the check GET command and update the TLS 1.1 protocol to false.\n\nExecute the following API call using curl or another REST API client:\n\nPUT https://<nsx-mgr>/api/v1/cluster/api-service\n\nExample request body:\n\n{\n  \"global_api_concurrency_limit\": 199,\n  \"client_api_rate_limit\": 100,\n  \"client_api_concurrency_limit\": 40,\n  \"connection_timeout\": 30,\n  \"redirect_host\": \"\",\n  \"cipher_suites\": [\n    {\"enabled\": true, \"name\": \"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384\"},\n    {\"enabled\": true, \"name\": \"TLS_RSA_WITH_AES_256_GCM_SHA384\"},\n    {\"enabled\": true, \"name\": \"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256\"},\n    {\"enabled\": true, \"name\": \"TLS_RSA_WITH_AES_128_GCM_SHA256\"}\n    {\"enabled\": true, \"name\": \"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}\",\n    {\"enabled\": true, \"name\": \"TLS_RSA_WITH_AES_256_CBC_SHA256\"},\n    {\"enabled\": true, \"name\": \"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA\"},\n    {\"enabled\": true, \"name\": \"TLS_RSA_WITH_AES_256_CBC_SHA\"},\n    {\"enabled\": true, \"name\": \"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256\"},\n    {\"enabled\": true, \"name\": \"TLS_RSA_WITH_AES_128_CBC_SHA256\"},\n    {\"enabled\": false, \"name\": \"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA\"},\n    {\"enabled\": false, \"name\": \"TLS_RSA_WITH_AES_128_CBC_SHA\"}\n  ],\n  \"protocol_versions\": [\n    {\"enabled\": false, \"name\": \"TLSv1.1\"},\n    {\"enabled\": true, \"name\": \"TLSv1.2\"}\n  ]\n}\n\nNote: Changes are applied to all nodes in the cluster. The API service on each node will restart after it is updated using this API. There may be a delay of up to a minute or so between the time this API call completes and when the new configuration goes into effect.","ccis":["CCI-000382"]},{"vulnId":"V-251799","ruleId":"SV-251799r879588_rule","severity":"medium","ruleTitle":"The NSX-T Manager must disable SNMP v2.","description":"SNMPv3 supports commercial-grade security, including authentication, authorization, access control, and privacy. Previous versions of the protocol contained well-known security weaknesses that were easily exploited. As such, SNMPv1/2 receivers must be disabled.","checkContent":"From the NSX-T Manager web interface, go to the System >> Fabric >> Profiles >> Node Profiles.\n\nClick \"All NSX Nodes\" and view the SNMP Polling and Traps configuration.\n\nIf SNMP v2c Polling or Traps are configured, this is a finding.","fixText":"From the NSX-T Manager web interface, go to the System >> Fabric >> Profiles >> Node Profiles.\n\nClick on \"All NSX Nodes\" and delete and v2c Polling or Trap configurations.","ccis":["CCI-000382"]},{"vulnId":"V-251800","ruleId":"SV-251800r879588_rule","severity":"medium","ruleTitle":"The NSX-T Manager must enable the global FIPS compliance mode for load balancers.","description":"If unsecured protocols (lacking cryptographic mechanisms) are used for load balancing, the contents of those sessions will be susceptible to eavesdropping, potentially putting sensitive data at risk of compromise.","checkContent":"From the NSX-T Manager web interface, go to the Home >> Monitoring Dashboards >> Compliance Report.\n\nReview the compliance report for code 72024 with description Load balancer FIPS global setting disabled.\n\nNote: This may also be checked via the API call GET https://<nsx-mgr>/policy/api/v1/infra/global-config\n\nIf the global FIPS setting is disabled for load balancers, this is a finding.","fixText":"Execute the following API call using curl or another REST API client:\n\nPUT https://<nsx-mgr>/policy/api/v1/infra/global-config\n\nExample request body:\n\n{\n    \"fips\": {\n        \"lb_fips_enabled\": true\n    },\n    \"resource_type\": \"GlobalConfig\",\n    \"_revision\": 2\n}\n\nThe global setting is used when the new load balancer instances are created. Changing the setting does not affect existing load balancer instances.\n\nTo update existing load balancers to use this setting, do the following:\n\nFrom the NSX-T Manager web interface, go to the Networking >> Load Balancing  and then click \"Edit\" on the target load balancer.\n\nIn the attachment field, click the \"X\" to detach the load balancer from its current Gateway and click \"Save\".\n\nEdit the target load balancer again, reattach it to its Gateway, and then click \"Save\".\n\nCaution: Detaching a load balancer from the tier-1 gateway results in a traffic interruption for the load balancer instance.","ccis":["CCI-000382"]}]}