Page 33 - MSDN Magazine, May 2017

Figure 1 List of Popular Platforms Supported by InSpec
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 exam­ ple, 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) bench­ marks for system security. While the CIS baselines provide a good starting point, you might need to modify them to meet your par­ ticular 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 directlymodifytheopensourceprofilesInSpecprovides.Youcan 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 auto­ mation 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 base­ line as defined by CIS, which is stored in a GitHub repo. Figure 3 shows an example of an InSpec run.
If you examine the results, the run shows that there are a num­ ber of configuration settings that do not meet the CIS baselines for
Figure 2 Example of InSpec with Metadata About Compliance Rules
Platform
Versions
AIX
6.1, 7.1, 7.2
MacOSX
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 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 com­ pletelist,youcanrefertotheInSpecdocumentationatbit.ly/2n3ekZe. YoucanalsoeasilyextendInSpecwithyourownresourcestocheck 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.
InSpec uses a client-server model, which means that you can audit remote systems from a centralized workstation.
Figure 2 shows an example of an InSpec rule that includes this information as metadata.
This example is for a rule (or control) called ssh­8. The impact, title, and desc fields define metadata that describes the rule’s impor­ tance, 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 con­ tains 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.
msdnmagazine.com
May 2017 29
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