Monday, November 30, 2015

vRealize Operations 6.1 Compliance

vRealize Operations 6.1 is packaged with it's own compliance engine, the compliance engine helps you monitor the security best practices of your vSphere virtual machines and hosts, which is essential in keeping your IT auditors happy! vRealize Operations utilizes the vSphere 5.5 Security Hardening Guide, hopefully we will have it updated to the latest version in an upcoming release, but it is still invaluable for providing insight into the security posture of your virtual infrastructure.

To start, we need to enable the alert definition in our base policy. The ESXi Host is violating vSphere 5.5 Hardening Guide and Virtual Machine is violating vSphere 5.5 Hardening Guide alert definitions aren't enabled by default. I am going to enable both alert definitions in my vSphere Solution's Default Policy, all child policies I have created underneath this base policy will inherit the setting. If you aren't familiar with vRealize Operations policies, I wrote a blog post covering the creation and modification of policies called vRealize Operations 6.1 Policies.

When editing the base policy, you are going to jump to step 6 Alert/Symptom Definitions and filter on hardening. This will display both of the alert definitions, you will notice that the State is local disabled.

To enable the alert definition, we are going to use the drop-down list under State and select local enabled (green check). You will notice that there are 20 symptom definitions for ESXi hosts and 49 symptom definitions for virtual machines. After we have modified both policies to enable the alert definition, we are going to save our base policy.

Let's take a look at the alert symptoms, we are going to click on the Content icon and select Alert Definitions.

Next we are going to filter on hardening, this will bring us to our ESXi host and Virtual Machine alert definitions.

If we edit the ESXi Host is violating vSphere 5.5 Hardening Guide alert definition it shows us the list of the 20 symptoms. We can negate these symptoms by clicking on the cross-though icon or delete the symptom by clicking the x icon. This provides modest flexibility to tailor the alert definition based on a custom security controls document for your organization. In my next post, we will dive into creating a security controls document to establish your security guidelines.

When a host or virtual machine is not complaint, it will show up as an alert under the Risk badge. In the image below, we have 6 ESXi host objects and 3 virtual machine objects that aren't compliant with the vSphere 5.5 Hardening Guide Rules. It also provides us with a link to download the vSphere 5.5 Hardening Guide spreadsheet.

If we look at the Compliance tab under Analysis for one of my ESXi hosts, I can see that it is 100% compliant with the vSphere 5.5 Hardening Guide.

Highlighting the compliance standard allows you to view the violated rules or all the rules. This detailed overview allows you to scroll through all the symptoms and provides visual indicators of the status. If you have modified the default alert definition for the ESXi host, the removed items will not show in the All Rules view.

There is no option to automatically remediate non-compliant systems with the Python Actions adapter, essentially it is a read-only view of definition rules. While the vRealize Operations compliance engine isn't as powerful as vRealize Configuration Manager, it isn't nearly as complex to deploy and manage; it provides a solid understanding of the vSphere systems that aren't compliant with your specific security guidelines. 

As mentioned previously, in my next blog post I will walk through the steps of creating a security controls document.

News: Top vBlog 2016 Trending: DRS Advanced Settings