Join Us on Apr 30: Unveiling Parasoft C/C++test CT for Continuous Testing & Compliance Excellence | Register Now

Ease DISA ASD STIG Compliance With Standards-Native SAST

Headshot of Arthur Hicken, Evangelist at Parasoft
June 13, 2022
5 min read

Securing enterprise applications used by the Department of Defense is critical to its mission, but application security at this scale can be daunting. See how Parasoft’s SAST tool can make this less of a hassle.

What Is DISA ASD STIG?

Defense Information Systems Agency (DISA), Application Security and Development (ASD), and Security Technical Implementation Guides (STIG) are a set of guidelines for securing desktop and enterprise applications used by the Department of Defense. The guidelines cover in-house application development specifically.

The DISA STIG for application security and development (DISA ASD STIG) can be intimidating. With almost 300 items to check, you might wonder how you’re ever going to be compliant, let alone where to start. But with the right approach, using the STIG to secure your applications doesn’t have to be too hard.

Requirements to Achieve Compliance With DISA ASD STIG

Achieving compliance with the DISA ASD STIG guidelines requires evidence, usually in the form of documentation, that satisfies auditors. This post discusses how Parasoft’s static application security testing (SAST) tools can help achieve compliance in an efficient, less risky, and cost-effective manner. To achieve this, both detection and prevention methods are recommended.

  • Application scanning with static analysis tools to ensure vulnerabilities are detected and remediated in the application. The DISA-ASD- STIG has specific guidelines on what classes of vulnerabilities to detect and remediate.
  • Shift-left compliance with preventative processes, which 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 Top 10 and SEI CERT C/C++. It also includes guidelines like the removal of “code smells”, which are poor practices known to be the root cause of software vulnerabilities.

How Is Compliance With DISA ASD STIG Evaluated?

Compliance with the guidelines is evaluated against product and process documentation as well as observing and verifying functionality.

Infographic listing DISA category code guidelines for Categories I, II, III.

2.1.2 Functionality

When reviewing an application, aspects of application functionality must be evaluated to ensure the appropriate controls exist to protect the application and the application
data. Items to consider include the type of data processed by the application such as classified, unclassified, and publicly releasable or Personally Identifiable Information (PII) data. The application’s network connections, network access controls, data entry/egress points, application authentication mechanisms, application access controls, and application auditing mechanisms. These items will vary based upon application architecture, design, and data protection requirements. —ASD STIG Overview, V4R9

In other words, the STIG requires evidence of secure design and implementation through documentation, verification, and validation of all aspects of the software development life cycle, including deployment and operation. These guidelines apply throughout the lifetime of the product including configuration, maintenance, and end of life.

DISA ASD STIG requires the use of application code scanners (Overview, Section 4.1) “…an automated tool that analyzes application source code for security flaws, malicious code, and back doors.” In more common terminology this is static application security testing (SAST) implemented through static code analysis and “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.”

How to Approach DISA ASD STIG Compliance for Software Development

What’s the Role of SAST Tools in DISA ASD STIG Compliance?

Version 3.x of the DISA ASD STIG required the use of static code analysis along with specific static analysis guidelines to check against. However, this is not the case with version 5, release 1.

V5.R1 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 requirements for:

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

On the surface, this looks like a small set of vulnerabilities. However, it translates into many related software weaknesses. For example, the OWASP Top 10 converts to over 50 CWEs, each of which has multiple related weaknesses.

Although this is the minimum set of vulnerabilities specific for compliance, it’s prudent to consider a wider swath of vulnerabilities to detect. This streamlines the STIG audit by detecting insecure code early before vulnerabilities occur.

Leverage Automation & a Shift-Left Approach for DISA ASD STIG Compliance

To ease complying with DISA ASD STIG, Parasoft recommends leveraging automation where it makes the most sense and using preemptive techniques to prevent vulnerabilities.

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

Developers are less concerned with the larger scope of DISA ASD STIG requirements. However, there are critical steps they can take to make life easier and reduce the backend workload during audits. A preventive, shift-left approach that makes use of automation is the key for developers.

Shift Left Testing With Code Analysis

Using static analysis right from the start of development prevents vulnerabilities from making their way into the software in the first place. It’s also a good way to assess the quality and security of legacy or third-party source code.

Turn on Code Smells & Preventative Standards Checkers to Harden the Code

Beyond direct detection of bugs and vulnerabilities, it’s important to prevent poor coding styles that can end up being a problem later. These are based on the work done by Kent Beck and Martin Fowler that outlines potential problem areas in poorly designed code, such as duplication or functions/methods being too large and complex, as areas where bugs and vulnerabilities are likely to manifest.

Use a Tool With Standards-Native Support

DISA ASD STIG specifically requires scanning for certain types of vulnerabilities, which developers do using an advanced static analysis tool that collates and analyzes results for later reporting and audits. Parasoft provides SAST checkers that work in a standards native format, using names and severity levels as defined by DISA ASD STIG. This avoids tedious mapping exercises to connect vulnerabilities to requirements in the STIG.

Parasoft static analysis has out-of-the-box support for DISA-ASD-STIG and OWASP Top 10, as well as out-of-the-box support for other common security standards like CWE and CERT, through preconfigured settings and specific web dashboard reports for C, C++, C#, Java, and VB.NET.

How to Choose a Modern Static Analysis Tool

DISA ASD STIG reporting in Parasoft tools provides a fully auditable compliance framework for projects. These reports are integrated into a standards-native dashboard. The test configuration, which is available in 2022.1 versions of C/C++test, dotTEST, and Jtest automated software testing solutions, makes it easy to automatically incorporate and demonstrate conformity into reports and prove compliance during an audit—saving time, labor, and costs. The native configuration also covers a broad range of security issues to improve software readiness for the functional part of the audit.

Parasoft DISA-ASD-STIG dashboard

Summary

The DISA ASD STIG presents a fairly daunting set of requirements for securing software for DoD applications. There are various methods of demonstrating compliance with the rules outlined in the STIG—usually through audits of documentation, reports, and manual effort to use an application and check its logs. There are opportunities for automation in key areas outlined in the STIG such as application code scanning. A standards-native SAST solution streamlines compliance with visibility provided by standards-native checkers and dedicated DISA ASD STIG format configurations.

A pragmatic approach that emphasizes preventative techniques that remove vulnerabilities early in the project life cycle works best. Parasoft’s SAST tools provide early detection of vulnerabilities and enforce code style and quality to prevent poor security practices as early as possible.

Detect vulnerabilities early and build quality into your software process from the beginning with Parasoft’s DISA ASD STIG SAST solution.

Related Post + Resources