Automating STIG Compliance and Reporting with Puppet

As a long-time soldier on the Information Assurance battlefield, I am all too familiar with the burdens of security and compliance, not to mention the conflict they can present in maintaining system operations.  As a leading partner with PuppetKinney Group, Inc. has developed a solution to improve operational security posture while dramatically reducing the time and effort required to achieve compliance and produce required documentation.  Automating security compliance, exempting nodes from enforcing security policy as needed, and on-demand, up to date, customized STIG checklistswhere has this been all my life? 


Check your STIG Boxes with Puppet 

Puppet is a configuration management tool used to automate compliance with regulatory requirements.  In the Department of Defense (DoD)the Defense Information Systems Agency (DISA) provides the Security Technical Implementation Guides (STIGs) as the security standard.  Deployed systems are configured in compliance with the STIG, after which the system Identity and Access Management (IAM) must document the security posture of each system against this standard using the STIG checklist.  The STIG checklist is an eXtensible Markup Language (XML) document that records the state of each finding from the applicable STIG. It also includes any mitigation or additional details the approval authority might need to certify and accept the system for operations.  The checklist file is included in the accreditation package for security certification and approval to operate. 

Typically, site system engineers and administrators perform the security hardening through some combination of manual and automated methods.  This can be a labor-intensive process, and the results are often inconsistent depending on the level of expertise of the staff performing the task.  DISA’s automation tools will audit the status of findings, meaning they stop short of making corrections.  In addition, the DISAprovided automation is incomplete, leaving around 30% of findings to be manually reviewed. 

The second half of the security accreditation process is the required documentation. A Java-based graphical tool creates the STIG checklists.  The IAMs often rely on inputs from the administrator that performed the security hardening to complete the checklist.  Sites often resort to keeping a master spreadsheet of findings and mitigations, which they then copy and paste into checklists as needed.  It’s also common simply to create a single checklist and copy it for each system to save time.  This process is very timeconsuming, but taking shortcuts often results in inaccurate documentation and defeats the purpose of the accreditation process. 

New call-to-action

The New Solution for STIG Compliance 

There are several solutions in the marketplace that offer automated security hardening in compliance with the STIG.  While some users may be able to assess compliance and even remediate the security findings, Puppet automation is uniquely suited taddress both the compliance and the reporting use cases.  The KGIdeveloped STIG implementation for RHEL7 can configure a system to implement security as the STIG requires.  With proper Puppet server infrastructure, managed nodes not only apply the required security but maintain that security posture, automatically correcting “configuration drift” that happens as systems customarily change over time. 

This is accomplished by deploying custom Puppet modules developed by KGI that apply configurations to meet STIG requirements. When these modules apply configuration and remediate drift, that activity is logged by Puppet. A key feature of the compliance Puppet modules we develop is allowing exceptions. This is where individual vulnerabilities are skipped or not, applied to a single node or a subset of nodes. Our modules are designed to log this exception information when Puppet runs as well. Another component key to the Puppet solution is “puppetdb, a database that stores the configuration state as reported by every managed node.  This database can be leveraged to dynamically build the STIG checklist files on-demand, using near real-time data from the latest run of the Puppet agent. 

The following is terminal output from a utility generating a STIG checklist file using a combination of outputs from the latest Puppet catalog and reports for the given node, as stored in puppetdb.  This report took about four seconds to generate and automatically populated nearly 250 security findings from the STIG.  Note that the output below has been truncated so we don’t have 250 open/closed/excluded records here:  



Locating certificates for puppetdb authentication 

Obtained latest report for node: 

Lookup for catalog with uuid: 749fdd6e-9d8c-4f56-b8ca-d6d9a9995fd6 

Found catalog with uuid: 749fdd6e-9d8c-4f56-b8ca-d6d9a9995fd6 

Obtained OS facts for the node 

Obtained the list of assigned STIG classes 

Obtained networking facts for the node 

Result Summary: 


Vul-ID: V-204427 is closed 

Vul-ID: V-204424 is closed 

Vul-ID: V-204429 is excluded 

Vul-ID: V-228563 is closed 

Vul-ID: V-228564 is open 

Vul-ID: V-204617 is closed 

Vul-ID: V-204608 is open 

Vul-ID: V-204499 is closed 

Vul-ID: V-204579 is excluded 

Vul-ID: V-204418 is closed 

Vul-ID: V-204419 is open 

Vul-ID: V-204578 is closed 

Vul-ID: V-204470 is closed 

Vul-ID: V-204471 is open 

Vul-ID: V-204472 is open 

Vul-ID: V-204473 is open 

Vul-ID: V-204524 is closed 

Vul-ID: V-204525 is closed 

Vul-ID: V-204608 automation data is being overridden 

Applied overrides from custom YAML 


Checklist saved to: ~/checklists/rh7.example.com_2021-02-01.ckl 


The KGI Puppet STIG Module in Action 

Here are some examples from the generated checklist file as seen from the DISA STIG Viewer application.  The first example is a STIG finding that is marked as Not Reviewed because the corresponding Puppet class is not assigned to the node.  The KGI Puppet STIG module is written in such a way that it is easy to exempt findings as needed for a single node or group of nodes.  This allows for flexibility to balance security compliance with operational requirements that may conflict with specific findings.  In this case, the node is exempt from enforcing the finding, and we can see that the comment reads “Puppet class not assigned.  

Figure 1 - STIG finding what is marked as "Not Reviewed"
Figure 1 – STIG finding what is marked as Not Reviewed – comment reads “Puppet class not assigned”

This next example shows a finding that was determined to be closed.  A closed finding is one that has the corresponding Puppet class assigned in the catalog, but the latest report from the agent has determined that no resources were required from the assigned class.  The status is “Not a Finding, and the comment contains the note “Enforced by Puppet class assignment. 

Figure 2 - STIG finding what is marked as closed
Figure 2 – STIG finding what is marked as closed – comment reads “Enforced by Puppet class assignment”

An open finding will have more detail as to why it is open.  From a Puppet perspective, these are the resources that needed to be applied during the last Puppet run.  In this case, the system did not detect a virus scanner, so a “notify” resource was applied.  The complete Puppet resource information is populated in Finding Details, and the comments contain the message “Identified by Puppet class assignment. 

Figure 3 - System did not detect a virus scanner, so a “notify” resource was applied
Figure 3 – Notify resource was applied when system did not detect a virus scanner- comment reads “Identified by Puppet class assignment”

This solution will save you hours in producing STIG checklists for the security accreditation process (and it’s super cool).  But what if youre mitigating findings outside of the standard STIG prescribed methods?  Do you need to go into the checklist file(s) and update them with actions local to your site?  If you were paying attention to the last couple lines of the report, you may have noticed that “automation data is being overridden.  The reporting tool allows the automated finding data from Puppet to be augmented as needed from a source outside of Puppet.  A previous site where I worked used VMware LogInsight (you could also use Splunk) to forward log events instead of the STIG prescribed “rsyslog.  Because of this, we would mark the related findings as closed because we were implementing the security requirement with a method other than the default as assumed by the STIG. 


Stay Tuned!

In an upcoming blog post, we’ll cover the integration of the Puppet security solution with Splunk to provide visibility and analysis of the secure Puppet environment. 

For more information or for help getting these kinds of results at your site, fill out our form below: 

New call-to-action