Software considerations essential to risk management, says SAFECode

Enterprise risk management must consider the software the organisation buys and uses, says Eric Baize of SAFECode

Enterprise risk management must include the software acquired by the organisation, said Eric Baize, founder member of software assurance industry group SAFECode.

“Traditional risk management processes need to be refined to include software, because that is the new perimeter and vulnerabilities are its weakness,” he told the ISSE 2014 security conference in Brussels.

Most large enterprises use risk management frameworks such as Cobit, he said, which all require addressing risk that can be introduced by third-party suppliers.

“Most specify that, when technology is necessary to support service delivery, organisations assess the third party’s infrastructure and application security,” said Baize.

This includes the software development lifecycle, he said, because one of the principles of software assurance is that it is the result of a comprehensive secure software engineering process.

“But in many organisations there is often little understanding of software security and they tend to use ineffective, ad hoc methods of assessing software products,” said Baize.

Four common - but wrong - approaches to software assurance

There are four common approaches to software assurance, which all represent the wrong way of going about it, he said:

  • The first is to require a software supplier to attest that no vulnerability exists in the code.

“But this is not a realistic expectation and, if anybody attests that their software has no vulnerability, you can be sure of only one thing: They don’t understand software security,” said Baize.

  • The second is to require a software supplier to share product source code.

“The roughly 22-year-old Shellshock vulnerability reminds us that publishing source code has nothing to do with software security. Software assurance is the result of a process,” said Baize.

  • The third is to require a software supplier to share known vulnerabilities.

“But no organisation would trust somebody who shares information on how to attack them, so it does not make sense to ask software suppliers for products' threat models or penetration-test results,” said Baize.

  • The fourth is to require a software supplier to adopt specific tools or coding standards.

“Mandating specific tools and coding standards to improve software security is like forcing top chefs to cook ingredients with a microwave,” said Baize.

“Rather than wasting time with these four approaches, there is a much more efficient way of assessing the security of software products,” he said.


Review suppliers' practices and governance

Baize draws the analogy of assessing which of two astronauts to send to Mars. He said it is more useful to know about regular exercise and healthy eating than body-mass index, blood pressure and cholesterol levels.

“What counts more is evidence of a healthy lifestyle than point-in-time indicators that can be manipulated or influenced at the time tests are done,” he said.

Similarly, Baize believes it is more meaningful to review a supplier’s secure development practices, product security governance, and vulnerability response processes.

“Pen-testing, binary code analysis and network scanning provide only a partial and point-in-time view, and can be inconsistent and expensive,” he said.

“The other approach is a more accurate predictor of risk of vulnerabilities, and can be more consistently applied.”

How to assess software suppliers' processes

A simple way of assessing suppliers' processes, he said, is to look at vulnerability reporting and response policy on the company’s website and at public security advisories.

“Also consider adherence to ISO vulnerability response standards, look for white papers or public documents on supplier software assurance processes, and history of security certification,” said Baize.

The “Holy Grail” would be to see adherence to newly developed standards for vulnerability response such as ISO 30111 and ISO 29147, and secure software development such as ISO27034-1, he said.

“In summary, assessment of vulnerabilities in procured IT products is part of enterprise risk management and current ad hoc assessment methods are ineffective and inaccurate.

“Assessment of vendor software assurance process is the most accurate and scalable approach, and emerging international standards provide a consistent framework for assessing suppliers’ software assurance processes.

“In the meantime, simple methods allow for the assessment of the vendor software assurance maturity, and use of software testing tools best applies to vendors with low software assurance maturity.”

Read more on Application security and coding requirements