The Role of SAST for Application Scanning in DISA ASD STIG Compliance

Defense Information Systems Agency (DISA), Application Security and Development (ASD), and Security Technical Implementation Guides (STIG), known as DISA ASD STIG, is a technical implementation guide about application security and development for the defense information systems agency. There are many STIGs for securing different parts of DoD infrastructure and services, however, the ASD guidelines cover in-house application development and the evaluation of third-party applications.

Achieving compliance with the DISA ASD STIG guidelines requires proof, usually in the form of documentation, that satisfies auditors. This post covers:

• Challenges associated with achieving compliance with DISA ASD STIG
• Parasoft’s recommended approach to achieving compliance in an efficient, less risky, and cost-effective manner.
• Requirements that specify the use of application scanners or application code scanners, which teams can validate with static analyzers.

Understanding DISA ASD STIG Compliance Challenges

The DISA ASD STIG provides a detailed set of guidelines for enhancing the security of software systems, primarily within the Department of Defense (DoD). The compliance authority assesses whether or not systems and software are configured to meet Defense Information Security Agency (DISA) requirements. Failure to comply with DISA STIGs can block or delay the deployment of your software.

Given the extensive nature of this compliance guideline, government agencies and defense contractors often encounter several challenges when trying to meet DISA ASD STIG compliance requirements. Some of these challenges include the following.

• Requirements are complex. DISA ASD STIGs consist of a large number of specific security controls, configurations, and recommendations. These guidelines cover a wide range of areas, such as authentication, access control, encryption, network settings, and more. The sheer volume of guidelines, along with their technical depth, can make it challenging for organizations to understand, interpret, and implement them correctly. Ensuring that every guideline is properly addressed across various systems and components requires meticulous attention to detail and expertise in security configurations.
• Issues with legacy systems. Many government agencies and DoD branches operate legacy systems that have been in use for years, if not decades. These systems might not have been designed with modern security principles in mind, and their architecture could be incompatible with some STIG requirements. Reconfiguring these legacy systems to meet current security standards can be a significant challenge. Quite often, it involves rewriting code, updating hardware, or even replacing the systems entirely, all of which can be costly and disruptive.
• Documentation and reporting. DISA ASD STIG compliance requires thorough documentation of the security configurations, changes made, and the rationale behind those changes. Organizations must maintain detailed records to demonstrate their adherence to the guidelines. Generating accurate and comprehensive reports for auditing purposes is essential, but this can be time-consuming and might introduce administrative overhead. Failure to maintain proper documentation can lead to difficulties during audits or when addressing security incidents.
• Diverse IT infrastructure. Government organizations and DoD components often operate complex and diverse IT environments. They may use a variety of operating systems, hardware, software applications, and networking equipment. Each of these components can have different security requirements and settings. Therefore, customizing the implementation of STIG guidelines to suit specific characteristics of each technology can be time-consuming and may require specialized knowledge and primarily manual effort.
• Balancing security and interoperability. Collaboration and information sharing are essential within government and defense institutions. Different agencies or components often need to work together using interconnected systems. However, implementing strict security controls to achieve compliance might hinder interoperability or data sharing within these agencies. So, the challenge here is about striking the right balance between enforcing security measures and maintaining seamless communication. In trying to ensure the right balance, adjustments might need to be made to configurations or workflows to accommodate both security and collaboration needs.
• Continuous monitoring and maintenance. Compliance is not a one-off task. It requires monitoring and maintenance whenever the system is updated to ensure that systems remain secure over time. Achieving initial compliance with DISA ASD STIG guidelines is just the starting point. The bulk of work lies in ensuring ongoing compliance, which requires organizations to establish processes for continuous monitoring and maintenance. Doing this may involve reviewing systems, configurations, and security measures regularly to identify any deviations from the established STIG requirements. However, this task can be daunting due to factors such as evolving DISA ASD STIG guidelines, system changes, evolving threat landscape, and the cost of the manual effort typically needed to assure compliance.

Three-Level Approach to Software Development Compliance

To achieve compliance, a three-level approach to validation is required:

• Application code scanning detects vulnerabilities with static analysis tools to ensure remediation in the application. The ASD STIG has specific guidelines on what classes of vulnerabilities to detect and remediate.
• System testing for security with functional and penetration testing tools verifies and validates DISA ASD STIG requirements.
• Shift-left compliance with preventative processes eliminates poor coding practices that lead to vulnerabilities. This wider swath of detection includes application scanning and the application of industry coding standards such as OWASP, CWE, or CERT secure coding. It also includes guidelines like the removal of “code smells”, which are poor practices known to be the root cause of software security vulnerabilities.

This 1-2-3 punch is the key to achieving compliance by validation and documentation. The goal is to mature the process beyond detection into the prevention of security vulnerabilities.

What Does Compliance With DISA ASD STIG Mean?

The ASD STIG uses a severity category code (CAT I, CAT II, CAT III) to organize and prioritize the guidelines based on the possible impact of an exploit of the guideline.

Evaluating product and process documentation as well as observing and verifying functionality against the guidelines determines compliance. In other words, the STIG requires evidence of secure design and implementation through documentation, verification, and validation of all aspects of the software development lifecycle. That includes deployment and operation. These guidelines apply throughout the lifetime of the product from configuration, deployment, maintenance, and end of life.

Static Application Security Testing

Important to the discussion in this post is the requirement for application code scanners:

“…an automated tool that analyzes application source code for security flaws, malicious code, and back doors.” —DISA ASD STIG Overview, Section 4.1

