9. Automated InSpec Testing

Sumaa SayedMay 22, 2022About 2 min

9.1 Automated Validation Tests

Now that we have written up some Check and Fix text, it's time to use one of Vulcan's other features -- the InSpec code pane.

9.1.1 The InSpec Control Body

Click on the InSpec Control Body tab in the requirement window.

You'll see a code editing window directly in Vulcan. At present there isn't much to see inside of it. We should fix that.

Wait, what if I have no idea how to write InSpec code?!

Great news, we have an in-depth training class on how to do this (two of them, actually).

But if you don't have the time for those, don't sweat it; we just want you to know that this is something you can do with Vulcan.

Let's add in a few lines of InSpec code. You can write your own, or borrow from the below.

describe parse_config_file('/etc/security/faillock.conf') do
  its('fail_interval') { should cmp <= 900 }
end

Go ahead and copy that code block and paste it into the editing window.

Note

If you have taken the SAF User class, you have used inspec exec to run code that looks like the above against a target system.

Save the requirement.

Now check the "InSpec Control (Read-Only)" tab. It has used the contents of the other two tabs to assemble a completed InSpec control from your requirement, including the complete context of your STIG control as metadata tags in the test.

We can export this content and start using it immediately if we wish (we'll discuss how in a later section).

9.1.2 Why am I writing test code inside Vulcan?

Vulcan includes the ability to write InSpec control code right alongside original guidance because we need a tight binding between the human-readable guidance and the machine-readable automation code.

Using Vulcan will ensure that all of your guidance is included in your test code as metadata (you can also do this by creating a profile stub with the SAF CLI.)

You can think of this process as recording the pedigree of your tests into the code, so that you dont lose it as your code moves down the pipeline, and so that you always know why you are running a check.

Furthermore, another reason we added the InSpec control editing window is because in most cases, you are writing security guidance because you want to write security validation code! Recall that the whole point of Vulcan is to help us define the security posture target so that we can automate reaching it!

If you've taken any other SAF classes, you may have noticed that a well-formed validation test's code will include tagging that aligns each individual test back to the baseline security document that required us to run it. The MITRE SAF tests in the validation library, in fact, include the exact text of the baseline document as tags and descriptions inside each test control. Therefore, Vulcan was built to automatically begin drafting an automated test as soon as we fill out our requirement details.

Do I need to use InSpec for my ATO process?

DOD does not and will not require teams to use any one particlar security validation tool.

MITRE SAF favors InSpec because it favors our use cases nicely, but there are many different security tools on the market, some of which are better suited to particular tasks.

In all cases, any test tool is better than no test tool.