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

VMware vSphere 8.0 vCenter Security Technical Implementation Guide

V2R1 · · · Released 01 Aug 2024 · 67 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

This Security Technical Implementation Guide is published as a tool to improve the security of Department of 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.
Digest of Updates vs. V1R1 · 31 Oct 2023 +2 ✎ 5

Comparison against the immediately-prior release (V1R1). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.

Added rules 2

  • V-265978 Medium The vCenter Server must use DOD-approved encryption to protect the confidentiality of network sessions.
  • V-265979 Medium The vCenter Server must disable accounts used for Integrated Windows Authentication (IWA).

Content changes 5

  • V-258919 Medium checkfix The vCenter Server must enable revocation checking for certificate-based authentication.
  • V-258927 Medium check The vCenter Server must compare internal information system clocks at least every 24 hours with an authoritative time server.
  • V-258951 Medium check The vCenter Server must restrict access to the default roles with cryptographic permissions.
  • V-258952 Medium check The vCenter Server must restrict access to cryptographic permissions.
  • V-258954 Medium fix The vCenter Server must have new Key Encryption Keys (KEKs) reissued at regular intervals for vSAN encrypted datastore(s).
Sort by
b
The vCenter Server must enforce the limit of three consecutive invalid login attempts by a user.
AC-7 - Medium - CCI-000044 - V-258905 - SV-258905r960840_rule
RMF Control
AC-7
Severity
M
CCI
CCI-000044
Version
VCSA-80-000023
Vuln IDs
  • V-258905
Rule IDs
  • SV-258905r960840_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. Limits are imposed by locking the account.
Checks: C-62645r934371_chk

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Lockout Policy. The following lockout policy should be set as follows: Maximum number of failed login attempts: 3 If this account lockout policy is not configured as stated, this is a finding.

Fix: F-62554r934372_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Lockout Policy. Click "Edit". Set the "Maximum number of failed login attempts" to "3" and click "Save".

b
The vCenter Server must display the Standard Mandatory DOD Notice and Consent Banner before logon.
AC-8 - Medium - CCI-000048 - V-258906 - SV-258906r960843_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
VCSA-80-000024
Vuln IDs
  • V-258906
Rule IDs
  • SV-258906r960843_rule
Display of the DOD-approved use notification before granting access to the application ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for applications that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -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. -At any time, the USG may inspect and seize data stored on this IS. -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. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -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." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read (literal ampersand) consent to terms in IS user agreem't." Satisfies: SRG-APP-000068, SRG-APP-000069, SRG-APP-000070
Checks: C-62646r934374_chk

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Login Message. If the selection box next to "Show login message" is disabled, "Details of login message" is not configured to the standard DOD User Agreement, or the "Consent checkbox" is disabled, this is a finding. Note: Refer to vulnerability discussion for user agreement language.

Fix: F-62555r934375_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Login Message. Click "Edit". Click the "Show login message" slider to enable. Configure the "Login message" to "DOD User Agreement". Click the "Consent checkbox" slider to enable. Set the "Details of login message" to the Standard Mandatory DOD Notice and Consent Banner text. Click "Save".

b
The vCenter Server must produce audit records containing information to establish what type of events occurred.
AU-3 - Medium - CCI-000130 - V-258907 - SV-258907r960891_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
VCSA-80-000034
Vuln IDs
  • V-258907
Rule IDs
  • SV-258907r960891_rule
Without establishing what types of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack.
Checks: C-62647r934377_chk

From the vSphere Client, go to Host and Clusters. Select a vCenter Server >> Configure >> Settings >> Advanced Settings. Verify the "config.log.level" value is set to "info". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.log.level and verify it is set to "info". If the "config.log.level" value is not set to "info" or does not exist, this is a finding.

Fix: F-62556r934378_fix

From the vSphere Client, go to Host and Clusters. Select a vCenter Server >> Configure >> Settings >> Advanced Settings. Click "Edit Settings" and configure the "config.log.level" setting to "info". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.log.level | Set-AdvancedSetting -Value info

b
vCenter Server plugins must be verified.
CM-7 - Medium - CCI-000381 - V-258908 - SV-258908r960963_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
VCSA-80-000057
Vuln IDs
  • V-258908
Rule IDs
  • SV-258908r960963_rule
The vCenter Server includes a vSphere Client extensibility framework, which provides the ability to extend the vSphere Client with menu selections or toolbar icons that provide access to vCenter Server add-on components or external, web-based functionality. vSphere Client plugins or extensions run at the same privilege level as the user. Malicious extensions might masquerade as useful add-ons while compromising the system by stealing credentials or incorrectly configuring the system. Additionally, vCenter comes with a number of plugins preinstalled that may or may not be necessary for proper operation.
Checks: C-62648r934380_chk

From the vSphere Client, go to Administration &gt;&gt; Solutions &gt;&gt; Client Plug-Ins. View the Installed/Available Plug-ins list and verify they are all identified as authorized VMware, third-party (partner), and/or site-specific approved plug-ins. If any installed/available plug-ins in the viewable list cannot be verified as allowed vSphere Client plug-ins from trusted sources or are not in active use, this is a finding.

Fix: F-62557r934381_fix

From the vSphere Client, go to Administration >> Solutions >> Client Plug-Ins, click the radio button next to the unknown plug-in, and click "Disable". If the plugin will not be needed in the future, proceed to uninstall the plug-in. To uninstall plug-ins, do the following: If vCenter Server is in linked mode, perform this procedure on the vCenter Server that is used to install the plug-in initially and then restart the vCenter Server services on the linked vCenter Server: In a web browser, navigate to "http://vCenter_Server_name_or_IP/mob", where "vCenter_Server_name_or_IP/mob" is the name of the vCenter Server or its IP address. Click "Content". Click "ExtensionManager". Select and copy the name of the plug-in to be removed from the list of values under "Properties". Click "UnregisterExtension". A new window appears. Paste the name of the plug-in and click "Invoke Method". This removes the plug-in. Close the window. Refresh the Managed Object Type:ManagedObjectReference:ExtensionManager window to verify the plug-in is removed successfully. Note: If the plug-in still appears, restart the vSphere Client. Note: The Managed Object Browser (MOB) may have to be enabled temporarily if it was disabled previously.

b
The vCenter Server must uniquely identify and authenticate users or processes acting on behalf of users.
IA-2 - Medium - CCI-000764 - V-258909 - SV-258909r1003590_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000764
Version
VCSA-80-000059
Vuln IDs
  • V-258909
Rule IDs
  • SV-258909r1003590_rule
To ensure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and any processes acting on behalf of users) must be uniquely identified and authenticated for all accesses except the following. (i) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and (ii) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Using Active Directory or an identity provider for authentication provides more robust account management capabilities and accountability. Satisfies: SRG-APP-000148, SRG-APP-000153, SRG-APP-000163, SRG-APP-000180, SRG-APP-000234
Checks: C-62649r934383_chk

From the vSphere Web Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Identity Provider. If the identity provider type is "embedded" and there is no identity source of type "Active Directory" (either Windows Integrated Authentication or LDAP), this is a finding. If the identity provider type is "Microsoft ADFS" or another supported identity provider, this is NOT a finding.

Fix: F-62558r934384_fix

When using the embedded identity provider type, perform the following: From the vSphere Web Client, go to Administration >> Single Sign On >> Configuration >> Identity Provider >> Identity Sources. Click "Add". Select either "Active Directory over LDAP" or "Active Directory (Windows Integrated Authentication)" and configure appropriately. Note: Windows Integrated Authentication requires that the vCenter server be joined to Active Directory before configuration via Administration >> Single Sign On >> Configuration >> Identity Provider >> Active Directory Domain. OR To change the identity provider type to a third-party identity provider such as Microsoft ADFS, perform the following: From the vSphere Web Client, go to Administration >> Single Sign On >> Configuration >> Identity Provider. Click "Change Identity Provider". Select "Microsoft ADFS" and click "Next". Enter the ADFS server information and User and Group details and click "Finish". For additional information on configuring ADFS for use with vCenter, refer to the vSphere documentation.

b
The vCenter Server must require multifactor authentication.
AU-10 - Medium - CCI-000166 - V-258910 - SV-258910r960864_rule
RMF Control
AU-10
Severity
M
CCI
CCI-000166
Version
VCSA-80-000060
Vuln IDs
  • V-258910
Rule IDs
  • SV-258910r960864_rule
Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). Satisfies: SRG-APP-000080, SRG-APP-000149, SRG-APP-000150, SRG-APP-000391, SRG-APP-000402
Checks: C-62650r934386_chk

From the vSphere Web Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Identity Provider. If the embedded identity provider is used, click on "Smart Card Authentication". If the embedded identity provider is used and "Smart Card Authentication" is not enabled, this is a finding. If a third-party identity provider is used, such as Microsoft ADFS, and it does not require multifactor authentication to log on to vCenter, this is a finding.

Fix: F-62559r934387_fix

To configure smart card authentication for vCenter when using the embedded identity provider, refer to the vSphere documentation. For vCenter Servers using a third-party identity provider, consult the product's documentation for enabling multifactor authentication.

b
The vCenter Server passwords must be at least 15 characters in length.
Medium - CCI-004066 - V-258911 - SV-258911r1003591_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
VCSA-80-000069
Vuln IDs
  • V-258911
Rule IDs
  • SV-258911r1003591_rule
The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. 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-62651r934389_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Local Accounts &gt;&gt; Password Policy. View the value of the "Minimum Length" setting. Minimum Length: 15 If the password policy is not configured with a "Minimum Length" policy of "15" or more, this is a finding.

Fix: F-62560r934390_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Password Policy. Click "Edit". Set the "Minimum Length" to "15" and click "Save".

b
The vCenter Server must prohibit password reuse for a minimum of five generations.
Medium - CCI-004061 - V-258912 - SV-258912r1003592_rule
RMF Control
Severity
M
CCI
CCI-004061
Version
VCSA-80-000070
Vuln IDs
  • V-258912
Rule IDs
  • SV-258912r1003592_rule
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords must be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the result is a password that is not changed per policy requirements.
Checks: C-62652r934392_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Local Accounts &gt;&gt; Password Policy. View the value of the "Restrict reuse" setting. Restrict reuse: Users cannot reuse any previous 5 passwords If the password policy is not configured with a "Restrict reuse" policy of "5" or more, this is a finding.

Fix: F-62561r934393_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Password Policy. Click "Edit". Set the "Restrict reuse" to "5" and click "Save".

b
The vCenter Server passwords must contain at least one uppercase character.
Medium - CCI-004066 - V-258913 - SV-258913r1003593_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
VCSA-80-000071
Vuln IDs
  • V-258913
Rule IDs
  • SV-258913r1003593_rule
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. Password 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.
Checks: C-62653r934395_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Local Accounts &gt;&gt; Password Policy. View the value of the "Character requirements" setting. Character requirements: At least 1 uppercase characters If the password policy is not configured with "Character requirements" policy requiring "1" or more uppercase characters, this is a finding.

Fix: F-62562r934396_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Password Policy. Click "Edit". Set "uppercase characters" to at least "1" and click "Save".

b
The vCenter Server passwords must contain at least one lowercase character.
Medium - CCI-004066 - V-258914 - SV-258914r1003594_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
VCSA-80-000072
Vuln IDs
  • V-258914
Rule IDs
  • SV-258914r1003594_rule
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. Password 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.
Checks: C-62654r934398_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Local Accounts &gt;&gt; Password Policy. View the value of the "Character requirements" setting. Character requirements: At least 1 lowercase characters If the password policy is not configured with "Character requirements" policy requiring "1" or more lowercase characters, this is a finding.

Fix: F-62563r934399_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Password Policy. Click "Edit". Set "lowercase characters" to at least "1" and click "Save".

b
The vCenter Server passwords must contain at least one numeric character.
Medium - CCI-004066 - V-258915 - SV-258915r1003595_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
VCSA-80-000073
Vuln IDs
  • V-258915
Rule IDs
  • SV-258915r1003595_rule
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. Password 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.
Checks: C-62655r934401_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Local Accounts &gt;&gt; Password Policy. View the value of the "Character requirements" setting. Character requirements: At least 1 numeric characters If the password policy is not configured with "Character requirements" policy requiring "1" or more numeric characters, this is a finding.

