Cyber Trackr - Free Compliance Library
Cyber Trackr
The Free Compliance Library

VMware NSX-T Manager NDM Security Technical Implementation Guide

  • Version/Release: V1R3
  • Published: 2023-06-22
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) 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.
c
NSX-T Manager must restrict the use of configuration, administration, and the execution of privileged commands to authorized personnel based on organization-defined roles.
AC-3 - High - CCI-000213 - V-251778 - SV-251778r879530_rule
RMF Control
AC-3
Severity
High
CCI
CCI-000213
Version
TNDM-3X-000010
Vuln IDs
  • V-251778
Rule IDs
  • SV-251778r879530_rule
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. Access 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. Controls 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. Satisfies: SRG-APP-000033-NDM-000212, SRG-APP-000340-NDM-000288, SRG-APP-000329-NDM-000287, SRG-APP-000340-NDM-000288
Checks: C-55238r810335_chk

From the NSX-T Manager web interface, go to System >> Users and Roles >> User Role Assignment. View each user and group and verify the role assigned to it. Application service account and user required privileges must be documented. If any user/group or service account are assigned to roles with privileges that are beyond those assigned by the SSP, this is a finding.

Fix: F-55192r810336_fix

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: From 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". To update user or group permissions to an existing role with reduced permissions, do the following: From 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".

b
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.
AC-7 - Medium - CCI-000044 - V-251779 - SV-251779r879546_rule
RMF Control
AC-7
Severity
Medium
CCI
CCI-000044
Version
TNDM-3X-000012
Vuln IDs
  • V-251779
Rule IDs
  • SV-251779r879546_rule
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.
Checks: C-55239r810338_chk

From an NSX-T Manager shell, run the following command(s): > get auth-policy api lockout-reset-period Expected result: 900 seconds If the output does not match the expected result, this is a finding. > get auth-policy api lockout-period Expected result: 900 seconds If the output does not match the expected result, this is a finding. > get auth-policy api max-auth-failures Expected result: 3 If the output does not match the expected result, this is a finding. > get auth-policy cli lockout-period Expected result: 900 seconds If the output does not match the expected result, this is a finding. > get auth-policy cli max-auth-failures Expected result: 3 If the output does not match the expected result, this is a finding.

Fix: F-55193r810339_fix

From an NSX-T Manager shell, run the following command(s): > set auth-policy api lockout-reset-period 900 > set auth-policy api lockout-period 900 > set auth-policy api max-auth-failures 3 > set auth-policy cli lockout-period 900 > set auth-policy cli max-auth-failures 3

b
The NSX-T Manager must enforce a minimum 15-character password length.
IA-5 - Medium - CCI-000205 - V-251780 - SV-251780r919231_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000205
Version
TNDM-3X-000041
Vuln IDs
  • V-251780
Rule IDs
  • SV-251780r919231_rule
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 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.
Checks: C-55240r919230_chk

From an NSX-T Manager shell, run the following command(s): > get auth-policy minimum-password-length Expected result: 15 characters If the "minimum-password-length" is not set to 15 or greater, this is a finding.

Fix: F-55194r810342_fix

From an NSX-T Manager shell, run the following command(s): > set auth-policy minimum-password-length 15

c
The NSX-T Manager must terminate the device management session at the end of the session or after 10 minutes of inactivity.
SC-10 - High - CCI-001133 - V-251781 - SV-251781r916342_rule
RMF Control
SC-10
Severity
High
CCI
CCI-001133
Version
TNDM-3X-000052
Vuln IDs
  • V-251781
Rule IDs
  • SV-251781r916342_rule
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.
Checks: C-55241r810344_chk

From an NSX-T Manager shell, run the following command(s): > get service http | find Session Expected result: Session timeout: 600 If the output does not match the expected result, this is a finding. From an NSX-T Manager shell, run the following command(s): > get cli-timeout Expected result: 600 seconds If the output does not match the expected result, this is a finding.

Fix: F-55195r810345_fix

From an NSX-T Manager shell, run the following command(s): > set service http session-timeout 600 > set cli-timeout 600

