New NIST Guidance to Help Organizations Better Assess Risk, Allocate Resources

Your business operates on a tight budget. Your sales team complains of old cell phones with inadequate data plans; your desktop computers are no longer supported by the manufacturer and spare parts are hard to find; and replacement hardware purchased on the aftermarket could contain viruses. The question before you: Where do you invest your limited resources?

This problem, writ large, confronts nearly every organization that depends on information or operational technology for its principal business or mission: how to keep its infrastructure up to date without either jeopardizing its ability to function or breaking the budget. The National Institute of Standards and Technology (NIST) has released new draft guidance to help organizations navigate the shoals lining both sides of the strait. 

NIST is requesting public comments by August 18, 2017 on this technical document, which will help organizations perform a step-by-step analysis to identify those critical parts of a system that must not fail or be compromised if the system is to successfully support the organization’s mission. The document, NIST Interagency Report (NISTIR) 8179, Criticality Analysis Process Model, builds on previous NIST guidance such as Special Publication (SP) 800-53 Rev. 4, SP 800-160, and SP 800-161, which emphasized the importance of identifying the critical points in a system, but did not provide a method for doing so.

“This draft report shows people how to perform a criticality analysis that's tailored to their organization,” said NIST cybersecurity expert Jon Boyens, who coauthored the report with his colleague Celia Paulsen. “Each agency will have its own situation. We are developing this for the government, but we want it to be friendly and useful for the private sector.”

The draft report will have repercussions beyond federal agencies because of the many private contractors that do business with the government, including military contractors whose wares will be used by troops in the field.

“I think guidance like this will help secure the supply chain,” said John Peterson, senior program manager at the Redhorse Corporation in San Diego. “A lot of these systems are integrated, so if you have one part that’s compromised in some way, it could affect the entire system.”

These risks are potentially heightened by the real-world issue of limited resources, which can vary substantially in the federal government depending on budget priorities. How can an organization maintain systems when it cannot always afford to buy the latest and greatest tools, but at times must make do with legacy technology?

“The legacy problem is notorious throughout industry," said Carol Woody, technical manager for cybersecurity engineering at the Software Engineering Institute in Pittsburgh. "All organizations are trying to keep technology costs down. It's hard to do because they have to make choices that may not always anticipate problems ten years down the road. What the NIST authors are doing is saying, think broadly. Ask yourself why you bought something and how long it will be before it could conceivably need more capability—plan for its usable life and budget accordingly."

Paulsen said that while fundamental ideas like this were already in use in many industries, they were not always applied as they should be for information security. 

“We looked at many processes and realized that people tend to view risk according to what they know best—their own goals and experiences,” she said. “Existing procedures don't always emphasize considering different—often competing—priorities or how a single component can impact various parts of an organization. With limited resources it is impossible to solve every problem, but our report will help you see the whole landscape more clearly. It will help you communicate with different parts of the organization, outside stakeholders, and supply chain partners about what’s important.”

Criticality analysis is not only essential to determining high-value assets. It also alters the traditional risk assessment focus on likelihood: from what adversaries are likely to do, to what they are capable of doing. The approach also eliminates debate over “return on investment” in favor of engineering systems that are resilient.

Guidance of the sort the report offers is necessary, said Boyens, because of the nature of the supply chain—the innumerable manufacturers whose individual wares end up combined into a system, which then becomes part of an agency’s larger infrastructure. Creating these larger “systems of systems” can create challenges when problems like those aging cell phones crop up.

“If they were using criticality analysis, they might have bought a 10-year supply of the crucial parts in advance, or would know that they'd need to do more testing of the aftermarket product,” Boyens said. “Without a proper analysis, they might not realize these vulnerable spots in the first place.”

The Software Engineering Institute's Woody added that this sort of analytical clarity combined with long-term thinking was needed in acquisition departments, which are often more knowledgeable about managing costs and schedules than the intricacies of how software is built.

“It’s that proactive thinking that’s hard to get into the supply chain,” she said. “The technology will still be there, and the attackers won’t take it easy just because we don’t have funds for an upgrade.”