Security Technical Implementation Guides (STIGs) are configuration standards developed by the Defense Information Systems Agency (DISA). They are designed to make device hardware and software as secure as possible, safeguarding the Department of Defense (DoD) IT network and systems.
Compliance with STIGs is a requirement for DoD agencies, or any organization that is a part of the DoD information networks (DoDIN). This includes defense contractors that connect to the DoD network or system.
There are hundreds of STIGs designed for specific software, routers, operating systems and devices. DoD agencies may use off-the-shelf IT products within their network and infrastructure and STIGs ensure these products are as secure as possible, in contrast to the default vendor configurations that may favor usability over security.
Hardening the configuration of IT solutions helps to mitigate vulnerabilities and lower the risk of cybersecurity incidents. The creation of a STIG will also be key to gaining approval for a product to be used within the network. This guide explores DISA STIGs, what they consist of, and an overview of solutions that can help your organization achieve compliance.
What is a DISA STIG?
The Defense Information Systems Agency is part of the US Department of Defense. It is a support agency that focuses on maintaining the IT services and infrastructure of the DoDIN. DISA provides IT and communications systems to all parts of the defense network, whether for combat or non-combat operations. The DoD relies on its IT systems and networks to operate effectively. A major focus for DISA is making the DoD network secure and resilient against cybersecurity threats and possible risks. It achieves this aim by focusing on infrastructure and network security, and strengthening cybersecurity measures, including boundary defense and endpoint security.
Security Technical Implementation Guides (STIGs) are a principal way that DISA works to safeguard DoD network resilience and protect government information systems from cybersecurity threats and malicious attacks by strengthening baseline security configurations. STIGs provide security standards for a range of specific products and solutions, and consist of controls, requirements and policies for securing networks, software and devices that are part of the DoDIN.
What is STIG Security?
Security Technical Implementation Guides (STIGs) are a series of cybersecurity requirements for IT products deployed within DoD agencies. STIGs are the source of configuration guidance for network devices, software, databases and operating systems. The aim is to lower the risk of cybersecurity threats, breaches and intrusion by making the set-up of the network as secure as possible.
Organizations that connect to DoD systems or networks must be STIG compliant. This applies to defense agencies, defense contractors that connect to DoD systems, and other federal agencies.
Topics for STIGs include:
- Cloud networks
- Mobile devices
- Operating systems
- Routers and servers
- Network devices
There have been hundreds of STIGs released to date, all covering a range of networks, operating systems, network devices and software. The guidance helps to seal off devices and software from outside influence or vulnerabilities, protecting the entire network. There are also guidelines for broader cybersecurity policies, such as user access.
Beyond products and software, STIGs can cover whole system architecture and configuration of many network elements together. Complex STIGs may include firewall, router, and server configurations. One system might require multiple overlapping STIGs to securely configure each element.
STIGs are also designed for specific versions of devices, operating systems and software. Therefore, unique vulnerabilities may need to be considered with each iteration.
How are STIGs developed?
New and updated STIGs are released by DISA every quarter, though some may be released in response to emerging threats and issues. The updates take into account version changes by the vendor, which may change configuration requirements, or to mitigate new vulnerabilities.
STIGs are developed either entirely by DISA, alongside other government agencies and departments, or by the software or device vendors themselves. In the first instance, internal specialists from DISA will design and update STIGs to meet emerging technologies or threats.
STIG compliance is needed for products or IT services to operate on DoD networks and systems. Each STIG assesses the product against DoD cybersecurity requirements. In many cases, DISA will work with the vendor to develop a STIG and ensure the product is compliant with DoD requirements.
STIG controls focus on being highly secure, which can impact functionality of software and applications. Vendor involvement in the development of a STIG means a balance of functionality and security.
When an IT solution is superseded by a newer product or is no longer supported, the relevant guidance becomes a ‘sunset STIG’. This means DISA is no longer actively updating the STIG, though the guidance is still available for legacy tools and software.
In 2020, DISA updated the systems that produce STIGs to provide increased flexibility for future developments. This has resulted in a modification to Group and Rule IDs (Vul and Subvul IDs). New and updated STIGs are now being published with the modified content.
DISA STIG requirements
There are hundreds of different STIG requirements covering a range of products, software versions, and operating systems. STIG requirements are comprehensive, and include mobile devices, operating systems, cloud networks, and applications. Requirements cover all areas of device or software configuration to achieve secure integration. This is to maintain security of the systems and prevent breaches or cybersecurity incidents.
Government systems will use a range of off-the-shelf software, servers, and network devices. STIG requirements make commercially available operating systems, devices and servers as secure as possible. Out-of-the box software, servers and devices need to be configured to lower the risk to the wider network. By setting minimum requirements when integrating a new system or IT product, DISA helps improve the resilience of government networks against attacks and outages.
Federal IT systems process and store highly sensitive information, and therefore a data breach or loss of service could have a direct impact on matters of national security. However, the default settings and configurations provided by product manufacturers generally will not meet the security requirements needed to safeguard DoD systems. STIG requirements strengthen the resilience of the system infrastructure as a whole, mitigating known vulnerabilities in software and networks.
What are the DISA STIG compliance levels?
The vulnerabilities mitigated by each STIG requirement have different levels of potential threat. These range from vulnerabilities at immediate risk of significant exploitation to indirect risks that affect the general security of the system. Compliance with the most at-risk controls is of utmost importance.
Each control found within the STIG has a compliance level assigned to it. The level corresponds to the degree of risk from the vulnerability or threat. There are three categories of severity, ranked on level of risk or vulnerability. These are known as Severity Category Codes (CAT), with CAT 1, CAT 2 and CAT 3 levels of risk. CAT 1 controls cover the most severe vulnerabilities and risks.
CAT 1 STIG compliance level
STIG category 1 controls cover the settings most at risk of serious exploitation. If exploited by a malicious attack, these vulnerabilities are the most significant threats to the wider network. If unchecked, CAT 1 vulnerabilities are likely to directly lead to data breaches or loss of services. These are deemed as high severity and should be resolved first.
CAT 2 STIG compliance level
STIG category 2 covers the settings or vulnerabilities that have the potential to result in a cybersecurity issue. Although the risk of incident is still high, CAT 2 would not cause the immediate loss in system integrity as outlined in CAT 1. These are deemed as medium risk and severity and can lead to a CAT 1 vulnerability if left unchecked.
CAT 3 STIG compliance level
STIG category 3 controls cover settings that lower the defenses of a system or network if left unchecked. These heighten the risk of cybersecurity attacks or system failure, but will not lead directly to either. These are deemed as low risk and low severity, though can lead to a CAT 2 vulnerability.
How to implement DISA STIG
DISA STIGs are comprehensive technical guides that outline controls to counter security risks and known vulnerabilities. STIGs take the form of a checklist of configurations to help with implementation, but hundreds of controls can take up time and resources.
The challenge comes from staying compliant as new versions are released, and the varying degree of input needed to meet each requirement. STIGs may include guidance on minimum levels of training for personnel, frequency of update, or configuration settings.
Here are some tips on how best to implement a STIG, including where to find the guidance and what tools are available to save time and resources when assessing STIG implementation and compliance.
Finding STIGs to implement
STIGs are available to browse and download from the STIG catalog, which is kept updated by DISA. Remember to check that the required STIG is the latest edition or fits the specific version of the device being configured. STIG updates are usually made every quarter to keep in line with emerging vulnerabilities or software updates from the vendor.
The newest version of a specific STIG will have a revision history, outlining any changes in previous documents that have since been revised. The documents are available for download as a ZIP file. Each STIG will have an executive summary that contextualizes the guidance, and many will explain key concepts and terminology. STIGs outline the steps and controls needed to achieve compliance, and the category of risk for each control.
Use a test environment when implementing changes
Organizations usually have a complex network environment, with many different software and device providers. Changes to network settings and configuration may have unintended consequences in this complex environment, so should always be tested. Otherwise, there could be loss of functionality.
Generally, STIG configurations favor security over anything else, so it is possible that software or devices may lose some degree of functionality. Configuration changes should always be tested in a staging environment before being rolled out to the live network. Making the initial changes in a test environment is a vital step in resolving any loss of functionality before deploying to your live environment.
Assessing STIG compliance
Security teams can now use tools that automate STIG compliance checks, helping to fine-tune and speed up the audit process. For assessing network devices, these tools either scan the network or audit network devices, checking for compliance with the preset configuration rules. Some scanning tools will require that the STIG is uploaded to the tool in Security Content Automation Protocol (SCAP) format.
A configuration benchmark for compliance will be used as a basis for the scan or audit. This way, non-compliance can be efficiently highlighted. Compliance scans or audits can then be scheduled regularly as part of the organization’s cybersecurity program.
Some STIGs may not have SCAP versions so will need to be checked manually for compliance. In this process, an auditor goes through the STIG rule by rule, testing compliance with each control. In this case, the STIG will outline the pass state and how to implement it, or the failure state of the rule and how to resolve it.
Maintaining STIG compliance
Technology and software are perpetually advancing, accordingly, IT products will continuously be updated to eliminate vulnerabilities, fix bugs, and introduce new features. But new versions can equally introduce new vulnerabilities and issues.
STIGs are usually updated every quarter to reflect new versions from the vendor or new vulnerabilities or threats. New STIGs for different versions of the same software are regularly released. The final challenge for an organization is maintaining compliance as the guidelines and risks evolve. Organizations should make sure they are aware of any updates that affect their systems and continuously monitor their compliance.
Tools for STIG compliance audits
With hundreds of different controls, STIG compliance audits can require significant resources to complete manually. Guidance is regularly updated, so keeping track of compliance can add to the drain on time and resources. Automated auditing tools that check against the latest STIGs requirements can save valuable time.
Titania has developed trusted solutions for automating STIG audits that reduce the resources required to achieve, evidence and maintain a secure and compliant environment.
Titania Nipper accurately detects vulnerabilities in firewalls, switches and routers and recommends exact fixes, helping teams save time when auditing STIGs compliance. Get a free trial of Titania Nipper to see how it can save time and resources when auditing STIG compliance.