b
The NSX-T Manager must be configured to synchronize internal information system clocks using redundant authoritative time sources.
AU-8 - Medium - CCI-001893 - V-251782 - SV-251782r879746_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001893
Version
TNDM-3X-000068
Vuln IDs
  • V-251782
Rule IDs
  • SV-251782r879746_rule
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. Multiple 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. DoD-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.
Checks: C-55242r810347_chk

From the NSX-T Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles. Click "All NSX Nodes" and verify the NTP servers listed. or From an NSX-T Manager shell, run the following command(s): > get ntp-server If the output does not contain at least two authoritative time sources, this is a finding. If the output contains unknown or non-authoritative time sources, this is a finding.

Fix: F-55196r810348_fix

To configure a profile to apply NTP servers to all NSX-T Manager nodes, do the following: From the NSX-T Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles. Click "All NSX Nodes" and then click "Edit". Under NTP servers, remove any unknown or non-authoritative NTP servers, enter at least two authoritative servers, and then click "Save". or From an NSX-T Manager shell, run the following command(s): > del ntp-server <server-ip or server-name> > set ntp-server <server-ip or server-name>

b
The NSX-T Manager must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC).
AU-8 - Medium - CCI-001890 - V-251783 - SV-251783r879747_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001890
Version
TNDM-3X-000069
Vuln IDs
  • V-251783
Rule IDs
  • SV-251783r879747_rule
If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time 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.
Checks: C-55243r810350_chk

From the NSX-T Manager web interface, go to System &gt;&gt; Fabric &gt;&gt; Profiles &gt;&gt; Node Profiles. Click "All NSX Nodes" and verify the time zone. or From an NSX-T Manager shell, run the following command(s): &gt; get clock If system clock is not configured with the UTC time zone, this is a finding. Note: This check must be run from each NSX-T Manager as they are configured individually if done from the command line.

Fix: F-55197r810351_fix

To configure a profile to apply NTP servers to all NSX-T Manager nodes, do the following: From the NSX-T Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles. Click "All NSX Nodes", and then click "Edit". In the time zone drop-down list, select "UTC", and then click "Save". or From an NSX-T Manager shell, run the following command(s): > set timezone UTC Note: This fix must be run from each NSX-T Manager as they are configured individually if done from the command line.

b
The NSX-T Manager must prohibit the use of cached authenticators after an organization-defined time period.
IA-5 - Medium - CCI-002007 - V-251784 - SV-251784r879773_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-002007
Version
TNDM-3X-000076
Vuln IDs
  • V-251784
Rule IDs
  • SV-251784r879773_rule
Some authentication implementations can be configured to use cached authenticators. If cached authentication information is out-of-date, the validity of the authentication information may be questionable. The 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.
Checks: C-55244r810353_chk

From an NSX-T Manager shell, run the following command(s): &gt; get service http | find Session Expected result: Session timeout: 600 If the output does not match the expected result, this is a finding. From an NSX-T Manager shell, run the following command(s): &gt; get cli-timeout Expected result: 600 seconds If the output does not match the expected result, this is a finding.

Fix: F-55198r810354_fix

From an NSX-T Manager shell, run the following command(s): > set service http session-timeout 600 > set cli-timeout 600

b
The NSX-T Manager must be configured to protect against known types of denial-of-service (DoS) attacks by employing organization-defined security safeguards.
SC-5 - Medium - CCI-002385 - V-251785 - SV-251785r879806_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
TNDM-3X-000080
Vuln IDs
  • V-251785
Rule IDs
  • SV-251785r879806_rule
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. This 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. The 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).
Checks: C-55245r810356_chk

From an NSX-T Manager shell, run the following command(s): &gt; get service http | find limit Expected result: Client API rate limit: 100 requests/sec Client API concurrency limit: 40 connections Global API concurrency limit: 199 connections If the output does not match the expected result, this is a finding.

Fix: F-55199r810357_fix

From an NSX-T Manager shell, run the following command(s): > set service http client-api-rate-limit 100 > set service http client-api-concurrency-limit 40 > set service http global-api-concurrency-limit 199

b
The NSX-T Manager must generate audit records when successful/unsuccessful attempts to delete administrator privileges occur.
AU-12 - Medium - CCI-000172 - V-251786 - SV-251786r879870_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TNDM-3X-000083
Vuln IDs
  • V-251786
