I chat with Aaron Lippold, creator of MITRE’s Security Automation Framework (SAF), to discuss how to escape the pain of manual STIG compliance. We explore the technical details of open-source tools like InSpec, Heimdall, and Vulcan that automate validation, normalize diverse security data, and streamline the entire security authoring process.
Episode Links
This episode is also available as a podcast, search for “Open Source Security” on your favorite podcast player.
It was a treat to finally sit down and talk with Aaron Lippold, the creator of MITRE’s Security Automation Framework (SAF). I’ve wanted dive into the world of STIGs and how SAF is revolutionizing compliance for a long time.
What is a STIG?
STIG stands for Security Technical Implementation Guide, it’s basically a hardening guide for a specific piece of software. These guides are written by the vendor, the company that creates the software also writes the STIG. The next question is “won’t they cheat?” They are based on documents called SRGs, or Security Requirements Guides, which outline more general security requirements created by Defense Information Systems Agency (DISA), so the vendors don’t get cherry pick only what they like.
STIGs are being talked about more than I’ve ever seen, I think due to FedRAMP specifically mentioning STIGs. It’s possible you’ll hear about them sooner or later.
The Traditional Pain of STIG Compliance
In the past, STIG was a ton of manual effort. It used to involve sitting down with a physical binder, hundreds of pages long, and going through a computer’s configuration, clicking here, checking settings there. It was pretty rough and took forever.
Aaron did explain why this was (I had no idea). STIGs were traditionally written for the worst-case scenario: imagine someone on a ship in a remote location with just a document and a terminal. The guidance had to be explicit enough for them. It’s not a use case most of us have to think about.
SAF will fix it!
This is where Aaron’s work with the Security Automation Framework comes in. He described SAF as an effort to unify the experience and knowledge around STIG (and other things too, but STIG was our topic). The idea was to consolidate this into a set of applications, practices, and procedures that help bridge gaps in the security development lifecycle.
The overarching goal of SAF is to take the entire process: the requirements, their validation, data conversion, and lastly visualization then make it more manageable. SAF aims to make security validation and STIG compliance repeatable and integratable into existing workflow and development processes (like CI/CD pipelines). Then making it all capable of continuous execution in operational environments. A key objective is to help organizations avoid starting from zero every time a new software version comes out.
Tools within SAF
We chatted about some of the tools in SAF that make the magic happen.
Heimdall: The Unified Security Data Viewer
The purpose of Heimdall is to normalize all this disparate security data into a common picture. This means you don’t have to jump between ten different dashboards to understand what’s going on. It’s designed to help make decisions based on the data, whether a failure is critical or acceptable within your risk tolerance. Technically, Heimdall can transform this normalized data into various formats, like spreadsheets for compliance officers, HTML reports for management, or the DOD favorite, checklists, for uploading to other government systems.
InSpec: The Validation Engine
The magic of InSpec, and how it drastically simplifies STIG validation compared to the old manual methods, lies in its abstractions. These are essentially Ruby classes that abstract the complex, low level interactions with a system. For example, there are resources for checking files, services, or kernel modules. Instead of figuring out the exact command to check a kernel parameter on Linux versus a registry key on Windows, you write a more logical human readable (mostly, it’s still pretty complicated) test in InSpec. And thanks to Ruby, it runs on nearly every platform out there.
Vulcan: Streamlining STIG Authoring
The biggest challenge of all (at least I think it is), is how do you write these InSpec rules, especially if you’re translating complex STIG controls. This leads us to Vulcan, another tool in the SAF suite. I’m impressed by Vulcan’s UI, which makes it incredibly easy to take STIG controls and turn them into something InSpec can parse.
You can leverage existing STIG work to make the process easier. Since many STIGs are derived from common SRGs, they often share common requirements. Vulcan allows an author when working on something like a new Red Hat STIG to easily see how that same requirement was addressed in a previous Red Hat STIG. You’re not starting from a blank slate.
Open source all the way down
The best part of SAF is it’s all open source. I pointed out if there were commercial tools that offer similar functionality, they would cost an enormous amount of money. MITRE is doing this work and giving it away, but it’s not just MITRE working in isolation and tossing code over the fence, it’s a collaborative effort.
Contributions come from individuals and from large corporations. Aaron pointed out many companies you might think of as competitors are cooperating on the tools. There are even international collaborators from countries such as France, the UK, and South Africa, and even from other governments. This collective effort helps to commoditize the solved problems in security, allowing the community to then focus its energy on new and emerging challenges.
Conclusion
This discussion with Aaron was incredibly insightful. The suite of tools within the Security Automation Framework – Heimdall, InSpec, Vulcan, and the underlying SAF CLI – represents a monumental step forward in making the task of STIG compliance feel like magic. It’s a testament to what can be achieved when the open source model is applied to security tooling.