DISA STIG compliance tools

• Author
• Recent Posts

Joshua Lambert

Josh Lambert is a senior system administrator with experience in manufacturing systems and IT infrastructure in both the public and private sectors. His current work focuses on security and compliance, risk management, and security automation.

Latest posts by Joshua Lambert (see all)

• DISA STIG compliance tools - Thu, Apr 7 2022
• Using nested templates and a PowerShell script to deploy multiple Azure resource groups with virtual machines and supporting resources - Thu, Feb 17 2022

What is STIG compliance?

A STIG is a collection of configuration standards for specific products, providing methodologies for securing systems across networks, servers, workstations, whole environments, and individual applications. STIGs cover a breadth of detail on their systems, from router and firewall configuration to DNS and Active Directory and beyond; STIGs delve into the security configuration of applications, OS, and equipment while also providing coverage for maintenance processes and vulnerability mitigation.

The applicability of STIG requirements covers DoD agencies, contractors connected to DoD networks, and any other organizations or systems that connect to DoD information networks. STIG topics include (but are not limited to):

• Applications
• Cloud networks
• Mobile devices
• Operating systems
• Browsers
• Routers and servers
• Networks
• Network devices
• System architecture

Since different versions of systems have different vulnerabilities, there are unique differences between STIG versions, as required. STIG versions are generally updated on a quarterly release schedule, and summaries of change are available to the public from the DoD Cyber Exchange.

STIG vulnerability levels

STIG vulnerabilities refer back to risk management controls, with each vulnerability assigned a level corresponding to the degree of risk the vulnerability poses. The three severity categories (CAT) are CAT 1, CAT 2, and CAT 3, with CAT 1 being the most severe level of risk.

• CAT 1—Poses the most serious risk of exploitation and the most significant threat to the broader network or system in which vulnerability is found. These vulnerabilities pose a direct threat to data integrity and system availability.
• CAT 2—Although a serious risk of a security incident is still present, exploitation of a CAT 2 vulnerability is less likely to compromise data integrity and system availability than CAT 1. In some cases, CAT 2, if left unresolved, can cause related CAT 1 vulnerabilities.
• CAT 3—These vulnerabilities may lower the overall security posture of the system but will not directly cause a cybersecurity incident or system failure.

Enforcing STIG compliance

STIGs can be accessed at cyber.mil in a document library maintained by DISA. STIG packages include a revision history, STIG checklists, and an executive summary document that explains key concepts related to the STIG.

As with any new system update or implementation, ensure your backups are functioning, and systems are recoverable in the event a STIG item remediation causes a system failure. STIGs are focused on system security, not necessarily availability, and some settings may break system functionality.

Should that occur, administrators can request risk acceptance for the vulnerability in question so long as justification and details on other related mitigations are provided. For vulnerabilities that require time to research and mitigate but that do not necessarily break the system, a Plan of Action and Milestones (POAM) can be documented, detailing the resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.

DISA provides starter group policies for domain-joined Windows systems, automation content for non-Windows operating systems, containers, and network devices via Ansible and Chef, and non-domain-attached Windows devices via PowerShell DSC.

Additionally, for many STIGS, DISA provides Security Content Automation Protocol (SCAP) data, providing an automated method for scanning systems for STIG compliance. Open source tools, such as Microsoft's PowerSTIG (GitHub - microsoft/PowerStig: STIG Automation) are in development to assist administrators with automated compliance scanning and vulnerability mitigation.

STIG compliance tools

STIG Viewer

The first tool needed to work with STIGs is the STIG Viewer, which is available from the DoD Public Cyber Exchange.

STIG checklists are, in essence, XML files that use a variety of file formats, depending on the use case. The two most common formats are XCCDF and OVAL, which correspond to STIG and SCAP content, respectively. More on SCAP content later.

The STIG Viewer can be downloaded as a JAR file for ease of use. Upon launching the STIG Viewer, users are greeted with a basic splash screen where STIG checklists can be opened or created from scratch.

STIG Viewer home screen

From here, navigate to File > Import STIG to import the data for one or more STIG checklists.

Once imported, STIGs can be selected in the "STIGs" table on the upper left, and rules will be displayed for any checked STIGs.

Checkmarked STIG

Select the relevant STIG, and then select Checklist > Create checklist.

Create Checklist 1

Once the checklist is generated, five expandable menus are available on the left. We'll discuss each in brief below.

Totals

Blank STIG chart                                                       

