Cracking the DISA STIGs Code: A Comprehensive Guide

We’ve talked a lot about FedRAMP, CMMC, and the typical business/contractor security controls outlined in NIST SP 800-171, but these aren’t the only elements of cybersecurity that the government wants enforced. There are also the DISA STIGS to follow. What are they, do they apply to you, and how can you follow them?

What is DISA?

First, let’s talk in brief about what DISA is. DISA stands for the Defense Information Systems Agency. Named in 1991, it was formerly called the Defense Communications Agency, which was founded in 1960.

DISA is a support agency for the Department of Defense. They’re the critical information control backbone for the US Government, from the President all the way down to subcontractors working for the DoD.

DISA controls a vast swath of communications and information used throughout the federal government and its agencies, so they take security very, very seriously.

What are the STIGs?

STIG stands for Security Technical Implementation Guide. DISA produces STIGs as a way to set the baseline computer settings necessary for a piece of hardware or software to be considered secure for use in the government information system.

Think of it this way. The government needs its systems to be secure for use. It can achieve this by The world of government information security is a warzone.

There may not be warplanes circling overhead, but there’s a near-constant barrage of cyberattacks, both from small-scale hacker groups and nation-state adversaries. Protecting national security involves maintaining aggressive and thorough information security standards and engineering those systems itself, or by using off-the-shelf, third-party, or bespoke systems.

Since the government doesn’t want to spend time and money reinventing the wheel, it often designs to use commercial off-the-shelf hardware and software – this is also known as “COTs” products. Large portions of the government operate using Microsoft Windows, others use Linux or OSX, different groups use Android or iPhone devices, and so on. Further in the infrastructure, you also have to consider things like routers switching in networking and cloud services.

STIGs cover the settings and security for software applications and apps, cloud networks, mobile devices, operating systems, browsers, servers, routers, networks, and networking devices. In other words, pretty much anything that touches the information systems of the government is subject to a STIG.

There are thousands of STIGS that have been created and maintained by DISA. These cover everything from ancient and outdated software that could still be in use and shouldn’t be in use, but was in the past, all the way to modern and newly-released software and hardware that the government might want to adopt.

STIGs can also cover not just individual software and hardware, but the interplay between them. Complex STIGs cover whole network configurations, and may have overlapping requirements.

What Does a STIG Look Like?

To see what a single STIG looks like, you can use tools like STIG viewer or Ignyte Scap data viewer. Here’s a list of STIGs. To pick a common one, here’s the viewer page for the STIG for Google Chrome. All of this information is also available directly from DISA via the DoD Cyber Exchange here. You can also download the compilation file of all currently enforced STIGs here.

You can see that this STIG is made up of 33 individual findings, of which two of them are low priority, 29 are medium priority, and two are high priority. You can also view each STIG specifically using Excel, JSON, or XML formatting.

What are the priorities? Priority, or compliance level, is the level of severity and attention that must be given to that particular finding in a given STIG. The category of a finding refers to both how severe the potential damage that can be done if the setting is incorrect and is used against the government, and to how likely it is to be attacked.

• Category III findings are the lowest severity and lowest priority. Using Google Chrome as an example, a Category III finding is to block third-party cookies. A third-party webpage tracking user activity from a DoD contractor isn’t exactly a compromising threat to national security, but it’s plausible that in an extreme circumstance the information could be used against an individual or agency, so it’s part of the in general hardening process. Category III vulnerabilities can lead to Category II damages.
• Category II findings are the middle priority and are usually where most findings are categorized. They are more potentially exploitable and more potentially damaging than Category III findings. For Chrome, an example is the built-in password manager must be disabled. This is because a malicious site could use an invisible form to exploit the password manager’s auto-fill feature to steal information. While good security processes including multi-factor authentication can prevent that password from being used against the agency, it’s still a severe breach. Category II vulnerabilities can lead to Category I damage.
• Category I findings are the highest priority. They are the most potentially devastating if they are breached, and are consequently the most likely to be attacked as well. For Chrome, an example is that the ability to run outdated plugins must be disabled. This is because as security standards advance, outdated plugins can become vectors for complete compromise of a system. These findings can lead directly to data breaches and are thus the highest priority for attention when a new system is being set up and a STIG applied.

The raw data of the STIG provides an ID for each individual check, along with descriptions of what the security control is, why it exists, and how to ensure it’s in force. Specific instructions on how to configure a system are provided when possible.

With nearly 350 current STIGs per checklist for a wide range of software and hardware, it’s an understandably daunting task to identify which apply to you and how to implement them.

When Do STIGs Apply?

STIGs apply to any piece of software or hardware used by the DoD, any federal or governmental agency, or their contractors. Any time a piece of software or hardware is to be used, whether it’s a networking device, a cloud service, or an operating system, a STIG needs to be enforced.

This means that any time the government wants to adopt a new technology, invest in new computer or networking hardware or software, or pick up a new program, that app or device needs to have a STIG developed for it. This is a complex and ongoing process that DISA is continually performing. If a device manufacturer or software developer wants to make their product available to the government, they can also apply to have a STIG created.

