We’re unpacking the differences between the Center for Internet Security’s CIS Benchmarks and the US Department of Defense Systems Agency (DISA) Security Technical Implementation Guides (STIG).
Previously, we discuss the anatomy of a baseline and gave a first introduction to free Lockdown Enterprise content.
Quick recap: STIG and CIS are the two primary third-party baselines adopted across public and private organizations. Even when you’re required to adhere to an industry standard (NIST 800-53, CMMC, PCI, HIPAA, etc.), using a baseline like STIG or CIS is a great starting point.
First the good news: they’re both similar, and for good reason—there are only so many ways to configure a system for security.
Public Sector and Commercial Adoption
STIGs tend to slant toward US Government requirements. Read the contents, and you’ll see that for documents are littered with callouts to the Defense Information Systems Agency (DISA) and other US Government agencies. They also include specific US Government-mandated language for things like login prompts, etc. Just because STIGs are usually targeted to the government doesn’t mean that they can’t be used by the private sector as well. Many commercial and even foreign governments rely on STIG guidance because of the inherent trust and respect they have for the STIG’s heavily researched and reviewed guidance. It’s important to note that STIGs often are defined with significant input from the vendors.
It should come as no surprise that CIS baselines are more common in commercial organizations, but in fact, they’re also used in many US Government civilian agencies. They are also heavily peer-reviewed, and member vendors participate in the CIS control creation and validation process.
Operating systems and Applications Coverage
For some, it may be a surprise to learn that there are also baselines for applications as well as operating systems. Both STIG and CIS offer coverage for modern operating systems like Red Hat Enterprise Linux, CentOS, Ubuntu, Amazon Linux, Microsoft Windows Server 2016 and 2019, as well as desktop platforms such as Windows 10 and MacOS. They also address popular infrastructure software and platforms, including Cisco and VMware, and key infrastructure service layer components such as Active Directory, Apache httpd, IIS, and BIND.
There certainly are differences, however. Running the popular web and reverse proxy server NGINX? CIS has a benchmark for that, but you’ll need to read into and apply the generic DISA Security Requirements Guide (SRG) for web servers(zip). The same goes for AWS, GCP, and Microsoft Azure. CIS has defined benchmarks for each of those platforms, but DISA has the more generic Cloud Computing SRG. There are also many notable examples beyond these where DISA has a STIG, and CIS does not. For instance, IBM WebSphere(zip), Red Hat JBOSS, and F5 BigIP all have STIG content, but no corresponding CIS baseline.
There’s something to be said about a research-based and purpose-written content for a specific platform and application. However, DISA’s use of more generic guidelines, makes it easier to apply these baselines on custom applications which may integrate some of these common components.
For our own engagements, we’ve used the common approach to use what is available. A customer might be largely STIG-based but is also running Apache Tomcat. In that case, we’ll use the STIG for the platform, but the CIS benchmark for Apache Tomcat.
File formats and Tooling
This is probably where STIG and CIS diverge the most. STIGs are primarily offered in XCCDF, an XML-based file format. Unless you really enjoy reading over XML, you’ll need an XML parser, or more ideally, an XCCDF viewer. Luckily, there are a number of XCCDF readers out there, and even DISA has created and publicly provides one aptly named STIG Viewer. Providing a machine-readable document does make it much easier to begin automating aspects of a STIG application.
CIS benchmarks, on the other hand, are available primarily as PDF documents. They have a toolset called CIS-CAT that is available in both a Lite (assessment only) and Pro (assessment and remediation, and customization, amongst other things). This tooling understands XCCDF files, but those files are only accessible/exportable to paying customers of CIS.
While researching this subject, you’re likely going to come across other terms. The most common one you may see is Security Content Automation Protocol (SCAP). Unfortunately, this doesn’t mean that a SCAP tool will magically force your systems into compliance. XCCDF is the file format SCAP uses. Another term you will likely come across is the Open Vulnerability and Assessment Language (OVAL), which is another machine-readable document format used for enumerating vulnerabilities and is meant to be easily digested and integrated with reporting tooling.
Cost of STIG vs CIS
Access to the STIG content is free, including the information, formats, and much of the tooling needed to automate the validation (and partial remediation) of systems and applications.
Access to CIS PDF documents is also free, but using the official content requires a relatively significant effort of manually walking through the PDF documents and parsing them into something machine-readable. Of course, a CIS membership drastically eases that pain and energy, and enables some remediation capabilities, too.
There is also a myriad of third-party tools that help with both STIG and CIS application, including many pre-built OS images in common cloud platforms that already have the baselines applied. Pre-built images are a quick way to ensure you deploy a compliant operating system but may cause issues longer-term due to differences in how those baselines are applied vs. how they’re handled in on-prem and development environments. Additionally, there is no built-in way to track drift, so once apps are installed and patches applied, it’s highly likely the pre-configured base image will no longer be compliant in key areas.
Automate validation and remediation
Manually applying baselines is painful, not scalable, and generally unsafe. But sometimes, there’s just no way around it.
Baseline automation tooling needs to be selected based on several criteria. An ideal tool should:
- Be used to deploy compliant systems.
- Be used to validate existing systems.
- Remediate existing systems.
- Easily toggle controls or control classes on and off.
- Plug into existing CI/CD pipelines.
- Plug into existing management tooling.
- Be trusted and usable by security AND operations teams.
It also might be more than one tool, so long as they integrate well together.
Thankfully, both CIS and STIG can be readily automated using both commercial offerings, services, and both vendor-provided and open source tooling. Vendors have also stepped up and provided their automation content in common formats, such as Ansible. In some cases, those have also then been provided back to DISA for distribution.
Tools to scan and validate the baseline application are plentiful. However, few of these scanning tools also remediate findings. Even fewer do so based contextually on the application running, and in a continuous basis through the lifecycle of a system. And again, even fewer can be easily integrated into deployment and maintenance pipelines.
Full disclosure: we also have a bunch of Ansible automation content to help you deal with both STIG and CIS. You can get free access to this content that enables your organization to save time and resources.
Selection: STIG vs CIS
Now that we’ve gone into a bunch of details about your best options, what is the best course of action? If you were expecting us to hand over a definitive recommendation, sorry! We believe that both STIG and CIS do excellent jobs of defining secure system configurations. However, we do have guidance that will help lead you to the best decision for your organization.
Voluntary vs mandatory
Some industries, such as the US Government and related systems integrators are required to abide by a specific baseline—usually the STIG. If your industry is beholden to some other higher-level standard (NIST 800-53, CMMC, PCI, HIPAA, etc.), you likely have more latitude to select a differing baseline as you meet the requirements contained in your framework.
Organizations and environments that are not specifically required to meet an industry standard have more flexibility to select the one that makes the most sense, or for which the tooling fits in well with existing management technologies.
What fits your existing tooling best?
The out-of-the-box tooling for the two primary baselines varies enough that it’s likely one baseline over the other will stand out. Be mindful of the six key points of an ideal tool that we listed above.
What has the best coverage?
Most organizations have a wide enough variety of technologies such that one baseline provider is unlikely to provide 100% coverage. Even in situations where you’re mandated to use a specific baseline, it may be necessary to use a different baseline to ensure coverage.
STIG vs CIS: Which one works for your teams?
If you’re in operations, there’s a good chance that you feel the security team is largely antagonistic to your objectives. Is there a specific baseline that helps your teams to feel more comfortable? Is there a specific set of outputs that other teams need to see? Are you able to work with your counterparts to discuss specific requirements?
Getting started
No matter where you are in your cybersecurity journey, baseline automation is a key part of your security posture. Our product, Lockdown Enterprise is 100% Ansible Role content that will:
- Automate STIG and CIS validation and remediation
- Enable continuous baseline management
- Save you tremendous amounts of time
The best part is, you can now download this content for free.
Related Products and Services
Automation Counselor >
Security Automation and Engineering >
Governance, Risk, and Compliance >
