More Profiles

InSpec has a solution for this in the form of a profile function: Many InSpec tests can be combined as a profile and then run together. The highlight of this method is that it is easy to build an InSpec profile (Figure 2) from a collection of InSpec tests. Assuming InSpec is installed, the following command is all you need to get started:

inspec init profile lm-example --overwrite

Figure 2: A simple description for a profile in InSpec that can be executed in the block on servers.

The command creates a new profile in the lm-example folder. The --overwrite parameter used here ensures that InSpec overwrites any existing files and must therefore be used wisely.

Two subfolders, controls and libraries, can be found in the folder as well as the README.md and inspec.yml files. First, move your tests to the controls folder. Second, ensure that the name of the file ends in .rb. The _spec string does not need to be part of the file name because InSpec identifies tests without it.

Third, edit the self-explanatory fields in the inspec.yml file. Here, you assign a name, a description of the profile, and a license statement. Once that has happened, the check command below can be used to verify the syntax of the profile and the tests (it needs to be executed from the parent directory). If no errors appear, the profile is then executable with the exec command (Figure 3):

inspec check lm-example
inspec exec lm-example

Figure 3: If you run exec against an InSpec profile on a system, all tests are performed only once.

Incidentally, it makes sense to manage your InSpec profiles in a Git repository. On the one hand, you can use Jenkins for a smart approach to installing the profile (see the "Combining InSpec with Jenkins" box), on the other hand, you have a meaningful version management option.

Combining InSpec with Jenkins

Compliance tests are all well and good, but InSpec is only really efficient if administrators can automatically examine their systems on a regular basis. The advantage of InSpec is that it can be called from any host and uses SSH to connect with other hosts and run tests. This property means that it can perhaps use an existing Jenkins instance: An appropriately configured InSpec can in fact be launched automatically by Jenkins. You just need to create a task in Jenkins that initially checks out each InSpec profile of the central Git directory and then calls InSpec to reel off its tests.

What's more, InSpec can change the output format using the --format parameter. For example, --format junit tells InSpec to output its test results in the JUnit format, which is precisely the format in which Jenkins expects its test results so that it can process and analyze them (Figure 4).

InSpec launches a workflow constructed in this manner on the target systems and stores the results of tests so that Jenkins can process them. Jenkins then informs you about failed tests in the web interface. If you want, Jenkins and InSpec can be combined with your monitoring system to field alerts automatically when InSpec compliance tests fail.

Figure 4: InSpec can easily be integrated into Jenkins with the JUnit format.

Connection to Other Servers

The finished InSpec profile raises another question: How is it possible to run the tests included in the profile on other computers – ideally via the SSH protocol? InSpec itself provides a solution: The -t parameter tells InSpec to run the tests on a different host.

The tool expects you to state a complete login parameter for the target (i.e., for an SSH connection, e.g., ssh://mloschwitz@server2). If you prefer to use root instead, you can continue doing so in InSpec. It is only important that the selected user can log on to the other host via SSH and that they can become root on the target system.

If, for security reasons, you do not want to work directly as root, InSpec gives you the option of using sudo: The --sudo and --sudo-password=<secret> parameters ensure that the InSpec user first runs the sudo command to become root before running tests against the remote system.

Tests as per Specification

Up to this point, you will have gathered that InSpec is a powerful tool whose directives are suitable for almost any type of testing. Once you understand InSpec and its basic functionality, you will be asking yourself other questions: What are the parameters for which you as an administrator should now test an existing system? Are there any requirements in terms of compliance that describe a meaningfully configured system? The answer is, as is so often the case, "yes and no." Compliance is a specific matter, but there is a baseline of best practices.

Basically, the following applies: If a company has a compliance certificate, such as the previously mentioned ISO 27001 or the BSI Baseline Protection Certificate, those rules specify the line of approach. You first need to check the requirements defined for your systems if you want to test for compliance with InSpec.

If you do not have such requirements or are interested in additional sources of knowledge, you can pick up various "benchmarks" from the Center for Internet Security (CIS). Using Ubuntu 4.16 [7] as an example, the experts establish rules that harden the system. Contrary to what the name suggests, the authors of the document have not tested Ubuntu or other distributions for implicit security. In this case "benchmark" means that you can implement the rules described in the document, and the total number of criteria will ultimately give you a score for the respective system. However, not all of the criteria in the book have an effect on the score.

Unfortunately, you will find only a few prebuilt compliance testing collections for InSpec online that implement, for example, the CIS recommendations. If you want to check your Ubuntu systems for compliance according to CIS recommendations, you need to package the tests from the CIS benchmark that are relevant for your operations as InSpec tests.

If you don't have much time, you will hardly be able to implement tests for the entire CIS document for Ubuntu (Figure 5): It has more than 300 pages of various tests, and it documents the results expected and the justification for those results.

Figure 5: The Center for Internet Security provides benchmarks that illustrate how Linux systems can be hardened.