Software acquisition is risk acquisition, says industry panel

Every time an organisation acquires new software, it risks introducing new security vulnerabilities,  an industry panel has told told the (ISC)2 Security Congress 2013 in Chicago.

“Application software is increasingly a target for attackers, and the reality is that vulnerabilities exist in commercial off the shelf software,” said Richard Tychansky, chair of the supply chain security subcommittee of the (ISC)2 Application Security Advisory Board.

“Managing risk is about discovering and understanding vulnerabilities that exist in commercial software,” he said.

Because software is used to do just about everything in the modern world, software assurance is something everyone should be concerned about, said Tony Vargas, security strategist at Cisco.

The problem is that most organisations acquire software without really knowing what they are getting, said Edward Bonver, senior principal software engineer at Symantec.

“Considering the risk, they should be doing research to ensure they understand what they are acquiring, but in most cases this is not happening, so they have no idea of the risk they are inheriting,” he said.

In addition to inadvertent vulnerabilities introduced by insecure software development methods, commercial software can also be sabotaged, said Mano Paul, CEO of SecuRisk Solutions.

Malicious code or logic can be injected at some point along the supply chain, and even within the organisation by a malicious insider, he said.

Procurement processes need to be designed to include software assurance, said Bonver. “It is vital to ask the right questions before purchasing software because that is when a buyer has the leverage to start the conversation,” he said.

According to Bonver, top questions should be:

• How do you ensure your code is secure?
• How is security part of the development process?
• How is code tested for security vulnerabilities?
• What threat modeling is used?
• Does software have any known vulnerabilities?
• Are any third party or open source elements used?
• Are developers trained in secure coding?
• How do you ensure the code remains secure throughout the supply chain?

“Organisation should have a clear understanding of what the developers of the software they want to use have done to ensure that it is created securely and remains secure through the supply chain,” he said.

Tychansky said that the technical team of the software supplier should be represented in purchasing negotiations to ensure that the supplier cannot bypass and questions around risk associated with code.

This is a requirement that can be defined in a proper acquisition strategy, which should be backed up by strict enforcement of that policy, said Paul.

“Without formal security software requirements, the likelihood that the software a company is running will get hacked, are significantly increased,” he said.

The likelihood that cost will trump security when it comes to the final buying decision is also increased.

Any acquisition strategy should also require software under consideration to be run first in the company environment to test that security features continue to work in that environment before acquisition.

Vargas said an acquisition strategy should also require the company not to purchase any software for which it is unable to get the software security assurances required by company policy.

Every organisation should set a policy to govern all software procurement and should make it clear to suppliers that they will not buy any products that do not comply.

Where software systems involve sensitive data, companies should get a guarantee that the code is vulnerability free from the supplier in the purchase contract.

Once the software is deployed, tools should be run against the software to verify supplier claims that it is vulnerability free.

However, Paul said organisations should ensure that if they go down this route, the contracts are enforceable if vulnerabilities are identified in the code.

A useful metric to include in contracts, he said, is “time to fix” if a vulnerability is discovered in the code.