Fix: F-62564r934402_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Password Policy. Click "Edit". Set "numeric characters" to at least "1" and click "Save".

b
The vCenter Server passwords must contain at least one special character.
Medium - CCI-004066 - V-258916 - SV-258916r1003596_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
VCSA-80-000074
Vuln IDs
  • V-258916
Rule IDs
  • SV-258916r1003596_rule
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. Password complexity is one factor in determining 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. Special characters are not alphanumeric. Examples include: ~ ! @ # $ % ^ *.
Checks: C-62656r934404_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Local Accounts &gt;&gt; Password Policy. View the value of the "Character requirements" setting. Character requirements: At least 1 special characters If the password policy is not configured with "Character requirements" policy requiring "1" or more special characters, this is a finding.

Fix: F-62565r934405_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Password Policy. Click "Edit". Set "special characters" to at least "1" and click "Save".

c
The vCenter Server must enable FIPS-validated cryptography.
IA-5 - High - CCI-000197 - V-258917 - SV-258917r961029_rule
RMF Control
IA-5
Severity
H
CCI
CCI-000197
Version
VCSA-80-000077
Vuln IDs
  • V-258917
Rule IDs
  • SV-258917r961029_rule
FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules use authentication that meets DOD requirements. In vSphere 6.7 and later, ESXi and vCenter Server use FIPS-validated cryptography to protect management interfaces and the VMware Certificate Authority (VMCA). vSphere 7.0 Update 2 and later adds additional FIPS-validated cryptography to vCenter Server Appliance. By default, this FIPS validation option is disabled and must be enabled. Satisfies: SRG-APP-000172, SRG-APP-000179, SRG-APP-000224, SRG-APP-000231, SRG-APP-000412, SRG-APP-000514, SRG-APP-000555, SRG-APP-000600, SRG-APP-000610, SRG-APP-000620, SRG-APP-000630, SRG-APP-000635
Checks: C-62657r934407_chk

From the vSphere Web Client, go to Developer Center &gt;&gt; API Explorer. From the "Select API" drop-down menu, select appliance. Expand system/security/global_fips &gt;&gt; GET. Click "Execute" and then "Copy Response" to view the results. Example response: { "enabled": true } or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Invoke-GetSystemGlobalFips If global FIPS mode is not enabled, this is a finding.

Fix: F-62566r934408_fix

From the vSphere Web Client go to Developer Center >> API Explorer. From the "Select API" drop-down menu, select appliance. Expand system/security/global_fips >> PUT. In the response body under "Try it out" paste the following: { "enabled": true } Click "Execute". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: $spec = Initialize-SystemSecurityGlobalFipsUpdateSpec -Enabled $true; Invoke-SetSystemGlobalFips -SystemSecurityGlobalFipsUpdateSpec $spec Note: The vCenter server reboots after FIPS is enabled or disabled.

b
The vCenter Server must enforce a 90-day maximum password lifetime restriction.
Medium - CCI-004066 - V-258918 - SV-258918r1003597_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
VCSA-80-000079
Vuln IDs
  • V-258918
Rule IDs
  • SV-258918r1003597_rule
Any password, no matter how complex, can eventually be cracked. Therefore, passwords must be changed at specific intervals. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. This requirement does not include emergency administration accounts, which are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions.
Checks: C-62658r934410_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Local Accounts &gt;&gt; Password Policy. View the value of the "Maximum lifetime" setting. Maximum lifetime: Password must be changed every 90 days If the password policy is not configured with "Maximum lifetime" policy of "90" or less, this is a finding.

Fix: F-62567r934411_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Password Policy. Click "Edit". Set "Maximum lifetime" to "90" and click "Save".

b
The vCenter Server must enable revocation checking for certificate-based authentication.
IA-5 - Medium - CCI-000185 - V-258919 - SV-258919r1003600_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000185
Version
VCSA-80-000080
Vuln IDs
  • V-258919
Rule IDs
  • SV-258919r1003600_rule
The system must establish the validity of the user-supplied identity certificate using Online Certificate Status Protocol (OCSP) and/or Certificate Revocation List (CRL) revocation checking. Satisfies: SRG-APP-000175, SRG-APP-000392, SRG-APP-000401, SRG-APP-000403
Checks: C-62659r1003598_chk

If a federated identity provider is configured and used for an identity source and supports smart card authentication, this is not applicable. From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Identity Provider &gt;&gt; Smart Card Authentication. Under Smart Card Authentication settings &gt;&gt; Certificate Revocation, verify "Revocation check" does not show as disabled. If "Revocation check" shows as disabled, this is a finding.

Fix: F-62568r1003599_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Identity Provider >> Smart Card Authentication. Under Smart Card Authentication settings >> Certificate Revocation, click the "Edit" button. Configure revocation checking per site requirements. OCSP with CRL failover is recommended. Note: If FIPS mode is enabled on vCenter, OCSP revocation validation may not function and CRL bay be used instead. By default, both locations are pulled from the cert. CRL location can be overridden in this screen, and local responders can be specified via the sso-config command line tool. Refer to the vSphere documentation for more information.

b
The vCenter Server must terminate vSphere Client sessions after 15 minutes of inactivity.
SC-10 - Medium - CCI-001133 - V-258920 - SV-258920r1003601_rule
RMF Control
SC-10
Severity
M
CCI
CCI-001133
Version
VCSA-80-000089
Vuln IDs
  • V-258920
Rule IDs
  • SV-258920r1003601_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 resources committed by the managed network element. Satisfies: SRG-APP-000190, SRG-APP-000295, SRG-APP-000389
Checks: C-62660r934416_chk

From the vSphere Client, go to Administration &gt;&gt; Deployment &gt;&gt; Client Configuration. View the value of the "Session timeout" setting. If the "Session timeout" is not set to "15 minute(s)" or less, this is a finding.

Fix: F-62569r934417_fix

From the vSphere Client, go to Administration >> Deployment >> Client Configuration. Click "Edit" and enter "15" minutes into the "Session timeout" setting. Click "Save".

b
The vCenter Server user roles must be verified.
SC-2 - Medium - CCI-001082 - V-258921 - SV-258921r961095_rule
RMF Control
SC-2
Severity
M
CCI
CCI-001082
Version
VCSA-80-000095
Vuln IDs
  • V-258921
Rule IDs
  • SV-258921r961095_rule
Users and service accounts must only be assigned privileges they require. Least privilege requires that these privileges must only be assigned if needed to reduce risk of confidentiality, availability, or integrity loss. Satisfies: SRG-APP-000211, SRG-APP-000233, SRG-APP-000380
Checks: C-62661r934419_chk

From the vSphere Client, go to Administration &gt;&gt; Access Control &gt;&gt; Roles. View each role and verify the users and/or groups assigned to it by clicking on "Usage". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VIPermission | Sort Role | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto Application service account and user required privileges should be documented. If any user or service account has more privileges than required, this is a finding.

Fix: F-62570r934420_fix

To update a user's or group's permissions to an existing role with reduced permissions, do the following: From the vSphere Client, go to Administration >> Access Control >> Global Permissions. Select the user or group, click the pencil button, change the assigned role, and click "OK". Note: If permissions are assigned on a specific object, the role must be updated where it is assigned (for example, at the cluster level). To create a new role with reduced permissions, do the following: From the vSphere Client, go to Administration >> Access Control >> Roles. Click the green plus sign and enter a name for the role and select only the specific permissions required. Users can then be assigned to the newly created role.

b
The vCenter Server must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of denial-of-service (DoS) attacks by enabling Network I/O Control (NIOC).
SC-5 - Medium - CCI-001095 - V-258922 - SV-258922r961155_rule
RMF Control
SC-5
Severity
M
CCI
CCI-001095
Version
VCSA-80-000110
Vuln IDs
  • V-258922
Rule IDs
  • SV-258922r961155_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. Managing excess capacity ensures sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.
Checks: C-62662r934422_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking. Select a distributed switch &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Properties. View the "Properties" pane and verify "Network I/O Control" is "Enabled". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDSwitch | select Name,@{N="NIOC Enabled";E={$_.ExtensionData.config.NetworkResourceManagementEnabled}} If "Network I/O Control" is disabled, this is a finding.

Fix: F-62571r934423_fix

From the vSphere Client, go to Networking. Select a distributed switch >> Configure >> Settings >> Properties. In the "Properties" pane, click "Edit". Change "Network I/O Control" to "Enabled". Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: (Get-VDSwitch "VDSwitch Name" | Get-View).EnableNetworkResourceManagement($true)

b
The vCenter Server must provide an immediate real-time alert to the system administrator (SA) and information system security officer (ISSO), at a minimum, on every Single Sign-On (SSO) account action.
AC-2 - Medium - CCI-000015 - V-258923 - SV-258923r1003602_rule
RMF Control
AC-2
Severity
M
CCI
CCI-000015
Version
VCSA-80-000123
Vuln IDs
  • V-258923
Rule IDs
  • SV-258923r1003602_rule
Once an attacker establishes initial access to a system, they often attempt to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to create a new account. They may also try to hijack an existing account by changing a password or enabling a previously disabled account. Therefore, all actions performed on accounts in the SSO domain much be alerted on in vCenter at a minimum and ideally on a Security Information and Event Management (SIEM) system as well. To ensure the appropriate personnel are alerted about SSO account actions, create a new vCenter alarm for the "com.vmware.sso.PrincipalManagement" event ID and configure the alert mechanisms appropriately. Satisfies: SRG-APP-000291, SRG-APP-000292, SRG-APP-000293, SRG-APP-000294, SRG-APP-000320
Checks: C-62663r934425_chk

From the vSphere Client, go to Host and Clusters. Select a vCenter Server &gt;&gt; Configure &gt;&gt; Security &gt;&gt; Alarm Definitions. Verify there is an alarm created to alert upon all SSO account actions. The alarm name may vary, but it is suggested to name it "SSO account actions - com.vmware.sso.PrincipalManagement". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AlarmDefinition | Where {$_.ExtensionData.Info.Expression.Expression.EventTypeId -eq "com.vmware.sso.PrincipalManagement"} | Select Name,Enabled,@{N="EventTypeId";E={$_.ExtensionData.Info.Expression.Expression.EventTypeId}} If an alarm is not created to alert on SSO account actions, this is a finding.

Fix: F-62572r934426_fix

From the vSphere Client, go to Host and Clusters. Select a vCenter Server >> Configure >> Security >> Alarm Definitions. Click "Add". Provide the alarm name of "SSO account actions - com.vmware.sso.PrincipalManagement" and an optional description. From the "Target type" dropdown menu, select "vCenter Server". Click "Next". Paste "com.vmware.sso.PrincipalManagement" (without quotes) in the line after "IF" and press "Enter". Next to "Trigger the alarm and", select "Show as Warning". Configure the desired notification actions that will inform the SA and ISSO of the event. Click "Next". Click "Next" again. Click "Create".

b
The vCenter Server must set the interval for counting failed login attempts to at least 15 minutes.
AC-7 - Medium - CCI-002238 - V-258924 - SV-258924r961368_rule
RMF Control
AC-7
Severity
M
CCI
CCI-002238
Version
VCSA-80-000145
Vuln IDs
  • V-258924
Rule IDs
  • SV-258924r961368_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. Limits are imposed by locking the account.
Checks: C-62664r934428_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Local Accounts &gt;&gt; Lockout Policy. View the value of the "Time interval between failures" setting. Time interval between failures: 900 seconds If the lockout policy is not configured with "Time interval between failures" policy of "900" or more, this is a finding.

Fix: F-62573r934429_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Lockout Policy. Click "Edit". Set the "Time interval between failures" to "900" and click "Save".

b
The vCenter Server must be configured to send logs to a central log server.
AU-4 - Medium - CCI-001851 - V-258925 - SV-258925r961395_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001851
Version
VCSA-80-000148
Vuln IDs
  • V-258925
Rule IDs
  • SV-258925r961395_rule
