Using Atlas STIG Compliance

Solution Overview

The Atlas STIG Compliance app relies on two core components to aggregate compliance data.

1. STIG Compliance Splunk App: Contains all necessary tools to correlate, visualize, and edit compliance related artifacts.

2. STIG Checklist Technical Add-on: Ingestion of STIG Checklists are performed using the Atlas STIG TA (Technology Add-on). This TA will process all desired checklist files from a given location, and automatically format them to be relevant to Splunk for use in the Atlas STIG Compliance app. It is required that users install both the Atlas STIG Compliance app, and its associated Atlas STIG TA on the Splunk search head which will be used to analyze compliance data.

Additionally, Atlas STIG Compliance contains features to incorporate results from common compliance scanning tools, such as SCAP. Results from compliance scans are ingested into Splunk in a similar manner as the checklist files and require a separate Atlas SCAP TA to correlate the data. There is an optional Puppet integration that can also provide STIG compliance automated scanning, remediation and enforcement of STIG vulnerabilities.

The following diagram illustrates how the components work together to make a comprehensive solution.

Concepts & Terminology

Certain terminology and concepts will be utilized throughout this documentation. It is important to understand these in order to effectively utilize the software and this documentation.

• STIG: A System Technical Implementation Guide is made up of a list of vulnerabilities defined by DISA (Defense Information Systems Agency) that provide guidance for how an IT asset must be configured or managed to be compliant.

• Target: A target is a computing resource such as a server, computer or network device that has STIGs being applied to it. A target can also be a non-computing resource as well. The DISA STIG Viewer tool allows users to specify a target name. This is typically a computer's hostname.

• System: A collection of Targets that make up a logical system representing a users IT organization. These are defined in the STIG Compliance app so that you can organize your Targets into logical groups that represent your environment. A target can belong to multiple systems if desired.

• STIG Checklist: A STIG checklist is an instance of a STIG that has been defined or assigned to a target.

• SCAP: A Security Content Automation Protocol is a method for using specific standards to enable automated vulnerability management, measurement, and policy compliance evaluation of systems deployed in an organization

• TA: Technology Add-on

Recommended Architecture

The Atlas STIG Compliance solution follows Splunk best practices in deploying its components to an existing system. The recommended approach is to install the STIG Compliance app as part of the Atlas Platform on the search tier. Additionally, the STIG TA and the SCAP TA should be installed on each component of the Splunk system (Including the Search Head). This can easily be achieved using a deployment server and is highly recommended for turn-key functionality. Refer to Splunk Documentation for additional detail on deploying Apps using a deployment server.

At a minimum, the TA for each data type needs to be present on each tier (Input, Parsing, Indexing, Search) that processes that data type. As an example, if STIG checklist data is only being stored and processed on the same machine hosting the Splunk Search Head, the STIG TA would only be required on that server. If, however STIG checklists are being stored on a remote datastore, that datastore is required to have forwarder with the STIG TA installed on it, and the STIG TA would additionally need to be installed on all associated Splunk Servers as part of that data path (Heavy Forwarders, Indexers, and/or Search Heads).

It should be noted that SCAP scans are typically generated on each machine locally. To automatically incorporate up to date SCAP data, each machine that generates SCAP scans should be equipped with a forwarder and the SCAP TA installed. To assist with integration, it is recommended that SCAP scans are output to a common location on each target machine. As seen in the following section, Ingesting Data, the SCAP TA must be configured to ingest data from a known file location. Creating a standard location for where SCAP data is stored on each machine allows the user to configure the SCAP TA once, then deploy it to every target.

Installation Checklist

Task	Search Head	Indexing Tier	Forwarding Tier	Notes
Install Atlas	Yes	No	No	Only Required on the Search Head or Search Head Cluster Members
Install Technical Add-on (TA) on all Splunk instances that process STIG data	Yes	Yes	Yes	Required on every tier where STIG/SCAP data will be present (i.e. Search Head, Indexes, any machine Forwarding unprocessed .ckls or SCAP data)
Set up ingest directory and create an Archive sub-directory	No	No	Yes	This needs to be present on each machine sending data to Atlas. Try to create a consistent location for each machine. Recommend making a directory where CKLs are dumped (this is your source directory), with an ‘Archive’ sub-directory to stay organized.
Configure inputs.conf on TA	No	No	Yes	Set source and archive directory in script stanza. Set disabled=false for either Python3 or PowerShell version
Add STIG/SCAP indexes to index.conf	No	Yes	No	Index must match the index field in the inputs.conf of the STIG Compliance app
Place ckl files in ingest (source) directory	No	No	Yes	Location must match source directory defined in inputs.conf
Select Metric Index on Configuration dashboard	Yes	No	No	Requires Admin permissions

Ingesting STIG Checklist Files into Splunk

In order to ingest STIG checklist files (.ckl) into Splunk, a Splunk Forwarder with the Atlas STIG Checklist TA must be used. The Splunk Forwarder will identify the .ckl files and will process them by converting them into a different format. Once the data has been indexed by Splunk the Atlas STIG TA will then move the .ckl file to another folder so that it is not picked up again by the forwarder. The recommended implementation of this solution is to create a file share where users can drop a .ckl file for the Atlas TA to process. This also can enable automated processes that will allow external systems to drop completed .ckl files in a location so that the data can automatically be brought into Splunk.

A configuration file must be modified which establishes the location of the raw .ckl files to be ingested, along with options for where to store the processed files and the rate at which the TA will automatically process the files.

There are 2 versions of the parsing script that are used by the Atlas STIG TA, one for Python3 and another for PowerShell. Use the version most appropriate for your environment and ensure that all dependencies for both are present before attempting to ingest the data into Splunk.

Configure the STIG Checklist Technical Add-On

The process for updating the Atlas STIG Checklist TA configuration file is as follows:

