Put our three-level approach into play for efficient, secure, and cost-effective software compliance with DISA ASD STIG.
Your software team can simplify compliance to the DISA ASD STIG guidelines. To satisfy auditors, proof of compliance is usually in the form of documentation. Parasoft recommends a three-level approach for achieving compliance for software development in an efficient, secure, and cost-effective manner.
Our approach is the key to achieving DISA ASD STIG compliance by verification and documentation with the goal of maturing the process beyond detection into prevention of security vulnerabilities. It includes:
Defense Information Systems Agency (DISA), Application Security and Development (ASD), and Security Technical Implementation Guides (STIG) is a set of guidelines for securing desktop and enterprise applications used by the Department of Defense.
The guidelines cover in-house application development and the evaluation of third-party applications. They don’t cover commercial off-the-shelf software.
The DISA ASD STIG uses a severity category code to organize and prioritize the guidelines based on the possible impact of an exploit of the particular guideline.
Following are the DISA category code guidelines:
CAT I: Any vulnerability, the exploitation of which will directly and immediately result in loss of Confidentiality, Availablity, or Integrity.
CAT II: Any vulnerability, the exploitation of which has a potential to result in loss of Confidentiality, Availablity, or Integrity.
CAT III: Any vulnerability, the existence of which degrades measures to protect against loss of Confidentiality, Availablity, or Integrity.
Compliance to the guidelines is evaluated against product and process documentation as well as observing and verifying 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
The previous version (v3.x) of the DISA ASD STIG required the use of static code analysis along with specific static analysis guidelines to check against. This isn't the case with the current version.
The latest revision 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:
This might look like a small list of vulnerabilities. The reality is that it translates into many related software weaknesses.
The Open Web Application Security Project (OWASP), as the name implies, is an organization that is 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.
Compliance to the OWASP Top 10 centers around making reasonable efforts to avoid the most common and critical security issues facing web applications today. While it’s possible to use static analysis tools to detect most of the issues, some are not statically analyzable. A9, for example, is related to Software Composition Analysis (SCA).
Parasoft’s software testing solutions support the entire software development process, from when the developer writes the first line of code all the way through
+1-888-305-0041
