In the world of government-adjacent security and compliance, there are many different terms and acronyms you’ll encounter for the processes you have to perform. Often, these terms are interrelated in a single process, so you tend to learn them in clusters. One such cluster includes STIGs, SRGs, SCAP, and CCIs. What are these, what do they mean, and what do you need to do to utilize them properly? Let’s answer the most commonly asked questions.

What is DISA?

Before you can learn what STIGs are and the rest of the chain of acronyms, it’s important to know where they come from. That source is DISA, the Defense Information Systems Agency. DISA as an agency has existed in one form or another since 1960 but gained its current name in 1991.

DISA is one of many agencies that works in support of the Department of Defense. Their commands and regulations encompass a wide range of communications, from the humblest defense contractor all the way up to the president.

What does DISA have to do with all of this? Well, they are the ones who set the standards for how a computer system can be configured to be secure.

But wait, I hear you ask. Doesn’t NIST, the National Institute of Standards and Technology, set the standards? After all, it’s in their name!

The answer is yes, and also no. By “standards” we’re referring to a couple of different things. NIST sets broad details, like “there must be multi-factor authentication” or “you must meet X encryption standards” or “you need physical security for your servers.” DISA, meanwhile, develops specific sets of configurations on how to implement those standards.

For example, NIST might say, “Your business must use a secure web browser.” DISA says things like:

• Your browser must not run plugins that are out of date.
• Your browser must disable incognito mode.
• Your browser history must be saved.
• Importing saved passwords must be disabled.
• Autofill must be disabled.

All of this is developed by DISA and given a priority from low to high. All of those individual factors for a given app or COTS will be laid out in a STIG.

What are COTS?

COTS stands for Commercial Off the Shelf Software. We’ve already used a good example above: a web browser. The government, generally, doesn’t want to have to develop new software from scratch when there’s a perfectly acceptable version already extant. It’s why various government systems will run on Microsoft Windows, Apple OS, or Linux, rather than having to develop GovernOS.

Fun fact: some governments aren’t given this luxury. For example, numerous embargos prevent many commercial programs from working in North Korea, so they have their own operating system, Red Star OS. Even that isn’t entirely engineered from the ground up; instead, it is based on Linux architecture.

At the same time, the government recognizes that simply downloading a copy of Google Chrome is unlikely to leave you in a tightly secured and regulated environment. So, NIST demands that the browser be secure, and DISA sets the standards for what that means using a STIG. The items in the bulleted list above are all taken directly from the Google Chrome STIG. This STIG only has 33 items in it; some have many more.

What are STIGs?

A STIG is a Security Technical Implementation Guide. It is effectively just a list of settings and configuration options that need to be set, enabled, disabled, or otherwise configured in a COTS before it can be used by the DoD.

STIGs cover everything from operating systems and server systems to web browsers to PDF readers and more. There are hundreds of STIGs, though the number is kind of not representative because different versions of the same app have a unique STIG; for example, there are fifteen different STIGs for different versions of the Java Runtime Environment. There are also complex STIGs that cover entire network configurations and systems and include information that overlaps from different STIGs.

The STIG Viewer has a complete list of STIGs publicly available if you’re interested in seeing what they look like or looking up the STIG for an app you’re familiar with to see what it demands.

We’ve covered DISA and the STIGs code in greater detail in this post, so if they’re critical to your auditing or operation, give that post a read.

What are CCIs?

CCIs are Control Correlation Identifiers. What does that mean?

A CCI is basically a singular, defined, identifiable, and numerated security standard and implementation. They are effectively a midway point between conceptual standards like what is outlined in NIST documentation and the exact specific actions taken as outlined in a STIG.

The idea is that the CCI will be a slightly more generalized conceptual rule that nevertheless provides specific implementation instructions. This removes room for error that might occur if you’re trying to follow the rules just based on NIST outlines. It also removes confusion and enhances security as compared to working directly with a STIG that may not be quite accurate or completely up to date. With a STIG, if a developer changes a security setting, following the STIG isn’t possible; following the CCI is.

Fortunately, to prevent conflicts, CCIs are mapped to NIST 800-54 standard controls.

You can think of CCIs as a sort of translation process. They help convert a high-level conceptual mandate such as “use a secure browser” into the specific set of controls that need to be configured to accomplish that goal, usually alongside or in conjunction with a STIG.

What are SRGs?

Next up on the acronym chain is SRGs. SRGs are Security Requirements Guides.

To quote NIST:

“A compilation of control correlation identifiers (CCIs) grouped in more applicable, specific technology areas at various levels of technology and product specificity. Contains all requirements that have been flagged as applicable from the parent level regardless if they are selected on a Department of Defense baseline or not.”

An SRG is a compilation of CCIs, which in turn often reference or relate to STIGs.

