May 2017
Volume 32 Number 5
[DevOps]
Compliance as Code with InSpec
By Michael Ducy | May 2017
Regulatory compliance is a fact of life for every enterprise. At the same time, competitive pressures are increasing with the advent of game-changing new technologies and customer expectations for digital services. Is it possible for industries to deliver new products and services at high velocity while still satisfying their obligations for regulatory compliance?
The answer is yes. The solution is to embed regulatory compliance into the software production line analogously to the way we embed other qualities, such as frame stiffness in automobiles or round-trip response time in banking applications.
Making compliance an integral part of the deployment process is possible when compliance is expressed as code. Just as the configuration of systems has shifted toward infrastructure as code (for example, PowerShell Desired State Configuration or Chef), you can manage compliance using a programmatic language.
InSpec is an open source project that lets you define your compliance requirements in a human- and machine-readable language. Once you’ve codified your requirements, you can run them as automated tests that audit your systems. InSpec provides a local agent, as well as full remote testing support.
InSpec supports a variety of different platforms, from Windows to Linux. Figure 1 lists some of the more popular ones. (A full list of supported platforms can be found on the InSpec Web site at inspec.io.)
Figure 1 List of Popular Platforms Supported by InSpec
| Platform | Versions |
| AIX | 6.1, 7.1, 7.2 |
| Mac OS X | 10.9, 10.10, 10.11 |
| Oracle Enterprise Linux | 5, 6, 7 |
| Red Hat Enterprise Linux (and variants) | 5, 6, 7 |
| Solaris | 10, 11 |
| Windows | 7, 8, 8.1, 10, 2008, 2008 R2, 2012, 2012 R2, 2016 |
| Ubuntu Linux | |
| SUSE Linux Enterprise Server | 11, 12 |
| OpenSUSE | 13.1, 13.2, 42.1 |
| HP-UX | 11.31 |
The InSpec broad platform support makes it a complete solution for managing compliance across your entire infrastructure. Because InSpec is an open source project, some OS vendors have contributed support for their own platforms. For instance, IBM has contributed much of the support for its AIX OS.
Getting Started with InSpec
It’s easy to get started with InSpec. InSpec is included in the Chef Development Kit (Chef DK) or you can download packages for a variety of platforms from the Chef download Web site at downloads.chef.io/inspec. Once you’ve downloaded the package and installed it, you can begin writing compliance rules. (Note that an alternative name for a compliance rule, often used by security teams, is auditing control.)
InSpec rules are simple to write once you understand the format. All rules begin with a resource. A resource is a configuration item you want to test. For instance, here’s an InSpec rule that uses the windows_feature resource:
describe windows_feature('DHCP Server') do
it { should_not be_installed }
end
The windows_feature resource declares the name of a Windows feature and tests to see if it matches a particular configuration. In this example, the rule tests that the DHCP Server is not installed.
There are resources for many standard pieces of your network, such as files, directories, users, groups and registry keys. For a complete list, you can refer to the InSpec documentation at bit.ly/2n3ekZe. You can also easily extend InSpec with your own resources to check configuration items that aren’t supported out of the box or that are specific to your particular application.
Including Metadata
InSpec lets you include metadata about your compliance rules. Metadata helps you tie tests to specific regulatory or security requirements. Traditionally, you’d find compliance requirements published in documents, spreadsheets or some other format that’s not actionable. The information in these official compliance documents is important because it gives administrators context as to why the compliance policy matters, however it’s often not conveniently available.
Figure 2 shows an example of an InSpec rule that includes this information as metadata.
Figure 2 Example of InSpec with Metadata About Compliance Rules
control 'sshd-8' do
impact 0.6
title 'Server: Configure the service port'
desc '
Always specify which port the SSH server should listen to.
Prevent unexpected settings.
'
tag 'ssh','sshd','openssh-server'
tag cce: 'CCE-27072-8'
ref 'NSA-RH6-STIG - Section 3.5.2.1',
url: 'https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf'
describe sshd_config do
its('Port') { should eq('22') }
end
end
This example is for a rule (or control) called ssh-8. The impact, title, and desc fields define metadata that describes the rule’s importance, its purpose, and a description. The tag field includes optional information and the ref field references external documents.
The describe field signals the beginning of the block that contains the rule. The resource being tested is sshd_config, which is the OpenSSH daemon on Linux and Unix platforms. The rule tests to see if the SSH server listens to port 22.
There are three important points to notice. First, without the metadata, the rule would be isolated and lack context. Next, all the pertinent information is included with the rule. You don’t have to check it against other documents. Finally, the InSpec language is extremely easy to read. Stakeholders such as compliance officers, who may not be programmers, can understand what the rule tests and the metadata tells them why the rule exists and what requirements it audits. They might even be inclined to contribute their own rules.
Using Open Source Profiles
To make life easier, InSpec has many open source profiles available that already include all the relevant rules and metadata. For example, there’s a DevSec Linux Baseline profile and a DevSec Apache Baseline profile. You can download these profiles at bit.ly/2mBVXNr.
Many of the open source profiles InSpec provides are based on the industry standard Center for Internet Security (CIS) benchmarks for system security. While the CIS baselines provide a good starting point, you might need to modify them to meet your particular compliance needs. InSpec allows you to create your own profiles and to inherit rules from other profiles. InSpec also lets you ignore rules from profiles. This is useful because you don’t need to directly modify the open source profiles InSpec provides. You can create your own profiles that inherit the open source profiles you need, and then ignore rules that aren’t applicable. When new open source profiles are released, you can simply update your version of the open source rules without having to modify your custom rules.
Scanning a Host
InSpec uses a client-server model, which means that you can audit remote systems from a centralized workstation. There are also options that let InSpec scans to run as part of a continuous automation system, such as Chef Automate (chef.io/automate). There’s a brief example of this option later in this article.
To run a compliance scan, you need a target system, which is the server you want to test and a compliance profile, which is the set of rules you use to test the target system. For this example, the target system is a Windows Server, and I’ll use the Dev-Sec Windows baseline as defined by CIS, which is stored in a GitHub repo. Figure 3 shows an example of an InSpec run.
.png "Example of an InSpec Run")
Figure 3 Example of an InSpec Run
If you examine the results, the run shows that there are a number of configuration settings that do not meet the CIS baselines for compliance. It’s worth noting that the server being tested is the default Windows Server 2016 image offered by a major cloud provider, so you can immediately see how InSpec gives you visibility into how well your network conforms to your company’s security policies.
If you look at the actual InSpec rule for the first failing test, cis-enforce-password-history-1.1.1, you can see how the rule translates into something actionable:
control 'cis-enforce-password-history-1.1.1' do
impact 0.7
title '1.1.1 Set Enforce password history to 24 or more passwords'
desc 'Set Enforce password history to 24 or more passwords'
describe security_policy do
its('PasswordHistorySize') { should be >= 24 }
end
end
The test fails because policy requires that there be a password history of at least 24 entries, but, in fact, no history is kept at all. Obviously, the current configuration setting needs to be changed to comply with the rule.
Using InSpec with Automated Release Pipelines
InSpec can, by itself, help you manage the compliance of your systems, but InSpec can also run as a series of automated tests that execute as part of your standard release pipelines. InSpec tests can be easily added to act as a quality gate for compliance. In this section, I’ll use InSpec with Chef Automate.
Chef Automate is an integrated solution for managing and deploying infrastructure and applications. It rests on a foundation of open source products that include InSpec and Chef, which is for infrastructure automation. Chef Automate provides an automated pipeline for change management and includes features for ensuring the visibility of those changes.
With Chef Automate, you can run your InSpec compliance tests on demand, see the results on the dashboard, and remediate the problem. You can also generate audit reports whenever you need them.
For example, patch management is one of the most critical aspects of IT security. It’s important that you be able to identify out-of-date systems and upgrade them. Most regulatory frameworks, such as the Payment Card Industry Data Security Standard (PCI DSS), require it. To ensure that your systems are current, you can use Chef Automate to manage the entire process, from the initial identification to remediation.
You can first scan your systems to see if they’re in compliance with policy and their software is up-to-date. You’ll receive a report telling you the status of your infrastructure. Figure 4 shows an example of such a report. It shows the status of the servers in a network, in terms of how well they meet compliance requirements.
.png "Example of a Compliance Report")
Figure 4 Example of a Compliance Report
Once you have the report, you can use the Chef DK to build your remediation and then test it locally before you deploy them to production. Chef DK contains all the tools you need to create and test your code.
After you’re satisfied with the changes, you can send them through the Chef Automate pipeline to deploy the remediation. The pipeline contains stages for testing your changes and making sure they work. Within the pipeline are two manual gates. One of them is for code review and the other sends the code to the release environments. You can involve compliance and security officers at either or both of these points to make sure they’re actively engaged in the release process.
Finally, when the changes have passed all the stages in the pipeline, you can send them to the Chef server. The Chef server can then begin to bring the nodes up-to-date. Chef Automate gives you visibility into everything that’s happening in your infrastructure once the changes are deployed.
Automating Compliance with InSpec
One of the largest banks in India has begun using InSpec in its Banking Services division, which is responsible for most of the bank’s transactions. Compliance is particularly critical for it. The division has approximately 500 HP-UX servers that make up its development, test and production environments.
Of course, there are many regulatory and security guidelines the bank must follow and each month the team checks to make sure its servers are compliant. There are around 100 checks and, before InSpec, they were performed manually. The process was very difficult. The team had to log in to each machine, check the configuration settings, provide the results on paper and then log them. Completing a single check took about 5 minutes, so vetting just one server took about 8 hours.
When the team began using automated compliance with InSpec, the impact was evident. It could see the entire scan result in minutes. The team could see how many servers were in compliance, how many weren’t in compliance, and based on that it could make quick decisions. What had taken 500 minutes to perform on one server what could now be performed in 2 minutes.
InSpec also made it much easier to satisfy the bank’s auditors. IT auditors sometimes asked to see the status of a particular machine and retrieving the information was slow. Team members had to run scripts manually, get the output and make it suitable for a report. Now, with a single click, the team could instantly show the auditor what checks have been performed.
Also, InSpec is human readable and easy to learn. Most vendors for security and auditing use a binary format and the tools are difficult to use. When the banking team members saw InSpec, they felt that they could easily learn it within a few days because the learning curve was very small. (You can read about this on the Learn Chef Web site at bit.ly/2mGthmE.)
Wrapping Up
InSpec is an open source testing language that lets you treat compliance as code. When compliance is code, rules are unambiguous and can be understood by everyone on the team. Developers know what standards they’re expected to meet and auditors know exactly what’s being tested. With InSpec, you can replace documents and manual checklists with programmatic tests that have a clear intent.
You can also integrate your compliance tests into your deployment pipeline and automatically test for adherence to security policies. Run tests as often as you need, start testing for compliance on every change and catch problems earlier in the development process, well before you’ve released to production.
Michael Ducy is director of Open Source Product Marketing for Chef Software. He’s used, managed and advocated for open source software for almost 20 years. Ducy has held a number of roles in technology from Linux systems engineer and IT instructor, to presales engineer and more. He’s always interested in engaging with the broader community and can be found on Twitter: @mfdii.
Thanks to the following technical experts for reviewing this article: Bakh Inamov, Adam Leff and Roberta Leibovitz