Security Controls Document

The VMware Security Hardening Guides contain recommended processes for deploying and operating VMware products in a secure manner given a specified risk profile. You may not need, or may not be able to follow each step of the security hardening guides because of the balance of operational efficiency, cost, risk tolerance, and security requirements. The security hardening practices are recommended by VMware, but equally important is having a security controls document that incorporates VMware best practice recommendations and your specific security policies. It can be an invaluable tool during an audit.

Security has a wide scope that touches every aspect of the datacenter; an important part of security is recognizing the tolerance of risk. To do that, you need to understand the value of the assets you are trying to protect and the cost of protecting that asset.  What is the likelihood of the asset being damaged or compromised? And what does it cost the company if that asset is compromised? A risk analysis provides a cost/benefit understanding of the cost to safeguard an item compared with the expected cost of loss. The security policy should be proportionate to the value of the asset, which may range from innocuous data processing up through a mission critical business process dealing with highly sensitive information. Each of these examples represents a different risk profile, which translates to different security requirements and thus different recommendations in the hardening guide. Securing systems is not an inexpensive endeavor. Even in terms of operations expenses, locking down systems can make internal operation teams far less inefficient on updating systems because of strict security controls. In many cases, a security policy will not be implemented unless the cost of the loss exceeds the security policy itself.

In certain instances, a customer may not require or desire the level of controls outlined in the VMware Security Hardening Guides; but in other cases customers may have stronger controls already implemented due to regulatory compliance.  In the end, you are the one that's best suited to make the decisions on the security posture of your IT assets.

Security Controls Document

Controls and audit compliance includes the process and mechanisms companies utilize to comply with laws such as Sarbanes Oxley or standards such as COBIT. In general, the larger the company, the more these regulations and practices are going to affect the organization. The trick is effectively implementing security hardening best practices across your organization in the most efficient way possible.

A security controls document provides the specific controls and options that are implemented in your environment. They are the standards that determine how hardware and software products are to be used in your organization. You can have them divided up into different indexes or appendices in the document based on the extent and scope of the security controls document. 

Operation controls may include:

• Resource protection
• Hardware controls
• Software controls
• Privileged-entity controls
• Media controls
• Physical access controls

For our instance, we are going to focus on virtualization; in the sample document we will cover VMware vSphere and VMware View. The document contains tables that describe the security settings that are specific to each category. The sample document is just that, a sample, and not an extensive list of all the controls that you may want to include in your security controls document.

To understand security controls, let’s assess the common risks that we find in the modern datacenter.

• Physical damage
• Human error
• Equipment malfunction
• Inside and outside attacks
• Misuse of data
• Loss of data
• Application failure

As we can see, these are some of the everyday threats we face when managing a data center. What is a threat? Simply put, it is any event that can cause damage to a system and create loss of confidentiality, integrity or availability. Risk comes in many forms, not all just computer related; not surprisingly the number one risk is human error. Security controls are enacted to mitigate the risk of human error, attacks, and misuse of data and to limit exposure in those events.

But, we also need to determine the overall value of an asset. A hardened security posture for a system that provides little company value and doesn’t impact the rest of the environment may not be cost effective.

Some of the costs we need to take into consideration include:

• Cost to acquire or develop the asset
• Cost to maintain and protect the asset
• Value of the asset to the business
• Value of intellectual property
• Productivity that is affected if the asset is unavailable
• Liability issues if compromised

Understanding the value of your assets and the support required for the asset to meet your business expectations is the starting point for understanding the security mechanisms that will compose your security controls document.

Security Controls Cycle

Below is a table that illustrates a standard security controls lifecycle.

Task	Start Time
Security Controls Baseline Created ·       Create baseline security controls document ·       Review with stakeholders ·       Publish the document
Security Controls Implementation ·       Document current values ·       Project plans ·       Security controls remediated	When the Security Controls document has been published
Semi-Annual Review ·       Determine if update is required ·       Document draft ·       Review with stakeholders ·       Final copy published	6 months after the published date or after the last annual review end
Semi-Annual Review Implementation ·       Document current values ·       Project plans ·       Security controls remediated	When the semi-annual review ends
Quarterly Health Check ·       Ensure that the controls that were in place are maintained	Every 3 months

Like in my previous post, we can ensure that the controls that were in place are maintained by using a tool like vRealize Operations Manager. We can use the Compliance feature to check for drift in our controls policy.

Risk Profile

A risk profile is a way to group similar systems together for the purpose of defining applicable security controls that are appropriate for specific groups. For example, a database server that stores Protected Health Information (PHI) for a healthcare organization will require security controls that are far more rigid than another database server that stores less valuable data. Just as it is a poor practice to unduly relax security controls on a high-value resource, it’s also a poor practice to impose overly rigorous controls on low value resources.

Recent versions of the VMware Hardening Guides provide recommendations for three different risk profiles:

• 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

For convenience, we can think of these as high risk, medium risk, and standard risk. Customers will need to evaluate which of their resources belong in which category. Some customers may not even use all categories, while others may find the need to define additional categories. In general, these three will provide most customers with a good start.

Security Baseline

The Security Baseline is the set of specific security controls for a resource that falls within a specific risk profile. This baseline will vary from resource to resource, for example a vCenter Server will have a different set of specific controls than an ESXi server even if both systems share the same risk profile. Think of risk profile as a general ranking of the criticality of a resource and the security baseline as the specific controls (or “settings”) required to meet that profile. Additionally, business requirements may dictate that specific systems have a higher level of protection due to regulatory compliance or because it is a mission critical system. For example, the security baseline for the password policy may be a minimum password length of 8 characters with upper case letters, lower case letters, and numbers. However, you may have applications that hold financial information or client medical records that require a higher level of security, such as a minimum password length of 12 characters with upper case letters, lower case letters, numbers, and symbols. The security baseline is the minimum security settings required. Any unique requirements below the baseline should be documented as a security exception.

Document Retention

Typically, you only need to retain the current version of your security controls document. However, there is a window when you may need to retain the latest and previous versions. If you have finished a review, and there are control processes that need to be modified, you should retain the previous version of the security controls until the implementation is completed. If you don’t do this, you may have a problem if an audit/review occur before the implementation is complete.

Security Appendices

If the security controls document covers several technology sections, you can break them up into individual appendices with the appropriate Executive Sponsor.

Appendix Title	Executive Sponsor
A.    vSphere	Joe Smith
B.    Windows Servers	Jane Poole
C.    Network Infrastructure	Mike Doe
D.    Oracle	Fred Cooper
E.    Apache Webserver	Nancy Welsh

Here is a sample security controls document I put together that you can download:

Sample Security Controls Document