This article is Part 2 of a two-part series – Part 1: US Executive Order 14028 Impact on Application & Cloud Security 

Cyberattacks are becoming more frequent, targeted, and complex with the sophistication of cybercriminals, techniques, and technologies. The rapid acceleration of software and digital adoption in all areas, particularly since the start of the COVID-19 pandemic, has led to an increased reliance on applications in many aspects of our work lives and daily routines such as: 

• Delivery services 
• Virtual communication and remote work 
• Online education and learning 
• Digital healthcare services 
• Transportation and ride-hailing apps 

As this trend continues, we are seeing a massive expansion in the attack surface, which in turn has made software security issues an even greater concern. 

In this environment, the U.S. signed Executive Order 14028, urging a partnership between public and private sectors to keep pace with the rapidly evolving software landscape and address the security challenges and vulnerabilities that arise from the increased reliance on software in today’s digital ecosystem. 

The Executive Order (EO) cites the need to make “bold changes and significant investments” across all information systems and specifically directs several US Federal agencies to develop strict new standards regarding cybersecurity, including the assignment of responsibilities to the National Institute of Standards and Technology (NIST) NISTIR 8397. 

Those initiatives, as outlined by NIST on its EO 14028 guidance webpage, encompass:

• Critical Software Definition 
• Security Measures for “EO-Critical Software” Use 
• Software Supply Chain Security Guidance 
• Recommended Minimum Standards for Vendor or Developer Verification of Software 

In Part 1 of this 2-part series, we examined the high-level implications the Executive Order has on cloud and application security In this article, we focus on NIST’s guidelines for minimizing risks in the software supply chain. 

NIST’s Successful Implementation of the May 2021 Executive Order 14028 

Since the May 2021 Executive Order, NIST has made significant achievements towards directing us in software security. It started with soliciting input from the public and private sectors and went on to publish a series of definitions, guidelines, and position papers over the past two years.  

There were several key outcomes of NIST’s assignments since EO 14028, issued May 12, 2021:  

1. June 26, 2021 – NIST releases its definition of “Critical Software”. 
2. July, 09, 2021 – NIST fulfills two assignments by publishing a guidance outlining security measures for critical software use and an initial guidelines recommending minimum standards for vendors’ testing their software source code (replaced later). 
3. October 2021 – NIST updates and publishes the guidelines recommending minimum standards for vendors’ testing their software source code in the NISTIR 8397. 
4. February 2022 – NIST publishes Secure Software Development Framework (SSDF V1.1) as a set of fundamental, sound practices for secure software development with a focus on the outcomes of the practices rather than on the tools, techniques, and mechanisms: 
   • SP800-218, from the software producer viewpoint. 
   • Additional Guidance from the software purchaser viewpoint, intended to help purchases understand what information to request from software producers regarding their secure software development practices. 
5. May 05, 2022 – NIST releases a revision of the Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (NIST Special Publication 800-161 Revision1). 

NIST Publishes New Standards for Verifying Application Software 

Many of us are familiar with the term “testing”, a more informal word for assessing security vulnerabilities of software, such as “penetration tests”. NIST uses a broader term of “verification” (aligned with International Standards Organization and others), referring to a range of analysis techniques and tests to review code and running programs using reviews, tools, and test cases.

To meet EO 14028, NIST has defined 11 recommended minimum standards for verification of software by software producers: 