Rule IDs
  • SV-251786r879870_rule
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. Audit records can be generated from various components within the network device (e.g., module or policy filter).
Checks: C-55246r810359_chk

From an NSX-T Manager shell, run the following command(s): &gt; get service async_replicator | find Logging &gt; get service http | find Logging &gt; get service manager | find Logging &gt; get service policy | find Logging Expected result: Logging level: info If the output does not match the expected result, this is a finding.

Fix: F-55200r810360_fix

From an NSX-T Manager shell, run the following command(s): > set service async_replicator logging-level info > set service http logging-level info > set service manager logging-level info > set service policy logging-level info

b
The NSX-T Manager must be configured to send logs to a central log server.
AU-4 - Medium - CCI-001851 - V-251787 - SV-251787r879886_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
TNDM-3X-000088
Vuln IDs
  • V-251787
Rule IDs
  • SV-251787r879886_rule
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity.
Checks: C-55247r810362_chk

From an NSX-T Manager shell, run the following command(s): &gt; get logging-servers If any configured logging-servers are not configured with protocol of "tcp", "li-tls", or "tls" and level of "info", this is a finding. If no logging-servers are configured, this is a finding. Note: This check must be run from each NSX-T Manager as they are configured individually.

Fix: F-55201r810363_fix

(Optional) From an NSX-T Manager shell, run the following command(s) to clear any existing incorrect logging-servers: > clear logging-servers From an NSX-T Manager shell, run the following command(s) to configure a tcp syslog server: > set logging-server <server-ip or server-name> proto tcp level info From an NSX-T Manager shell, run the following command(s) to configure a tls syslog server: > set logging-server <server-ip or server-name> proto tls level info serverca ca.pem clientca ca.pem certificate cert.pem key key.pem From an NSX-T Manager shell, run the following command(s) to configure an li-tls syslog server: > set logging-server <server-ip or server-name> proto li-tls level info serverca root-ca.crt Note: 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.

b
The NSX-T Manager must generate log records for the info level to capture the DoD-required auditable events.
AU-12 - Medium - CCI-000169 - V-251788 - SV-251788r879887_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
TNDM-3X-000090
Vuln IDs
  • V-251788
Rule IDs
  • SV-251788r879887_rule
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.
Checks: C-55248r810365_chk

From an NSX-T Manager shell, run the following command(s): &gt; get service async_replicator | find Logging &gt; get service http | find Logging &gt; get service manager | find Logging &gt; get service policy | find Logging Expected result: Logging level: info If the output does not match the expected result, this is a finding.

Fix: F-55202r810366_fix

From an NSX-T Manager shell, run the following command(s): > set service async_replicator logging-level info > set service http logging-level info > set service manager logging-level info > set service policy logging-level info

c
The NSX-T Manager must integrate with either VMware Identity Manager (vIDM) or VMware Workspace ONE Access.
CM-6 - High - CCI-000370 - V-251789 - SV-251789r916111_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000370
Version
TNDM-3X-000092
Vuln IDs
  • V-251789
Rule IDs
  • SV-251789r916111_rule
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. Use 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. Two 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. Satisfies: SRG-APP-000516-NDM-000336, SRG-APP-000177-NDM-000263, SRG-APP-000149-NDM-000247, SRG-APP-000080-NDM-000220
Checks: C-55249r819177_chk

From the NSX-T Manager web interface, go to System &gt;&gt; Users and Roles &gt;&gt; VMware Identity Manager. If the VMware Identity Manager integration is not enabled, this is a finding. If 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.

Fix: F-55203r819721_fix

To configure NSX-T to integrate with VMware Identity Manager or Workspace ONE Access as the authentication source, do the following: From the NSX-T Manager web interface, go to System >> Users and Roles >> VMware Identity Manager and click "Edit". If using an external load balancer for the NSX-T Management cluster, enable "External Load Balancer Integration". If using a cluster VIP, leave this disabled. Click the toggle button to enable "VMware Identity Manager Integration". Enter the VMware Identity Manager or Workspace ONE Access appliance name, OAuth Client ID, OAuth Client Secret, and certificate thumbprint as provided by the administrators. Enter the NSX Appliance FQDN. For a cluster, enter the load balancer FQDN or cluster VIP FQDN. Click "Save", import users and groups, and then assign them roles. Ensure the VMware Identity Manager administrators have configured the certificate authentication adapter to provide two-factor authentication.