In more common terminology, this is static application security testing (SAST) implemented through static code analysis. It “should be utilized whenever possible. Particularly in the development environment where code that has been identified as requiring remediation can be addressed prior to release.” The ASD STIG also contains the following guidance:

“An application scanner can be used to test development or production application systems for security vulnerabilities resulting from either application code errors or application system misconfigurations. These vulnerabilities include SQL Injection, Code Injection, Cross Site Scripting (XSS), file disclosures, permissions, and other security vulnerabilities that can be found in network accessible applications” —DISA ASD STIG Overview, Section 4.2 – Application Scanner

The ASD STIG requires the use of active vulnerability testing, for example, pen testing tools or DAST, to test executable software. These tools are required during development and deployment to support vulnerability assessments.

DISA ASD STIG Validation Methods

The ASD STIG outlines ways to verify compliance with requirements, which include:

• Application code and application scanning
• Manual review
• Functional security testing

Teams use SAST tool reports and audits to validate applications and code scanning. Functional testing is verifying with automated tools or manual testing that the vulnerability is not present in the software. In other words, think about the approach as “do something, check something”. For example, check if the action worked properly and was logged if necessary). These approaches suit automated testing because of the efficiency and the audit trail tools provide.

A Pragmatic Approach to DISA ASD STIG Compliance With Static Analysis Tools

The reality of software development for DoD, which requires DISA ASD STIG, is that you must test for all requirements and vulnerabilities. It can be a daunting task, but automation is possible to lift some of the burdens.

Parasoft’s recommendation on how to approach complying with DISA ASD STIG is to leverage automation where it makes the most sense, such as in CI/CD pipelines or DevSecOps processes. The goal is to ease the burden of compliance, use pre-emptive techniques to prevent vulnerabilities, and ultimately achieve continuous compliance.

It’s more expensive and time-consuming to detect and fix vulnerabilities when the software is almost complete versus during development. For this reason, Parasoft’s approach is to shift left assessing, detecting, and remediating vulnerabilities earlier in the life cycle.

Satisfying DISA ASD STIG Application Scanning Requirements With Static Analysis

The DISA ASD STIG uses the term “application scanning”, which amounts to static code analysis and related technologies such as software composition analysis. In addition to the general requirement for vulnerability assessment via static code analysis, there are specific requirements to scan for specific vulnerabilities such as:

• OWASP Top 10 (V-69513)
• Overflows (V-70277)
• Race conditions (V-70185)
• Error handling (V-70391)

Although this looks like a small set of vulnerabilities, the reality is this translates into many related software weaknesses. For example, the OWASP (Open Web Application Security Project) Top 10 translates to over 50 CWEs. Each can have multiple related weaknesses.

Although this is the set of vulnerabilities specific for compliance, it’s prudent to consider a wider swath of vulnerabilities to detect. In addition, it’s important that teams expand their focus beyond the guidelines in the DISA ASD STIG to include preventative guidelines like those included in common industry secure coding standards.

As the name implies, the OWASP Top 10 is an organization committed to improving the security of web applications. Their OWASP Top 10 project provides a list of the most common and high-impact web application security vulnerabilities.

Integrating With SCA Tools

While it’s possible to use static analysis tools to detect most of the issues, some are not statically analyzable. The guideline to avoid software with known vulnerabilities is related to software composition analysis (SCA). Parasoft supports this by integrating with SCA tools with our static analysis output into a single report resulting in full Top 10 coverage.

Parasoft static analysis has out-of-the-box support for OWASP Top 10 through preconfigured settings and specific web dashboards for C/C++, Java, and C#/.NET. OWASP reporting in Parasoft DTP provides a fully auditable compliance framework for projects. The standards-specific dashboard, like the one below for DISA ASD STIG, provides an easy way to continuously monitor status.

Parasoft implemented all the major application security standards, such as SEI CERT secure coding, CWE (Common Weakness Enumeration) coding guidelines, UL 2900, OWASP, and security-specific dashboards for each. This helps users understand risk and prioritization of outstanding violations/vulnerabilities/security defects.

Security-Focused Reports

Compliance reports are available on demand. Compliance criteria is flexible and specific to the team’s project and codebase. Developers can craft policies based on severity, risk, impact, age of code, the importance of components, and so on. They can use them to easily guide development and show efforts to an auditor. Developers can also pass policies to the security team to integrate with the results of other parts of security testing, such as the OS, network, and more.

One of the crucial aspects of static analysis tools is reporting and analytics capabilities. Projects create a large amount of data in terms of warnings and are multiplied build by build. Data management is key to the successful adoption and return on investment for static analysis tools.

Dashboards, reports, and conformance tuned for each coding standard and security guideline are critical. Parasoft analytics leverage industry-standard risk models and multiple artificial intelligence (AI) and machine learning (ML) techniques to prioritize the security warnings and help developers focus on the most critical issues with the biggest impact.

Ensuring DISA ASD STIG Compliance With SAST

The DISA ASD STIG presents a daunting set of requirements for securing software for DoD applications. There are various methods of demonstrating compliance with the rules outlined in the STIG. The usual methods include:

• Audits of documentation
• Reports from tools like static analyzers and others
• Manual effort to investigate application logs, if necessary

The STIG outlines key areas of opportunity for automation such as application code and application scanning. Static analysis helps achieve some of these.

A pragmatic approach eases the compliance burden and encourages preventative techniques that remove vulnerabilities early in the project lifecycle. Parasoft’s static analysis provides early detection of vulnerabilities. This solution enforces code style and quality to prevent poor security practices as early as possible.