The Role of SAST for Application Scanning in DISA ASD STIG Compliance
By Arthur Hicken
December 22, 2020
6 min read
Jump to Section
DISA ASD STIG includes the Defense Information Systems Agency (DISA), Application Security and Development (ASD), and Security Technical Implementation Guides (STIG). They’re a set of guidelines for securing desktop and enterprise applications used by the Department of Defense. There 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 to the DISA ASD STIG guidelines requires proof, usually in the form of documentation, that satisfies auditors. This post covers:
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.
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. See The Role of Functional Test Automation in DISA ASD STIG to learn more.
- 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 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) 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 application 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 but also to use pre-emptive techniques to prevent vulnerabilities. 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 the vulnerability assessment, detection, and remediation earlier in the lifecycle.
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 dashboard reports for C/C++, Java, and C#/.NET. OWASP reporting in Parasoft tools provides a fully auditable compliance framework for projects. These reports integrate into a standards-specific dashboard like the one below for DISA ASD STIG.
Parasoft implemented all the major application security standards, such as SEI CERT secure coding, CWE (Common Weakness Enumeration) coding guidelines, UL 2900, and OWASP, and security-specific dashboards for each. This helps users understand risk and prioritization of outstanding violations/vulnerabilities/security defects.
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.
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.
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 burden of compliance 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.
Learn more about the role of test automation, required aspects of the tools, and a pragmatic approach to implementing DISA ASD STIG in our whitepaper.