b
The NSX-T Manager must be configured to conduct backups on an organizationally defined schedule.
CP-9 - Medium - CCI-000537 - V-251790 - SV-251790r916221_rule
RMF Control
CP-9
Severity
Medium
CCI
CCI-000537
Version
TNDM-3X-000093
Vuln IDs
  • V-251790
Rule IDs
  • SV-251790r916221_rule
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. 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.
Checks: C-55250r810371_chk

From the NSX-T Manager web interface, go to System &gt;&gt; Backup and Restore to view the backup configuration. If backup is not configured and scheduled on a recurring frequency, this is a finding.

Fix: F-55204r810372_fix

To configure a backup destination, do the following: From the NSX-T Manager web interface, go to System >> Backup and Restore, and then click "Edit" next to SFTP Server. Enter the target SFTP server, Directory Path, Username, Password, SSH Fingerprint, and Passphrase, and then click "Save". To configure a backup schedule do the following: From the NSX-T Manager web interface, go to System >> Backup and Restore, and then click "Edit" next to Schedule. Click 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".

b
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.
CM-6 - Medium - CCI-000366 - V-251791 - SV-251791r879887_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TNDM-3X-000094
Vuln IDs
  • V-251791
Rule IDs
  • SV-251791r879887_rule
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. This 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.
Checks: C-55251r810374_chk

From the NSX-T Manager web interface, go to System &gt;&gt; Backup and Restore to view the backup configuration. If backup is not configured and scheduled on a recurring frequency, this is a finding.

Fix: F-55205r810375_fix

To configure a backup destination, do the following: From the NSX-T Manager web interface, go to System >> Backup and Restore, and then click "Edit" next to SFTP Server. Enter the target SFTP server, Directory Path, Username, Password, SSH Fingerprint, and Passphrase, and then click "Save". To configure a backup schedule do the following: From the NSX-T Manager web interface, go to System >> Backup and Restore, and then click "Edit" next to Schedule. Click 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".

b
The NSX-T Manager must obtain its public key certificates from an approved DoD certificate authority.
SC-17 - Medium - CCI-001159 - V-251792 - SV-251792r879887_rule
RMF Control
SC-17
Severity
Medium
CCI
CCI-001159
Version
TNDM-3X-000095
Vuln IDs
  • V-251792
Rule IDs
  • SV-251792r879887_rule
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.
Checks: C-55252r810377_chk

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. Browse to the NSX-T Manager web interface for each node and cluster VIP and view the certificate and its issuer of the website. or From an NSX-T Manager shell, run the following command(s): &gt; get certificate api &gt; get certificate cluster Save the output to a .cer file to examine. If 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.

Fix: F-55206r810378_fix

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. Import the certificate(s) into NSX-T by doing the following: From 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". After import note the ID of the certificate(s). Using curl or another REST API client perform the following API calls and replace the certificate IDs noted in the previous steps. To replace a managers certificate: POST https://<nsx-mgr>/api/v1/node/services/http?action=apply_certificate&certificate_id=e61c7537-3090-4149-b2b6-19915c20504f To replace the cluster certificate: POST https://<nsx-mgr>/api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=d60c6a07-6e59-4873-8edb-339bf75711ac Note: 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.

c
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).
SI-2 - High - CCI-002605 - V-251793 - SV-251793r916114_rule
RMF Control
SI-2
Severity
High
CCI
CCI-002605
Version
TNDM-3X-000096
Vuln IDs
  • V-251793
Rule IDs
  • SV-251793r916114_rule
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.
Checks: C-55253r810380_chk

From an NSX-T Manager shell, run the following command(s): &gt; get logging-servers If any configured logging-servers are not configured with protocol of "tcp", "li-tls", or "tls" and level of "info", this is a finding. If no logging-servers are configured, this is a finding. Note: This check must be run from each NSX-T Manager as they are configured individually.