vCenter must be configured to send near real-time log data to syslog collectors so information will be available to investigators in the case of a security incident or to assist in troubleshooting.
Checks: C-62665r934431_chk

Open the Virtual Appliance Management Interface (VAMI) by navigating to https://&lt;vCenter server&gt;:5480. Log in with local operating system administrative credentials or with a Single Sign-On (SSO) account that is a member of the "SystemConfiguration.BashShellAdministrator" group. Select "Syslog" on the left navigation pane. On the resulting pane on the right, verify at least one site-specific syslog receiver is configured and is listed as "Reachable". If no valid syslog collector is configured or if the collector is not listed as "Reachable", this is a finding.

Fix: F-62574r934432_fix

Open the VAMI by navigating to https://<vCenter server>:5480. Log in with local operating system administrative credentials or with an SSO account that is a member of the "SystemConfiguration.BashShellAdministrator" group. Select "Syslog" on the left navigation pane. On the resulting pane on the right, click "Edit" or "Configure". Edit or add the address and port of a site-specific syslog aggregator or Security Information Event Management (SIEM) system with the appropriate protocol. User Datagram Protocol (UDP) is discouraged due to its stateless and unencrypted nature. Transport Layer Security (TLS) is preferred. Click "Save".

b
The vCenter server must provide an immediate real-time alert to the system administrator (SA) and information system security officer (ISSO), at a minimum, of all audit failure events requiring real-time alerts.
AU-12 - Medium - CCI-000172 - V-258926 - SV-258926r961401_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
VCSA-80-000150
Vuln IDs
  • V-258926
Rule IDs
  • SV-258926r961401_rule
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Alerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less). Satisfies: SRG-APP-000360, SRG-APP-000379, SRG-APP-000510
Checks: C-62666r934434_chk

Review the Central Logging Server being used to verify it is configured to alert the SA and ISSO, at a minimum, on any AO-defined events. Otherwise, this is a finding. If there are no AO-defined events, this is not a finding.

Fix: F-62575r934435_fix

Configure the Central Logging Server being used to alert the SA and ISSO, at a minimum, on any AO-defined events.

b
The vCenter Server must compare internal information system clocks at least every 24 hours with an authoritative time server.
Medium - CCI-004923 - V-258927 - SV-258927r1003604_rule
RMF Control
Severity
M
CCI
CCI-004923
Version
VCSA-80-000158
Vuln IDs
  • V-258927
Rule IDs
  • SV-258927r1003604_rule
Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside of the configured acceptable allowance (drift) may be inaccurate. Additionally, unnecessary synchronization may have an adverse impact on system performance and may indicate malicious activity. Synchronizing internal information system clocks to an authoritative time server provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network.
Checks: C-62667r1003603_chk

Open the Virtual Appliance Management Interface (VAMI) by navigating to https://&lt;vCenter server&gt;:5480. Log in with local operating system administrative credentials or with a single sign-on (SSO) account that is a member of the "SystemConfiguration.BashShellAdministrator" group. Select "Time" on the left navigation pane. On the resulting pane on the right, verify at least one authorized time server is configured and is listed as "Reachable". If "NTP" is not enabled and at least one authorized time server configured, this is a finding.

Fix: F-62576r934438_fix

Open the VAMI by navigating to https://<vCenter server>:5480. Log in with local operating system administrative credentials or with an SSO account that is a member of the "SystemConfiguration.BashShellAdministrator" group. Select "Time" on the left navigation pane. On the resulting pane on the right, click "Edit" under "Time Synchronization". Select "NTP" for "Mode" and enter a list of authorized time servers separated by commas. Click "Save".

b
The vCenter Server Machine Secure Sockets Layer (SSL) certificate must be issued by a DOD certificate authority.
SC-23 - Medium - CCI-002470 - V-258928 - SV-258928r961596_rule
RMF Control
SC-23
Severity
M
CCI
CCI-002470
Version
VCSA-80-000195
Vuln IDs
  • V-258928
Rule IDs
  • SV-258928r961596_rule
Untrusted certificate authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DOD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DOD-approved CA, trust of this CA has not been established. The DOD will only accept public key infrastructure (PKI) certificates obtained from a DOD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of Transport Layer Security (TLS) certificates. The default self-signed, VMware Certificate Authority (VMCA)-issued vCenter reverse proxy certificate must be replaced with a DOD-approved certificate. The use of a DOD certificate on the vCenter reverse proxy and other services assures clients that the service they are connecting to is legitimate and trusted.
Checks: C-62668r934440_chk

From the vSphere Client, go to Administration &gt;&gt; Certificates &gt;&gt; Certificate Management &gt;&gt; Machine SSL Certificate. Click "View Details" and examine the "Issuer Information" block. If the issuer specified is not a DOD approved certificate authority, this is a finding.

Fix: F-62577r934441_fix

Obtain a DOD-issued certificate and private key for each vCenter in the system following the requirements below: Key size: 2048 bits or more (PEM encoded) CRT format (Base-64) x509 version 3 SubjectAltName must contain DNS Name=<machine_FQDN> Contains the following Key Usages: Digital Signature, Non Repudiation, Key Encipherment Export the entire certificate issuing chain up to the root in Base-64 format. Concatenate the individual certificates into one file with the ".cer" extension. From the vSphere Client, go to Administration >> Certificates >> Certificate Management >> Machine SSL Certificate. Click Actions >> Import and Replace Certificate. Select the "Replace with external CA certificate" radio button and click "Next". Supply the CA-issued certificate , the exported roots file, and the private key. Click "Replace".

b
The vCenter Server must enable data at rest encryption for vSAN.
SC-28 - Medium - CCI-002475 - V-258929 - SV-258929r961599_rule
RMF Control
SC-28
Severity
M
CCI
CCI-002475
Version
VCSA-80-000196
Vuln IDs
  • V-258929
Rule IDs
  • SV-258929r961599_rule
Applications handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. Data encryption is a common technique used in environments that require additional levels of security. It consists of a process to ensure that data can only be consumed by systems that have appropriate levels of access. Approved systems must have and use the appropriate cryptographic keys to encrypt and decrypt the data. Systems that do not have the keys will not be able to consume the data in any meaningful way, as it will remain encrypted in accordance with the commonly used Advanced Encryption Standard (AES) from the National Institute of Standards and Technology, or NIST. vSAN supports Data-At-Rest Encryption and Data-in-Transit Encryption and uses an AES 256 cipher. Data is encrypted after all other processing, such as deduplication, is performed. Data at rest encryption protects data on storage devices in case a device is removed from the cluster.
Checks: C-62669r934443_chk

If no clusters are enabled for vSAN, this is not applicable. From the vSphere Client, go to Host and Clusters. Select the vCenter Server &gt;&gt; Select the cluster &gt;&gt; Configure &gt;&gt; vSAN &gt;&gt; Services &gt;&gt; Data Services. Review the "Data-at-rest encryption" status. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-Cluster | Where-Object {$_.VsanEnabled -eq $true} | Get-VsanClusterConfiguration | Select-Object Name,EncryptionEnabled If "Data-At-Rest encryption" is not enabled, this is a finding.

Fix: F-62578r934444_fix

From the vSphere Client, go to Host and Clusters. Select the vCenter Server >> Select the target cluster >> Configure >> vSAN >> Services >> Data Services. Click "Edit". Enable "Data-At-Rest encryption" and select a pre-configured key provider from the drop down. Click "Apply". Note: Before enabling, read and understand the operational implications of enabling data at rest encryption in vSAN and how it effects capacity, performance, and recovery scenarios.

b
The vCenter Server must disable the Customer Experience Improvement Program (CEIP).
CM-6 - Medium - CCI-000366 - V-258930 - SV-258930r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000248
Vuln IDs
  • V-258930
Rule IDs
  • SV-258930r961863_rule
The VMware CEIP sends VMware anonymized system information that is used to improve the quality, reliability, and functionality of VMware products and services. For confidentiality purposes, this feature must be disabled.
Checks: C-62670r934446_chk

From the vSphere Client, go to Administration &gt;&gt; Deployment &gt;&gt; Customer Experience Improvement Program. If Customer Experience Improvement "Program Status" is "Joined", this is a finding.

Fix: F-62579r934447_fix

From the vSphere Client, go to Administration >> Deployment >> Customer Experience Improvement Program. Click "Leave Program".

b
The vCenter server must enforce SNMPv3 security features where SNMP is required.
IA-3 - Medium - CCI-001967 - V-258931 - SV-258931r961878_rule
RMF Control
IA-3
Severity
M
CCI
CCI-001967
Version
VCSA-80-000253
Vuln IDs
  • V-258931
Rule IDs
  • SV-258931r961878_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. SNMPv3 can be configured for identification and cryptographically based authentication. SNMPv3 defines a user-based security model (USM) and a view-based access control model (VACM). SNMPv3 USM provides data integrity, data origin authentication, message replay protection, and protection against disclosure of the message payload. SNMPv3 VACM provides access control to determine whether a specific type of access (read or write) to the management information is allowed. Implement both VACM and USM for full protection. SNMPv3 must be disabled by default and enabled only if used. SNMP v3 provides security feature enhancements to SNMP, including encryption and message authentication.
Checks: C-62671r934449_chk

At the command prompt on the vCenter Server Appliance, run the following commands: # appliancesh # snmp.get Note: The "appliancesh" command is not needed if the default shell has not been changed for root. If "Enable" is set to "False", this is not a finding. If "Enable" is set to "True" and "Authentication" is not set to "SHA1", this is a finding. If "Enable" is set to "True" and "Privacy" is not set to "AES128", this is a finding. If any "Users" are configured with a "Sec_level" that does not equal "priv", this is a finding.

Fix: F-62580r934450_fix

At the command prompt on the vCenter Server Appliance, run the following commands: # appliancesh # snmp.set --authentication SHA1 # snmp.set --privacy AES128 To change the security level of a user, run the following command: # snmp.set --users <username>/<auth_password> <priv_password>/priv

b
The vCenter server must disable SNMPv1/2 receivers.
IA-3 - Medium - CCI-001967 - V-258932 - SV-258932r961878_rule
RMF Control
IA-3
Severity
M
CCI
CCI-001967
Version
VCSA-80-000265
Vuln IDs
  • V-258932
Rule IDs
  • SV-258932r961878_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. Therefore, SNMPv1/2 receivers must be disabled, while SNMPv3 is configured in another control. vCenter exposes SNMP v1/2 in the UI and SNMPv3 in the CLI.
Checks: C-62672r934452_chk

From the vSphere Client, go to Host and Clusters. Select a vCenter Server &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; General. Click "Edit". On the "SNMP receivers" tab, note the presence of any enabled receiver. If there are any enabled receivers, this is a finding.

Fix: F-62581r934453_fix

From the vSphere Client, go to Host and Clusters. Select a vCenter Server >> Configure >> Settings >> General. Click "Edit". On the "SNMP receivers" tab, ensure all receivers are disabled.

b
The vCenter Server must require an administrator to unlock an account locked due to excessive login failures.
AC-7 - Medium - CCI-002238 - V-258933 - SV-258933r961368_rule
RMF Control
AC-7
Severity
M
CCI
CCI-002238
Version
VCSA-80-000266
Vuln IDs
  • V-258933
Rule IDs
  • SV-258933r961368_rule
By requiring that Single Sign-On (SSO) accounts be unlocked manually, the risk of unauthorized access via user password guessing, otherwise known as brute forcing, is reduced. When the account unlock time is set to zero, a locked account can only be unlocked manually by an administrator.
Checks: C-62673r934455_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Local Accounts &gt;&gt; Lockout Policy. View the value of the "Unlock time" setting. Unlock time: 0 seconds If the lockout policy is not configured with "Unlock time" policy of "0", this is a finding.

Fix: F-62582r934456_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Local Accounts >> Lockout Policy. Click "Edit". Set the "Unlock time" to "0" and click "Save".

b
The vCenter Server must disable the distributed virtual switch health check.
CM-6 - Medium - CCI-000366 - V-258934 - SV-258934r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000267
Vuln IDs
  • V-258934
Rule IDs
  • SV-258934r961863_rule
