Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Ask the SA if software and system security patches are installed and up-to-date for all ESXi hypervisors/VMs, including the vCenter Server (vCS) and the VMware Update Manager (vUM), if they are also installed as VMs rather than as physical machines. If the vUM's hypervisor host/VM patch, update, and remediation procedure does not include its own hypervisor/VM or that of the vCS (if installed as VMs), this check is not a finding. If the vUM's hypervisor host/VM patch, update, and remediation process also includes its own hypervisor host/VM and/or the vCS's hypervisor host/VM, this is a finding.
Determine if both the VMware Update Manager (vUM) and vCenter Server (vCS) are installed as physical or virtual machines. No fix is required for vCS/vUM if the vCS and vUM are both installed as physical machines. If the vCS and vUM are installed as virtual machines, they must both be managed either manually or by a secondary installation of vCS and the vUM. All remaining organization hypervisor hosts/VMs must be configured to receive software and security patch updates, via the vUM, on an organization-defined, regularly scheduled basis.
After the Windows server hosting the vCenter Server has been rebooted, a vCenter Server user or member of the user group granted the administrator role must log in and verify the role permissions remain intact. If the user and/or user group granted vCenter administrator role permissions cannot be verified intact, this is a finding.
As a Windows Administrator, log in to the vCenter Server and restore a legitimate administrator account per site-specific user/group/role requirements.
If the Web datastore browser is required for normal, daily operational tasks, this check is not applicable. Verify the Web datastore browser is disabled: Determine the location of the vpxd.cfg file on the vCenter Server's Windows OS host. Edit the file and locate the <vpxd> </vpxd> element. Ensure the following element is set. <enableHttpDatastoreAccess>false</enableHttpDatastoreAccess> If the Web datastore browser is not disabled, this is a finding.
If the Web datastore browser is enabled and required for normal, daily operational tasks, no fix is required. Disable the Web datastore browser: Determine the location of the vpxd.cfg file on the Windows host. Edit the file and locate the <vpxd> ... </vpxd> element. Ensure the following element is set <enableHttpDatastoreAccess>false</enableHttpDatastoreAccess> Restart the vCenter Service to ensure the config file change(s) are in effect.
The Managed Object Browser (MOB) was designed to be used by SDK developers to assist in the development, programming, and debugging of objects. It is an inventory object, full-access interface, allowing attackers to determine the inventory path of an infrastructure's managed entities. Check the operational status of the MOB : Determine the location of the vpxd.cfg file on the vCenter Server's Windows OS host. Edit the file and locate the <vpxd> ... </vpxd> element. Ensure the following element is set. <enableDebugBrowse>false</enableDebugBrowse> If the MOB is currently enabled, ask the SA if it is being used for object maintenance. If the enableDebugBrowse element is enabled (set to true), and object maintenance is not being performed, this is a finding. If the enableDebugBrowse element is enabled (set to true), and object maintenance is being performed, this is not a finding.
If the datastore browser is enabled and required for object maintenance, no fix is immediately required. Disable the managed object browser: Determine the location of the vpxd.cfg file on the Windows host. Edit the file and locate the <vpxd> ... </vpxd> element. Ensure the following element is set. <enableDebugBrowse>false</enableDebugBrowse> Restart the vCenter Service to ensure the configuration file change(s) are in effect.
Verify vCenter Server was installed using a special-purpose user account on the Windows host with a local-only administrator role. This account should have the "Act as part of the operating system" privilege, and write access to the local file system with a local-only administrator role. If the vCenter Server was not installed with a special-purpose, local-only administrator role with the "Act as part of the operating system" privilege, this is a finding.
Re-install the vCenter Server with a special-purpose, local-only administrator role with the "Act as part of the operating system" privilege.
Check the following conditions: The Update Manager must be configured to use the Update Manager Download Server. The use of physical media to transfer update files to the Update Manager server (air-gap model example: separate Update Manager Download Server which may source vendor patches externally via the Internet versus an internal, organization defined source) must be enforced with site policies. If all of the above conditions are not met, this is a finding.
Configure the Update Manager Server to use a separate Update Manager Download Server; the use of physical media to transfer updated files to the Update Manager server (air-gap model) must be enforced and documented with organization policies. Configure the Update Manager Download Server and enable the Download Service. Patches must not be directly accessible to the Update Manager Server application from the Internet.
Check that roles are created in vCenter with the required granularity of privilege for the organization's administrator types, and that these roles are assigned to the correct, site-specific users: Log into the vCenter Server System using the vSphere Client as a vCenter Server System Administrator. Go to "Home>> Administration>> Roles" and verify that a role exists for each of the administrator privilege sets the organization requires and allows. Right click on each Role name and select "Edit". Verify under "All Privileges>> Virtual Machines" that only site-specific, required checkboxes are selected. If the organization does not require roles for administrator privilege sets, this is a finding. If a role does not exist for each of the organization-required, administrator privilege sets, this is a finding.
Create roles in vCenter with the required granularity of privilege for the organization's administrator types, and ensure that these roles are assigned to the correct, site-specific users. As a vCenter Server administrator, log into the vCenter Server with the vSphere Client. Go to "Home>> Administration>> Roles" and create a role for each of the administrator privilege sets the organization requires and allows. Right click on each role name and select "Edit". Verify under "All Privileges>> Virtual Machines" that only site-specific, required checkboxes are selected.
Ask the SA if event log monitoring is used to alert on non-service account access to the certificates directory. If event log monitoring is not used, this is a finding.
Set up Windows event log monitoring to alert on nonservice account access to the certificates directory.
To check the status of SSL certificates on vCenter Server, open the vSphere Client and connect to the vCenter Server and log in. In the Security Warning dialog, click View Certificate and check the Valid from mm/dd/yy to mm/dd/yy field for the expiry information. Click OK. If unable to determine the certificate status from the certificate details, ask the SA if there is a site procedure to ensure the monitoring and removal of expired certificates from the vCenter Server Windows host. Use this procedure to check the vCenter Server/host for the presence of expired certificates. If a procedure does not exist and/or expired certificates are found, this is a finding.
If a site procedure to ensure the monitoring and removal of expired certificates from the vCenter Server Windows host does not exist, create one. Check the vCenter Server/host for the presence of expired certificates. Remove all expired certificates.
If at any time a vCenter Server installation fails, only the log files of format "hs_err_pid...." should be identified on the Windows host and deleted securely before putting the host into production. Determine if a site policy exists for handling failed installation cleanup of the Windows host prior to deployment. Using the Windows host search function, determine the existence of any log files of format "hs_err_pid". If a file name of the format "hs_err_pid" is found, this is a finding. If a site policy does not exist and/or is not followed, this is a finding.
Develop a site policy for handling failed installation cleanup of the Windows host prior to deployment. Using the Windows host search function, determine the existence of any log files of format "hs_err_pid and remove them.
To check the status of SSL certificates on vCenter Server, open the vSphere Client and connect to the vCenter Server and log in. In the Security Warning dialog, click View Certificate and check the Valid from mm/dd/yy to mm/dd/yy field for the expiry information. Click OK. If unable to determine the certificate status from the certificate details, ask the SA if there is a site procedure to ensure the monitoring and removal of revoked certificates from the vCenter Server Windows host. Use this procedure to check the vCenter Server/host for the presence of revoked certificates. If a procedure does not exist and/or revoked certificates are found, this is a finding.
If a site procedure to ensure the monitoring and removal of revoked certificates from the vCenter Server Windows host does not exist, create one. Check the vCenter Server/host for the presence of revoked certificates. Remove all revoked certificates.
Check the permissions assigned in vSphere. Verify that a non-Windows administrative user account is used to manage vCenter. Ensure the user does not belong to any local groups, such as administrator. If a Windows administrative account is used to manage vCenter, this is a finding. If the account used to manage vCenter belongs to a local Windows or administrative group, this is a finding.
Ensure "Administrator" or any other account or group does not have any privileges except users created as follows: Create an ordinary user account that will be used to manage vCenter (example vi-admin). Make sure the user does not belong to any local groups, such as administrator. On the top-level hosts and clusters context, log onto vCenter as the Windows administrator; then grant the role of administrator (global vCenter administrator) to the created account. Log out of vCenter and log into vCenter with the account created. Verify user is able to perform all tasks available to a vCenter administrator. Remove the permissions in the vCenter for the local administrator group.
Check the Windows file permission on the SSL certificate directory files are set so only the vCenter service account and authorized vCenter Server Administrators can access them. Verify the directory and all files within are only accessible to the service user (System) and authorized vCenter Server administrators. The location by default for vCenter this is C:\ProgramData\VMware\VMware VirtualCenter\SSL and for the Inventory Service SSL certificate is C:\Program Files\VMware\Infrastructure\Inventory Service\ssl. If the SSL certificate directory/files are not set so that only the vCenter service account and authorized vCenter Server Administrators can access them, this is a finding.
Ensure the Windows file permission on the SSL certificate directory files are set so only the vCenter service account and authorized vCenter Server Administrators can access them. Ensure the directory and all files within are only accessible to the service user (System) and authorized vCenter Server administrators. The location by default for vCenter this is C:\ProgramData\VMware\VMware VirtualCenter\SSL and for the Inventory Service SSL certificate is C:\Program Files\VMware\Infrastructure\Inventory Service\ssl.
Check that a role is used to manage the vCenter Server without the Guest Access Control (example "Administrator No Guest Access"), and that this role is assigned to administrators who should not have Guest file and program interaction privileges. Log into the vCenter Server System using the vSphere Client as a vCenter Server System Administrator. Go to "Home>> Administration>> Roles" and verify that a role exists for administrators with Guest access removed. Right click on the role name and select "Edit". Verify under "All Privileges>> Virtual Machines" the "Guest Operations" checkbox is unchecked. Verify users requiring Administrator privileges without Guest access privileges are assigned to that role and not the default Administrator role. Ask the SA for a list of users that require administrator privileges without Guest access privileges and verify their role assignments. If users requiring administrator privileges without Guest access privileges are assigned to the default Administrator role, this is a finding.
Create a role to manage vCenter without the Guest Access Control (example "Administrator No Guest Access"), and that this role is assigned to administrators who should not have Guest file and program interaction privileges. Log into the vCenter Server System using the vSphere Client as a vCenter Server System Administrator. Go to "Home>> Administration>> Roles" and verify a role exists for administrators with Guest access removed. Right click on the role name and select "Edit". Verify under "All Privileges>> Virtual Machines" the "Guest Operations" checkbox is unchecked. Create account(s) requiring administrator privileges without Guest access privileges.
Verify all client operating systems connecting to the vCenter Server are not Linux. If any client operating system connecting to the vCenter Server is Linux-based, this is a finding.
Replace all Linux-based clients connecting to the vCenter Server with non-Linux-based clients.
The vCenter Server must be protected by a network and/or local firewall on the vCenter Server Windows system. This protection must include IP-based access restrictions, enabling only necessary components to communicate with the vCenter Server system. If the vCenter Server Windows system is not protected by a network and/or local firewall, this is a finding.
The vCenter Server Windows system must be protected by utilizing a network and/or local firewall. Install the vCenter Server Windows system behind the firewall and/or install a firewall application on the Windows system. Firewall protections must include IP-based access restrictions, enabling only necessary components to communicate with the vCenter Server system.
Verify only the runtime privileges needed for the current vCenter state, on either Oracle or Microsoft SQL Server, is assigned. Verify that the following permissions are granted to the vCenter user in the vCenter database. GRANT ALTER ON SCHEMA :: <schema> to <user>; GRANT REFERENCES ON SCHEMA :: <schema> to <user>; GRANT INSERT ON SCHEMA :: <schema> to <user>; GRANT CREATE TABLE to <user>; GRANT CREATE VIEW to <user>; GRANT CREATE Procedure to <user>; For SQL, verify that the following permissions are granted to the user in the MSDB database. Note that the msdb database is used by SQL Server Agent for scheduling alerts and jobs. GRANT SELECT on msdb.dbo.syscategories to <user>; GRANT SELECT on msdb.dbo.sysjobsteps to <user>; GRANT SELECT ON msdb.dbo.sysjobs to <user>; GRANT EXECUTE ON msdb.dbo.sp_add_job TO <user>; GRANT EXECUTE ON msdb.dbo.sp_delete_job TO <user>; GRANT EXECUTE ON msdb.dbo.sp_add_jobstep TO <user>; GRANT EXECUTE ON msdb.dbo.sp_update_job TO <user>; GRANT EXECUTE ON msdb.dbo.sp_add_category TO <user>; GRANT EXECUTE ON msdb.dbo.sp_add_jobserver TO <user>; GRANT EXECUTE ON msdb.dbo.sp_add_jobschedule TO <user>; For Oracle, verify that the following permissions (or DBA role) are granted to the user. grant connect to <user> grant resource to <user> grant create view to <user> grant create materialized view to <user> grant execute on dbms_job to <user> grant execute on dbms_lock to <user> grant unlimited tablespace to <user> If the runtime privileges are not configured per the above guidelines, this is a finding.
Set the runtime privileges needed for the current vCenter state, on either Oracle or Microsoft SQL Server as noted below. Grant the following permissions to the vCenter user in the vCenter database: GRANT ALTER ON SCHEMA :: <schema> to <user>; GRANT REFERENCES ON SCHEMA :: <schema> to <user>; GRANT INSERT ON SCHEMA :: <schema> to <user>; GRANT CREATE TABLE to <user>; GRANT CREATE VIEW to <user>; GRANT CREATE Procedure to <user>; Grant the following permissions to the user in the MSDB database. Note that the msdb database is used by SQL Server Agent for scheduling alerts and jobs. GRANT SELECT on msdb.dbo.syscategories to <user>; GRANT SELECT on msdb.dbo.sysjobsteps to <user>; GRANT SELECT ON msdb.dbo.sysjobs to <user>; GRANT EXECUTE ON msdb.dbo.sp_add_job TO <user>; GRANT EXECUTE ON msdb.dbo.sp_delete_job TO <user>; GRANT EXECUTE ON msdb.dbo.sp_add_jobstep TO <user>; GRANT EXECUTE ON msdb.dbo.sp_update_job TO <user>; GRANT EXECUTE ON msdb.dbo.sp_add_category TO <user>; GRANT EXECUTE ON msdb.dbo.sp_add_jobserver TO <user>; GRANT EXECUTE ON msdb.dbo.sp_add_jobschedule TO <user>; For Oracle, either assign the DBA role or grant the following permissions to the user. grant connect to <user> grant resource to <user> grant create view to <user> grant create materialized view to <user> grant execute on dbms_job to <user> grant execute on dbms_lock to <user> grant unlimited tablespace to <user>
Verify only the following permissions are allowed to the VUM DB user after installation. For Oracle DB normal operation, only the following permissions are required. Create session create any table drop any table For SQL Server DB normal operation, the dba_owner role or sysadmin role can be removed from the MSDB database. The dba_owner role or sysadmin role is still required for the Update Manager database. Note: While current, it is always best to check both the latest VMware Update Manager Administration Guide and the vendor database documentation for any updates to these configurations. If the above vendor database-dependent permissions are not strictly adhered to, this is a finding.
For Oracle DB normal runtime operation, set the following permissions. Create session create any table drop any table For SQL Server DB normal runtime operation remove/delete the dba_owner role or sysadmin role from the MSDB database. The dba_owner role or sysadmin role is still required for the Update Manager database. Note: While current, it is always best to check both the latest VMware Update Manager Administration Guide and the vendor database documentation for any updates to these configurations.
On each Windows computer with the vSphere Client installed, verify: A 15 minute (maximum) timeout is set in the VpxClient.exe.config file: Locate the VpxClient.exe.config file using the Windows OS search facility. Next, right click on VpxClient.exe.config and edit the file using an editor, such as Notepad. In the <cmdlineFallback>... </cmdlineFallback> section, verify the setting <inactivityTimeout>X</inactivityTimeout> where X is the (maximum=15) number of minutes before the vSphere Client will automatically disconnect from the server. Verify the timeout that the vSphere Client executable is started with is an execution flag: Locate the vSphere Client executable icon on the desktop, right click, and select properties. Verify the presence of "-inactivityTimeout 15" in the command. If either of the above methods are invoked and the timeout interval exceeds 15 minutes, this is a finding.
On each Windows computer with the vSphere Client installed: Set a 15 minute (maximum) timeout in the VpxClient.exe.config file: Locate the VpxClient.exe.config file using the Windows OS search facility. Next, right click on VpxClient.exe.config and edit the file using an editor, such as Notepad. In the <cmdlineFallback>... </cmdlineFallback> section, modify the <inactivityTimeout>X</inactivityTimeout> where X is the (maximum=15) number of minutes before the vSphere Client will automatically disconnect from the server. Exit, saving the file. Set a 15 minute (maximum) timeout execution flag when starting the vSphere Client executable: Locate the vSphere Client executable icon on the desktop, right click, and select properties. Add "-inactivityTimeout X", where X is the (maximum=15) number of minutes before the vSphere Client will automatically disconnect from the server.
Verify the vSphere Client used by administrators includes only authorized extensions from trusted sources: From the vSphere Client, "Plug-ins>> Manage Plug-ins" and click the Installed Plug-ins tab. View the Installed/Available Plug-ins list and verify they are all identified as authorized VMware, 3rd party (Partner) and/or site-specific (locally developed and site) approved plug-ins. If any Installed/Available plug-ins in the viewable list cannot be verified as vSphere Client plug-ins and/or authorized extensions from trusted sources, this is a finding.
Disable/remove all listed plug-ins that cannot be verified as distributed from trusted sources: From the vSphere client, connect to the vCenter server. On the menu bar, go to "Plug-ins >> Manage Plug-ins". Under Installed Plug-ins, right-click the plug-in of choice and select Disable.
Connect to the vCenter Server via the vSphere Client. Highlight the data center name and navigate to the Permissions tab. Observe the list of users and/or groups. If any local administrator group permissions appear in the displayed list, this is a finding. If a vCenter Administrator account (must be an ordinary user assigned the administrator role) does not appear in the displayed list, this is a finding. If a vCenter Administrator account (must be an ordinary user assigned the administrator role) does appear in the displayed list, this is not a finding.
Log into the Windows server as the Windows administrative user and create an ordinary user account that will be used to manage vCenter Server (example user: vAdmin). Ensure the ordinary user account (created above) does not belong to any local groups (example group: administrators). As the Windows administrative user, log into the vCenter Server (using the vSphere Client). Grant the role of administrator (global vCenter Server administrator) to the ordinary user account (created above). Log into the vCenter Server (using the vSphere Client) with the ordinary user account (created above) and verify that the user is able to perform all vCenter Server administrative tasks. As the Windows administrative user, log into the vCenter Server (using the vSphere Client). Delete the local administrator group from the permissions tab in the vSphere Client. Close the vSphere Client connection and attempt to reconnect to the Windows server as the Windows administrative user. The connection should now fail due to lack of administrator access/permissions.
If the Update Manager Download Server does not connect to the Internet to source vendor patches, this check is not applicable. Verify there is a Web proxy between Update Manager Download Server and the Internet. Check the proxy settings for the Update Manager Download Server to ensure correct configuration. To verify proxy settings, from the vSphere Client/vCenter Server system, click Update Manager under Solutions and Applications. On the Configuration tab, under Settings, click Download Settings. In the Proxy Settings pane, select properties and view the proxy information. If a web proxy between Update Manager Download Server and the Internet is not configured, this is a finding.
If the Update Manager Download Server does not connect to the Internet to source vendor patches, no fix is required. To configure proxy settings, from the vSphere Client/vCenter Server system, click Update Manager under Solutions and Applications. On the Configuration tab, under Settings, click Download Settings. In the Proxy Settings pane, select Use proxy and change the proxy information. Optional: If the proxy requires authentication, select Proxy requires authentication and provide a user name and password. Optional: Click Test Connection at any time to test a connection to the Internet through the proxy is possible. Click Apply.
Verify the Update Manager download source is not the Internet. To verify download settings, from the vSphere Client/vCenter Server system, click Update Manager under Solutions and Applications. On the Configuration tab, under Settings, click Download Settings. In the Download Sources pane, verify "Direct connection to Internet" is not selected. If "Direct connection to Internet" is configured, this is a finding.
To configure a Web server or local disk repository as a download source (i.e., "Direct connection to Internet" must not be selected as the source), from the vSphere Client/vCenter Server system, click Update Manager under Solutions and Applications. On the Configuration tab, under Settings, click Download Settings. In the Download Sources pane, select Use a shared repository. Enter the <site-specific> path or the URL to the shared repository. Click Validate URL to validate the path. Click Apply.