Fix: F-55207r810381_fix

(Optional) From an NSX-T Manager shell, run the following command(s) to clear any existing incorrect logging-servers: > clear logging-servers From an NSX-T Manager shell, run the following command(s) to configure a tcp syslog server: > set logging-server <server-ip or server-name> proto tcp level info From an NSX-T Manager shell, run the following command(s) to configure a tls syslog server: > set logging-server <server-ip or server-name> proto tls level info serverca ca.pem clientca ca.pem certificate cert.pem key key.pem From an NSX-T Manager shell, run the following command(s) to configure a li-tls syslog server: > set logging-server <server-ip or server-name> proto li-tls level info serverca root-ca.crt Note: 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.

c
The NSX-T Manager must be running a release that is currently supported by the vendor.
CM-6 - High - CCI-000366 - V-251794 - SV-251794r879887_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
TNDM-3X-000097
Vuln IDs
  • V-251794
Rule IDs
  • SV-251794r879887_rule
Network devices running an unsupported operating system lack current security fixes required to mitigate the risks associated with recent vulnerabilities.
Checks: C-55254r810383_chk

From the NSX-T Manager web interface, go to the System &gt;&gt; Upgrade. If the NSX-T Manager current version is not the latest approved for use in DoD and supported by the vendor, this is a finding.

Fix: F-55208r810384_fix

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. https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html If NSX-T is part of a VMware Cloud Foundation, refer to that documentation for latest supported versions and upgrade guidance.

b
The NSX-T Manager must not provide environment information to third parties.
CM-7 - Medium - CCI-000382 - V-251795 - SV-251795r879588_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
TNDM-3X-000098
Vuln IDs
  • V-251795
Rule IDs
  • SV-251795r879588_rule
Providing technical details about an environment's infrastructure to third parties could unknowingly expose sensitive information to bad actors if intercepted.
Checks: C-55255r810386_chk

From the NSX-T Manager web interface, go to System &gt;&gt; Customer Experience Improvement Program. If Joined is set to "Yes", this is a finding.

Fix: F-55209r810387_fix

From the NSX-T Manager web interface, go to System >> Customer Experience Improvement Program, and then click "Edit". Uncheck "Join the VMware Customer Experience Improvement Program" and click "Save".

a
The NSX-T Manager must disable SSH.
CM-7 - Low - CCI-000382 - V-251796 - SV-251796r879588_rule
RMF Control
CM-7
Severity
Low
CCI
CCI-000382
Version
TNDM-3X-000099
Vuln IDs
  • V-251796
Rule IDs
  • SV-251796r879588_rule
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.
Checks: C-55256r810389_chk

From an NSX-T Manager shell, run the following command(s): &gt; get service ssh Expected results: Service name: ssh Service state: stopped Start on boot: False If the output does not match the expected results, this is a finding.

Fix: F-55210r810390_fix

From an NSX-T Manager shell, run the following command(s): > stop service ssh > clear service ssh start-on-boot

b
The NSX-T Manager must disable unused local accounts.
CM-7 - Medium - CCI-000382 - V-251797 - SV-251797r879588_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
TNDM-3X-000100
Vuln IDs
  • V-251797
Rule IDs
  • SV-251797r879588_rule
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.
Checks: C-55257r810392_chk

If NSX-T is not at least version 3.1.1, this is not applicable. From the NSX-T Manager web interface, go to the System &gt;&gt; Users and Roles &gt;&gt; Local Users and view the status column. If the audit, guestuser1, or guestuser2 local accounts are active, this is a finding.

Fix: F-55211r810393_fix

From the NSX-T Manager web interface, go to the System >> Users and Roles >> Local Users. Select the menu drop down next to the user to modify and click "Deactivate User".

b
The NSX-T Manager must disable TLS 1.1 and enable TLS 1.2.
CM-7 - Medium - CCI-000382 - V-251798 - SV-251798r879588_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
TNDM-3X-000101
Vuln IDs
  • V-251798
Rule IDs
  • SV-251798r879588_rule
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.
Checks: C-55258r810395_chk