Network health check is disabled by default. Once enabled, the health check packets contain information on host#, vds#, and port#, which an attacker would find useful. It is recommended that network health check be used for troubleshooting and turned off when troubleshooting is finished.
Checks: C-62674r934458_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Health Check. View the health check pane and verify the "VLAN and MTU" and "Teaming and failover" checks are "Disabled". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $vds = Get-VDSwitch $vds.ExtensionData.Config.HealthCheckConfig If the health check feature is enabled on distributed switches and is not on temporarily for troubleshooting purposes, this is a finding.

Fix: F-62583r934459_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Configure >> Settings >> Health Check. Click "Edit". Disable the "VLAN and MTU" and "Teaming and failover" checks. Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-View -ViewType DistributedVirtualSwitch | ?{($_.config.HealthCheckConfig | ?{$_.enable -notmatch "False"})}| %{$_.UpdateDVSHealthCheckConfig(@((New-Object Vmware.Vim.VMwareDVSVlanMtuHealthCheckConfig -property @{enable=0}),(New-Object Vmware.Vim.VMwareDVSTeamingHealthCheckConfig -property @{enable=0})))}

b
The vCenter Server must set the distributed port group Forged Transmits policy to "Reject".
CM-6 - Medium - CCI-000366 - V-258935 - SV-258935r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000268
Vuln IDs
  • V-258935
Rule IDs
  • SV-258935r961863_rule
If the virtual machine operating system changes the Media Access Control (MAC) address, the operating system can send frames with an impersonated source MAC address at any time. This allows an operating system to stage malicious attacks on the devices in a network by impersonating a network adaptor authorized by the receiving network. When the "Forged Transmits" option is set to "Accept", ESXi does not compare source and effective MAC addresses. To protect against MAC impersonation, set the "Forged Transmits" option to "Reject". The host compares the source MAC address being transmitted by the guest operating system with the effective MAC address for its virtual machine adapter to determine if they match. If the addresses do not match, the ESXi host drops the packet.
Checks: C-62675r934461_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Select a port group &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Policies. Verify "Forged Transmits" is set to "Reject". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy If the "Forged Transmits" policy is set to accept for a nonuplink port, this is a finding.

Fix: F-62584r934462_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Select a port group >> Configure >> Settings >> Policies. Click "Edit". Click the "Security" tab. Set "Forged Transmits" to "Reject". Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -ForgedTransmits $false Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy | Set-VDSecurityPolicy -ForgedTransmits $false

b
The vCenter Server must set the distributed port group Media Access Control (MAC) Address Change policy to "Reject".
CM-6 - Medium - CCI-000366 - V-258936 - SV-258936r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000269
Vuln IDs
  • V-258936
Rule IDs
  • SV-258936r961863_rule
If the virtual machine operating system changes the MAC address, it can send frames with an impersonated source MAC address at any time. This allows it to stage malicious attacks on the devices in a network by impersonating a network adaptor authorized by the receiving network. This will prevent virtual machines from changing their effective MAC address and will affect applications that require this functionality. This will also affect how a layer 2 bridge will operate and will affect applications that require a specific MAC address for licensing.
Checks: C-62676r934464_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Select a port group &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Policies. Verify "MAC Address Changes" is set to "Reject". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy If the "MAC Address Changes" policy is set to accept, this is a finding.

Fix: F-62585r934465_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Select a port group >> Configure >> Settings >> Policies. Click "Edit". Click the "Security" tab. Set "MAC Address Changes" to "Reject". Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -MacChanges $false Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy | Set-VDSecurityPolicy -MacChanges $false

b
The vCenter Server must set the distributed port group Promiscuous Mode policy to "Reject".
CM-6 - Medium - CCI-000366 - V-258937 - SV-258937r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000270
Vuln IDs
  • V-258937
Rule IDs
  • SV-258937r961863_rule
When promiscuous mode is enabled for a virtual switch, all virtual machines connected to the port group have the potential of reading all packets across that network, meaning only the virtual machines connected to that port group. Promiscuous mode is disabled by default on the ESXi Server, and this is the recommended setting.
Checks: C-62677r934467_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Select a port group &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Policies. Verify "Promiscuous Mode" is set to "Reject". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy If the "Promiscuous Mode" policy is set to accept, this is a finding.

Fix: F-62586r934468_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Select a port group >> Configure >> Settings >> Policies. Click "Edit". Click the "Security" tab. Set "Promiscuous Mode" to "Reject". Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -AllowPromiscuous $false Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy | Set-VDSecurityPolicy -AllowPromiscuous $false

b
The vCenter Server must only send NetFlow traffic to authorized collectors.
CM-6 - Medium - CCI-000366 - V-258938 - SV-258938r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000271
Vuln IDs
  • V-258938
Rule IDs
  • SV-258938r961863_rule
The distributed virtual switch can export NetFlow information about traffic crossing the switch. NetFlow exports are not encrypted and can contain information about the virtual network, making it easier for a man-in-the-middle attack to be executed successfully. If NetFlow export is required, verify that all NetFlow target Internet Protocols (IPs) are correct.
Checks: C-62678r934470_chk

If distributed switches are not used, this is not applicable. To view NetFlow Collector IPs configured on distributed switches: From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; NetFlow. View the NetFlow pane and verify any collector IP addresses are valid and in use for troubleshooting. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDSwitch | select Name,@{N="NetFlowCollectorIPs";E={$_.ExtensionData.config.IpfixConfig.CollectorIpAddress}} To view if NetFlow is enabled on any distributed port groups: From the vSphere Client, go to "Networking". Select a distributed port group &gt;&gt; Manage &gt;&gt; Settings &gt;&gt; Policies. Go to "Monitoring" and view the NetFlow status. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup | Select Name,VirtualSwitch,@{N="NetFlowEnabled";E={$_.Extensiondata.Config.defaultPortConfig.ipfixEnabled.Value}} If NetFlow is configured and the collector IP is not known and documented, this is a finding.

Fix: F-62587r934471_fix

To remove collector IPs, do the following: From the vSphere Client, go to "Networking". Select a distributed switch >> Configure >> Settings >> NetFlow. Click "Edit". Remove any unknown collector IPs. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $dvs = Get-VDSwitch dvswitch | Get-View ForEach($vs in $dvs){ $spec = New-Object VMware.Vim.VMwareDVSConfigSpec $spec.configversion = $vs.Config.ConfigVersion $spec.IpfixConfig = New-Object VMware.Vim.VMwareIpfixConfig $spec.IpfixConfig.CollectorIpAddress = "" $spec.IpfixConfig.CollectorPort = "0" $spec.IpfixConfig.ActiveFlowTimeout = "60" $spec.IpfixConfig.IdleFlowTimeout = "15" $spec.IpfixConfig.SamplingRate = "0" $spec.IpfixConfig.InternalFlowsOnly = $False $vs.ReconfigureDvs_Task($spec) } Note: This will reset the NetFlow collector configuration back to the defaults. To disable NetFlow on a distributed port group, do the following: From the vSphere Client, go to "Networking". Select a distributed port group >> Configure >> Settings >> Policies. Click "Edit". Click the "Monitoring" tab. Change "NetFlow" to "Disabled". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $pgs = Get-VDPortgroup | Get-View ForEach($pg in $pgs){ $spec = New-Object VMware.Vim.DVPortgroupConfigSpec $spec.configversion = $pg.Config.ConfigVersion $spec.defaultPortConfig = New-Object VMware.Vim.VMwareDVSPortSetting $spec.defaultPortConfig.ipfixEnabled = New-Object VMware.Vim.BoolPolicy $spec.defaultPortConfig.ipfixEnabled.inherited = $false $spec.defaultPortConfig.ipfixEnabled.value = $false $pg.ReconfigureDVPortgroup_Task($spec) }

b
The vCenter Server must configure all port groups to a value other than that of the native virtual local area network (VLAN).
CM-6 - Medium - CCI-000366 - V-258939 - SV-258939r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000272
Vuln IDs
  • V-258939
Rule IDs
  • SV-258939r961863_rule
ESXi does not use the concept of native VLAN. Frames with VLAN specified in the port group will have a tag, but frames with VLAN not specified in the port group are not tagged and therefore will end up belonging to native VLAN of the physical switch. For example, frames on VLAN 1 from a Cisco physical switch will be untagged, because this is considered as the native VLAN. However, frames from ESXi specified as VLAN 1 will be tagged with a "1"; therefore, traffic from ESXi that is destined for the native VLAN will not be correctly routed (because it is tagged with a "1" instead of being untagged), and traffic from the physical switch coming from the native VLAN will not be visible (because it is not tagged). If the ESXi virtual switch port group uses the native VLAN ID, traffic from those virtual machines will not be visible to the native VLAN on the switch, because the switch is expecting untagged traffic.
Checks: C-62679r934473_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Select a distributed port group &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Policies. Review the port group VLAN tags and verify they are not set to the native VLAN ID of the attached physical switch. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup | select Name, VlanConfiguration If any port group is configured with the native VLAN of the ESXi hosts attached physical switch, this is a finding.

Fix: F-62588r934474_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Select a distributed port group >> Configure >> Settings >> Policies. Click "Edit". Click the "VLAN" tab. Change the VLAN ID to a nonnative VLAN. Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup "portgroup name" | Set-VDVlanConfiguration -VlanId "New VLAN#"

b
The vCenter Server must not configure VLAN Trunking unless Virtual Guest Tagging (VGT) is required and authorized.
CM-6 - Medium - CCI-000366 - V-258940 - SV-258940r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000273
Vuln IDs
  • V-258940
Rule IDs
  • SV-258940r961863_rule
When a port group is set to VLAN Trunking, the vSwitch passes all network frames in the specified range to the attached virtual machines without modifying the virtual local area network (VLAN) tags. In vSphere, this is referred to as VGT. The virtual machine must process the VLAN information itself via an 802.1Q driver in the operating system. VLAN Trunking must only be implemented if the attached virtual machines have been specifically authorized and are capable of managing VLAN tags themselves. If VLAN Trunking is enabled inappropriately, it may cause a denial of service or allow a virtual machine to interact with traffic on an unauthorized VLAN.
Checks: C-62680r934476_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Select a distributed port group &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Policies. Review the port group "VLAN Type" and "VLAN trunk range", if present. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup | Where {$_.ExtensionData.Config.Uplink -ne "True"} | Select Name,VlanConfiguration If any port group is configured with "VLAN trunking" and is not documented as a needed exception (such as NSX appliances), this is a finding. If any port group is authorized to be configured with "VLAN trunking" but is not configured with the most limited range necessary, this is a finding.

Fix: F-62589r934477_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Select a distributed port group >> Configure >> Settings >> Policies. Click "Edit". Click the "VLAN" tab. If "VLAN trunking" is not authorized, remove it by setting "VLAN type" to "VLAN" and configure an appropriate VLAN ID. Click "OK". If "VLAN trunking" is authorized but the range is too broad, modify the range in the "VLAN trunk range" field to the minimum necessary and authorized range. An example range would be "1,3-5,8". Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command to configure trunking: Get-VDPortgroup "Portgroup Name" | Set-VDVlanConfiguration -VlanTrunkRange "<VLAN Range(s) comma separated>" or Run this command to configure a single VLAN ID: Get-VDPortgroup "Portgroup Name" | Set-VDVlanConfiguration -VlanId "<New VLAN#>"

b
The vCenter Server must not configure all port groups to virtual local area network (VLAN) values reserved by upstream physical switches.
CM-6 - Medium - CCI-000366 - V-258941 - SV-258941r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000274
Vuln IDs
  • V-258941
Rule IDs
  • SV-258941r961863_rule
Certain physical switches reserve certain VLAN IDs for internal purposes and often disallow traffic configured to these values. For example, Cisco Catalyst switches typically reserve VLANs 1001 to 1024 and 4094, while Nexus switches typically reserve 3968 to 4094. Check with the documentation for the organization's specific switch. Using a reserved VLAN might result in a denial of service on the network.
Checks: C-62681r934479_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Select a distributed port group &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Policies. Review the port group VLAN tags and verify that they are not set to a reserved VLAN ID. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup | select Name, VlanConfiguration If any port group is configured with a reserved VLAN ID, this is a finding.

