A customer asked me recently “Why were the Risk Profile definitions pulled out of the vSphere 6 Hardening Guide?”
When we moved to the more streamlined Hardening Guide for 6.0, the intent was that the spreadsheet would be consumable by automated methods. It’s a bit of a pain to programatically parse through tabs and then extract the content. It’s far easier when it’s a “flat” namespace.
That meant that some content that used to be on the introduction tab was now gone, because that tab was no longer there. After getting the question, I did a search for “vsphere hardening guide risk profile” and frankly, came up a little short. There was no substitute for the original intro tab on any VMware.com location. I did find some of the content on some bloggers pages (Thanks to my mate Simon!) however.
So, this warrented an overview of Risk Profiles for those that are unfamiliar and those that are looking for official VMware content. I’m also tossing in some clarification about guidelines as well so read all the way through!
What is a “Risk Profile”
A Risk Profile is a way to categorize the security level of a guideline. Some guidelines are “3” because these are things you should be doing as part of a regular IT Operations routine.
For example: Setting NTP is something you’d do for all Risk Profiles. The way *I* look at Risk Profile 3 is that it’s based on common sense/industry standard practice IT Operations.
Why isn’t Risk Profile 3 the default shipped setting?
How does VMware know what NTP server to set on your systems? Or what the IP of your SYSLOG server is? Or how to connect to your Active Directory? vSphere ships out of the box with Common Criteria certification so it meets solid security standards. The hardening guide is more about configuring your system for production use and as such, that requires site-specific settings and policies.
Risk Profile Example
Setting ESXi Acceptance Level to “PartnerSupported” instead of “Community Supported” ensures that at a minimum, you are using digitally signed VIB’s. So, that’s a 3. Common sense, right? I don’t want unsigned VIB’s installed on my ESXi server and I suspect that neither do you.
For more paranoid customers (and yes, you know who you are), they may only want VIB’s that are from a partner but signed and tested by VMware. In that case, the risk profile would be 2.
Ultra paranoid customers (and yes, *I* know who you are and going forward, we shall refer to you as UFP’s because we know how much you love 3 letter acronyms!) would select a Risk Profile of 1 and ONLY installed VMware created, signed and shipped bits so they’d set the acceptance level of ESXi to VMwareCertified.
What a Risk Profile is NOT
I get this all the time. “If I set everything to Risk Profile 1 am I compliant with PCI, HIPAA, etc??”
NO. NO. NO.
Two different things. Compliance regulations like PCI or HIPAA or DISA used the hardening guide as a basis upon which they match up compliance objectives with settings. There might be a requirement like “ensure only shipped binaries are run”. That gets mapped to one of the accepance level guidelines in the Hardening Guide.
Will Risk Profile 1 make me more secure?
You don’t seek to become “compliant” with the Hardening Guide. It’s a tool to help you understand how to run your vSphere environment in a more secure manner. Period. Compliance does not mean secure. You can set everything to Risk Profile 1 and still be compromised. It happens all the time.
So why Risk Profiles?
As I mentioned above, they are there to categorize the security level of a guideline. Customers wanted to have some idea of whether a guideline was “common sense” vs “ultra paranoid” and then act accordingly.
Those isolation.tools.* guidelines
This one comes up all…the…time… Why are there so many of these settings? Do I need to do all of them for every VM? Why are they all Risk Profile 1??
Here’s the history. Back to our ultra-paranoid friends, the UFP’s. They have a requirement that if there’s a published setting, it MUST have a value even if there is no code backing that setting! Most of these settings come from virtual machines that were running on our Workstation or Fusion products and got moved up to vSphere/ESXi. All of a sudden our UPF’s were seeing settings they didn’t see before. As you can imagine, this caused great consternation.
So, all of these settings got put into the Hardening Guide to satisfy the UPF’s. That’s why they are a Risk Profile 1. I know, you can all sleep well tonight knowing this.
You’ll find that MANY of the Risk Profile 1 settings are there not to “lock down” something but are there for you to “audit”. For example, SSH is turned off by default on ESXi. It’s in the hardening guide because when you audit the system and SSH is turned on, that’s something you should address. The guide is as much an “audit” guide as it is a “hardening” guide. In fact, maybe moreso.
Risk Profile History
In 5.1, these were called just “Profiles”. In 5.5, I renamed them to “Risk Profiles” to more clearly match the intent. It also got the UPF’s attention as well when I used the word “Risk”!
Risk Profile Definitions
Risk Profile 1: guidelines that only be implemented in the highest security environments, e.g. top-secret government or military, extremely sensitive data, etc.
Risk Profile 2: guidelines that should be implemented for more sensitive environments, e.g. those handling more sensitive data, those subject to stricter compliance rules, etc.
Risk Profile 3: guidelines that should be implemented in all environments
Oh yes, and please remember, the Hardening Guide is a list of “guidelines” not mandates. If you can mitigate a threat in a different manner that suites your environment then go for it. The Hardening Guide should foster discussion, not be something that gets tossed on an IT persons desk as “something they need to do”. That’s why compliance regs like PCI are for after all!
Does this help? Let me know! Hopefully this blog post puts to rest the whole issue of Risk Profiles and some Hardening Guide Q&A and why some settings are marked accordingly. If you have questions, reach out here in the comments or to @mikefoley or @vspheresecurity on Twitter.
If you’re a UFP, you can send me mail at mfoley at VMware.com or slip me an unmarked envelope while I work out here in my Shedquarters. Look out for the German Shepherd!
mike
p.s. I thought this would be a quick blog about Risk Profile but it’s turned into something a little more. This always happens to me!