1. Obtain the Atlas STIG TA software from the Atlas Customer Support portal

2. Unzip the file and move the contents of the Atlas STIG TA into the /opt/Splunk/etc/apps directory if it is not already present

3. Copy the inputs.conf template from /opt/splunk/etc/apps/<atlas_stig_ta>/default/inputs.conf to a local directory: /opt/splunk/etc/apps/<atlas_stig_ta>/local/inputs.conf

4. There should be 2 stanzas present in the default inputs.conf, one for a Python version of the .ckl file parsing script and a second for the PowerShell version. Copy the stanza relevant to the platform you are running this TA on or leave the stanza you don't need commented.

    # Python - Based inputs example stanza
    # [script://$SPLUNK_HOME/etc/apps/TA_atlas_stig/bin/stigparser.py /source/directory/goes/here /destination/directory/goes/here]
    # disabled = false
    # index = stig
    # sourcetype = compliance:stig_ckl
    # interval = 30
    # python.version = python3
   
    # PowerShell - Based inputs example stanza
    #[powershell://Processes-STIGParser]
    #script = . $SplunkHome\etc\apps\ta_atlas_stig\bin\stigparser.ps1 \source\directory\goes\here \destination\directory\goes\here
    #disabled = false
    #index = stig
    #sourcetype = compliance:stig_ckl
    #schedule = 30

