NIST’s EO-mandated software security guidelines could be a game-changer

Following a string of high-profile supply chain hacks, President Biden’s wide-ranging executive order on cybersecurity (EO) issued on May 12 directed the National Institute of Standards and Technology (NIST) to produce guidance on a series of software security matters. First, the EO asked NIST to produce a definition of critical software, which it released at the end of June. Second, the EO directed NIST to publish guidance on security measures for EO-critical software use, which NIST released last Friday.

To tackle the complex issue of keeping software secure, NIST solicited papers from interested parties and held a two-day workshop to gain insight from industry and other experts.  NIST defined five objectives for the operational-only (not covering development and acquisition matters) security measures:

1. Protect EO-critical software and EO-critical software platforms (the platforms on which EO-critical software runs, such as endpoints, servers, and cloud resources) from unauthorized access and usage. Measures here include use of multi-factor authentication, following privileged access management principles, and employing boundary protection techniques.
2. Protect the confidentiality, integrity, and availability of data used by EO-critical software and EO-critical software platforms. Measures here include maintaining a data inventory, protecting data at rest and in transit, and back up data with a tested recovery plan.
3. Identify and maintain EO-critical software platforms and the software deployed to those platforms to protect the EO-critical software from exploitation. Measures here include maintaining a software inventory, have a patch management plan, and use configuration management practices.
4. Quickly detect, respond to, and recover from threats and incidents involving EO-critical software and EO-critical software platforms. Measures here include recording necessary logging information, continuous security monitoring, and using endpoint and network security protection.
5. Strengthen the understanding and performance of humans’ actions that foster the security of EO-critical software and EO-critical software platforms. Measures here include training all users and administrators of EO-critical software and conducting frequent awareness activities.

Security measures prioritized to protect critical software use

NIST stresses that the security measures it developed are not comprehensive and could be updated in the future. It says the measures are “to assist agencies by defining a set of common security objectives for prioritizing the security measures that should be in place to protect EO-critical software use.”

Like so many other NIST guidance and framework documents, NIST presents each measure along with its corresponding federal government informative references, mostly technical specifications and industry standards, so that practitioners can rely on more detailed guidance. In addition, all software security measures count both the NIST Cybersecurity Framework (CSF) and NIST Special Publication (SP) 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations as informative references. NIST released a white paper that lays out the new software security schema in detail.

The EO further directed NIST to publish guidelines on vendors’ source code testing. NIST also released a set of voluntary guidelines for this code testing with the release of the security measures. While NIST says the guidelines are voluntary, it also states OMB “shall take appropriate steps to require that agencies comply with such guidelines with respect to software procured after the date of this order,” as the EO also requires. NIST expects its guidelines will be incorporated into OMB’s requirements.

The guidelines, which are spelled out further in a standalone document, recommend a series of minimum techniques for code verification by developers. The techniques include threat modeling, automated testing, code-based (static) analysis, dynamic analysis (running the program on test cases), check included software, and fix bugs.

Expert reaction is positive

Reaction from cybersecurity experts to NIST’s guidance and guidelines appears to be positive. “This is long overdue,” Padraic O’Reilly, co-founder and chief product officer of Cybersaint Security, tells CSO. “Third-party software is a serious, serious vulnerability right now.”

Padriac says he co-founded Cybersaint “about four and a half, five years ago, largely predicated upon some of the good work that NIST was doing around the Cybersecurity Framework.” After the Framework was released, “the C-suite started to understand a little bit better the practice of cyber and some of the associated risks. It’s been a game-changer,” he says.

O’Reilly believes that the security measures and testing guidelines produced by NIST under the EO can serve as similar catalysts to improve software security. “What this will allow us to do is actually say, look, here’s a framework for secure practices on third-party software, and then you can associate it with the CSF like they’ve done in the document. Then you can drive [relevant metrics in the right direction].”

“The US federal government is taking a strong position by drawing a line in the sand that will set expectations for software suppliers across many industries,” Daniel Nurmi, co-founder and chief technology officer at security workflow solution company Anchore, tells CSO. “As a company that develops software technologies to secure the development process, the core ideas in the EO, as well as the evolving formal guidance from NIST, are very much in line with what needs to be done.”

“Across the software industry, we have to step up our defenses against software supply chain attacks by investing more in our own security practices,” Nurmi says. “These attacks are likely to increase as long as the attackers are successful.”

Will the software industry step up security practices?

It’s too soon to tell if the NIST software security measures, or the guidelines on vendor source code testing, will force software suppliers to make substantial changes in how they operate. However, O’Reilly believes that software companies aren’t already implementing the practices that NIST articulates. For example, most software suppliers don’t use “multi-factor authentication that is verifier impersonation-resistant for all users and administrators,” which is the first required security measure under the objective of protecting software and platforms from unauthorized access and usage. “No, they’re not already doing it.”

“NIST put it first because, if you look at what happened at Colonial Pipeline, they were using some kind of a remote desktop protocol,” O’Reilly says. “The [Oldsmar] water plant in Florida was using RDP as well. So, all the hackers had to do was go to the dark web and look up some passwords.” Multi-factor authentication would have stopped those attacks, O’Reilly says.

“Software supplier organizations that have already invested heavily in secure development practices will have some additional work to translate their existing practices into the evolving new standards,” Nurmi says.” But for those organizations who haven’t yet, or have, but only partially, [the NIST guidance] may be the catalyst that creates the incentive to do so across the software supplier industry.”

NIST’s job in developing software security recommendations under the EO is not yet complete.  Next February, NIST will also issue guidance on software testing tools and attestations. In the meantime, the EO states that within 30 days of NIST’s release of its guidelines, or around August 10, the director of OMB, acting through the Administrator of the Office of Electronic Government within OMB, will take appropriate steps to require that agencies comply with the security measures and code testing guidelines.