1. Perform threat modeling early in the software development lifecycle to look for design-level security issues and prioritize the greatest risks to organizations. Threat modelling can be thought of a risk assessment for applications and can be used to help focus verification efforts and identify priorities for mitigation strategies.  
2. Integrate automated testing into existing workflows or issue tracking. This kind of testing can easily be repeated, testing for consistency, with minimal additional effort by developers. Automated tools for verification testing range from basic scripts to advanced systems that configure environments and perform tests, reducing the need for human intervention and expertise. These tools are capable of interacting with web-enabled applications, executing high-level commands, and generating reports on test results. These tools ensure consistency, accuracy, and allow for frequent repetition in the testing process. Additionally, they can be integrated seamlessly into existing workflows or issue tracking systems. 
3. Employ static analysis tools (code-based analysis or scanners) to assess the code itself against known top vulnerabilities that relate to coding errors, as soon as code is written. 
4. Heuristic tools can be employed to detect the presence of unwanted hardcoded secrets in the code, such as passwords or private encryption keys. Dynamic testing, on the other hand, is unlikely to be effective in identifying these unwanted lines of code. 
5. Run with built-in checks and protection capabilities provided by the programming languages, both during development and in the released version. 
6. Create “Black-box” test cases based on functional specifications, without knowing the inner workings of the target, to expose vulnerabilities in the production environment. 
7. Use code-based structural test cases based on the specific requirements of the implementation, testing to see if there are errors in the intended system flows or functions required. 
8. Run historical test cases, or retesting, to show the absence of a previously identified bug to revalidate modified software as part of the maintenance stage. 
9. Run fuzzing tools and related automated randomized active test generation to help catch unexpected bugs early. Fuzzing can produce actual positive tests for bugs, not just static warnings in later stages. 
10. Scan web applications that are connected to the internet to monitor for unusual behavior or internal faults using Dynamic Application Security Testing (DAST) tools or Interactive Application Security Testing (IAST) tools to detect vulnerabilities. 
11. To ensure that the security of software components included in the software is at least as secure as code developed internally, the techniques mentioned above should be applied. In addition, it is recommended to use Software Composition Analysis (SCA) tools to identify all components and their known vulnerabilities, such as open-source libraries, suites, packages, bundles, or kits that the software uses. It is essential to implement tools and processes that can continuously monitor software components, as these components can become outdated, and new vulnerabilities may be reported at any time. 

It is worth noting that NIST recommends correcting critical risks as soon as possible and subsequently enhancing processes based on known issues to prevent future vulnerabilities or, at the very least, detect them early on. 

How to Apply NIST’s Verification Standards in your Organization

If you’re building out your software development processes and assurance programs, it’s strongly advisable to integrate these minimum standards, even considering the additional supplemental details (Section 3). Developers should apply the new NIST Code Verification guidelines, performing the testing themselves continuously as they build software.

Since not all developers are subject matter experts in security, it’s understandable that they may not be able to identify all vulnerabilities. To address this, NIST’s verification standards can be applied by an outside party, bringing expertise in application security and testing techniques to identify vulnerabilities that may have been overlooked by your in-house team.

It is generally recommended to bring in a third-party to repeat or perform additional tests as a second set of eyes. This independent verification fulfills compliance requirements to customers and security frameworks. Third-party testing can include periodic penetration testing, scanning, and more but the frequency of testing should be unique to your organization’s business context and risk.

While the public sector and organizations providing products and services to the U.S. government are required to comply with NIST’s standards, all organizations are encouraged to adapt to the continuously changing threat environment by using these guidelines to ensure best practices are being upheld. 

NIST Encourages a Mixed-Strategy Approach 

A key takeaway conveyed by NIST’s latest standards is to enhance your defensive posture by implementing a diverse set of techniques and strategies over the entire lifecycle of an application. Since pentesting is not deemed as a sufficient approach for application security testing, organizations who rely solely on annual pen tests of their applications may have a false sense of security. 

In this way, NIST’s new guidance aligns with other existing and highly-regarded industry standards such as OWASP‘s Application Security Verification Standard (ASVS) and Web Security Testing Guide (WSTG), which similarly recommend organizations follow a balanced approach software testing, over and above pentesting. This includes manual design review, source code security analysis, software composition analysis, threat modelling, and pentesting. 

A Better Approach to Testing Your Applicaitons 

As discussed, NIST has defined 11 recommended minimum standards for software verification by software producers. These recommendations will help to correct critical risks as soon as possible and subsequently enhancing processes based on known issues to prevent future vulnerabilities or, at the very least, detect them early on.

They furthher ecommend a balanced approach, combining different techniques that go above and beyond pentesting such as manual design review, source code security analysis, software composition analysis, threat modelling.

If this security expertise is not available by your team of in-house developers, then it is recommended to have a third-party step in and to manage it for you. 

At Forward Security, we offer a comprehensive application security risk assessment that includes: manual design review, source code security analysis, software composition analysis, threat modelling, and pentesting.  

We are your partner in helping you meet the NIST recommendations for EO 14028.