5. Edit the local version of the inputs.conf file and uncomment the lines for the version of the STIG checklist ingestion script you want to use.

   # Python - Based inputs example stanza
   [script://$SPLUNK_HOME/etc/apps/TA_atlas_stig/bin/stigparser.py /source/directory/goes/here /destination/directory/goes/here]
   disabled = false
   index = stig
   sourcetype = compliance:stig_ckl
   interval = 30
   python.version = python3
   
   # PowerShell - Based inputs example stanza
   [powershell://Processes-STIGParser]
   script = . $SplunkHome\etc\apps\ta_atlas_stig\bin\stigparser.ps1 /source/directory/goes/here /destination/directory/goes/here
   disabled = false
   index = stig
   sourcetype = compliance:stig_ckl
   schedule = 30

   • Source directory: The directory that will be scanned by the Splunk Forwarder where the .ckl files to be ingested into Splunk will be placed.

   • Destination directory: The directory where the processed ckl files will be placed after being processed by the Splunk Forwarder.

   • disabled: Defaults to false. Set the value to true for the stanza that should be enabled in your environment. Only one version of the script should be set to enabled.

   • index: The Splunk index where the data will ingested. Use the default provided or modify for your environment.

   • sourcetype: The default Splunk source type for the compliance data being ingested. Do not change this field, use the default value provided.

   • interval: The interval that the scripted input will be executed. The default value is 30 seconds.

   • python.version Specifies the version of Python to be used. This is only relevant for the Python stanza. Modify if you are using a different version of Python.

   tip

   You must create a separate archive folder within the directory containing the .ckl files are dropped so that the scripted input can send processed .ckl files to that folder. The script will not automatically create the directory; however it will warn the user that the 'processed file' directory is not found.

   • If implemented as suggested, an example configuration file might read:

     [script://./bin/stigparser.py /home/Checklist /home/Checklist/archive]

   • If needed in your environment, you can use different indexes for STIG data to implement role based access control to data. For example, if you have two separate systems, you can separate the data for each by placing the checklist files in different directories, and have each directory ingested into a different index.

   • If an index is declared in the config file, it must be defined in the indexes.conf file. Declaring an invalid index here will lead to unsearchable data.

   • Warning: Do not attempt to change the sourcetype field, as it is used for data aggregation within the STIG Compliance App.

Validating STIG CKL Configuration

Once final edits are made to the inputs.conf in the local directory, restart Splunk for the changes to take effect. The TA should automatically begin importing checklist files into Splunk if provided. You can validate that the TA is set up correctly by checking the defined 'Archived' directory declared in the inputs.conf file. There should now be checklist files present in this directory if the Splunk forwarder processed them. Additionally, verify that you can search the new data by opening a new Splunk search window and searching the index and sourcetype specified in the inputs.conf file search: index=”stig” sourcetype=”compliance:stig_ckl”.

Ingesting SCAP Scan Results into Splunk

In order to ingest SCAP scan results into Splunk, a Splunk Forwarder with the Atlas SCAP TA must be used. The Splunk Forwarder will identify the .xccdf files and will process them by converting them into a different format. Once the data has been indexed by Splunk the Atlas SCAP TA will then move the .xccdf file to another folder so that it is not picked up again by the forwarder. The recommended implementation of this solution is to create a file share where users can drop a .xccdf file for the Atlas TA to process. This also can enable automated processes that will allow external systems to drop completed .xccdf files in a location so that the data can automatically be brought into Splunk.

A configuration file must be modified which establishes the location of the raw .xccdf files to be ingested, along with options for where to store the processed files and the rate at which the TA will automatically process the files.

There is currently only one version of the SCAP parsing script that is available and it requires Python 3. A non-python version is not available, so this TA must deployed on machines that have the Python perquisites installed.

Configure the SCAP Technical Add-On

The process for updating the Atlas STIG Checklist TA configuration file is as follows:

1. Obtain the Atlas SCAP TA software from the Atlas Customer Support portal

2. Install Python on the target node where the TA will be deployed if it is not already installed

3. Unzip the file and move the contents of the Atlas SCAP TA into the /opt/Splunk/etc/apps directory if it is not already present

4. Copy the inputs.conf template from /opt/splunk/etc/apps/<atlas_scap_ta>/default/inputs.conf to a local directory: /opt/splunk/etc/apps/<atlas_scap_ta>/local/inputs.conf

5. There should be 2 stanzas present in the default inputs.conf, one for a Python version of the .ckl file parsing script and a second for the PowerShell version. Copy the stanza relevant to the platform you are running this TA on or leave the stanza you don't need commented.

   # [script://$SPLUNK_HOME/etc/apps/TA_atlas_scap/bin/scapparser.py /source/directory/goes/here /destination/directory/goes/here]
   # sourcetype = compliance:scap_xccdf
   # source = SCAP scan: Ingested from TA_atlas_scap
   # interval = 30
   # python.version = python3

6. Edit the local version of the inputs.conf file and uncomment the lines for the version of the STIG checklist ingestion script you want to use.

   [script://$SPLUNK_HOME/etc/apps/TA_atlas_scap/bin/scapparser.py /source/directory/goes/here /destination/directory/goes/here]
   sourcetype = compliance:scap_xccdf
   source = SCAP scan: Ingested from TA_atlas_scap
   index = scap
   interval = 30
   python.version = python3

   note

   The line index = scap must be added to the template inputs.conf file.

   • Source directory: The directory that will be scanned by the Splunk Forwarder where the .xccdf files to be ingested into Splunk will be placed.

   • Destination directory: The directory where the processed .xccdf files will be placed after being processed by the Splunk Forwarder.

   • disabled: Defaults to false. Set the value to true to enable the TA in your environment.

   • index: The Splunk index where the data will ingested. Use the default provided or modify for your environment. NOTE: This line must be added to the templated

   • sourcetype: The default Splunk sourcetype for the compliance data being ingested. Do not change this field, use the default value provided.

   • interval: The interval that the scripted input will be executed. The default value is 30 seconds.

   • python.version Specifies the version of Python to be used. This is only relevant for the Python stanza. Modify if you are using a different version of Python.

   tip

   You must create a separate archive folder within the directory containing the .xccdf files are dropped so that the scripted input can send processed .xccdf files to that folder. The script will not automatically create the directory; however it will warn the user that the 'processed file' directory is not found.

   If implemented as suggested, an example configuration file might read:

   [script://./bin/scapparser.py /home/SCAP /home/SCAP/archive]

Validating SCAP Configuration

Once final edits are made to the inputs.conf in the local directory, restart Splunk for the changes to take effect. The TA should automatically begin importing checklist files into Splunk if provided. You can validate that the TA is set up correctly by checking the defined 'Archived' directory declared in the inputs.conf file. There should now be checklist files present in this directory if the Splunk forwarder processed them. Additionally, verify that you can search the new data by opening a new Splunk search window and searching the index and sourcetype specified in the inputs.conf file search: index=”scap” sourcetype=”compliance:scap_xccdf”.

Dedicated STIG Compliance Indexes (Optional)

Atlas STIG Compliance provides users the ability to partition compliance data into individual indexes, which can be used to provide Splunk-native role based access controls to the data. To enable this, additional settings must be configured by editing the macros.conf file of the STIG Compliance Splunk App. This is an optional configuration and is not required if you do not need to restrict access to compliance certain compliance data.

Configuring Dedicated STIG Compliance Indexes

Setting dedicated indexes not only increases performance in large environments but can be used to set user permissions on the data, which is a Splunk native capability and is enforced on the indexing level. In environments that have one or more dedicated indexes for compliance data, you must set the index that Atlas STIG Compliance will search when retrieving Compliance data.

On the Search Head running Atlas STIG Compliance perform the following steps:

1. Copy the macros.conf template from the location /opt/splunk/etc/apps/<atlas_stig_ta>/default/macros.conf to a local directory: /opt/splunk/etc/apps/<atlas_stig_ta>/local/macros.conf

2. Edit the definition of the [atlas_Compliance_indexes] stanza to search the appropriate indexes:

   • By default, Atlas STIG Compliance has the definition set to (index=*), which will search all Indexes for relevant compliance data.
   • If adding multiple indexes the definition, separate each index with an OR: definition = index=”Compliance_A” OR index=”Compliance_B”

3. Ensure that your Compliance Data is being stored in the correct index that Atlas STIG Compliance is now searching.

   • Checks you can execute include:
     • Indexes have been properly defined on Splunk’s indexes.conf file
     • The TAs for STIG and/or SCAP are forwarding to the correct index, by setting their inputs.conf file. The ‘index’ argument of the stanza being used should match your desired index.

Creating & Configuring Metric Indexes

Metric indexes are concise Splunk indexes that are updated with specifically formatted events. They do not count towards license utilization, while providing speed improvements. Atlas STIG Compliance utilizes a metric index to store historical vulnerability data used to populate Health Score trends visualizations on System Overview and System Compliance.

Follow standard Splunk guidance for creating a metric index, then navigate as an Admin to the STIG Compliance Configuration dashboard. Under the Settings section, select teh configured metric index and select Save Changes button. Vulnerability and Health Score data will now be periodically saved to the metric index, and will start to populate the following visualizations:

• Trend lines on System Tiles on System Overview dashboard
• Score Trend column on Target Summary Table on System Compliance dashboard

Application Overview

The STIG Compliance Splunk App has the unique ability to aggregate the compliance data of a system or groups of systems, and report overall health of compliance. The dashboards are designed to guide the user from viewing the system at a summary level and then providing tools and resources to drill-down into the discrete compliance details.

System Overview Dashboard

This dashboard can be used to get a quick view of compliance health across all of your defined systems. The purpose of this dashboard is to group compliance targets into systems, and show an overview of each individual system known to the STIG Compliance app. Each system is broken into individual tiles on this dashboard. Each tile contains a visual of vulnerabilities sorted by status, a calculated health score, and a trend line showing the health score over time.

1. Filters: Use the filter to filter out systems and time range of reported data. STIG Compliance always reports the most recent system data, but the Time Range picker can be used to adjust system health score trend lines.

2. System Tile: Overview for each specific system. The name and description of each system is listed at the top of the tile. Clicking anywhere in this tile will navigate the user to System View dashboard, filtered for the specific system selected. If multiple systems are defined, a ‘Selected Systems’ tile will appear, giving an overview of all targets that have been grouped into systems. Additionally, an ‘All Data’ system is generated by default, which contains all compliance data known by the STIG Compliance app.

3. Overview Pie Chart: Displays the relative number of findings for that system, categorized by their status: Open CAT 1/2/3, Not a Finding, Not Reviewed, or Not Applicable.

4. Health Score: Weighted average, where 60% of the score is calculated by the ratio of Open CAT 1 findings to total CAT 1 findings, 30% comes from the ratio of open CAT 2 findings, and 10% comes from Open CAT 3 findings. Additionally, a trend line shows how the health score has improved/degraded over time as findings are mitigated or added to the system.

5. Add New System: Click this button to add a new system definition. A modal will appear on screen which allows you to name your new system, then assign targets to the system. The Targets search bar allows you to search your system for targets that have compliance data associated with them. Additionally, you can create a target that you anticipate will be introduced to the system once data is ingested. All data will be associated with the newly created target based on its hostname. The number in grey to the left of each target shows how many data sources have been ingested for the given target. The Description field will appear as a subheading on the System Tile and can be used to store additional description of system. Finally, you can assign ownership to the system by designating an owner and contact info.

6. Edit Existing System: Click on this button to view information about the selected system. Here System Administrators can edit or delete systems. Users will have the ability to view system information, however, will not be able to change any of the fields.

Adding a New System

You will need to create a System in the STIG Compliance App in order to group together targets that make up a logical system in your environment. A target can be associated to more than one system. Creating and editing systems is done in STIG Compliance App UI after data has been brought into Splunk. To add a new system use the following steps:

1. Click on the Add New System button in the top right corner of the System Overview Dashboard. The New System Modal appears.

2. Provide a name for your system in the System Name field

3. Add targets to your system by moving them by name from the 'Available Targets' field to the 'Selected Targets' field

4. You can also use the Targets field to create a custom target that is not yet indexed in Splunk. This helps if you want to add a Target that you know will eventually be added. This will show in your list but will not impact your health score until compliance data is available.

5. Provide a description of your system in the Description field. This will be the description that appears in the system tile on System Overview dashboard.

6. 'Owner' is a text field that allows you to provide the name of a system owner. This will appear on the system tile on the System Overview dashboard.

7. 'Contact Info' is a text field that allows you to put information for how to contact the system owner. This will appear on the system tile on the System Overview dashboard.

8. Hit the Save button to save your system. The new System tile should appear immediately after the page refreshes.

Editing an Existing System

To edit an existing system, click on the icon that appears in the bottom right corner of each tile. This will open the System edit modal. On this screen you can modify some of the fields of a System.

1. Click on the icon that appears in the bottom right corner of the desired system tile

2. You can adjust the targets that are assigned to a system by moving them between the 'Available Target' and 'Selected Targets' fields

3. Modify the System Description

4. Modify the System Owner

5. Modify the Contact Info

6. Click the Save button when done making changes to the system

7. The tile will be updated immediately once the page refreshes

System Compliance Dashboard

This dashboard can be used by system owners or maintainers to get a detailed overview of their system. This dashboard includes a system overview, containing the heath score of the system, the number of target machines contained in the system, and the total number of unique STIGs being tracked for the system. Additionally, vulnerabilities are displayed by severity (CAT 1/2/3) in separate graphics, which show the relative amount of Open, Not Reviewed, Not Applicable and Not a Finding statuses in each severity category. Finally, two tables summarize the data captured for the system sorted by Target Machine, and by STIG.

1. Filters: Use the filters to change visibility to sort by systems, or targets within the system.

2. System Summaries: Provides System summary data, including a System Health Score, total number of machines within the system, and how many unique STIGs are being tracked for that system.

3. Vulnerability Summaries: Each pie chart groups vulnerabilities of the system by their severity. Hovering over any piece of the pie will show the total amount of vulnerabilities in that selection. Clicking on a slice of the pie will produce an additional table which shows all vulnerabilities selected from that group.

4. Target Summaries Table: Lists all target machines that have up to date compliance information in the system, along with a summary of vulnerability statuses. Note that only data for current STIGs will be displayed in this table, meaning that if you have a target that has compliance data for a STIG that is out of date, it will not be displayed in this table. Each target is given an individual target health score, which is calculated based on all STIGs applied to it. Additionally, a Score Trend tracks the daily health score over the time range selected by the time range filter above the table. Selecting a row will navigate the user to the STIG Viewer dashboard, with the selected target pre-filtered.

5. Active Checklists Table: Lists all available checklists in the system with version info and a summary of vulnerability statuses. Note that this table only displays current STIGs. Out of date compliance data will not be displayed. Selecting a row will navigate the user to the STIG Viewer dashboard with the selected STIG pre-filtered.

STIG Viewer Dashboard

This dashboard is designed for a system maintainer or auditor to view the details of individual controls. The purpose of the STIG Viewer dashboard is to provide an in-depth view of a single target machine and all applicable STIGs and controls associated with that target. The dashboard is broken into two sections:

• The top section of the dashboard, labeled Section Overview, provides an overview of the target or targets selected by the filter. A summary of controls sorted by severity gives a visual representation of the compliance status of the target, and the tables below queue the user in to selected target(s), and all associated STIGs available for review.

• The bottom section, labeled Checklist Browser, provides a detailed view of each individual control. This view is meant to mimic the functionality of the DISA STIG viewer, with the exception that multiple checklists can be searched and aggregated at once, providing a more comprehensive view of the target machine.

1. Filters: Use the filter to change visibility to sort by systems, target machines, STIG, status or severity.

2. Vulnerabilities by Severity Overview: Shows a relative breakdown of statuses of vulnerabilities.

3. Target Information: List of identifying information about the selected target such as its IP address, MAC address, domain name, and role within the system.

4. STIGS: Table that displays all (unless filtered) STIGs that apply to the selected target, with some high-level identifying information about each STIG.

   

5. Filters: Further filter based on keywords found in the text of the vulnerabilities. Vulnerabilities can also be sorted by status and severity using the dropdown lists.

6. Vulnerabilities table: All vulnerabilities for the selected target(s) and STIG(s). Here you can see an aggregate view of all vulnerabilities within your filter criteria. Table headings help you sort that table by applicable column, such as status or category. Selecting a row in the table will populate the Vulnerability Overview section on the right side of the page. If SCAP data is present, an icon appears in the right column showing the scan results. Green represents passing scans, while red represents a failed scan. If multiple targets are included in the filtered view, there are additional color combinations to represent a mixed dataset. Grey outlines around the circle will always indicate that there is missing SCAP data for one or more targets. In the case that there are targets that have both passing and failing scans, a half red – half green indicator appears. Below is a list of all the potential indication scenarios, but for simplicity: Green is passing, Red is failing, and a grey outline means SCAP data is missing for that vulnerability. Selecting the button in the Update column will open up the Update Vulnerability modal for updating the specific vulnerability on the STIG Viewer dashboard.

   note

   SCAP Scans typically do not cover every vulnerability in a STIG, so it should be expected that some vulnerabilities will never have a comparable SCAP scan and will always present an icon indicating that no SCAP data is found.

7. Vulnerability Overview: Lists all fields for the selected vulnerability, including identifying information, Fix Test, Discussion, Check Text, and other applicable fields.

8. Change History: Shows an audit trail of every time the vulnerability was ingested or changed within the STIG Compliance App. A timestamp and source information are included for each entry. Use this table to track changes over time for a specific control. The time range filter above the table can be used to adjust the time window.

   

9. Update Vulnerability: Will send the user to the Edit Checklists dashboard with current filters applied, allowing the user to edit information about this vulnerability.

STIG Viewer SCAP Status Indicators

The SCAP scan indicators are designed to provide a quick visual reference for what the latest status of a SCAP result is. These icons are also used to show the status of multiple targets when multiple targets are selected. Each of the icons used have their own meaning. Use the table below as a reference for each SCAP icon.

Status Icon	Icon Definition
	From the selected targets, all of them have passing SCAP scan results but none are missing
	From the selected targets, all of them have failing SCAP scan results but none are missing
	From the selected targets, all of them are either passing or failing SCAP scan results but none are missing
	From the selected targets, there are no SCAP results found
	From the selected targets, there are passing and missing SCAP scan results
	From the selected targets, there are failing and missing SCAP scan results
	From the selected targets, there are passing failing and missing SCAP scan results

Editing Checklists in the STIG Compliance element

There are multiple methods to edit vulnerabilities within the Atlas STIG Compliance App. Both the STIG Viewer dashboard and Edit Checklists dashboard can be used to edit the Status, Finding Details, add Comments, or even provide Status or Severity Override for a single vulnerability. This can save time by forgoing the need of creating a new checklist file for small, simple changes, or by enabling compliance engineers to apply changes over multiple targets.

There are two workflows that you can use to accomplish updating vulnerabilities in a STIG checklist within the STIG Compliance Element:

STIG Viewer's Update Vulnerability Modal

If a user wants to change one vulnerability on one target, the Update Vulnerability modal on STIG Viewer is the perfect tool. When viewing a list of vulnerabilities on the STIG Viewer screen that are selected by your filters, you can select the Update Vulnerability button on the Checklist Browser.

This will open up the Update Vulnerability modal. This modal will reflect the current status of the vulnerability selected, from its status to its current comments and finding details identified. After any change is detected, the Update button will activate, allowing the user to save their changes to the vulnerability. The modal will not close automatically to support later edits. After each update, all visualizations on STIG Viewer will update to show the new changes.

Update Checklist Dashboard

If a user wants to change one vulnerabilities on more than one target, the Update Checklist dashboard will enable the user to apply and append changes on multiple targets. Users can navigate to this page from the STIG Compliance navigation bar, or by selecting the Update Vulnerability button on STIG Viewer below the Change History table.

Using the filters at the top of the Edit Checklists page, users can select a combination of System, Targets, STIG and Vulnerability ID to populate the screen with the details for the vulnerability they want to update. Once the screen populates with details, a list of vulnerabilities has been found in the system. From here, users will be able to update vulnerability details across multiple STIG checklists across many targets. The number of STIG checklists updated is controlled by what is selected in the filters at the top of the page. All affected targets will be listed in the Selected Vulnerability

When you are ready to apply your updates, you will click the Apply Update button in the bottom right corner fo the screen. You will be prompted with a modal that will summarize the updates that will be applied to the STIG Checklists stored in Splunk. If you are confident that these are the correct changes, click OK. Otherwise you should click the Cancel button and adjust your updates before committing your changes.

Field Descriptions

Users can update the following fields on STIG Vulnerabilities using both methods described.

Field	Usage	Values	Description
Status	STIG Checklist	Open, Not Applicable, Not a Finding, Not Reviewed	Use this field to set the status of a vulnerability
Status Override	STIG Checklist	Unlock Status, Lock Status	This is a custom field used by Atlas STIG Compliance. Since it is designed accept the status of the latest data source ingested by Splunk, the Status value will update based on the last value ingested by Splunk. The Status Override option allows you to "lock" a value so that it will not be overridden by data ingested into Splunk. The data will still be ingested but enabling the Status Override will prevent the Status field from being updated. This is useful for when you want to export STIG Checklists out of Splunk.
Finding Details	STIG Checklist	Append Value, New Value	This field allows you to either append or update the Finding Details field on the STIG Checklist
Comments	STIG Checklist	Append Value, New Value	This field allows you to either append or update the Comments field on the STIG Checklist
Severity Override	STIG Checklist	None, CAT III, CAT II, CAT I	This is the Severity Override field from DISA's STIG Viewer tool
Severity Justification	STIG Checklist	Append Value, New Value	This is the Severity Justification field from DISA's STIG Viewer tool

Status Override

Atlas STIG Compliance continuously monitors the status of vulnerabilities being provided by external data sources. This means that if there are multiple sources sending the status of a vulnerability into Splunk, it will consider the last one it received to be current status. Sometimes it might be desirable to override this behavior and keep the status of a vulnerability 'locked' so that incoming data does not change the value. In Atlas STIG Compliance this is called Status Override.

If a Status Override is set on a vulnerability, this is the status that will be displayed throughout the STIG Compliance app, and will be the status that is exported from Splunk. The Status Override field can be removed (or unlocked) at any time, and the status will be reverted to the vulnerability's true status from the last known data source. When a Status Override is set, the latest status will still be updated and recorded in STIG Compliance as normal, however the latest status will only be visible on the Edit Checklists dashboard.

Navigate to the Edit Checklists dashboard, and select the vulnerability which you would like to edit. Optionally narrow down the targets using the filters provided at the top of the page.

Take note of the Most Recent Annotations by Targets table. Columns 2 and 3 show the Status and Status_Override of each target selected. Here Status is the latest status as recorded in the most recent data ingested into Splunk, while the Status_Override field will be the status displayed and exported throughout STIG Compliance. If the Status_Override field is displaying 'none', that status is unlocked, and the latest status will be displayed and exported like normal.

Locking and Unlocking the Status of a Vulnerability

Navigate directly to the Edit Checklists dashboard or select the Update Vulnerability button while viewing a vulnerability on STIG Viewer dashboard. On the Edit Checklists screen select all of the targets that you want to lock the status of the vulnerability for. The list of targets currently in scope is displayed in the Most Recent Annotations by Targets table on this page. In this table, the Status Field is the latest status and the Status Override is the value that the vulnerabilities are locked to, if currently set.

If desired, you can change the list of targets by changing the filters at the top of the page. Once you have the desired list of targets selected, scroll down to the Status Override selector and set it to Lock Status. Scroll down to the Apply Update button to save the Lock.

A Lock Icon will be visible next to the vulnerability status on the STIG Checklist page when a lock has been applied.

To unlock a status simply perform the steps above but select the Unlock Status option.

STIG Library

These are the primary tasks you can accomplish with the STIG Library tool:

1. Lookup most of the latest unclassified STIGs published by DISA for reference

2. Create a STIG checklist for a target or targets and add it to your inventory in the STIG Compliance App

3. Convert SCAP results for a target into a STIG Checklist already in your inventory

The Atlas STIG Compliance app comes with all of the unclassified STIGs provided by DISA pre-loaded into the app. Use STIG Library to search the latest available STIGs and assign them to targets on your system. The Save as Checklist feature will apply the given STIG to a target or a group of targets, marking any unknown vulnerabilities as Not Reviewed. This allows users to begin the compliance journey for new targets on their system directly from the Splunk UI.

STIG Library is your starting point for manually adding STIG Checklists to your inventory in Splunk without having to ingest anything into Splunk. The Save as Checklist feature can be used to convert incomplete compliance data, such as a SCAP scan, into a full STIG checklist. By performing a Save as Checklist operation on a target that has SCAP data recorded for it, Atlas will fill in the gaps for you by adding any missing vulnerabilities as Not Reviewed.

STIG Library Interface

1. STIG Selection: Select a STIG from a searchable dropdown list. This must be populated for the rest of the page to become visible. Selection options are based off DISA’s current release of STIGs (Updated with every App version), as well as any additional STIGs added manually.

2. Vulnerabilities Overview: Displays how many vulnerabilities are present in the selected STIG based on their severity.

3. Save as Checklist: This feature will display a modal which will allow the user to assign targets to the selected STIG. The user has the option to add additional data to any currently tracked targets, as well as add new targets to the system with a blank STIG checklist assigned to them.

   

4. Vulnerability Browser: Filter and view all vulnerabilities for a selected STIG.

5. Vulnerability Display: Shows all of the information associated with that vulnerability.

Create a New STIG Checklist from STIG Library

1. Navigate to the STIG Library dashboard

2. Select the STIG from the list that you want to add

3. Click the Save as Checklist button

4. On the modal that appears you must select Existing Target button if you want to assign it to a target that is already in your inventory or select New Target if you want to create a STIG checklist for a target that is not in your inventory. If you are selecting an existing target or target(s) select them from the 'Available Targets' list on the left and move them to the 'Selected Targets' column. If you are selecting a new target you will need to provide the required information about the target. At a minimum, you should provide the Host Name. These selections mimic the information requested in the DISA STIG Viewer.

5. Select the Splunk Index being used to hold your STIG compliance data. Leave this as the default if you have not created custom indexes for the STIG Compliance data.

Atlas STIG Compliance comes pre-loaded with the currently supported Unclassified STIGs published by DISA on their DoD Cyber Exchange website. Each version of STIG Compliance should provide the user with everything they need to STIG their systems in accordance to current DISA guidance. There are however cases where additional STIGs must be added to the system, for example if the user is tracking STIGs in a classified environment, or simply keeping compliance data for a system that is no longer officially supported by DISA.

STIG Compliance provides tooling to allow users to include additional STIGs for tracking on their STIG Compliance system. Once added, these STIGs will be viewable in the STIG Library and made available to add to targets for compliance tracking. Additionally, any ingested checklists pertaining to these STIGs will be automatically incorporated into the STIG Compliance system and have access to the full suite of tools available in the STIG Compliance app.

Adding STIGs to the STIG Library

The STIG Library only comes pre-loaded with the STIGs that DISA provides on Cyber Exchange. Adding more STIGs to STIG Library will be required if you want to report on STIGs that are not provided from this source or if you want to upgrade your STIGs to a later version than what is already in STIG Library. You can use this method to upgrade single STIGs or an entire compilation of STIGs.

Atlas STIG Compliance provides a method for adding more STIGs as most users will find this to be necessary in their environment. Adding to the STIG Library is accomplished by putting the STIG template files on your Splunk Search Head and running a script in the STIG Compliance directory. The process to add new STIGs to STIG Library is as follows:

caution

A STIG must be present in the STIG Library for it to show up in any of the STIG Compliance interfaces. The data will still be indexed in Splunk if it is being sent, but it will not be visible until the STIG is present in STIG Library.

1. Download the files for the STIGs from your preferred source. These are typically delivered in an archive file (.zip) that contains all of the relevant files provided by DISA. The file that is needed from the archive file is the XML file that should be named something similar to mySTIG_Manual-xccdf.xml. A completed checklist file (.ckl) will not work here. These files will be skipped by the STIG template upload process.

2. You must now copy your STIG Template file(s) to the Atlas Search head using the file transfer method of your choosing. Place the files in the <SPLUNK_HOME>/etc/apps/atlas_stig_compliance/lookups/AddonSTIGs/ directory. This is the default directory that the script will use to look for these files. You can also put them in another location and provide that path to the script.

3. Log on to your Splunk Search Head where Atlas STIG Compliance is deployed and locate the file <SPLUNK_HOME>/etc/apps/atlas_stig_compliance/bin/stig-library-addon.py.

4. Execute the stig-library-addon.py script from the command line using the command listed below. The script assumes that Python3 is installed on your Splunk environment. You can validate this using the python --version command. The path parameter is optional if you placed your STIG template files in the default directory listed above. It is critical to note that any older versions of STIGs that are already in the STIG Library will be ignored by this script. STIG Library does not support having more than one version of a STIG loaded into the library at one time.

   python stig-library-addon.py --path=<path to directory>

5. Upon execution the script look at the directory specified and will locate any file that ends with xccdf.xml and will attempt to load it into the STIG Library. The script will provide output if there are any failures during execution.

6. Upon successful completion of the script, validate that the new STIG(s) have been added to the system by searching the STIG Library dashboard for the STIG(s) that you expect to see. These STIG(s) should now also appear in the rest of the STIG Compliance app.

note

If you upgrade the STIG Compliance Element to a newer version, you must rerun this script to add any extra STIGs back to the library.

Promoting STIG Checklists to New Versions

STIG Compliance subscribes to the concept of 'auto-promotion' of STIGs which means that the STIG Compliance App will automatically upgrade your STIG Checklists to the latest version of the STIG that is loaded into STIG Library. This means that if you upgrade a STIG to a later version by updating the STIG Library or upgrading the STIG Compliance Atlas Element the version of the STIG Checklist will automatically be upgraded.

The auto-promotion process does not evaluate the content of the STIGs to see if anything has changed. It assumes that your want to carry your vulnerability statuses forward to the new version.

warning

You must manually determine if there have been STIG changes between versions that impact your implementation. This is critical to ensure that your documentation matches your actual system configuration. STIG Compliance does not validate or evaluate the changes between STIG versions.

Web and Database Instance STIGs

A STIG checklist contains optional fields that are typically used for web and database instance STIGs. Atlas STIG Compliance treats these fields different than other STIG checklists. Each instance is automatically treated as a separate target. This means that if you have STIG that is for a database server and then have instance STIGs for each of the databases on that server, they must be their own target. This is similar to how DISA's STIG viewer handles this type of STIG. Instance STIGs that have the Web or Database fields populated will be automatically assigned as a new target named using the values from the hostname field and the value(s) from the web and/or instance fields.

For example, a STIG checklist for a host named 'host1-db1' with a value of 'instance1' in the instance field, the target will automatically be named 'host1-db1 [Instance: instance1]' by STIG Compliance. You will have to assign these targets to your systems just like you do any other STIG.

The Site field works exactly the same way. If a host named 'webserver1' with a value of 'site1' in the Site field, the target will automatically be named 'webserver1 [Site: site1]'.

If both the web and instance fields are populated with values STIG Compliance will use both values and create a target with both site and instance in the name.

Updating Existing STIG Data to utilize Web and Database Instance STIGs

If you have STIGs in your inventory that use the web and/or database instance field in the STIG checklist (this would be prior to STIG Compliance v1.6.0 in Atlas v2022.3.2), you must follow these steps below to make sure they appear in STIG Compliance correctly. If you have not been utilizing the web or database instance fields, or have not installed STIG Compliance prior to 1.6.0, this does not apply to your STIG Compliance installation.

1. Upgrade Atlas STIG Compliance to version 1.6.0 (Atlas V2022.3.2) by obtaining the package from the customer portal

2. Manually execute the Atlas STIG Compliance State search found in the Search and Reporting App with a time range that includes the most recent STIGs with the web and database instance fields used

3. Manually execute the Update Compliance State search listed below to correctly label the state of targets

Update Compliance State

| inputlookup atlas_compliance_state
| eval dest=dest_host.if(WEB_OR_DATABASE=="true", if(isnotnull(WEB_DB_SITE) and WEB_DB_SITE!="null", " [Site: ".WEB_DB_SITE."]", "").if(isnotnull(WEB_DB_INSTANCE) and WEB_DB_INSTANCE!="null", " [Instance: ".WEB_DB_INSTANCE."]", ""), "")
| lookup atlas_STIG_library compliance_test_title as compliance_test rule_group_id output rule_severity as rule_default_severity
| eval _key=dest.compliance_test.rule_group_id
| outputlookup atlas_compliance_state

4. Manually execute the Update System Groups search listed below to restructure systems data to work with historical data

Update System Groups

| inputlookup atlas_compliance_systems 
| mvexpand targets 
| rename _key as key
| join type=left max=0 targets
    [ inputlookup atlas_compliance_state 
    | stats c by dest_host dest
    | rename dest_host as targets
    | table targets dest ]
| eval targets=dest
| stats values(targets) as targets by key, name, description, owner, owner_contact
| rename key as _key
| outputlookup atlas_compliance_systems

Reporting Tools

STIG Compliance comes with several pre-developed reports that can be used to accomplish different auditing and reporting tasks with the data you have in your STIG Compliance inventory. These reports utilize the power of Splunk to automate many tasks and help you to get data out of Splunk for other reporting purposes.

Vulnerability Changes Report

The Vulnerability Changes Report provides a single dashboard for reviewing change across Systems, Targets, and STIGs. This dashboard identifies specific vulnerabilities on targets that have experienced any fluctuations in their reported Status in a selected time range.

Vulnerabilities will appear on this table if there has been any data in the selected time range that does not match the current state of the vulnerability. This includes the following examples:

• A vulnerability that has been Not A Finding for the majority of the time range, but in the past hour has been marked Open, will be recorded as a status change to Open
• A vulnerability that was marked Open at the start of the time range, was briefly marked Not A Finding, and then was marked Open shortly after, will be recorded as a status change to Open
• A vulnerability that has just been ingested for the first time with the status Open will be recorded as a status change to Open

Selecting a status change KPI will filter the table to only show the vulnerabilities with that current status. Select the Vulnerabilities with Status Changes KPI to revert back to viewing all changes.

Selecting a vulnerability in the table will reveal an investigation table that shows all changes in the time range.

Checklist Audit

The Atlas STIG Compliance App provides an audit tool that can evaluate the STIG Checklists that you have in your inventory. The Checklist Audit report tool will look for STIG Checklists that have missing comments or finding details fields. You can then either export the list out to a csv file or you can edit the comments in the Splunk UI by clicking on the Edit icon next to the item in the report. Clicking the Edit icon will take you to the Edit Checklists screen. There you can update the finding details or comments for that vulnerability across one or multiple targets.

1. Filters: Filter by system, target machine, STIG, and time range of available data.

2. Checklist Summary: Shows total number of STIG checklist files selected, and how many of those have missing data.

3. Affected Checklists: Table of STIG checklists in the given filter criteria. Each row will give a description of the checklist, host, time of last import, and how many instances of missing data (Comments or Fix text) are present in that file. Selecting a checklist will prompt an Audit Report panel to generate below.

   

4. Title Block: STIG title for the selected checklist file.

5. Summary of Missing Info: Highlights the missing Comments and missing Fix Text for the selected checklist.

6. Vulnerabilities with Missing Data: Information about which specific vulnerabilities are missing data. Table presents identifying information about each vulnerability as well as what field is missing.

7. Edit: Button at the end of each row which will direct the user to the Edit Checklists page, with all applicable filters preset, so users can easily remediate missing data.

Export Checklist

The Export Checklist dashboard is used to easily export one or many STIG checklists to be transferred or viewed in the standard checklist format expected by the DISA STIG Viewer tool. This dashboard allows the user to either download individual checklists or download a zip file containing any number of checklists for the given search criteria provided in the UI.

1. Filters: Filter by system, target machine, STIG, and time range of available data. Additionally, toggle between searching specific named system or the entire suite of compliance data using the radio toggles.

2. Export Comment and Finding Detail History: Selecting this checkbox will append the five most recent Comments and Finding Details to each vulnerability, separated by a timestamp. Use this option to provide an audit trail of system changes. Leaving this unchecked will only export the most recent Comments and Finding Details.

3. Bulk Download: Selecting this will download all selected checklists as a zip file. The button will display how many checklists will be exported.

4. Download Individual Checklist: Use this to download the checklist for the displayed checklist in that row.

5. Preview Pane: Expanding any row will show a preview of what the checklist will look like on export. This is the standard checklist xml format used to view data in the DISA STIG Viewer.

To export STIG checklists from STIG Compliance use the following procedure:

1. Filter the data you want to export using the filters at the top of the page

2. Check the Export Comment and Finding Detail History checkbox if you want that data included in your STIG checklists

3. Select the Download Selected Checklists button to download a .zip file of all STIG Checklists selected

4. Select the Download icon next to the target in the list to download the STIG checklist for that target

5. If you want to preview the XML prior to downloading you can also do that by clicking on the arrow icon to expand the selection

Export Data

The Export Data dashboard is a tool used to export a collection of checklists based on filter criteria. This tool can be used to automate generation of POA&M lists or provide an aggregate list of controls to appropriate stakeholders. This can also be used to export data to additional systems in csv, xml, or json format.

1. Filters: Allows user to filter by system, target machine, STIG, vulnerability, status, vulnerability, and time options.

2. Export Preview: Shows a preview of selected data based on filters. Hover over this table to expose the export button.

3. Export button: Presents a modal to the user to allow the data to be exported as CSV, XML, or JSON.

POA&M Helper

The POA&M Helper dashboard is a powerful tool that uses CCI correlation data to join STIG Vulnerability data back to RMF Controls. Users can filter by System, Targets, STIGs, NIST Control Groups, and individual NIST Controls to create reports that meet their needs. Using this dashboard, users can jump-start POA&M creation by identifying notable NIST Controls with vulnerabilities with statuses selected in the Vulnerability Status filter (defaults to Not Reviewed and Open). This can be used to find Controls that have associated open vulnerabilities to better understand overall RMF Compliance.