Fix: F-62590r934480_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Select a distributed port group >> Configure >> Settings >> Policies. Click "Edit". Click the "VLAN" tab. Change the VLAN ID to an unreserved VLAN ID. Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup "portgroup name" | Set-VDVlanConfiguration -VlanId "New VLAN#"

b
The vCenter Server must configure the "vpxuser" auto-password to be changed every 30 days.
CM-6 - Medium - CCI-000366 - V-258942 - SV-258942r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000275
Vuln IDs
  • V-258942
Rule IDs
  • SV-258942r961863_rule
By default, vCenter will change the "vpxuser" password automatically every 30 days. Ensure this setting meets site policies. If it does not, configure it to meet password aging policies. Note: It is very important the password aging policy is not shorter than the default interval that is set to automatically change the "vpxuser" password to preclude the possibility that vCenter might be locked out of an ESXi host.
Checks: C-62682r934482_chk

From the vSphere Client, go to Host and Clusters. Select a vCenter Server &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Advanced Settings. Verify that "VirtualCenter.VimPasswordExpirationInDays" is set to "30". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity &lt;vcenter server name&gt; -Name VirtualCenter.VimPasswordExpirationInDays If the "VirtualCenter.VimPasswordExpirationInDays" is set to a value other than "30" or does not exist, this is a finding.

Fix: F-62591r934483_fix

From the vSphere Client, go to Host and Clusters. Select a vCenter Server >> Configure >> Settings >> Advanced Settings. Click "Edit Settings" and configure the "VirtualCenter.VimPasswordExpirationInDays" value to "30" or if the value does not exist create it by entering the values in the "Key" and "Value" fields and clicking "Add". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: If the setting already exists: Get-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays | Set-AdvancedSetting -Value 30 If the setting does not exist: New-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays -Value 30

b
The vCenter Server must configure the "vpxuser" password to meet length policy.
CM-6 - Medium - CCI-000366 - V-258943 - SV-258943r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000276
Vuln IDs
  • V-258943
Rule IDs
  • SV-258943r961863_rule
The "vpxuser" password default length is 32 characters. Ensure this setting meets site policies; if not, configure to meet password length policies. Longer passwords make brute-force password attacks more difficult. The "vpxuser" password is added by vCenter, meaning no manual intervention is normally required. The "vpxuser" password length must never be modified to less than the default length of 32 characters.
Checks: C-62683r934485_chk

From the vSphere Client, go to Host and Clusters. Select a vCenter Server &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Advanced Settings. Verify that "config.vpxd.hostPasswordLength" is set to "32". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity &lt;vcenter server name&gt; -Name config.vpxd.hostPasswordLength and verify it is set to 32. If the "config.vpxd.hostPasswordLength" is set to a value other than "32, this is a finding. If the setting does not exist, this is not a finding.

Fix: F-62592r934486_fix

From the vSphere Client, go to Host and Clusters. Select a vCenter Server >> Configure >> Settings >> Advanced Settings. Click "Edit Settings" and configure the "config.vpxd.hostPasswordLength" value to "32". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.vpxd.hostPasswordLength | Set-AdvancedSetting -Value 32

a
The vCenter Server must be isolated from the public internet but must still allow for patch notification and delivery.
CM-6 - Low - CCI-000366 - V-258944 - SV-258944r961863_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
VCSA-80-000277
Vuln IDs
  • V-258944
Rule IDs
  • SV-258944r961863_rule
vCenter and the embedded Lifecycle Manager system must never have a direct route to the internet. Despite this, updates and patches sourced from VMware on the internet must be delivered in a timely manner. There are two methods to accomplish this: a proxy server and the Update Manager Download Service (UMDS). UMDS is an optional module for Lifecycle Manager that fetches upgrades for virtual appliances, patch metadata, patch binaries, and notifications that would not otherwise be available to an isolated Lifecycle Manager directly. Alternatively, a proxy for Lifecycle Manager can be configured to allow controlled, limited access to the public internet for the sole purpose of patch gathering. Either solution mitigates the risk of internet connectivity by limiting its scope and use.
Checks: C-62684r934488_chk

Check the following conditions: 1. Lifecycle Manager must be configured to use the UMDS. OR 2. Lifecycle Manager must be configured to use a proxy server for access to VMware patch repositories. OR 3. Lifecycle Manager must disable internet patch repositories and any patches must be manually validated and imported as needed. Option 1: From the vSphere Client, go to Lifecycle Manager &gt;&gt; Settings &gt;&gt; Patch Setup. Click the "Change Download Source" button. Verify the "Download patches from a UMDS shared repository" radio button is selected and that a valid UMDS repository is supplied. Click "Cancel". If this is not set, this is a finding. Option 2: From the vSphere Client, go to Lifecycle Manager &gt;&gt; Settings &gt;&gt; Patch Setup. Click the "Change Download Source" button. Verify the "Download patches directly from the internet" radio button is selected. Click "Cancel". Navigate to the vCenter Server Management interface at https://&lt;vcenter dns&gt;:5480 &gt;&gt; Networking &gt;&gt; Proxy Settings. Verify that "HTTPS" is "Enabled". Click the "HTTPS" row. Verify the proxy server configuration is accurate. If this is not set, this is a finding. Option 3: From the vSphere Client, go to Lifecycle Manager &gt;&gt; Settings &gt;&gt; Patch Downloads. Verify the "Automatic downloads" option is disabled. From the vSphere Client, go to Lifecycle Manager &gt;&gt; Settings &gt;&gt; Patch Setup. Verify any download sources are disabled. If this is not set, this is a finding.

Fix: F-62593r934489_fix

Option 1: From the vSphere Client, go to Lifecycle Manager >> Settings >> Patch Setup. Click the "Change Download Source" button. Select the "Download patches from a UMDS shared repository" radio button and supply a valid UMDS repository. Click "Save". Option 2: From the vSphere Client, go to Lifecycle Manager >> Settings >> Patch Setup. Click the "Change Download Source" button. Select the "Download patches directly from the internet" radio button. Click "Save". Navigate to the vCenter Server Management interface at https://<vcenter dns>:5480 >> Networking >> Proxy Settings. Click "Edit". Slide "HTTPS" to "Enabled". Supply the appropriate proxy server configuration. Click "Save". Option 3: From the vSphere Client, go to Lifecycle Manager >> Settings >> Patch Downloads. Click "Edit" and uncheck "Download patches". Under "Patch Setup" select each download source and click Disable.

b
The vCenter Server must use unique service accounts when applications connect to vCenter.
CM-6 - Medium - CCI-000366 - V-258945 - SV-258945r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000278
Vuln IDs
  • V-258945
Rule IDs
  • SV-258945r961863_rule
To not violate nonrepudiation (i.e., deny the authenticity of who is connecting to vCenter), when applications need to connect to vCenter they must use unique service accounts.
Checks: C-62685r934491_chk

Verify each external application that connects to vCenter has a unique service account dedicated to that application. For example, there should be separate accounts for Log Insight, Operations Manager, or anything else that requires an account to access vCenter. If any application shares a service account that is used to connect to vCenter, this is a finding.

Fix: F-62594r934492_fix

For applications sharing service accounts, create a new service account to assign to the application so that no application shares a service account with another. When standing up a new application that requires access to vCenter, always create a new service account prior to installation and grant only the permissions needed for that application.

b
The vCenter Server must protect the confidentiality and integrity of transmitted information by isolating Internet Protocol (IP)-based storage traffic.
CM-6 - Medium - CCI-000366 - V-258946 - SV-258946r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000279
Vuln IDs
  • V-258946
Rule IDs
  • SV-258946r961863_rule
Virtual machines might share virtual switches and virtual local area networks (VLAN) with the IP-based storage configurations. IP-based storage includes vSAN, Internet Small Computer System Interface (iSCSI), and Network File System (NFS). This configuration might expose IP-based storage traffic to unauthorized virtual machine users. IP-based storage frequently is not encrypted. It can be viewed by anyone with access to this network. To restrict unauthorized users from viewing the IP-based storage traffic, the IP-based storage network must be logically separated from the production traffic. Configuring the IP-based storage adaptors on separate VLANs or network segments from other VMkernels and virtual machines will limit unauthorized users from viewing the traffic.
Checks: C-62686r934494_chk

If IP-based storage is not used, this is not applicable. IP-based storage (iSCSI, NFS, vSAN) VMkernel port groups must be in a dedicated VLAN that can be on a standard or distributed virtual switch that is logically separated from other traffic types. The check for this will be unique per environment. To check a standard switch, do the following: From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Networking &gt;&gt; Virtual switches. Select a standard switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and note the VLAN ID associated with each port group. Verify it is dedicated to that purpose and is logically separated from other traffic types. To check a distributed switch, do the following, From the vSphere Client, go to "Networking". Select and expand a distributed switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and navigate to the "Summary" tab. Note the VLAN ID associated with each port group and verify it is dedicated to that purpose and is logically separated from other traffic types. If any IP-based storage networks are not isolated from other traffic types, this is a finding.

Fix: F-62595r934495_fix

Configuration of an IP-based VMkernel will be unique to each environment. To configure VLANs and traffic types, do the following: Standard switch: From the vSphere Client, select the ESXi host and go to Configure >> Networking >> VMkernel adapters. Select the Storage VMkernel (for any IP-based storage). Click "Edit..." and click the "Port properties" tab. Uncheck everything (unless vSAN). Click the "IPv4" settings or "IPv6" settings tab. Enter the appropriate IP address and subnet information. Click "OK". From the vSphere Client, select the ESXi host and go to Configure >> Networking >> Virtual switches. Select a standard switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and click "...". Click "Edit Settings". On the "Properties" tab, enter the appropriate VLAN ID and click "OK". Distributed switch: From the vSphere Client, go to "Networking". Select a distributed switch >> Configure >> Settings >> Topology. Select the Storage VMkernel (for any IP-based storage). Click "..." and click "Edit Settings". On the "Port properties" tab, uncheck everything (unless vSAN). Click the "IPv4" settings or "IPv6" settings tab. Enter the appropriate IP address and subnet information. Click "OK". From the vSphere Client, go to "Networking". Select and expand a distributed switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and navigate to Configure >> Settings >> Properties. Click "Edit". Click the "VLAN" tab. Enter the appropriate VLAN type and ID and click "OK".

b
The vCenter server must be configured to send events to a central log server.
AU-4 - Medium - CCI-001851 - V-258947 - SV-258947r961395_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001851
Version
VCSA-80-000280
Vuln IDs
  • V-258947
Rule IDs
  • SV-258947r961395_rule
vCenter server generates volumes of security-relevant application-level events. Examples include logins, system reconfigurations, system degradation warnings, and more. To ensure these events are available for forensic analysis and correlation, they must be sent to the syslog and forwarded on to the configured Security Information and Event Management (SIEM) system and/or central log server. The vCenter server sends events to syslog by default, but this configuration must be verified and maintained.
Checks: C-62687r934497_chk

From the vSphere Client, go to Host and Clusters. Select a vCenter Server &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Advanced Settings. Verify that "vpxd.event.syslog.enabled" value is set to "true". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity &lt;vcenter server name&gt; -Name vpxd.event.syslog.enabled If the "vpxd.event.syslog.enabled" value is not set to "true", this is a finding.

Fix: F-62596r934498_fix

From the vSphere Client, go to Host and Clusters. Select a vCenter Server >> Configure >> Settings >> Advanced Settings. Click "Edit Settings" and configure the "vpxd.event.syslog.enabled" setting to "true". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name vpxd.event.syslog.enabled | Set-AdvancedSetting -Value true

b
The vCenter Server must disable or restrict the connectivity between vSAN Health Check and public Hardware Compatibility List (HCL) by use of an external proxy server.
CM-6 - Medium - CCI-000366 - V-258948 - SV-258948r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000281
Vuln IDs
  • V-258948
Rule IDs
  • SV-258948r961863_rule
The vSAN Health Check is able to download the HCL from VMware to check compliance against the underlying vSAN Cluster hosts. To ensure the vCenter server is not directly downloading content from the internet, this functionality must be disabled. If this feature is necessary, an external proxy server must be configured.
Checks: C-62688r934500_chk