Filled in STIG chart

A new checklist with no data looks like the pie chart on the left in the above image. As data is entered into the checklist, the pie chart will change to give a quick look at the state of the checklist.

The four categories available for a checklist item are as follows:

• Not Applicable—Some STIG items provide reasons why an item does not apply to particular system configurations. For example, in the Windows Server operating system STIGs, some checks only apply to domain controllers, and the STIG will state that the item is not applicable to member servers.
• Not reviewed—A determination on the status of the item has not been reached.
• Not A Finding—The system is compliant with the STIG.
• Open—The system is noncompliant with the STIG.

Target data

STIG target data

The "Target Data" field should list the following for the system to which the checklist applies:

• Classification level
• Host name
• IP address
• MAC address
• Fully Qualified Domain Name
• Comments
• Server role
• Indication of whether the system is a web or database system

STIGs

List of checklist STIGS

The "STIGs" section displays the STIG checklists that have been selected for review.

Technology area

Technology area

The Technology area enables the reviewer to select a general category for the system under review.

Filter panel

Filter Panel

The Filter panel enables the reviewer to filter the checklist on keywords or various categories.

STIG vulnerability layout

Each STIG item provides the following types of information:

• Rule Title—The title of the specific item.
• Discussion—A brief overview of why the STIG item is important.
• Check Text—How the reviewer can validate the system's compliance with the item.
• Fix Text—The method for achieving compliance with the STIG. This could be as simple as providing a registry value or as complex as discussing WAN architecture.
• References—Any applicable NIST controls related to the STIG item.

SCAP content

The Secure Content Automation Protocol (SCAP) provides an automated method for assessing compliance with many of the available STIGs. For any STIG that can be assessed using the SCAP scanning tool, DISA provides benchmarks, which are essentially definition files that allow the scanner tool to review a local or remote system for compliance. Note that many of the scans require admin access to the system being scanned.

The SCAP compliance checker (SCC) tool and associated benchmarks.

Upon launching the SCC, available STIG benchmarks are displayed, as well as the option to select a local or remote system to scan.

SCAP Home screen

Scanning a system with the selected benchmarks generates checklist files, the paths to which are displayed to the reviewer. These checklists can be imported into the STIG viewer; the status of any items the SCC was able to scan are prefilled.

SCAP scan in progress

To open a checklist generated by the SCC, open the STIG Viewer, navigate to Import > XCCDF Results File, and select the file generated by the SCAP scan.

Open XCCDF

Other automated options

Ansible playbooks

DISA provides Ansible playbooks for many of the available Linux OS and network device STIGs.

An Ansible playbook, as defined by RedHat, is "a blueprint of automation tasks—which are complex IT actions executed with limited or no human involvement. Ansible playbooks are executed on a set, group, or classification of hosts, which together make up an ansible inventory." More on Ansible is available from RedHat.

Chef

Automation content is available for Chef, though only for Windows Server 2016 and 2019, and RHEL 7.

PowerSTIG

An especially useful tool for IT administrators in environments capable of, or already leveraging, PowerShell Desired State Configuration, Microsoft's open source project "PowerSTIG" (Home · microsoft/PowerStig Wiki · GitHub) provides a method for generating Desired State Configuration (more info on DSC here: PowerShell Desired State Configuration (DSC) - PowerShell | Microsoft Docs) for most of the STIG checklists available from DISA. In my use cases, PowerSTIG provides advantages over the SCAP or manual reviewing methods because it provides mitigation for open findings instead of only assessing the current state of a system.

• PowerSTIG is a Microsoft open-source PS module that generates PowerShell Desired State Configuration MOFs from DISA STIG checklists.
  PowerSTIG is available in the PowerShell gallery and can be installed through PowerShellGet, using "Install-module PowerSTIG."
• Once installed, a full list of STIGs available with PowerSTIG can be retrieved with "Get-STIG –ListAvailable."
• To view STIGs for a specific technology, use "Get-STIG –technology."
• Custom organizational settings for STIGs that are not universal, such as members of a local group, or an IIS application pool setting, can be configured using the reference files in the PowerSTIG module folder titled STIGData.

To generate PowerShell DSC configuration files for a given system using PowerSTIG:

configuration example #enter DSC configuration name here
{
    param #node name is a required parameter
    (
        [parameter()]
        [string]
        $NodeName = 'localhost'
    )

    Import-DscResource -ModuleName PowerStig

    Node $NodeName
    {
        WindowsServer BaseLine #Format is Technology Name, BaseLine. The information in brackets below comes from Get-STIG -Listavailable
        {
            OSVersion   = '2016'
            OSRole      = 'MS'
            StigVersion = '1.10'
            #ServerInstance = 'SECLEE'
            OrgSettings = .\zOrgSettings\WindowsServer-2016-MS-1.10.org.default.xml" #original XMLs found at %PowerSTIG module path%\%version%\StigData\Processed. These can be customized to add/remove preferred DSC org settings
            # DomainName  = 'your.domain'
            # ForestName  = 'your.domain'
        }
    }
} 
example -OutputPath “.\PowerSTIG_MOFs\Server" #Outputs DSC config "Example" to the Output path listed

Once the MOF can been created, it can be converted to a STIG checklist for validation prior to a wide deployment.

$ReferenceConfiguration = ".\reference.mof"
$XccdfPath = '.\U_Windows_2012_and_2012_R2_MS_STIG_V2R12_Manual-xccdf.xml'
$outputPath = ".\checklist.ckl"
New-StigCheckList -ReferenceConfiguration $ReferenceConfiguration -XccdfPath $XccdfPath -OutputPath $outputPath

Settings for multiple STIGs can be generated as well, since most systems have multiple applicable STIG checklists:

$MofFile = 'C:\contoso.local.mof'
$XccdfPath = @(
   ‘C:\STIGS\SQL Server\U_MS_SQL_Server_2016_Instance_STIG_V1R7_Manual-xccdf.xml',
    ‘C:\STIGS\Windows.Server.2012R2\U_MS_Windows_2012_and_2012_R2_DC_STIG_V2R19_Manual-xccdf.xml'
)
$outputPath = 'C:\SqlServer01_mof.ckl'
New-StigCheckList -DscResults $auditRehydrated -XccdfPath $XccdfPath -OutputPath $outputPath

Once the MOF can been created, it can be converted to a STIG checklist for validation prior to a wide deployment.

$ReferenceConfiguration = ".\reference.mof"
$XccdfPath = '.\U_Windows_2012_and_2012_R2_MS_STIG_V2R12_Manual-xccdf.xml'
$outputPath = ".\checklist.ckl"
New-StigCheckList -ReferenceConfiguration $ReferenceConfiguration -XccdfPath $XccdfPath -OutputPath $outputPath

Settings for multiple STIGs can be generated as well, since most systems have multiple applicable STIG checklists:

$MofFile = 'C:\contoso.local.mof'
$XccdfPath = @(
   ‘C:\STIGS\SQL Server\U_MS_SQL_Server_2016_Instance_STIG_V1R7_Manual-xccdf.xml',
    ‘C:\STIGS\Windows.Server.2012R2\U_MS_Windows_2012_and_2012_R2_DC_STIG_V2R19_Manual-xccdf.xml'
)
$outputPath = 'C:\SqlServer01_mof.ckl'
New-StigCheckList -DscResults $auditRehydrated -XccdfPath $XccdfPath -OutputPath $outputPath

Once validated, the MOF can be applied to the target system using Desired State Configuration with:

Start-DscConfiguration -path %Path to MOF file folder% -computername %computername%

After applying the desired state configuration file to a system, you can generate checklists directly from the Test-DscConfiguration results. This shows the resources that have been employed to apply STIG vulnerability rules.

$DscResults = Test-DsCconfiguration -ComputerName targetPC -Detailed 
$XccdfPath  = ".\targetPC\OS\U_MS_Windows_Server_2016_STIG_V1R11_Manual-xccdf.xml"
$outputPath = ".\targetPC\OS\AZURW4FH11A4DB1_wINDOWS_SERVER_2016_DSC_CKL.ckl"
New-StigCheckList -DscResult $DscResults -XccdfPath $XccdfPath -OutputPath $outputPath  

Complete information on the PowerSTIG module is available on the Microsoft GitHub page, here: Home · microsoft/PowerStig Wiki · GitHub

Summary

For IT professionals working in the DoD space, STIG compliance is a hard requirement. There are hundreds of STIGs, each with dozens of vulnerabilities applicable to their systems. A DISA STIG provides thorough technical guidance to empower IT teams to secure systems and data that may be vulnerable to a variety of threats from malicious actors if left in a default configuration. DISA STIG compliance tools exist to aid administrators in evaluating and enforcing STIG compliance.