So, at the top level, you have a security mandate from something like an executive order or specific guidance from the DoD. This mandate is translated into an SRG or, more likely, a series of SRGs. You may have, for example, an SRG for your operating system, an SRG for your network configuration, an SRG for your applications as a whole, and an SRG for your policies.

Each of these can further be broken down into other SRGs. An Application SRG can contain database, mail server, app server, and web server SRGs, depending on what that application uses and requires.

The SRG is made up of specific CCIs, which specify what it means to comply with the SRG. These are more specific directives but are still not so narrowly specific that they are single-application referential. For example, one CCI might say that you must “employ malicious code protection mechanisms at information system entry and exit points to detect and eradicate malicious code transported by email, email attachments, web access, removable media, and other means.” This is a slightly paraphrased version of CCI-001239.

Malicious code detection might then be completed by a firewall. So, you would then refer to the Firewall STIG to configure your firewall properly.

What is SCAP?

There’s one more acronym we’ve skipped so far, and it’s SCAP. What is SCAP?

SCAP is the Secure Content Automation Protocol. SCAP is a way to assess and automate a system’s adherence to SRGs.

If you’ve read all of the above as a software provider, you’ve likely drawn back already and decided that maybe DoD contracting isn’t for you. After all, it’s a ton of work, and there’s a lot of challenges involved. Consider:

• You would have to identify every SRG that is relevant to your system, figure out which CCIs are components of those SRGs, identify which STIGs mandate the implementation of those CCIs, and put all of that information to work. But, STIGs are updated every month if there are changes to the underlying system. Can you keep up with every bit of patch notes for every component of every application you use?
• What if you want to pick up a new technology and integrate it with your system? Can you? It’s quite likely that the new application or technology does not yet have a STIG.
• To even begin, you have to cross-check security information across at least three or four different government agencies and drill down into very specific, narrow data, hoping you’re correct.

All of these are challenges, and the government recognizes that. That’s why SCAP was developed. SCAP is a way to automate the analysis and adherence to these security standards. It does, primarily, two things.

The first is that it provides a centralized, authoritative, and maintained framework for analyzing complex systems as automatically as possible. It may not 100% fit your system, but if it can relieve you of 80-90% of the burden, it’s an incredibly massive savings in time, money, effort, and risk.

The second is that it’s a community-contributed and community-maintained application. If another vendor uses technology and goes through analyzing that technology for SRG, CCI, and STIG applicability, that information can be added to SCAP so that if you choose to use that technology, you don’t have to repeat all of their work.

SCAP is actually two things in modern parlance. The first is the set of information outlined above; the second is as a broad name for tools that use that information. SCAP can take the form of checklists, but modern software allows for auditing tools that take those checklists and scan your existing systems for adherence to those checklists. In this way, you can relieve the burden of a significant amount of the security administration that would otherwise need to be done repeatedly, frequently, by hand.

What is SCAP V2?

SCAP V2 is the ongoing initiative to upgrade and update SCAP. Throughout the last few years, as SCAP has been used and explored more broadly, a number of issues and problems have come up. Some of them have been solved with iterations on the core SCAP program, which is currently up to SCAP 1.3. However, just as in application development, when a major milestone and version change needs to happen, the number increases.

SCAP 2 is continually under development. To join in the development and feedback process, you can join the SCAP community. A variety of links are available on the NIST page, which can be found here.

Who Needs to Care About Any of This?

There’s a lot of information above, but depending on who you are and what your role is in the greater governmental-industrial-contractor complex, it may fly entirely over your head. Who needs to be concerned with SCAP, SRGs, CCI, STIGs, and all the rest of it?

The entire process, shortcutted to SCAP, helps enterprises and government contractors ensure cybersecurity. It’s a fast and streamlined way to cut a huge amount of work out of vulnerability assessments, and it dramatically simplifies the process of obtaining and maintaining compliance in a world with rapid technological evolution and changing standards.

It’s also a critical factor for contractors and related enterprises when they want to roll out a new system. Instead of needing to start at ground zero, you can check for existing STIGs and CCIs, figure out how it rolls into your SRGs, and use SCAP to review them automatically.

Make no mistake: all of this is quite confusing. It can be difficult to identify what, if any of this, you’re beholden to as a contractor or cloud service provider. Fortunately, you’re not alone. If you want to know what SCAP can do for you, or if you want a greater discussion of STIGs, CCIs, and SRGs, and how they apply to your business, you can feel free to reach out and talk to us directly. The Ignyte Platform includes a scan data module for SCAP auditing, so we’re well-versed in its application and functionality. You can learn more here or simply contact us for a demo.

*** This is a Security Bloggers Network syndicated blog from Ignyte authored by Max Aulakh. Read the original post at: https://www.ignyteplatform.com/blog/security/stigs-srgs-scap-ccis/