If no clusters are enabled for vSAN, this is not applicable. From the vSphere Client, go to Host and Clusters. Select the vCenter Server &gt;&gt; Configure &gt;&gt; vSAN &gt;&gt; Internet Connectivity. If the HCL internet download is not required, verify "Status" is "Disabled". If the "Status" is "Enabled", this is a finding. If the HCL internet download is required, verify "Status" is "Enabled" and a proxy host is configured. If "Status" is "Enabled" and a proxy is not configured, this is a finding.

Fix: F-62597r934501_fix

From the vSphere Client, go to Host and Clusters. Select the vCenter Server >> Configure >> vSAN >> Internet Connectivity. Click "Edit". If the HCL internet download is not required, ensure that "Status" is "Disabled". If the HCL internet download is required, ensure that "Status" is "Enabled" and that a proxy host is appropriately configured.

b
The vCenter Server must configure the vSAN Datastore name to a unique name.
CM-6 - Medium - CCI-000366 - V-258949 - SV-258949r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000282
Vuln IDs
  • V-258949
Rule IDs
  • SV-258949r961863_rule
A vSAN Datastore name by default is "vsanDatastore". If more than one vSAN cluster is present in vCenter, both datastores will have the same name by default, potentially leading to confusion and manually misplaced workloads.
Checks: C-62689r934503_chk

If no clusters are enabled for vSAN, this is not applicable. From the vSphere Client, go to Host and Clusters. Select a vSAN Enabled Cluster &gt;&gt; Datastores. Review the datastores and identify any datastores with "vSAN" as the datastore type. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: If($(Get-Cluster | where {$_.VsanEnabled} | Measure).Count -gt 0){ Write-Host "vSAN Enabled Cluster found" Get-Cluster | where {$_.VsanEnabled} | Get-Datastore | where {$_.type -match "vsan"} } else{ Write-Host "vSAN is not enabled, this finding is not applicable." } If vSAN is enabled and a datastore is named "vsanDatastore", this is a finding.

Fix: F-62598r934504_fix

From the vSphere Client, go to Host and Clusters. Select a vSAN Enabled Cluster >> Datastores. Right-click on the datastore named "vsanDatastore" and select "Rename". Rename the datastore based on site-specific naming standards. Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: If($(Get-Cluster | where {$_.VsanEnabled} | Measure).Count -gt 0){ Write-Host "vSAN Enabled Cluster found" $Clusters = Get-Cluster | where {$_.VsanEnabled} Foreach ($clus in $clusters){ $clus | Get-Datastore | where {$_.type -match "vsan"} | Set-Datastore -Name $(($clus.name) + "_vSAN_Datastore") } } else{ Write-Host "vSAN is not enabled, this finding is not applicable." }

b
The vCenter Server must disable Username/Password and Windows Integrated Authentication.
CM-6 - Medium - CCI-000366 - V-258950 - SV-258950r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000283
Vuln IDs
  • V-258950
Rule IDs
  • SV-258950r961863_rule
All forms of authentication other than Common Access Card (CAC) must be disabled. Password authentication can be temporarily reenabled for emergency access to the local Single Sign-On (SSO) accounts or Active Directory user/pass accounts, but it must be disabled as soon as CAC authentication is functional.
Checks: C-62690r934506_chk

If a federated identity provider is configured and used for an identity source, this is not applicable. From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Identity Provider &gt;&gt; Smart Card Authentication. Under "Authentication method", examine the allowed methods. If "Smart card authentication" is not enabled and "Password and windows session authentication" is not disabled, this is a finding.

Fix: F-62599r934507_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Identity Provider >> Smart Card Authentication. Next to "Authentication method", click "Edit". Select to radio button to "Enable smart card authentication". Click "Save". To re-enable password authentication for troubleshooting purposes, run the following command on the vCenter Server Appliance: # /opt/vmware/bin/sso-config.sh -set_authn_policy -pwdAuthn true -winAuthn false -certAuthn false -securIDAuthn false -t vsphere.local

b
The vCenter Server must restrict access to the default roles with cryptographic permissions.
CM-6 - Medium - CCI-000366 - V-258951 - SV-258951r1003606_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000284
Vuln IDs
  • V-258951
Rule IDs
  • SV-258951r1003606_rule
In vSphere, the built-in "Administrator" role contains permission to perform cryptographic operations such as Key Management Server (KMS) functions and encrypting and decrypting virtual machine disks. This role must be reserved for cryptographic administrators where virtual machine encryption and/or vSAN encryption is in use. A new built-in role called "No Cryptography Administrator" exists to provide all administrative permissions except cryptographic operations. Permissions must be restricted such that normal vSphere administrators are assigned the "No Cryptography Administrator" role or more restrictive. The "Administrator" role must be tightly controlled and must not be applied to administrators who will not be doing cryptographic work. Catastrophic data loss can result from poorly administered cryptography.
Checks: C-62691r1003605_chk

By default, there are five roles that contain cryptographic related permissions: Administrator, No Trusted Infrastructure Administrator, vCLSAdmin, VMOperator Controller Manager, and vSphere Kubernetes Manager. From the vSphere Client, go to Administration &gt;&gt; Access Control &gt;&gt; Roles. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VIPermission | Where {$_.Role -eq "Admin" -or $_.Role -eq "NoTrustedAdmin" -or $_.Role -eq "vCLSAdmin" -or $_.Role -eq "VMOperatorController" -or $_.Role -eq "vSphereKubernetesManager"} | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto If there are any users or groups assigned to the default roles with cryptographic permissions and are not explicitly designated to perform cryptographic operations, this is a finding. The built-in solution users assigned to the administrator role are NOT a finding.

Fix: F-62600r934510_fix

From the vSphere Client, go to Administration >> Access Control >> Roles. Move any accounts not explicitly designated for cryptographic operations, other than Solution Users, to other roles such as "No Cryptography Administrator".

b
The vCenter Server must restrict access to cryptographic permissions.
CM-6 - Medium - CCI-000366 - V-258952 - SV-258952r1003608_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000285
Vuln IDs
  • V-258952
Rule IDs
  • SV-258952r1003608_rule
These permissions must be reserved for cryptographic administrators where virtual machine encryption and/or vSAN encryption is in use. Catastrophic data loss can result from poorly administered cryptography.
Checks: C-62692r1003607_chk

By default, there are five roles that contain cryptographic related permissions: Administrator, No Trusted Infrastructure Administrator, vCLSAdmin, VMOperator Controller Manager, and vSphere Kubernetes Manager. From the vSphere Client, go to Administration &gt;&gt; Access Control &gt;&gt; Roles. Highlight each role and click the "Privileges" button in the right pane. Verify that only the Administrator, No Trusted Infrastructure Administrator, vCLSAdmin, and vSphere Kubernetes Manager and any site-specific cryptographic roles have the following permissions: Cryptographic Operations privileges Global.Diagnostics Host.Inventory.Add host to cluster Host.Inventory.Add standalone host Host.Local operations.Manage user groups or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $roles = Get-VIRole ForEach($role in $roles){ $privileges = $role.PrivilegeList If($privileges -match "Crypto*" -or $privileges -match "Global.Diagnostics" -or $privileges -match "Host.Inventory.Add*" -or $privileges -match "Host.Local operations.Manage user groups"){ Write-Host "$role has Cryptographic privileges" } } If any role other than the five default roles contain the permissions listed above and is not authorized to perform cryptographic related operations, this is a finding.

Fix: F-62601r934513_fix

From the vSphere Client, go to Administration >> Access Control >> Roles. Highlight the target custom role and click "Edit". Remove the following permissions from any custom role that is not authorized to perform cryptographic related operations: Cryptographic Operations privileges Global.Diagnostics Host.Inventory.Add host to cluster Host.Inventory.Add standalone host Host.Local operations.Manage user groups

b
The vCenter Server must have Mutual Challenge Handshake Authentication Protocol (CHAP) configured for vSAN Internet Small Computer System Interface (iSCSI) targets.
CM-6 - Medium - CCI-000366 - V-258953 - SV-258953r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000286
Vuln IDs
  • V-258953
Rule IDs
  • SV-258953r961863_rule
When enabled, vSphere performs bidirectional authentication of both the iSCSI target and host. When not authenticating both the iSCSI target and host, the potential exists for a man-in-the-middle attack in which an attacker might impersonate either side of the connection to steal data. Bidirectional authentication mitigates this risk.
Checks: C-62693r934515_chk

If no clusters are enabled for vSAN or if vSAN is enabled but iSCSI is not enabled, this is not applicable. From the vSphere Client, go to Host and Clusters. Select a vSAN Enabled Cluster &gt;&gt; Configure &gt;&gt; vSAN &gt;&gt; iSCSI Target Service. For each iSCSI target, review the value in the "Authentication" column. If the Authentication method is not set to "CHAP_Mutual" for any iSCSI target, this is a finding.

Fix: F-62602r934516_fix

From the vSphere Client, go to Host and Clusters. Select a vSAN Enabled Cluster >> Configure >> vSAN >> iSCSI Target Service. For each iSCSI target, select the item and click "Edit". Change the "Authentication" field to "Mutual CHAP" and configure the incoming and outgoing users and secrets appropriately.

b
The vCenter Server must have new Key Encryption Keys (KEKs) reissued at regular intervals for vSAN encrypted datastore(s).
CM-6 - Medium - CCI-000366 - V-258954 - SV-258954r1003610_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000287
Vuln IDs
  • V-258954
Rule IDs
  • SV-258954r1003610_rule
The KEK for a vSAN encrypted datastore is generated by the Key Management Server (KMS) and serves as a wrapper and lock around the Disk Encryption Key (DEK). The DEK is generated by the host and is used to encrypt and decrypt the datastore. A shallow rekey is a procedure in which the KMS issues a new KEK to the ESXi host, which rewraps the DEK but does not change the DEK or any data on disk. This operation must be done on a regular, site-defined interval and can be viewed as similar in criticality to changing an administrative password. If the KMS is compromised, a standing operational procedure to rekey will put a time limit on the usefulness of any stolen KMS data.
Checks: C-62694r934518_chk

If vSAN is not in use, this is not applicable. Interview the system administrator (SA) to determine that a procedure has been put in place to perform a shallow rekey of all vSAN encrypted datastores at regular, site-defined intervals. VMware recommends a 60-day rekey task, but this interval must be defined by the SA and the ISSO. If vSAN encryption is not in use, this is not a finding. If vSAN encryption is in use and a regular rekey procedure is not in place, this is a finding.

Fix: F-62603r1003609_fix

If vSAN encryption is in use, ensure a regular rekey procedure is in place. To generate new encryption keys for vSAN, do the following: From the vSphere Client, go to Host and Clusters. Select the vCenter Server >> Select the cluster >> Configure >> vSAN >> Services >> Data Services. Select "Generate New Encryption Keys" and optionally generate new DEKs and click "Generate".

b
The vCenter Server must use secure Lightweight Directory Access Protocol (LDAPS) when adding an LDAP identity source.
CM-6 - Medium - CCI-000366 - V-258955 - SV-258955r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000288
Vuln IDs
  • V-258955
Rule IDs
  • SV-258955r961863_rule
LDAP is an industry standard protocol for querying directory services such as Active Directory. This protocol can operate in clear text or over a Secure Sockets Layer (SSL)/Transport Layer Security (TLS) encrypted tunnel. To protect confidentiality of LDAP communications, secure LDAP (LDAPS) must be explicitly configured when adding an LDAP identity source in vSphere Single Sign-On (SSO). When configuring an identity source and supplying an SSL certificate, vCenter will enforce LDAPS. The server URLs do not need to be explicitly provided if an SSL certificate is uploaded.
Checks: C-62695r934521_chk

If LDAP is not used as an identity provider, this is not applicable. From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Configuration &gt;&gt; Identity Provider. Click the "Identity Sources" tab. For each identity source of type "Active Directory over LDAP", if the "Server URL" does not indicate "ldaps://", this is a finding.

Fix: F-62604r934522_fix

