Security Think Tank: Balancing cost and risk in software vulnerability management

In trying to pinpoint the most practical and cost-effective way for organisations to identify and remediate high-risk software vulnerabilities, approaching this solely from a product or tools perspective only looks at the issue through one particular lens.

What is cost-effective is whatever meets the precise assurance requirements of the organisation – anything more, and you’re wasting vital resources; anything less, and you’re exposing the organisation to risk it’s not (theoretically) prepared to accept.    

On that basis, a blended model of technical and business activities is most likely to meet the cost-effectiveness and the practicality question. Only doing one type of assessment, or using one tool or process, will not provide the depth required to assure top management.

So what does that look like in practice? For a small business that is not IT-focused, the most cost-effective solution could be a managed service with annual penetration testing activity and ongoing support to address vulnerabilities and provide advice to avoid exposing the firm to potentially vulnerable components. For an organisation of a similar size but with a greater focus on IT, it may be more cost-effective to invest in training developers in the art of writing secure code, thus reducing the number of vulnerabilities from the very beginning.

For enterprise-scale organisations, it may be more valuable to run an in-house team which has a full understanding of the complex infrastructure in place, thereby reducing the costs associated with a lengthy third-party review.

All of the above types of company should implement a recognised process for patch and vulnerability management programmes to help at each stage of their journey.

In terms of the tools that could be used, a company should consider those designed to assess specific types of software in place. A web application assessment would be different from a device review or a privilege escalation assessment on a laptop. Similarly, a company using laptops from a single supplier with the same operating system would not need to implement a solution that supports and protects other suppliers. 

It is also important to remember that complexity of the software solution, as well as larger chunks of source code behind a small piece of software, will increase the number of potential vulnerabilities to defend against.

All of the above may sound like a blocker for creative and innovation-focused companies – however, be assured that it is not. An organisation may experiment with as many software products as it wishes to foster the growth of the business, but this has to be done in a modern test environment – preferably air gapped or sandboxed – to avoid introducing unknown risks to the main business.