This past March, the National Institute of Standards and Technology (NIST) released the NIST Special Publication 800-53, Revision 5, which was their final public draft revision. According to the abstract, “This publication provides a catalog of security and privacy controls for federal information systems and organizations to protect organizational operations and assets, individuals, other organizations, and the Nation from a diverse set of threats and risks… The controls are flexible and customizable and implemented as part of an organization-wide process to manage risk.”
In the context of software security, in section SA-11, DEVELOPER TESTING AND EVALUATION beginning on page 267, this control requires the developer of the system, system component, or system service, at all post-design stages of system development life cycle to:
- Develop and implement a plan for ongoing security and privacy assessments;
- Perform testing/evaluation;
- Produce evidence of the execution of the assessment plan and the results of the testing and evaluation;
- Implement a verifiable flaw remediation process;
- Correct flaws identified during testing and evaluation.
Control SA-11, which is quite comprehensive, also calls out:
- STATIC CODE ANALYSIS
- THREAT MODELING AND VULNERABILITY ANALYSIS
- INDEPENDENT VERIFICATION OF ASSESSMENT PLANS AND EVIDENCE
- MANUAL CODE REVIEWS
- PENETRATION TESTING
- ATTACK SURFACE REVIEWS
- VERIFY SCOPE OF TESTING AND EVALUATION
- DYNAMIC CODE ANALYSIS
- INTERACTIVE CODE ANALYSIS
In light of Control SA-11, it appears that the 9 recommendations above do adhere to industry best practices. However, federal agencies and their software developers will likely be challenged when attempting to release software in today’s fast-paced, iterative world of software releases. The control methods listed above will likely add considerable delays to federal agencies wanting to release new or updated software that supports their mission objectives. Often, federal standards and guidelines driven by FISMA list many sound objectives, but they frequently fail to adequately describe how they can be achieved overall.
Today, many agencies are attempting to adopt DevOps fundamentals within their software development practices, while at the same time, desiring to move toward DevSecOps by adding security practices into the mix. Therefore, agencies are at a crossroads whereby they must (and should) adhere to the proposed NIST requirements, while at the same time trying to pivot quickly like their commercial counterparts who deploy multiple software releases per day. This represents quite the quandary, but it’s not insurmountable. The key is making use of security automation within their software development efforts.
When looking closer at the list above, notice that items 2, 3, 4, 6, and 7 can, in many cases, be performed before the application is developed. These items are often performed no more than once per application overall. On the other hand, Static Code Analysis (1.), Dynamic Code Analysis (8.), and Interactive Code Analysis (9.) should be performed during the software development process itself for every software version and updated sub-version. And finally, Penetration Testing (5.) is normally performed post-delivery and/or deployment. That being said, the real challenge agencies face is how to automate and accelerate the code analysis process during software development, and not allow security to become a roadblock to release.
Recently, and to help agencies chart this complex landscape, DLT partnered with the Institute for Critical Infrastructure Technology (ICIT) aka “The Cybersecurity Think Tank” and top government and industry leaders for an online discussion: Interactive Security Testing, DevSecOps, and NIST SP 800-53 Rev. 5., which was well attended. Jeff Hsiao, ICIT Contributor & Security Solutions Engineer, Checkmarx, AWS, and Dr. Ron Ross participated in the discussion and demonstrated their highly valuable technical insight pertaining to the topic. All agreed that Interactive Security Testing plays an important role in the code analysis process, however, agencies must also consider static analysis, open source analysis, and developer AppSec awareness and training. At the end of the day, vulnerability detection, remediation, and secure coding practices are the goals for all federal agencies.
Here at Checkmarx, we are experts at DevSecOps and fully deliver on automating code analysis and vulnerability remediation during the software development process. In fact, we scored highest for the DevOps/DevSecOps use case in the 2020 Gartner Critical Capabilities for Application Security Testing Report. If you would like to learn more about how we can help your agency comply with the pending standards and guidelines from NIST, don’t hesitate to contact us here. Not only will our approach streamline all of your code analysis and vulnerability remediation efforts, we’ll measurably reduce your time to software release.