ISACA Journal Author Blog

ISACA > Journal > Practically Speaking Blog > Posts > Third-party Product Insecurity Is Costing You

Third-party Product Insecurity Is Costing You

Rohit Sethi, CISSP, CSSLP, and Ehsan Foroughi, CISM, CISSP
| Published: 7/20/2015 3:00 PM | Permalink | Email this Post | Comments (0)

Insecure third-party software products contribute significant risk to an organization. When an enterprise buys, uses or downloads web, mobile and desktop software, it inherits the risk that stems from that software's insecurity. This is also true for the embedded devices that make up the Internet of Things (IoT). Nearly all of the vulnerabilities listed in the Common Vulnerabilities and Exposures database are rooted in software. This means, for example, that nearly all malware today takes advantage of some secure programming mistake on other software, such as an operating system or browser.

It may be expected that by now, product vendors have responded in kind by holistically incorporating security into their software development processes. Unfortunately, that is far from reality. Most software development organizations rely on automated testing tools, which the US National Institute of Standards and Technology (NIST) SAMATE project has shown capture only a small percentage of security vulnerabilities.

In our ISACA Journal article, we discuss 3 methods auditors can use to help ensure that application security is actually built into software.

However, when an organization procures rather than purchases software, it may not have the same influence over the software development process. The good news is that it can still do things to push risk back to the vendors who create insecurity in the organization:

  1. In contract negotiations, demand verifiable evidence that software development companies have built security into the software they are selling. Use the approaches outlined in the article as a guideline for what evidence to accept. Require that they follow some kind of standard, e.g., the Open Security Assurance Maturity Model or ISO 27034. Do not accept hollow statements like, "We secure against the Open Web Application Security Project (OWASP) Top 10."
  2. Make it known through request for proposal (RFP) criteria and conversations with vendors that secure software is important. Nothing drives product vendors more than customer demand.
  3. Educate industry peers on the need for pushing back the risk of insecure products. You may not have much leverage with a vendor if you are alone in asking for increased software security, but when several key customers ask for the same thing, it is hard for vendors to ignore.

Imagine in 10 years if we continue to see products riddled with preventable security defects at the same rate we see today. How will we be able to effectively manage the explosion in risk? IT auditors have a significant role to play in ensuring the state of the industry changes.

Read Rohit Sethi and Ehsan Foroughi’s recent Journal article:
Three Ways to Simplify Auditing Software Security Requirements and Design,” ISACA Journal, volume 4, 2015.


There are no comments yet for this post.