From the vSphere Client, go to Administration >> Single Sign On >> Configuration >> Identity Provider. Click the "Identity Sources" tab. For each identity source of type "Active Directory over LDAP" where LDAPS is not configured, highlight the item and click "Edit". Ensure the primary and secondary server URLs, if specified, are configured for "ldaps://". At the bottom, click the "Browse" button, select the AD LDAP cert previously exported to your local computer, click "Open", and "Save" to complete modifications. Note: With LDAPS, the server must be a specific domain controller and its specific certificate or the domain alias with a certificate that is valid for that URL.

b
The vCenter Server must limit membership to the "SystemConfiguration.BashShellAdministrators" Single Sign-On (SSO) group.
CM-6 - Medium - CCI-000366 - V-258956 - SV-258956r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000290
Vuln IDs
  • V-258956
Rule IDs
  • SV-258956r961863_rule
vCenter SSO integrates with PAM in the underlying Photon operating system so members of the "SystemConfiguration.BashShellAdministrators" SSO group can log on to the operating system without needing a separate account. However, even though unique SSO users log on, they are transparently using a group account named "sso-user" as far as Photon auditing is concerned. While the audit trail can still be traced back to the individual SSO user, it is a more involved process. To force accountability and nonrepudiation, the SSO group "SystemConfiguration.BashShellAdministrators" must be severely restricted.
Checks: C-62696r934524_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Users and Groups &gt;&gt; Groups. Click the next page arrow until the "SystemConfiguration.BashShellAdministrators" group appears. Click "SystemConfiguration.BashShellAdministrators". Review the members of the group and ensure that only authorized accounts are present. Note: By default the Administrator and a unique service account similar to "vmware-applmgmtservice-714684a4-342f-4eff-a232-cdc21def00c2" will be in the group and should not be removed. If there are any accounts present as members of SystemConfiguration.BashShellAdministrators that are not authorized, this is a finding.

Fix: F-62605r934525_fix

From the vSphere Client, go to Administration >> Single Sign On >> Users and Groups >> Groups. Click the next page arrow until the "SystemConfiguration.BashShellAdministrators" group appears. Click "SystemConfiguration.BashShellAdministrators". Click the three vertical dots next to the name of each unauthorized account. Select "Remove Member".

b
The vCenter Server must limit membership to the "TrustedAdmins" Single Sign-On (SSO) group.
CM-6 - Medium - CCI-000366 - V-258957 - SV-258957r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000291
Vuln IDs
  • V-258957
Rule IDs
  • SV-258957r961863_rule
The vSphere "TrustedAdmins" group grants additional rights to administer the vSphere Trust Authority feature. To force accountability and nonrepudiation, the SSO group "TrustedAdmins" must be severely restricted.
Checks: C-62697r934527_chk

From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Users and Groups &gt;&gt; Groups. Click the next page arrow until the "TrustedAdmins" group appears. Click "TrustedAdmins". Review the members of the group and ensure that only authorized accounts are present. Note: These accounts act as root on the Photon operating system and have the ability to severely damage vCenter, inadvertently or otherwise. If there are any accounts present as members of TrustedAdmins that are not authorized, this is a finding.

Fix: F-62606r934528_fix

From the vSphere Client, go to Administration >> Single Sign On >> Users and Groups >> Groups. Click the next page arrow until the "TrustedAdmins" group appears. Click "TrustedAdmins". Click the three vertical dots next to the name of each unauthorized account. Select "Remove Member".

b
The vCenter server configuration must be backed up on a regular basis.
CM-6 - Medium - CCI-000366 - V-258958 - SV-258958r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000292
Vuln IDs
  • V-258958
Rule IDs
  • SV-258958r961863_rule
vCenter server is the control plane for the vSphere infrastructure and all the workloads it hosts. As such, vCenter is usually a highly critical system in its own right. Backups of vCenter can now be made at a data and configuration level versus traditional storage/image-based backups. This reduces recovery time by letting the system administrator (SA) spin up a new vCenter while simultaneously importing the backed-up data. For sites that implement the Native Key Provider (NKP), introduced in 7.0 Update 2, regular vCenter backups are critical. In a recovery scenario where the virtual machine files are intact but vCenter was lost, the encrypted virtual machines will not be able to boot as their private keys were stored in vCenter after it was last backed up. When using the NKP, vCenter becomes critical to the virtual machine workloads and ceases to be just the control plane.
Checks: C-62698r934530_chk

Option 1: If vCenter is backed up in a traditional manner, at the storage array level, interview the SA to determine configuration and schedule. Option 2: For vCenter native backup functionality, open the Virtual Appliance Management Interface (VAMI) by navigating to https://&lt;vCenter server&gt;:5480. Log in with local operating system administrative credentials or with a Single Sign-On (SSO) account that is a member of the "SystemConfiguration.BashShellAdministrator" group. Select "Backup" on the left navigation pane. On the resulting pane on the right, verify the "Status" is "Enabled". Click "Status" to expand the backup details. If vCenter server backups are not configured and there is no other vCenter backup system, this is a finding. If the backup configuration is not set to a proper, reachable location or if the schedule is anything less frequent than "Daily", this is a finding.

Fix: F-62607r934531_fix

Option 1: Implement and document a VMware-supported storage/image-based backup schedule. Option 2: To configure vCenter native backup functionality, open the VAMI by navigating to https://<vCenter server>:5480. Log in with local operating system administrative credentials or with an SSO account that is a member of the "SystemConfiguration.BashShellAdministrator" group. Select "Backup" on the left navigation pane. On the resulting pane on the right, click "Configure" (or "Edit" for an existing configuration). Enter site-specific information for the backup job. Ensure "Schedule" is set to "Daily". Limiting the number of retained backups is recommended but not required. Click "Create".

b
The vCenter server must have task and event retention set to at least 30 days.
CM-6 - Medium - CCI-000366 - V-258959 - SV-258959r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000293
Vuln IDs
  • V-258959
Rule IDs
  • SV-258959r961863_rule
vCenter tasks and events contain valuable historical actions, useful in troubleshooting availability issues and for incident forensics. While vCenter events are sent to central log servers in real time, it is important that administrators have quick access to this information when needed. vCenter retains 30 days of tasks and events by default, and this is sufficient for most purposes. The vCenter disk partitions are also sized with this in mind. Decreasing is not recommended for operational reasons, while increasing is not recommended unless guided by VMware support due to the partition sizing concerns.
Checks: C-62699r934533_chk

From the vSphere Client, go to Host and Clusters. Select a vCenter Server &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; General. Click to expand the "Database" section. Note the "Task retention" and "Event retention" values. If either value is configured to less than "30" days, this is a finding.

Fix: F-62608r934534_fix

From the vSphere Client, go to Host and Clusters. Select a vCenter Server >> Configure >> Settings >> General. Click "Edit". On the "Database" tab, set the value for both "Task retention" and "Event retention" to "30" days (default) or greater, as required by your site. Click "Save".

b
The vCenter server Native Key Provider must be backed up with a strong password.
CM-6 - Medium - CCI-000366 - V-258960 - SV-258960r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000294
Vuln IDs
  • V-258960
Rule IDs
  • SV-258960r961863_rule
The vCenter Native Key Provider feature was introduced in 7.0 U2 and acts as a key provider for encryption-based capabilities such as encrypted virtual machines without requiring an external KMS solution. When enabling this feature, a backup must be taken, which is a PKCS#12 formatted file. If no password is provided during the backup process, this presents the opportunity for this to be used maliciously and compromise the environment.
Checks: C-62700r934536_chk

If the vCenter Native Key Provider feature is not in use, this is not applicable. Interview the system administrator and determine if a password was provided for any backups taken of the Native Key Provider. If backups exist for the Native Key Provider that are not password protected, this is a finding.

Fix: F-62609r934537_fix

From the vSphere Client, go to Host and Clusters. Select a vCenter Server >> Configure >> Settings >> Key Providers. Select the Native Key Provider, click "Back-up", and check the box "Protect Native Key Provider data with password". Provide a strong password and click "Back up key provider". Delete any previous backups that were not protected with a password.

b
The vCenter server must require authentication for published content libraries.
CM-6 - Medium - CCI-000366 - V-258961 - SV-258961r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000295
Vuln IDs
  • V-258961
Rule IDs
  • SV-258961r961863_rule
In the vSphere Client, you can create a local or a subscribed content library. By using content libraries, you can store and manage content in one vCenter Server instance. Alternatively, you can distribute content across vCenter Server instances to increase consistency and facilitate the deployment workloads at scale. When publishing a content library it can be protected by requiring authentication for subscribers.
Checks: C-62701r934539_chk

From the vSphere Client, go to Content Libraries. Review the "Password Protected" column. If a content library is published and is not password protected, this is a finding.

Fix: F-62610r934540_fix

From the vSphere Client, go to Content Libraries. Select the target content library. Select "Actions" then "Edit Settings". Click the checkbox to "Enable user authentication for access to this content library". Enter and confirm a password for the content library. Click "OK". Note: Any subscribed content libraries will need to be updated to enable authentication and provide the password.

b
The vCenter server must enable the OVF security policy for content libraries.
CM-6 - Medium - CCI-000366 - V-258962 - SV-258962r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000296
Vuln IDs
  • V-258962
Rule IDs
  • SV-258962r961863_rule
In the vSphere Client, you can create a local or a subscribed content library. By using content libraries, you can store and manage content in one vCenter Server instance. Alternatively, you can distribute content across vCenter Server instances to increase consistency and facilitate the deployment workloads at scale. You can protect the OVF items by applying default OVF security policy to a content library. The OVF security policy enforces strict validation on OVF items when you deploy or update the item, import items, or synchronize OVF and OVA templates. To make sure that the OVF and OVA templates are signed by a trusted certificate, you can add the OVF signing certificate from a trusted CA.
Checks: C-62702r934542_chk

From the vSphere Client, go to Content Libraries. Review the "Security Policy" column. If a content library does not have the "OVF default policy" enabled, this is a finding.

Fix: F-62611r934543_fix

From the vSphere Client, go to Content Libraries. Select the target content library. Select "Actions" then "Edit Settings". Click the checkbox to "Apply Security Policy". Click "OK". Note: If you disable the security policy of a content library, you cannot reuse the existing OVF items.

b
The vCenter Server must separate authentication and authorization for administrators.
CM-6 - Medium - CCI-000366 - V-258963 - SV-258963r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000298
Vuln IDs
  • V-258963
Rule IDs
  • SV-258963r961863_rule
Many organizations do both authentication and authorization using a centralized directory service such as Active Directory. Attackers who compromise an identity source can often add themselves to authorization groups, and simply log into systems they should not otherwise have access to. Additionally, reliance on central identity systems means that the administrators of those systems are potentially infrastructure administrators, too, as they can add themselves to infrastructure access groups at will. The use of local SSO groups for authorization helps prevent this avenue of attack by allowing the centralized identity source to still authenticate users but moving authorization into vCenter itself.
Checks: C-62703r934545_chk

From the vSphere Client, go to Administration &gt;&gt; Access Control &gt;&gt; Roles. View the Administrator role and any other role providing administrative access to vCenter to verify the users and/or groups assigned to it by clicking on "Usage". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VIPermission | Sort Role | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto If any user or group is directly assigned a role with administrative access to vCenter that is from an identity provider, this is a finding. Note: Users and/or groups assigned to roles should be from the "VSPHERE.LOCAL" identity source.

Fix: F-62612r934546_fix

To add groups from an identity provider to the local SSO Administrators group, as an example, do the following: From the vSphere Client, go to Administration >> Single Sign On >> Groups. Select the Administrators group and click "Edit". In the "Add Members" section, select the identity source and type the name of the target user/group in the search bar. Select the target user/group to add them and click "Save". Note: A new SSO group or groups can be created as needed and used to provide authorization to vCenter. To remove identity provider users/groups from a role, do the following: From the vSphere Client, go to Administration >> Access Control >> Global Permissions. Select the offending user/group and click "Delete". Note: If permissions are assigned on a specific object, then the role must be updated where it is assigned (for example, at the cluster level).

