Bringing resiliency to software acquisition

Cybersecurity becomes harder as the systems and data being secured become more complex. In a simple world, critical information could be isolated in a risk-free environment. But this is impractical when information must be shared across diverse platforms. Software running on these platforms, when developed with only functionality in mind, results in systems that are fragile and difficult to protect.

Standards are emerging from organizations such as CISQ — the Consortium for IT Software Quality — for software development that goes beyond the merely functional. This can produce systems with the resilience to mitigate the risks faced in today’s hostile cyber environment.

But too often, this mission-critical software is a sophisticated, extremely complex stack of technologies integrated into what is called a “product,” but which has no overall design or architecture. Unless resiliency standards are applied in the software acquisition process, complex mission-critical systems will continue to be technically acceptable but insecure in the real world.

Thought leaders from government, industry and academia discussed the opportunities and challenges of IT resiliency at the Cyber Resilience Summit hosted earlier this year by CISQ.

“Resilience is about risk,” said Paul Nielsen, director and CEO of the Carnegie Mellon Software Engineering Institute. “And one of the things about risk is, you can’t eliminate it.”

Basic cyber hygiene can help eliminate low-hanging vulnerabilities, but increasingly persistent and sophisticated attacks against complex systems will continue to pose threats. Those risks that cannot be eliminated must be managed. Resilient software working as a coherent system can mitigate the impact of intrusions when they occur, continuing to operate while avoiding or minimizing damage.

Too often functionality trumps security in mission-critical software. 

In health care, for example, accessibility and performance take precedence over security, said Lucia Savage, the Health and Human Services Department’s chief privacy officer for Health IT. Even when cybersecurity features are included in software, they often are not used. “You can’t let cybersecurity impede information getting where it needs to be to improve patient care,” Savage said. “It’s a balancing act.”

There also is a lack of correlation between good coding practices at the code unit level and value for the business of the software system as a whole. Even high-quality parts can combine to form a fragile, unpredictable and dangerous whole, occasionally disrupting a vital business process.

At the core of CISQ recommended standards for software resiliency are four non-functional characteristics:

• Reliability
• Performance Efficiency
• Security
• Maintainability

The standards are based on established software engineering rules for coding practices at three levels: The level of the individual unit of code (a method, function or an entire program for unstructured languages); the technology level (an integrated collection of code units written in the same language); and the system level (comprising all code units and layers of technology). 

Automated quality measures that check against engineering rules for each for these four characteristics can provide inputs at each level of analysis. 

At the unit level, most coding practices can be checked with free code analyzers already embedded in development environments. The technology level typically requires more advanced code analysis products. System level analysis is more complex and requires the ability to exchange information between tools to provide a comprehensive logical image of the software app’s inner structure.

According to Nielsen, these technology and system level evaluations differentiate CISQ standards from simple code quality standards.

Producing reliable, resilient and secure software is possible. To ensure it, requirements must be included in the acquisition process so that developers know precisely what is expected of them by government customers.

To accomplish this, agencies must define desired outcomes, then work with contractors to produce the desired results. Agencies need not go outside existing Federal Acquisition Regulations for this. Contract language can encourage innovation and flexibility. 

Recommendations for effective acquisitions include:

• Using a common vocabulary for requirements
• Setting structural quality objectives for software
• Measuring software quality at the system level
• Evaluating contract deliverables
• Using rewards and penalties wisely

William Jackson is writer with the Tech Writers Bureau with more than 35 years’ experience reporting for daily, business and trade publications, including two decades covering information technology and cybersecurity in the federal government. Contact him at wjackson@techwritersbureau.com. This article was written with funding from the Consortium for IT Software Quality.