This blog will cover how we can pass custom values into the SaltStack state that make up the security checks. Such customisation provides the ability to define SaltStack compliance policies with a custom variable value. It essentially supports applying certain checks with required variables using the out-of-the-box CIS benchmarks, e.g. security compliance check “Ensure password expiration is 365 days or less”, which will ensure password expiration is 365 days or less. However, my standard policy accepts password expiration to 180 days.
Variables are used to customize policies to the specific organization’s internal policies.
Please note that this process is not applicable If you like to create and test custom compliance components ground up. Custom Compliance content allows you to define security standards that supplement the library of security benchmarks and checks built into SaltStack SecOps Compliance. SaltStack SecOps Compliance includes a Custom Content Software Development Kit (SDK) you can use to create, test, and build your custom security content. You can read more about it here.
Before we dive into how to use SaltStack SecOps policies and its functionalities, I will quickly share a bit more on VMware SaltStack.
Security and IT operations teams must work together to keep modern datacenters compliant and secure, but their efforts are often hindered by contrasting toolsets, disordered processes, and contesting preferences.
Much like DevOps before, SecOps (security + operations) is a movement created to facilitate collaboration between security and operations teams and integrate the technology and processes they use to keep systems and data secure.
vRealize Automation SaltStack SecOps helps IT and security teams work together to reduce risk and improve business agility with powerful event-driven automation and relevant, up-to-date security content. Teams can now define an IT security policy, scan systems against it, detect issues, and actively remediate them from a single platform.
For more details on SaltStack, please refer to the official VMware documentation.
Let’s assume you have SaltStack deployed and SecOps is enabled in your environment. To secure your infrastructure assets with SaltStack SecOps Compliance, you must start by defining policies. First, prepare our SaltStack SecOps environment to scan for the RedHat CIS benchmark using SecOps policies.
SaltStack SecOps Compliance provides different industry benchmarks to choose from including checks for Center for Internet Security (CIS) and more. Each benchmark includes a collection of security checks. You can choose to apply all available checks for a given benchmark, or use only a subset of available checks. Using a subset of checks is useful for customizing SaltStack SecOps Compliance for your unique infrastructure needs, for example if remediating a given check poses the risk of breaking a known dependency.
When creating your policy, you must select a target to apply the policy to, along with benchmarks and checks to run against your system.
So here is the SecOps compliance and policies dashboard.
SaltStack SecOps Compliance simplifies the process of defining your security policy by grouping security checks by a benchmark.
Benchmarks are a category of security checks. SaltStack SecOps Compliance benchmarks are defined by widely-accepted experts, while your own organization’s standards define custom benchmarks. You can use benchmarks to help create a range of policies optimized for different groups of nodes. For example, I will use RedHat Linux 7 Benchmark from the Benchmarks catalog.
These Benchmarks are provided as out of the box catalog within SaltStack SecOps.
As noticed below, the benchmark I have selected covers multiple checks. A check is a security standard that SaltStack SecOps Compliance assesses for compliance. The SaltStack SecOps Compliance library updates checks frequently as security standards change. In addition to checks included the SaltStack SecOps Compliance content library, you can create your own custom checks. Custom checks are indicated by a 
custom-checks-user-icon, instead of the 
built-in-checks-shield-icon.
Now, as in our use case, I would say we need to assign a custom check for the Password Policy. For example, instead of using the default compliance check ” 5.5.1.1 Ensure password expiration is 365 days or less”, which is going to ensure password expiration is 365 days or less. My company’s acceptable policy is 180 days. So what can we do here? How can we modify this check to match my custom requirement?
Well, in this case, the Variable parameter comes handy.
PS Note: Not all the Checks come with a Variable as a parameter. It purely depends on the nature of the Check.
Let’s dive into it. If we look at this specific Check, notice you can learn more about the description, action, rationale, and audit details of the Check. However, you can see the Variable information as well.
Here is the information around the Variable this particular check applies. It applies “SHADOW_PASS_MAX_DAYS”, which is the maximum age of password enforced by shadow password suite parameters.
To secure your infrastructure assets with SaltStack SecOps Compliance, you must start by defining policies. So let’s create a Policy here to define a custom variable on the Compliance Check.
Select the RedHat benchmark that consists of the Password Policy Check.
Next, select the required Check to be included in your policy.
Now you can see the default Variable parameter setting. It is by default set to 365 days. This is where you can change the Variable and assign your custom value, e.g. I will change the value to 180 days.
Here you can see I have changed the Variable as per my requirement.
Finally, you can save and run the Policy against the selected target, reinforcing the updated Variable in the Policy.