Viewing TLS protocol enablement must be done via the API. Execute the following API call using curl or another REST API client: GET https://&lt;nsx-mgr&gt;/api/v1/cluster/api-service Expected result: "protocol_versions": [ { "name": "TLSv1.1", "enabled": false }, { "name": "TLSv1.2", "enabled": true } ], If TLS 1.1 is enabled, this is a finding.

Fix: F-55212r810396_fix

Capture the output from the check GET command and update the TLS 1.1 protocol to false. Execute the following API call using curl or another REST API client: PUT https://<nsx-mgr>/api/v1/cluster/api-service Example request body: { "global_api_concurrency_limit": 199, "client_api_rate_limit": 100, "client_api_concurrency_limit": 40, "connection_timeout": 30, "redirect_host": "", "cipher_suites": [ {"enabled": true, "name": "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"}, {"enabled": true, "name": "TLS_RSA_WITH_AES_256_GCM_SHA384"}, {"enabled": true, "name": "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"}, {"enabled": true, "name": "TLS_RSA_WITH_AES_128_GCM_SHA256"} {"enabled": true, "name": "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}", {"enabled": true, "name": "TLS_RSA_WITH_AES_256_CBC_SHA256"}, {"enabled": true, "name": "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"}, {"enabled": true, "name": "TLS_RSA_WITH_AES_256_CBC_SHA"}, {"enabled": true, "name": "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"}, {"enabled": true, "name": "TLS_RSA_WITH_AES_128_CBC_SHA256"}, {"enabled": false, "name": "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"}, {"enabled": false, "name": "TLS_RSA_WITH_AES_128_CBC_SHA"} ], "protocol_versions": [ {"enabled": false, "name": "TLSv1.1"}, {"enabled": true, "name": "TLSv1.2"} ] } Note: 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.

b
The NSX-T Manager must disable SNMP v2.
CM-7 - Medium - CCI-000382 - V-251799 - SV-251799r879588_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
TNDM-3X-000102
Vuln IDs
  • V-251799
Rule IDs
  • SV-251799r879588_rule
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.
Checks: C-55259r810398_chk

From the NSX-T Manager web interface, go to the System &gt;&gt; Fabric &gt;&gt; Profiles &gt;&gt; Node Profiles. Click "All NSX Nodes" and view the SNMP Polling and Traps configuration. If SNMP v2c Polling or Traps are configured, this is a finding.

Fix: F-55213r810399_fix

From the NSX-T Manager web interface, go to the System >> Fabric >> Profiles >> Node Profiles. Click on "All NSX Nodes" and delete and v2c Polling or Trap configurations.

b
The NSX-T Manager must enable the global FIPS compliance mode for load balancers.
CM-7 - Medium - CCI-000382 - V-251800 - SV-251800r879588_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
TNDM-3X-000103
Vuln IDs
  • V-251800
Rule IDs
  • SV-251800r879588_rule
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.
Checks: C-55260r810401_chk

From the NSX-T Manager web interface, go to the Home &gt;&gt; Monitoring Dashboards &gt;&gt; Compliance Report. Review the compliance report for code 72024 with description Load balancer FIPS global setting disabled. Note: This may also be checked via the API call GET https://&lt;nsx-mgr&gt;/policy/api/v1/infra/global-config If the global FIPS setting is disabled for load balancers, this is a finding.

Fix: F-55214r810402_fix

Execute the following API call using curl or another REST API client: PUT https://<nsx-mgr>/policy/api/v1/infra/global-config Example request body: { "fips": { "lb_fips_enabled": true }, "resource_type": "GlobalConfig", "_revision": 2 } The global setting is used when the new load balancer instances are created. Changing the setting does not affect existing load balancer instances. To update existing load balancers to use this setting, do the following: From the NSX-T Manager web interface, go to the Networking >> Load Balancing and then click "Edit" on the target load balancer. In the attachment field, click the "X" to detach the load balancer from its current Gateway and click "Save". Edit the target load balancer again, reattach it to its Gateway, and then click "Save". Caution: Detaching a load balancer from the tier-1 gateway results in a traffic interruption for the load balancer instance.