a
The vCenter Server must disable CDP/LLDP on distributed switches.
CM-6 - Low - CCI-000366 - V-258964 - SV-258964r961863_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
VCSA-80-000299
Vuln IDs
  • V-258964
Rule IDs
  • SV-258964r961863_rule
The vSphere Distributed Virtual Switch can participate in Cisco Discovery Protocol (CDP) or Link Layer Discovery Protocol (LLDP), as a listener, advertiser, or both. The information is sensitive, including IP addresses, system names, software versions, and more. It can be used by an adversary to gain a better understanding of your environment, and to impersonate devices. It is also transmitted unencrypted on the network, and as such the recommendation is to disable it.
Checks: C-62704r934548_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Properties. Review the "Discovery Protocol" configuration. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDSwitch | Select Name,LinkDiscoveryProtocolOperation If any distributed switch does not have "Discovery Protocols" disabled, this is a finding.

Fix: F-62613r934549_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Configure >> Settings >> Properties. Click "Edit". Select the advanced tab and update the "Type" under "Discovery Protocol" to disabled and click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDSwitch -Name "DSwitch" | Set-VDSwitch -LinkDiscoveryProtocolOperation "Disabled"

b
The vCenter Server must remove unauthorized port mirroring sessions on distributed switches.
CM-6 - Medium - CCI-000366 - V-258965 - SV-258965r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000300
Vuln IDs
  • V-258965
Rule IDs
  • SV-258965r961863_rule
The vSphere Distributed Virtual Switch can enable port mirroring sessions allowing traffic to be mirrored from one source to a destination. If port mirroring is configured unknowingly this could allow an attacker to observe network traffic of virtual machines.
Checks: C-62705r934551_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Port Mirroring. Review any configured "Port Mirroring" sessions. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDSwitch | select Name,@{N="Port Mirroring Sessions";E={$_.ExtensionData.Config.VspanSession.Name}} If there are any unauthorized port mirroring sessions configured, this is a finding.

Fix: F-62614r934552_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Configure >> Settings >> Port Mirroring. Select the unauthorized "Port Mirroring" session and click "Remove". Click "OK".

b
The vCenter Server must not override port group settings at the port level on distributed switches.
CM-6 - Medium - CCI-000366 - V-258966 - SV-258966r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000301
Vuln IDs
  • V-258966
Rule IDs
  • SV-258966r961863_rule
Port-level configuration overrides are disabled by default. Once enabled, this allows for different security settings to be set from what is established at the Port Group level. If overrides are not monitored, anyone who gains access to a VM with a less secure VDS configuration could exploit that broader access. If there are cases where particular VMs require unique configurations then a different port group with the required configuration should be created instead of overriding port group settings.
Checks: C-62706r934554_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Select a distributed port group &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Properties. Review the "Override port policies". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: (Get-VDPortgroup).ExtensionData.Config.Policy If there are any distributed port groups that allow overridden port policies, this is a finding. Note: This does not apply to the "Block Ports" or "Configure reset at disconnect" policies.

Fix: F-62615r934555_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Select a distributed port group >> Configure >> Settings >> Properties. Click "Edit". Select advanced and update all port policies besides "Block Ports" to "disabled" and click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: $pgs = Get-VDPortgroup | Get-View ForEach($pg in $pgs){ $spec = New-Object VMware.Vim.DVPortgroupConfigSpec $spec.configversion = $pg.Config.ConfigVersion $spec.Policy = New-Object VMware.Vim.VMwareDVSPortgroupPolicy $spec.Policy.VlanOverrideAllowed = $False $spec.Policy.UplinkTeamingOverrideAllowed = $False $spec.Policy.SecurityPolicyOverrideAllowed = $False $spec.Policy.IpfixOverrideAllowed = $False $spec.Policy.BlockOverrideAllowed = $True $spec.Policy.ShapingOverrideAllowed = $False $spec.Policy.VendorConfigOverrideAllowed = $False $spec.Policy.TrafficFilterOverrideAllowed = $False $pg.ReconfigureDVPortgroup_Task($spec) }

b
The vCenter Server must reset port configuration when virtual machines are disconnected.
CM-6 - Medium - CCI-000366 - V-258967 - SV-258967r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000302
Vuln IDs
  • V-258967
Rule IDs
  • SV-258967r961863_rule
Port-level configuration overrides are disabled by default. Once enabled, this allows for different security settings to be set from what is established at the Port Group level. If overrides are not monitored, anyone who gains access to a VM with a less secure VDS configuration could exploit that broader access. If any unknown or unauthorized per-port overrides exist and are not discarded when a virtual machine is disconnected from that port then a future virtual machine connected to that port may receive a less secure port.
Checks: C-62707r934557_chk

If distributed switches are not used, this is not applicable. From the vSphere Client, go to "Networking". Select a distributed switch &gt;&gt; Select a distributed port group &gt;&gt; Configure &gt;&gt; Settings &gt;&gt; Properties. Review the "Configure reset at disconnect" setting. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: (Get-VDPortgroup).ExtensionData.Config.Policy.PortConfigResetAtDisconnect If there are any distributed port groups with "Configure reset at disconnect" configured to "disabled" or "False", this is a finding.

Fix: F-62616r934558_fix

From the vSphere Client, go to "Networking". Select a distributed switch >> Select a distributed port group >> Configure >> Settings >> Properties. Click "Edit". Select advanced and update "Configure reset at disconnect" to be enabled and click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: $pgs = Get-VDPortgroup | Get-View ForEach($pg in $pgs){ $spec = New-Object VMware.Vim.DVPortgroupConfigSpec $spec.configversion = $pg.Config.ConfigVersion $spec.Policy = New-Object VMware.Vim.VMwareDVSPortgroupPolicy $spec.Policy.PortConfigResetAtDisconnect = $True $pg.ReconfigureDVPortgroup_Task($spec) }

b
The vCenter Server must disable Secure Shell (SSH) access.
CM-6 - Medium - CCI-000366 - V-258968 - SV-258968r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000303
Vuln IDs
  • V-258968
Rule IDs
  • SV-258968r961863_rule
vCenter Server is delivered as an appliance, and intended to be managed through the VAMI, vSphere Client, and APIs. SSH is a troubleshooting and support tool and should only be enabled when necessary. vCenter Server High Availability uses SSH to coordinate the replication and failover between the nodes. Use of this feature requires SSH to remain enabled.
Checks: C-62708r934560_chk

Open the Virtual Appliance Management Interface (VAMI) by navigating to https://&lt;vCenter server&gt;:5480. Log in with local operating system administrative credentials or with a Single Sign-On (SSO) account that is a member of the "SystemConfiguration.BashShellAdministrator" group. Select "Access" on the left navigation pane. If "SSH Login" is not "Deactivated", this is a finding.

Fix: F-62617r934561_fix

Open the Virtual Appliance Management Interface (VAMI) by navigating to https://<vCenter server>:5480. Log in with local operating system administrative credentials or with a Single Sign-On (SSO) account that is a member of the "SystemConfiguration.BashShellAdministrator" group. Select "Access" on the left navigation pane. Click "Edit" then disable "Activate SSH Login" and click "OK".

b
The vCenter Server must enable data in transit encryption for vSAN.
CM-6 - Medium - CCI-000366 - V-258969 - SV-258969r961863_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000304
Vuln IDs
  • V-258969
Rule IDs
  • SV-258969r961863_rule
Transit encryption must be enabled to prevent unauthorized disclosure information and to protect the confidentiality of organizational information. vSAN data-in-transit encryption has the following characteristics: -vSAN uses AES-256 bit encryption on data in transit. -Forward secrecy is enforced for vSAN data-in-transit encryption. -Traffic between data hosts and witness hosts is encrypted. -File service data traffic between the VDFS proxy and VDFS server is encrypted. -vSAN file services inter-host connections are encrypted. -vSAN uses symmetric keys that are generated dynamically and shared between hosts. Hosts dynamically generate an encryption key when they establish a connection, and they use the key to encrypt all traffic between the hosts. You do not need a key management server to perform data-in-transit encryption. Each host is authenticated when it joins the cluster, ensuring connections only to trusted hosts are allowed. When a host is removed from the cluster, it is authentication certificate is removed. vSAN data-in-transit encryption is a cluster-wide setting. When enabled, all data and metadata traffic is encrypted as it transits across hosts.
Checks: C-62709r934563_chk

If no clusters are enabled for vSAN, this is not applicable. From the vSphere Client, go to Host and Clusters. Select the vCenter Server &gt;&gt; Select the cluster &gt;&gt; Configure &gt;&gt; vSAN &gt;&gt; Services &gt;&gt; Data Services. Review the "Data-in-transit encryption" status. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $vsanclusterconf = Get-VsanView -Id VsanVcClusterConfigSystem-vsan-cluster-config-system $vsanclusterconf.VsanClusterGetConfig((Get-Cluster -Name &lt;cluster name&gt;).ExtensionData.MoRef).DataInTransitEncryptionConfig Repeat these steps for each vSAN enabled cluster in the environment. If "Data-In-Transit encryption" is not enabled, this is a finding.

Fix: F-62618r934564_fix

From the vSphere Client, go to Host and Clusters. Select the vCenter Server >> Select the target cluster >> Configure >> vSAN >> Services >> Data Services. Click "Edit". Enable "Data-In-Transit encryption" and choose a rekey interval suitable for the environment then click "Apply".

b
The vCenter Server must use DOD-approved encryption to protect the confidentiality of network sessions.
AC-17 - Medium - CCI-000068 - V-265978 - SV-265978r1003613_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000068
Version
VCSA-80-000009
Vuln IDs
  • V-265978
Rule IDs
  • SV-265978r1003613_rule
Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. In vCenter 8 Update 3, Transport Layer Security (TLS) Profiles were introduced that allow users to manage and configure TLS parameters for the vCenter server. Several TLS profiles are available by default but not all may be suitable for high security environments.
Checks: C-69901r1003611_chk

From the vSphere Client, go to Developer Center &gt;&gt; API Explorer. Select "appliance" from the "Select API" drop down list then scroll down to the "tls/profiles/global" section. Expand the GET call and click Execute and review the response for the configured global TLS profile. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Invoke-GetTlsProfilesGlobal If the global TLS profile is not "NIST_2024", this is a finding.

Fix: F-69804r1003612_fix

From the vSphere Client, go to Developer Center >> API Explorer. Select "appliance" from the "Select API" drop down list then scroll down to the "tls/profiles/global" section. Expand the PUT call and enter the following in the value box: { "profile": "NIST_2024" } Click Execute and Continue to configure a new global TLS profile. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Invoke-SetProfilesGlobalAsync -TlsProfilesGlobalSetSpec (Initialize-TlsProfilesGlobalSetSpec -VarProfile NIST_2024) To monitor the status of the operation the task id from the command output can be used with the "Invoke-GetTask" command. For example: Invoke-GetTask -Task 66b247c2-fe02-4425-9338-1c88eb856138:com.vmware.appliance.tls.profiles.global

b
The vCenter Server must disable accounts used for Integrated Windows Authentication (IWA).
CM-6 - Medium - CCI-000366 - V-265979 - SV-265979r1003616_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
VCSA-80-000305
Vuln IDs
  • V-265979
Rule IDs
  • SV-265979r1003616_rule
If not used for their intended purpose, default accounts must be disabled. vCenter ships with several default accounts, two of which are specific to IWA and SASL/Kerberos authentication. If other methods of authentication are used, these accounts are not needed and must be disabled.
Checks: C-69902r1003614_chk

If IWA is used for vCenter authentication, this is not applicable. From the vSphere Client, go to Administration &gt;&gt; Single Sign On &gt;&gt; Users and Groups &gt;&gt; Users. Change the domain to "vsphere.local" and review the "K/M" and "krbtgt/VSPHERE.LOCAL" accounts. If the "K/M" and "krbtgt/VSPHERE.LOCAL" accounts are not disabled, this is a finding.

Fix: F-69805r1003615_fix

From the vSphere Client, go to Administration >> Single Sign On >> Users and Groups >> Users. Select the "K/M" or "krbtgt/VSPHERE.LOCAL" and click "More" then select "Disable". Click "Ok" to disable the user account.