-
Transcripted Summary
In this chapter, you will learn about InSpec profiles, which you can use to group your controls into compliance test suites.
After the introduction, we will see how easy it is, and we will create a compliance profile to support the PCI DSS industry standard.
Individual controls are grouped into an InSpec compliance profile.
Profiles organize multiple controls into a reusable artifact, which is more or less a compliance test suite.
Each profile is a standalone structure in a predefined directory.
Let's get started creating a profile.
We will create a profile which checks that a given system component is PCI DSS compliant.
# What is PCI DSS?
PCI DSS is the global data security standard for all entities that process, store or transmit cardholder data and/or sensitive authentication data.
PCI DSS is a security standard for organizations that handle credit card data and store them.
It is mandated by the card brands, but administered by the Payment Card Industry Security Standards Council.
It was created to reduce credit card fraud.
Control objectives describe 12 compliance requirements divided into six logically related groups so-called "control objectives".
Let's create a profile for an imaginary company called "Test Automation School" which offers online courses about test automation.
The online courses can be paid with PayPal and Credit Cards.
The security officer of the Test Automation School defined a set of IT and application controls to cover PCI DSS requirements.
Among others, he defined IT control SEC-41 to cover PCI DSS requirement 4.1.
Together with security specialists, he defined these three application controls.
Due to the fact that the Test Automation School has established a continuous compliance culture, these controls will be implemented as Compliance as Code.
# Control 1
According to the defined controls from the security officer, we have to cover three requirements.
Each of them will be defined as a single control file that we can reuse if needed.
Take a look at control number 1 as defined from the security officer.
"Only SSH two connections should be allowed."
Let's see how this could be implemented via InSpec.
The file name will be the name of the control, and the control name also.
As desc, we use the description defined by the security officer and as ref for the requirement, we use the PDF file name of the official PCI DSS document.
Now, we take a look at the describe blog which implements the test.
We will use the sshd_config resource to implement this test.
For our assertion, we use a universal matcher that checks that the protocol entry is equal to that's all - not more, not less, no rocket science.
# Control 2
Let's proceed with requirement number two.
We have seen how we'll use the file name, control name, and other metadata so now we will only talk about the implementation of the tests and the assertions.
What is control number two all about?
The compliance officer has defined that only secure ports should listen to incoming requests.
How can this be implemented?
This time we have two describe blocks.
For our tests we are using the port resource.
For port(80), we are using the should_not_be_listening resource specific matcher.
For port(443), we use again a resource specific matcher - in this case, we check the port(443) is listening.
For the same port, we define a second assertion which checks with a universal metric that TCP is allowed.
That's all. Let's jump to the last control.
# Control 3
Control three defines that the telnetd package should not be installed.
How can this be implemented?
We use the package resource for the telnetd package and check via a resource specific nature that the package is not installed.
Any questions? Any thoughts?
I think that you know how you can use resources and different types of matchers.
Let's jump to the next lesson and create a profile with control files to check our system for PCI DSS compliance.
Let's create our profile.
Open your terminal and navigate to the InSpecTAU directory.
First, delete the helloworld files since they should not be part of our profile.
The remaining three files are our control files.
Now, we create the directory structure and the required metadata files with the command:
inspec init profile sec41
sec41 is the name of the profile which we created.
InSpec has created the directory, sec41 with some sub-directories and example controls.
Delete the sample control with:
rm sec41/controls/example.rb
Now, we have a clear structure for our control.
In the next step, we have to define the metadata for our profile.
Therefore, open the inspec.yml file and change the content as follows.
name: sec41
title: InSpec Profile
maintainer: The Authors
copyright: The Authors
copyright_email: you@example.com
license: Apache-2.0
summary: An InSpec Compliance Profile
version: 0.1.0
supports:
platform: os
In the next step, we must move the control files to the controls directory and run a syntax check for the profile.
mv sec*.rb sec41/controls
Now, we run the syntax check for the profile with:
inspec check sec41
Here, you see that we have a valid profile.
The profile is valid, which means we should execute it against our target.
In our case, the target is the docker container with the Tomcat inside - check the Container ID with:
docker ps
Now we run the profile with the following command:
inspec exec sec41 -t docker://0d643ba6ec94
Well, now our profile confirmed that the Tomcat installation is not in the expected state as defined by the compliance officer, but this is another story.
We are at the end of this chapter - now you know all about InSpec profiles.
This was the last chapter in this InSpec course.
If you want to know more about InSpec as a tool, again, please take a look at the official website for the tool.
I hope you've enjoyed this InSpec course for the Test Automation University and I wish you happy compliance testing.
