Tread Lightly on Critical Software, Industry Asks NIST
The National Institute of Standards and Technology should tread lightly defining “critical software” and avoid disincentivizing innovation, officials from Microsoft, Linux, BSA|The Software Alliance and cloud providers told NIST Wednesday. President Joe Biden’s cybersecurity executive order directs NIST to publish a definition by June 26 (see 2105240072).
Sign up for a free preview to unlock the rest of this article
Export Compliance Daily combines U.S. export control news, foreign border import regulation and policy developments into a single daily information service that reliably informs its trade professional readers about important current issues affecting their operations.
The consensus is that defining “critical software is going to be really hard,” BSA Policy Director Henry Young told a virtual workshop (see 2105170058). “If everything becomes critical software, we won’t really have made much progress.” He urged “reasonable” boundaries on the definition.
“This is an incredibly difficult undertaking and one that just merits an iterative, phased approach,” said Microsoft Cybersecurity Policy Director Amanda Craig Deckard. Microsoft is encouraged by the “ambition” of the EO, Section 4 in particular, which would designate critical software and enable a consistent approach for prioritizing security, she said.
Section 4 for “enhancing software supply chain security” is the most important EO section said White House National Security Council acting Senior Director-Cybersecurity Jeff Greene. The section has the potential to have the largest impact domestically and globally, he said. If it works, “two or three years from now, bottom line, we’re going to have more secure software,” he said.
OMB’s “big task” from the EO is to review federal acquisition rules to recommend potential contract language updates to the Federal Acquisition Regulatory Council and other agencies, said OMB Federal Chief Information Security Officer Chris DeRusha. The object is to remove contractual barriers and require providers to share breach information that could affect government networks, he said: “That’s crucial to enabling our network defenders across the federal government to really be able to address these risks in real time and ensure awareness.” He cited the SolarWinds attack (see 2105250083) for the EO section.
The federal government isn’t alone in managing third-party risks and using “contract levers to drive appropriate change,” said DHS Cybersecurity and Infrastructure Security Agency Executive Assistant Director-Cybersecurity Eric Goldstein. CISA’s cloud services provisions in the EO will help set a baseline for how federal agencies use the cloud, he said. Cloud incidents happen “not because the right control wasn’t in place but because of a misconfiguration or a mistake of process, which generally is a governance issue,” he said.
Operating systems are huge, and not everything included in an OS is critical, so NIST should have a “laser focus,” said Linux Foundation Open Source Supply Chain Security Director David Wheeler. He noted some components are installed and never used again: “If everything is critical, nothing is.”
The federal government should ensure critical software providers aren’t required to share data outside the “standard customer-software developer-provider relationship,” said Enterprise Cloud Coalition Executive Director Andrew Howell, whose organization represents Dropbox, Slack, Twilio, Workday and others. “Anything that opens the door to confusion in that regard will not be well-received by the international cloud software marketplace.”
The federal government is notorious for installing software and never updating it, said Wheeler. Attackers are thinking in terms of hours when testing for vulnerabilities, but the government is often thinking in terms of years about updating software, he said, calling it a “fundamental difference” and blaming the government for sticking to normal operating procedure.