STIGs, OSCAL and SBOMs

A good deal of security compliance is now exchanged as structured files instead of documents. Three kinds come up again and again: STIGs, which say how to configure a product securely, OSCAL, which describes controls and how a system meets them, and SBOMs, which list what software is made of. This guide explains each one at the level you need to open the file and understand what you are looking at.

How they fit together#

They work at different levels. An SBOM describes one piece of software. A STIG describes the secure settings for one product. OSCAL describes a whole system and the controls around it, and can point to the other two as evidence.

1. System LevelOSCALSystem security plans, control baselines, and assessment findings across the whole system.
2. Product LevelSTIGsConfiguration rules, checks, and fixes for specific operating systems, databases, and apps.
3. Component LevelSBOMsComponent inventories, library dependencies, and package versions for software.

What a STIG is#

A Security Technical Implementation Guide is a list of configuration rules for a specific product and version: an operating system, a database, a web server, a network device. Each rule says what to check and how to fix it. Systems on Department of Defense networks are expected to be configured to the STIGs that apply to them.

Related terms:

• A Security Requirements Guide (SRG) is the general version for a class of technology. A STIG applies an SRG to one product.
• A benchmark is a STIG in a form that scanning tools can run automatically.
• A checklist is a filled-in copy of a STIG for one machine, recording the result of every rule.

STIGs are public. They are downloaded from DISA’s cyber site at cyber.mil, and they are reissued several times a year. Always note the version and release you worked from.

Inside a STIG rule#

A STIG is an XML file in a format called XCCDF. Each rule carries the same fields:

Severity has three categories:

When a rule is reviewed on a real system, its status is one of four: open (the system fails it), not a finding (it passes), not applicable, or not reviewed.

Working with STIGs#

• Find the right ones. A single server usually needs several: the operating system, each major application on it, sometimes the container platform underneath.
• Search by any identifier. People cite rules by Group ID, Rule ID or STIG ID interchangeably. A lookup needs to handle all three.
• Read the check text before the fix text. Many rules are already satisfied by default settings.
• Record a reason for every exception. “Not applicable” and accepted “open” findings need a written justification that someone else can read later.
• Recheck after each release. Rule IDs gain a new revision when the text changes, so a rule you closed can come back altered.

What OSCAL is#

The Open Security Controls Assessment Language is a set of formats from NIST for writing security controls, system descriptions and assessment results in a form software can process. The aim is to replace the long word-processor documents and spreadsheets that compliance has traditionally run on.

The same content can be written as XML, JSON or YAML, and converted between them without loss.

The OSCAL models#

OSCAL is several related formats, called models, grouped in three layers.

Each file refers to the ones above it. A system security plan points to a profile, and the profile points to a catalog. To read a plan fully you need the files it refers to.

1. ResultsAssessment layerAssessment plans, assessment results, and plan of action and milestones (POA&M).
2. System PlanImplementation layerComponent definitions and system security plans (SSP) mapping controls to systems.
3. BaselinesControls layerCatalogs of standard controls and profiles defining baselines with adjustments.

Checking an OSCAL file#

There are three levels of “valid”, and they are worth keeping apart.

1. Well-formed. The file is correct JSON, XML or YAML. A missing bracket fails here.
2. Schema-valid. The file has the structure the OSCAL model requires: the right fields, in the right places, with values of the right type. NIST publishes the schemas for each version.
3. Meaningful. The identifiers resolve, the references point to things that exist, and the content says something true about the system.

A validator checks the first two, and some of the third. No validator can tell you whether the plan describes your system accurately. A file can pass every check and still be wrong.

Note the OSCAL version in the file’s metadata and validate against the schema for that version. An older file checked against a newer schema can fail for reasons that have nothing to do with its content.

1. Stage 1Well-formed checkVerify syntax is valid JSON, XML, or YAML without parse errors.
2. Stage 2Schema-valid checkValidate structure and data types against the official NIST schema for that OSCAL version.
3. Stage 3Meaningful checkConfirm references resolve and the content accurately describes the real system.

What an SBOM is#

A software bill of materials is a list of the components a piece of software is built from: the libraries, their versions and how they relate. It is the software equivalent of an ingredients label.

It matters for two reasons. When a vulnerability is announced in a library, an SBOM tells you in minutes whether you ship that library. And on a network with no internet connection, it tells the people who approve software exactly what they are being asked to bring in.

Two formats dominate:

Both can describe the same things. Tools usually read and write both.

What a useful SBOM contains#

Guidance published by the U.S. government in 2021 set out the minimum fields. For each component:

• the supplier’s name
• the component’s name
• its version
• other unique identifiers, such as a package URL
• its relationship to the other components, such as “depends on”
• who produced the SBOM data
• when it was produced

When you are handed an SBOM, a few questions tell you how far to trust it:

• How deep does it go? Only the direct dependencies, or the dependencies of those as well?
• How was it made? From the build itself, from a lockfile, or by scanning the finished product? Each sees slightly different things.
• Does it match the artifact? A good SBOM includes a checksum of what it describes. Compare it with the file you actually have.
• How old is it? An SBOM describes one build. A new version of the software needs a new one.

Before you load a file into a tool#

These files can describe a real system in detail: host names, addresses, open findings, software versions. A filled-in checklist or a system security plan may itself be controlled information.

• Use made-up or public sample files to learn how a tool behaves.
• Handle real ones only on a system approved for what they contain.
• A tool that runs in the browser does not send the file anywhere, but it also does not change the rules for the computer it runs on. See What happens to what you type.

The blank STIGs, the OSCAL schemas and NIST’s published catalogs are public and safe to use anywhere.

Sources#

• DISA, Security Technical Implementation Guides and Security Requirements Guides, at cyber.mil.
• NIST, OSCAL: the models, schemas and reference documentation.
• NIST, the Security Content Automation Protocol and XCCDF specifications, at csrc.nist.gov.
• National Telecommunications and Information Administration, “The Minimum Elements For a Software Bill of Materials (SBOM)”, 2021.
• The SPDX and CycloneDX specifications.