STIGs also need to be monitored and updated. DISA releases updates to STIGs across the board every quarter, along with additional emergency updates in the case of major issues or emerging threats, like supply chain compromises or the discovery of zero-day exploits.

In times where old software or hardware is made obsolete, a STIG may be deemed no longer relevant to keep updated, because the software or hardware either should not, is not, or will not be used. But, these STIGs are still kept around as “sunset STIGs”, for historical record and for the rare case where a specific old device or app needs to be used, but momentarily.

Who Needs to Comply with STIGs?

If you’ve spent any time looking at the requirements to achieve CMMC certification or obtain a FedRAMP authority to operate, you might already be looking at months of work and a long, convoluted, and complex process of auditing, verification, documentation, and compliance. It’s already an immensely daunting task. To then find out about STIGs, that there are nearly 350 of them per checklist, and that each one can be made up of dozens or hundreds of specific controls – which need to apply to every instance of a program and every individual device – can be heart-dropping.

Fortunately, three things make this a less daunting task than you might worry.

The first is that STIGs are not necessarily required, and there are different levels of implementation depending on your Mission Assurance Category. Usually, STIGs are required of DoD and other federal government agencies, and defense contractors themselves, but are less maybe required from third-party contractors. Some STIGs are becoming increasingly part of other frameworks like CIS Benchmarks, NSAs Hardening guidelines, but that’s convergent evolution; basically, the standards are the partially duplicated across both, so rather than implement two identical standards to maintain, agencies like DISA and NIST are working together to maintain one guideline.

Your Mission Assurance Category also defines how strict the STIGs need to be followed, what auditing is involved, and in some cases, variance in what the STIGs control. Though MAC Levels are not used for controls assessment – they are still maintained for STIGs. From lowest to highest priority, the MACs are:

• MAC III: Administrative, Sensitive
• MAC III: Administrative, Public
• MAC III: Administrative, Classified
• MAC II: Mission Support, Sensitive
• MAC II: Mission Support, Public
• MAC II: Mission Support, Classified
• MAC I: Mission Critical, Sensitive
• MAC I: Mission Critical, Public
• MAC I: Mission Critical, Classified

Determining where your systems fall in priority is an important matter, but is also primarily focused on Department of Defense Information Networks rather than third-party contractors, except for Defense Contractors maintaining systems with government information
.

In other words, while some STIGs can help you achieve a baseline of security necessary to achieve compliance with frameworks like CMMC or FedRAMP, others are not necessary. You don’t need to blindly implement every single STIG that could possibly apply to your systems (and in fact should not, as they can harm accessibility of information and even jeopardize some compliance auditing.)

The second is that STIGs are almost entirely technical in nature. They refer to configurations of software and hardware settings and their interoperability. They do not usually refer to things like business processes or employee behavior. Some STIGs that apply to the DoD do, but for the most part, they are entirely centered around settings and configurations.

This has three effects:

• The first is that it makes them security Framework and business agnostic. It doesn’t matter what business you are or what your purpose is, if you use a particular kind of Cisco router or iPhone, it the STIG for it is the same, regardless of how you use it.
• The second is that it’s much easier to actually implement the controls. You don’t need to spend time auditing  system specific procedures and user behavior, implementing and documenting employee use of systems, and all the other messy human elements. You need to go into configuration files and set specific settings, and that’s it.
• The third is that STIG compliance can be automated. There are many companies, like Titania, Puppet, SolarWinds, and others, that offer automated STIG compliance tools. Here at Ignyte we integrate the well known SCAP scanner into the controls workflow. Whether you use a third-party tool or simply develop your own implementations using tools like Group Policy, it’s easier to manage when you can, for example, put every computer on your network into a single group and push a setting to all of them from a central control, rather than having to tweak each device individually.

A good automation system will audit and evaluate the settings of the devices and software that needs to comply with STIGs, monitor them for changes, push the appropriate settings, and generate logs of activity and changes on a continual basis.

What Happens if You Don’t Comply with STIGs?

Noncompliance with STIGs standards can lead to have a variety of issues.

Unlike administrative controls, STIG apply technical controls that can prevent your system from easily getting breached. Failure to apply certain STIG will significantly increase the chances of your computer system getting breached.

If you are a third-party contractor and not part of the general DoD’s internal network, you are usually not actually required to comply with STIGs. You may have to comply with other  hardening standards like CIS benchmarks, but a STIGs audit won’t be useful, and failing that audit won’t be meaningful.

If you are an agency or company that is required to comply with STIGs, noncompliance can result in penalties including heavy fines, intense auditing and scrutiny through CCRI or DCSA Audits, and potentially the loss of contracts.

Individuals responsible for STIGs compliance can face stiff professional backlash themselves within agencies. In the most extreme cases – particularly if an actual breach occurs and information is compromised – there can even be more extreme penalties.

Obviously, you don’t want to get on the bad side of the Department of Defense.

Fortunately, STIGs are usually “easy” to adhere to, particularly since they can be automated and monitored. It’s a far cry from the more people-focused processes in other forms of DoD compliance. That’s why Ignyte Platform is focused on those more complex systems; STIGs can be done in a thousand different ways, but frameworks like FedRAMP and CMMC need a different kind of attention. Attention we can provide. Get in touch with us today!