{"stig":{"title":"VMware NSX 4.x Manager NDM Security Technical Implementation Guide","version":"1","release":"2"},"checks":[{"vulnId":"V-265289","ruleId":"SV-265289r994090_rule","severity":"medium","ruleTitle":"The NSX Manager must configure logging levels for services to ensure audit records are generated.","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).\n\nSatisfies: SRG-APP-000027-NDM-000209, SRG-APP-000495-NDM-000318, SRG-APP-000499-NDM-000319, SRG-APP-000503-NDM-000320, SRG-APP-000504-NDM-000321, SRG-APP-000505-NDM-000322, SRG-APP-000506-NDM-000323, SRG-APP-000516-NDM-000334","checkContent":"From an NSX Manager shell, run the following commands:\n\n> get service async_replicator | find Logging\n> get service auth | find Logging\n> get service http | find Logging\n> get service manager | find Logging\n> get service telemetry | find Logging\n\nExpected result:\nLogging level: info\n\nIf any service listed does not have logging level configured to \"info\", this is a finding.","fixText":"From an NSX Manager shell, run the following commands:\n\n> set service async_replicator logging-level info\n> set service auth logging-level info\n> set service http logging-level info\n> set service manager logging-level info\n> set service telemetry logging-level info","ccis":["CCI-001403","CCI-000172","CCI-000169"]},{"vulnId":"V-265292","ruleId":"SV-265292r994099_rule","severity":"high","ruleTitle":"The NSX Manager must assign users/accounts to organization-defined roles configured with approved authorizations.","description":"The lack of authorization-based access control could result in the immediate compromise and unauthorized access to sensitive information. Users must be assigned to roles which are configured with approved authorizations and access permissions. The NSX Manager must be configured granularly based on organization requirements to only allow authorized administrators to execute privileged functions. Role assignments should control which administrators can view or change the device configuration, system files, and locally stored audit information.\n\nSatisfies: SRG-APP-000033-NDM-000212, SRG-APP-000038-NDM-000213, SRG-APP-000119-NDM-000236, SRG-APP-000120-NDM-000237, SRG-APP-000133-NDM-000244, SRG-APP-000231-NDM-000271, SRG-APP-000329-NDM-000287, SRG-APP-000340-NDM-000288, SRG-APP-000378-NDM-000302, SRG-APP-000380-NDM-000304, SRG-APP-000408-NDM-000314, SRG-APP-000516-NDM-000335","checkContent":"From the NSX Manager web interface, go to System >> Settings >> User Management >> User Role Assignment.\n\nView each user and group and verify the role assigned has authorization limits as appropriate to the role and in accordance with the site's documentation.\n\nIf any user/group or service account are assigned to roles with privileges that are beyond those required and authorized by the organization, this is a finding.","fixText":"To create a new role with reduced permissions, do the following:\n\nFrom the NSX Manager web interface, go to System >> Settings >> User Management >> Roles.\n\nClick \"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 Manager web interface, go to System >> User Management >> User Role Assignment.\n\nClick the menu dropdown next to the target user or group and select \"Edit\".\n\nRemove the existing role, select the new one, and then click \"Save\".","ccis":["CCI-000213","CCI-001368","CCI-000163","CCI-000164","CCI-001499","CCI-001199","CCI-002169","CCI-002235","CCI-001812","CCI-001813","CCI-002883","CCI-000345"]},{"vulnId":"V-265293","ruleId":"SV-265293r994102_rule","severity":"medium","ruleTitle":"The NSX 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 Manager shell, run the following commands:\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 Manager shell, run the following commands:\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-265294","ruleId":"SV-265294r994105_rule","severity":"medium","ruleTitle":"The NSX Manager must display the Standard Mandatory DOD Notice and Consent Banner before granting access.","description":"Display of the DOD-approved use notification before granting access to the network device ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSystem use notifications are required only for access via logon interfaces with human users.","checkContent":"Determine if the network device is configured to present a DOD-approved banner that is formatted in accordance with DTM-08-060.\n\nFrom the NSX Manager web interface, go to System >> Settings >> General Settings >> User Interface.\n\nReview the Login Consent Settings.\n\nIf the \"Consent Message Description\" does not contain the Standard Mandatory DOD Notice and Consent Banner verbiage, this is a finding.\n\nThe Standard Mandatory DOD Notice and Consent Banner verbiage is as follows:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\"","fixText":"From the NSX Manager web interface, go to System >> Settings >> General Settings >> User Interface.\n\nUnder Login Consent Settings click \"Edit\".\n\nEnter the banner language in the \"Consent Message Description\" text box, formatted in accordance with DTM-08-060, and click \"Save\".\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\"","ccis":["CCI-000048"]},{"vulnId":"V-265295","ruleId":"SV-265295r994108_rule","severity":"medium","ruleTitle":"The NSX Manager must retain the Standard Mandatory DOD Notice and Consent Banner on the screen until the administrator acknowledges the usage conditions and takes explicit actions to log on for further access.","description":"The banner must be acknowledged by the administrator prior to the device allowing the administrator access to the network device. This provides assurance that the administrator has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the administrator, DOD will not be in compliance with system use notifications required by law.\n\nTo establish acceptance of the network administration policy, a click-through banner at management session logon is required. The device must prevent further activity until the administrator executes a positive action to manifest agreement.\n\nIn the case of CLI access using a terminal client, entering the username and password when the banner is presented is considered an explicit action of acknowledgement. Entering the username, viewing the banner, then entering the password is also acceptable.","checkContent":"From the NSX Manager web interface, go to System >> Settings >> General Settings >> User Interface.\n\nReview the Login Consent Settings.\n\nVerify \"Login Consent\" is not On.\nVerify \"Require Explicit User Consent\" is set to Yes.\n\nIf the Standard Mandatory DOD Notice and Consent Banner is not retained on the screen until the administrator acknowledges the usage conditions and takes explicit actions to log on for further access, this is a finding.","fixText":"From the NSX Manager web interface, go to System >> Settings >> General Settings >> User Interface.\n\nUnder Login Consent Settings, click \"Edit\".\n\nToggle \"Login Consent\" to On.\n\nToggle \"Require Explicit User Consent\" to Yes.\n\nNote: The banner text is also entered; however, that is covered by NMGR-4X-000013.","ccis":["CCI-000050"]},{"vulnId":"V-265296","ruleId":"SV-265296r994111_rule","severity":"high","ruleTitle":"The NSX Manager must be configured to integrate with an identity provider that supports multifactor authentication (MFA).","description":"Common attacks against single-factor authentication are attacks on user passwords. These attacks include brute force password guessing, password spraying, and password credential stuffing. This requirement also supports nonrepudiation of actions taken by an administrator.\n\nThis requirement ensures the NSX Manager is configured to use a centralized authentication services to authenticate users prior to granting administrative access.\n\nAs of NSX 4.1 and vCenter 8.0 Update 2, NSX Manager administrator access can also be configured by connecting VMware NSX to the Workspace ONE Access Broker in VMware vCenter for federated identity. Refer to the NSX product documentation to configure this access option.\n\nSatisfies: SRG-APP-000080-NDM-000220, SRG-APP-000149-NDM-000247, SRG-APP-000516-NDM-000336","checkContent":"From the NSX Manager web interface, go to System >> Settings >> Users Management >> Authentication Providers.\n\nVerify that the \"VMware Identity Manager\" and \"OpenID Connect\" tabs are configured.\n\nIf NSX is not configured to integrate with an identity provider that supports MFA, this is a finding.","fixText":"To configure NSX to integrate with VMware Identity Manager or Workspace ONE Access, as the authentication source, do the following:\n\nFrom the NSX 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 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. (The users are not actually local and remain in the authentication/AAA server.)\n\nNote: As of NSX 4.1 and vCenter 8.0 Update 2, NSX Manager administrator access can also be configured by connecting VMware NSX to the Workspace ONE Access Broker in VMware vCenter for federated identity. Refer to the NSX product documentation to configure this access option.\n\nEnsure the identity provider administrators have configured the provider to support multi-factor authentication.","ccis":["CCI-000166","CCI-000765","CCI-000370"]},{"vulnId":"V-265313","ruleId":"SV-265313r1051115_rule","severity":"medium","ruleTitle":"The NSX Manager must be configured with only one local account to be used as the account of last resort in the event the authentication server is unavailable.","description":"Authentication for administrative (privileged level) access to the device is required at all times. An account can be created on the device's local database for use when the authentication server is down or connectivity between the device and the authentication server is not operable. This account is referred to as the account of last resort since it is intended to be used as a last resort and when immediate administrative access is absolutely necessary.\n\nThe account of last resort logon credentials must be stored in a sealed envelope and kept in a safe. The safe must be periodically audited to verify the envelope remains sealed. The signature of the auditor and the date of the audit should be added to the envelope as a record. Administrators should secure the credentials and disable the root account (if possible) when not needed for system administration functions.","checkContent":"From the NSX Manager web interface, go to the System >> Settings >> User Management >> Local Users and view the status column.\n\nIf any local account other than the account of last resort are active, this is a finding.","fixText":"From the NSX Manager web interface, go to the System >> Settings >> User Management >> Local Users.\n\nSelect the menu drop down next to any local user on the list except for the \"admin\" account. Click modify and click \"Deactivate User\".","ccis":["CCI-001358"]},{"vulnId":"V-265315","ruleId":"SV-265315r994168_rule","severity":"high","ruleTitle":"The NSX Manager must only enable TLS 1.2 or greater.","description":"A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. Configuration of TLS on the NSX also ensures that passwords are not transmitted in the clear.\n\nTLS 1.0 and 1.1 are deprecated protocols with well-published shortcomings and vulnerabilities. TLS 1.2 or greater must be enabled on all interfaces and TLS 1.1 and 1.0 disabled where supported.\n\nSatisfies: SRG-APP-000156-NDM-000250, SRG-APP-000172-NDM-000259","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\nExample result:\n\n\"protocol_versions\": [\n{\n\"name\": \"TLSv1.1\",\n\"enabled\": false\n},\n{\n\"name\": \"TLSv1.2\",\n\"enabled\": true\n},\n{\n\"name\": \"TLSv1.3\",\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\nRun 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    \"session_timeout\": 1800,\n    \"connection_timeout\": 30,\n    \"protocol_versions\": [\n        {\n            \"name\": \"TLSv1.1\",\n            \"enabled\": false\n        },\n        {\n            \"name\": \"TLSv1.2\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLSv1.3\",\n            \"enabled\": true\n        }\n    ],\n    \"cipher_suites\": [\n        {\n            \"name\": \"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_RSA_WITH_AES_128_CBC_SHA\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_RSA_WITH_AES_128_CBC_SHA256\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_RSA_WITH_AES_128_GCM_SHA256\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_RSA_WITH_AES_256_CBC_SHA\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_RSA_WITH_AES_256_CBC_SHA256\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_RSA_WITH_AES_256_GCM_SHA384\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_AES_128_GCM_SHA256\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_AES_256_GCM_SHA384\",\n            \"enabled\": true\n        },\n        {\n            \"name\": \"TLS_CHACHA20_POLY1305_SHA256\",\n            \"enabled\": true\n        }\n    ],\n    \"redirect_host\": \"\",\n    \"client_api_rate_limit\": 100,\n    \"global_api_concurrency_limit\": 199,\n    \"client_api_concurrency_limit\": 40,\n    \"basic_authentication_enabled\": true,\n    \"cookie_based_authentication_enabled\": true,\n    \"resource_type\": \"ApiServiceConfig\",\n    \"id\": \"reverse_proxy_config\",\n    \"display_name\": \"reverse_proxy_config\",\n    \"_create_time\": 1703175890703,\n    \"_create_user\": \"system\",\n    \"_last_modified_time\": 1703175890703,\n    \"_last_modified_user\": \"system\",\n    \"_system_owned\": false,\n    \"_protection\": \"NOT_PROTECTED\",\n    \"_revision\": 0\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-001941","CCI-000197"]},{"vulnId":"V-265316","ruleId":"SV-265316r994171_rule","severity":"medium","ruleTitle":"The NSX Manager must enforce a minimum 15-character password length for local accounts.","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 Manager shell, run the following command:\n\n>  get password-complexity\n\nIf the minimum password length is not 15 or greater, this is a finding.","fixText":"From an NSX Manager shell, run the following command:\n\n> set password-complexity minimum-password-length 15","ccis":["CCI-000205"]},{"vulnId":"V-265317","ruleId":"SV-265317r994174_rule","severity":"medium","ruleTitle":"The NSX Manager must enforce password complexity by requiring that at least one uppercase character be used for local accounts.","description":"Use of a complex passwords helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.\n\nMultifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using public key infrastructure (PKI) is not available, and for the account of last resort and root account.","checkContent":"From an NSX Manager shell, run the following command:\n\n>  get password-complexity\n\nIf the minimum uppercase characters is not 1 or more, this is a finding.\n\nNote: If a maximum number of uppercase characters has been configured a minimum will not be shown.","fixText":"From an NSX Manager shell, run the following command:\n\n> set password-complexity upper-chars -1\n\nNote: Negative numbers indicate a minimum number of characters.","ccis":["CCI-000192"]},{"vulnId":"V-265318","ruleId":"SV-265318r994177_rule","severity":"medium","ruleTitle":"The NSX Manager must enforce password complexity by requiring that at least one lowercase character be used for local accounts.","description":"Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.\n\nMultifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account.","checkContent":"From an NSX Manager shell, run the following command:\n\n>  get password-complexity\n\nIf the minimum lowercase characters is not 1 or more, this is a finding.\n\nNote: If a maximum number of lowercase characters has been configured, a minimum will not be shown.","fixText":"From an NSX Manager shell, run the following command:\n\n> set password-complexity lower-chars -1\n\nNote: Negative numbers indicate a minimum number of characters.","ccis":["CCI-000193"]},{"vulnId":"V-265319","ruleId":"SV-265319r994180_rule","severity":"medium","ruleTitle":"The NSX Manager must enforce password complexity by requiring that at least one numeric character be used for local accounts.","description":"Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.\n\nMultifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account.","checkContent":"From an NSX Manager shell, run the following command:\n\n>  get password-complexity\n\nIf the minimum numeric characters is not 1 or more, this is a finding.\n\nNote: If a maximum number of numeric characters has been configured, a minimum will not be shown.","fixText":"From an NSX Manager shell, run the following command:\n\n> set password-complexity digits -1\n\nNote: Negative numbers indicate a minimum number of characters.","ccis":["CCI-000194"]},{"vulnId":"V-265320","ruleId":"SV-265320r994183_rule","severity":"medium","ruleTitle":"The NSX Manager must enforce password complexity by requiring that at least one special character be used for local accounts.","description":"Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.\n\nMultifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account.","checkContent":"From an NSX Manager shell, run the following command:\n\n>  get password-complexity\n\nIf the minimum special characters is not 1 or more, this is a finding.\n\nNote: If a maximum number of special characters has been configured, a minimum will not be shown.","fixText":"From an NSX Manager shell, run the following command:\n\n> set password-complexity special-chars -1\n\nNote: Negative numbers indicate a minimum number of characters.","ccis":["CCI-001619"]},{"vulnId":"V-265321","ruleId":"SV-265321r1043189_rule","severity":"medium","ruleTitle":"The NSX Manager must require that when a password is changed, the characters are changed in at least eight of the positions within the password.","description":"If the application allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks.\n\nThe number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.\n\nMultifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account.","checkContent":"From an NSX Manager shell, run the following command:\n\n>  get password-complexity\n\nIf the number of consecutive characters allowed for reuse is not eight or more, this is a finding.\n\nNote: If this has not previously been configured it will not be shown in the output.","fixText":"From an NSX Manager shell, run the following command:\n\n> set password-complexity max-repeats 8","ccis":["CCI-000195"]},{"vulnId":"V-265327","ruleId":"SV-265327r994204_rule","severity":"high","ruleTitle":"The NSX Manager must terminate all network connections associated with a session after five minutes of inactivity.","description":"Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take immediate 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 deallocating 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.\n\nSatisfies: SRG-APP-000190-NDM-000267, SRG-APP-000186-NDM-000266, SRG-APP-000400-NDM-000313","checkContent":"From an NSX Manager shell, run the following command:\n\n> get service http | find Session\n\nExpected result:\nSession timeout: 300\n\nIf the session timeout is not configured to 300 or less, this is a finding.\n\nFrom an NSX Manager shell, run the following command:\n\n> get cli-timeout\n\nExpected result:\n300 seconds\n\nIf the CLI timeout is not configured to 300 or less, this is a finding.","fixText":"From an NSX Manager shell, run the following commands:\n\n> set service http session-timeout 300\n> set cli-timeout 300","ccis":["CCI-001133","CCI-000879","CCI-002007"]},{"vulnId":"V-265338","ruleId":"SV-265338r994237_rule","severity":"medium","ruleTitle":"The NSX 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 use an authoritative time server and/or be configured to use redundant authoritative time sources.\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 Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles.\n\nClick \"All NSX Nodes\" and verify the NTP servers listed.\n\nor\n\nFrom an NSX Manager shell, run the following command:\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 nonauthoritative time sources, this is a finding.","fixText":"To configure a profile to apply NTP servers to all NSX Manager nodes, do the following:\n\nFrom the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles.\n\nClick \"All NSX Nodes\" and then click \"Edit\".\n\nUnder NTP servers, remove any unknown or nonauthoritative NTP servers, enter at least two authoritative servers, and then click \"Save\".\n\nor\n\nFrom an NSX Manager shell, run the following commands:\n\n> del ntp-server <server-ip or server-name>\n> set ntp-server <server-ip or server-name>","ccis":["CCI-001893"]},{"vulnId":"V-265339","ruleId":"SV-265339r994240_rule","severity":"medium","ruleTitle":"The NSX 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 Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.","checkContent":"From the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles.\n\nNote: This check must be run from each NSX Manager as they are configured individually if done from the command line.\n\nClick \"All NSX Nodes\" and verify the time zone.\n\nor\n\nFrom an NSX Manager shell, run the following command:\n\n> get clock\n\nIf system clock is not configured with the UTC time zone, this is a finding.","fixText":"To configure a profile to apply a time zone to all NSX Manager nodes, do the following:\n\nFrom the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles.\n\nClick \"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 Manager shell, run the following command:\n\n> set timezone UTC\n\nNote: This fix must be run from each NSX Manager as they are configured individually if done from the command line.","ccis":["CCI-001890"]},{"vulnId":"V-265346","ruleId":"SV-265346r994261_rule","severity":"medium","ruleTitle":"The NSX Manager must be configured to protect against denial-of-service (DoS) attacks by limit the number of concurrent sessions to an organization-defined number.","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\nLimiting the number of concurrent open sessions helps limit the risk of DoS attacks.\n\nOrganizations may define the maximum number of concurrent sessions for system accounts globally or by connection type. By default, the NSX Manager has a protection mechanism in place to prevent the API from being overloaded. This setting also addresses concurrent sessions for integrations into NSX API to monitor or configure NSX.\n\nSatisfies: SRG-APP-000435-NDM-000315, SRG-APP-000001-NDM-000200","checkContent":"From an NSX Manager shell, run the following command:\n\n> get service http | find limit\n\nExpected result:\nClient API concurrency limit: 40 connections\nGlobal API concurrency limit: 199 connections\n\nIf the NSX does not limit the number of concurrent sessions to an organization-defined number, this is a finding.","fixText":"From an NSX Manager shell, run the following commands:\n\n> set service http client-api-concurrency-limit 40\n> set service http global-api-concurrency-limit 199\n\nNote: The limit numbers in this example, while not mandatory, are the vendor recommend options. Setting the limits to lower numbers in a large environment that is very busy may cause operational issues. Setting the limits higher may cause resource contention so should be tested and monitored.","ccis":["CCI-002385","CCI-000054"]},{"vulnId":"V-265348","ruleId":"SV-265348r994267_rule","severity":"high","ruleTitle":"The NSX 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\nOff-loading is a common process in information systems with limited audit storage capacity.\n\nSatisfies: SRG-APP-000515-NDM-000325, SRG-APP-000357-NDM-000293, SRG-APP-000516-NDM-000350","checkContent":"From the NSX Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles.\n\nClick \"All NSX Nodes\" and verify the Syslog servers listed.\n\nor\n\nFrom an NSX Manager shell, run the following command:\n\n> get logging-servers\n\nNote: This command must be run from each NSX Manager as they are configured individually.\n\nIf no logging severs are configured or unauthorized logging servers are configured, this is a finding.\n\nIf the log level is not set to INFO, this is a finding.","fixText":"To configure a profile to apply syslog servers to all NSX Manager nodes, do the following:\n\nFrom the NSX Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles.\n\nClick \"All NSX Nodes\" and then under \"Syslog Servers\" click \"Add\".\n\nEnter the syslog server details and choose \"Information\" for the log level and click \"Add\".\n\nor\n\n(Optional) From an NSX Manager shell, run the following command to clear any existing incorrect logging-servers:\n\n> clear logging-servers\n\nFrom an NSX Manager shell, run the following command to configure a udp/tcp syslog server:\n\n> set logging-server <server-ip or server-name> proto <tcp or udp> level info\n\nFrom an NSX Manager shell, run the following command 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 Manager shell, run the following command 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","CCI-001849"]},{"vulnId":"V-265349","ruleId":"SV-265349r994270_rule","severity":"low","ruleTitle":"The NSX 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 Manager web interface, go to System >> Settings >> General Settings >> Customer Program >> Customer Experience Improvement Program.\n\nIf Joined is set to \"Yes\", this is a finding.","fixText":"From the NSX Manager web interface, go to System >> Settings >> General Settings >> Customer Program >> Customer Experience Improvement Program, and then click \"Edit\".\n\nUncheck \"Join the VMware Customer Experience Improvement Program\" and click \"Save\".","ccis":["CCI-000366"]},{"vulnId":"V-265350","ruleId":"SV-265350r994273_rule","severity":"medium","ruleTitle":"The NSX Manager must be configured to conduct backups on an organizationally defined schedule.","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.\n\nSatisfies: SRG-APP-000516-NDM-000341, SRG-APP-000516-NDM-000340","checkContent":"From the NSX Manager web interface, go to System >> Lifecycle Management >> 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 Manager web interface, go to System >> Lifecycle Management >> 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 Manager web interface, go to System >> Lifecycle Management >> Backup and Restore, and then click \"Edit\" next to Schedule.\n\nClick the \"Recurring Backup\" toggle and configure an interval between backups.\n\nEnable \"Detect NSX configuration change\" to trigger backups on detection of configuration changes and specify an interval for detecting changes. Click \"Save\".","ccis":["CCI-000539","CCI-000366"]},{"vulnId":"V-265351","ruleId":"SV-265351r994276_rule","severity":"medium","ruleTitle":"The NSX Manager must obtain its public key certificates from an appropriate certificate policy through an approved service provider.","description":"For user certificates, each organization obtains certificates from an approved, shared service provider, as required by Office of Management and Budget (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 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 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 Manager shell, run the following commands:\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 Manager web interface or cluster is using is not issued by an approved certificate authority and is not currently valid, this is a finding.","fixText":"Obtain a certificate or certificates signed by an approved certification authority.\n\nThis can be done individually by generating CSRs through the NSX Manager web interface >> System >> Settings >> Certificates >> CSRs >> Generate CSR or outside of NSX if a common manager and cluster certificate is desired.\n\nImport the certificate(s) into NSX by doing the following:\n\nFrom the NSX Manager web interface, go to System >> Settings >> Certificates >> Certificates >> Import >> Import Certificate. Provide a name for the certificate and paste the certificates contents and key.\n\nUncheck \"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. Refer to the VMware Knowledge Base article https://kb.vmware.com/s/article/78505 for more information.","ccis":["CCI-000366"]},{"vulnId":"V-265352","ruleId":"SV-265352r994279_rule","severity":"high","ruleTitle":"The NSX 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 Manager web interface, go to the System >> Lifecycle Management >> Upgrade.\n\nIf the NSX 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, reference the upgrade guide in the documentation for the relevant version being upgraded. Refer to the NSX documentation and release notes for information on the latest releases.\n\nhttps://docs.vmware.com/en/VMware-NSX/index.html\n\nIf NSX is part of a VMware Cloud Foundation deployment, refer to that documentation for latest supported versions and upgrade guidance.","ccis":["CCI-000366"]},{"vulnId":"V-265353","ruleId":"SV-265353r994282_rule","severity":"medium","ruleTitle":"The NSX Manager must disable SSH.","description":"The NSX shell provides temporary access to commands essential for server maintenance. Intended primarily for use in break-fix scenarios, the NSX shell is well suited for checking and modifying configuration details, not always generally accessible, using the web interface. The NSX 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 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 Manager shell, run the following command:\n\n> get service ssh\n\nExpected results:\nService name: ssh\nService state: stopped\nStart on boot: False\n\nIf the SSH server is not stopped or starts on boot, this is a finding.","fixText":"From an NSX Manager shell, run the following command(s):\n\n> stop service ssh\n> clear service ssh start-on-boot","ccis":["CCI-000366"]},{"vulnId":"V-265354","ruleId":"SV-265354r994285_rule","severity":"medium","ruleTitle":"The NSX 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 Manager web interface, go to the System >> Configuration >> 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 Manager web interface, go to the System >> Configuration >> Fabric >> Profiles >> Node Profiles.\n\nClick on \"All NSX Nodes\" and delete and v2c Polling or Trap configurations.","ccis":["CCI-000366"]},{"vulnId":"V-265355","ruleId":"SV-265355r994288_rule","severity":"medium","ruleTitle":"The NSX 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 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 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-000366"]},{"vulnId":"V-265358","ruleId":"SV-265358r994297_rule","severity":"medium","ruleTitle":"The NSX Manager must be configured as a cluster.","description":"Failure in a known state can address safety or security in accordance with the mission needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the SDN controller. Preserving network element state information helps to facilitate continuous network operations minimal or no disruption to mission-essential workload processes and flows.","checkContent":"From the NSX Manager web interface, go to System >> Configuration >> Appliances.\n\nVerify three NSX Managers are deployed, a VIP or external load balancer is configured, and the cluster is in a healthy state.\n\nIf three NSX Managers are not deployed, a VIP or external load balancer is not configured, and the cluster is not in a healthy state, this is a finding.","fixText":"To add additional NSX Manager appliances do the following:\n\nFrom the NSX Manager web interface, go to System >> Configuration >> Appliances, and then click \"Add NSX Appliance\".\n\nSupply the required information to add additional nodes as needed, up to three total.\n\nTo configure NSX with a cluster VIP or external load balancer, do the following:\n\nFrom the NSX Manager web interface, go to System >> Configuration >> Appliances, and then click \"Set Virtual IP\", enter a VIP that is part of the same subnet as the other management nodes, and then click \"Save\".\n\nTo configure NSX with an external load balancer, setup an external load balancer with the following requirements:\n\n- Configure the external load balancer to control traffic to the NSX Manager nodes.\n- Configure the external load balancer to use the round robin method and configure source persistence for the load balancer's virtual IP.\n- Create or import a signed certificate and apply the same certificate to all the NSX Manager nodes. The certificate must have the FQDN of the virtual IP and each of the nodes in the SAN.\n\nNote: An external load balancer will not work with the NSX Manager VIP. Do not configure an NSX Manager VIP if using an external load balancer.\n\nIf the cluster status is not in a healthy state, identify the degraded component on the appliance and troubleshoot the issue with the error information provided.","ccis":["CCI-002385"]},{"vulnId":"V-265359","ruleId":"SV-265359r994300_rule","severity":"medium","ruleTitle":"The NSX Managers must be deployed on separate physical hosts.","description":"SDN relies heavily on control messages between a controller and the forwarding devices for network convergence. The controller uses node and link state discovery information to calculate and determine optimum pathing within the SDN network infrastructure based on application, business, and security policies. Operating in the proactive flow instantiation mode, the SDN controller populates forwarding tables to the SDN-aware forwarding devices. At times, the SDN controller must function in reactive flow instantiation mode; that is, when a forwarding device receives a packet for a flow not found in its forwarding table, it must send it to the controller to receive forwarding instructions.\n\nWith total dependence on the SDN controller for determining forwarding decisions and path optimization within the SDN infrastructure for both proactive and reactive flow modes of operation, having a single point of failure is not acceptable. A controller failure with no failover backup leaves the network in an unmanaged state. Hence, it is imperative that the SDN controllers are deployed as clusters on separate physical hosts to guarantee high network availability.","checkContent":"This check must be performed in vCenter.\n\nFrom the vSphere Client, go to Administration >> Hosts and Clusters >> Select the cluster where the NSX Managers are deployed >> Configure >> Configuration >> VM/Host Rules.\n\nIf the NSX Manager cluster does not have rules applied to it that separate the nodes onto different physical hosts, this is a finding.","fixText":"This fix must be performed in vCenter.\n\nFrom the vSphere Client, go to Administration >> Hosts and Clusters >> Select the cluster where the NSX Managers are deployed >> Configure >> Configuration >> VM/Host Rules.\n\nClick \"Add\" to create a new rule.\n\nProvide a name and select \"Separate Virtual Machines\" under Type.\n\nAdd the three NSX Manager virtual machines to the list and click \"OK\".","ccis":["CCI-002385"]}]}