Are we asking the wrong question?

I recently joined a panel session to talk about cloud security. During the course of the discussion, we were asked how to prioritise fixing vulnerabilities given that often developers are under pressure to deliver software more and more frequently. Engineering progress is measured on the notion of producing working software above any other measure. Defects, including security defects, are put on the backlog for future consideration, unless they are deemed a significant risk to the business. But is this the right question? Why do we need to prioritise fixing vulnerabilities?

On the face of it, the answer to this question seems simple… there are too many defects to fix now, so we need to prioritise them. Thus product delivery teams are encouraged to rank defects based on their severity or criticality, usually using the CVSS rating as the differentiating metric. However this poses a challenge… how are defects prioritised in relation to business value added development such as implementing new features? Fixing a defect or vulnerability is a cost to the organisation that does not generate easily measurable and tangible benefits to the business in terms of return on investment. Often, security teams have to fight their cause to justify prioritising a security defect above a product feature. Added complexity comes from the CVSS scoring system applied ‘out-of-the-box’ which means that context is rarely considered, unless of course it is obvious, such as those organisations not using Java and therefore most likely to be unaffected by Log4J. The default action is to set short timeframes for fixing critical defects, and longer timeframes for fixing lower rated vulnerabilities.

Ranking and fixing defects in this manner obfuscates the risk hat those lower rated defects are in reality more critical to the organisation than perceived. Organisations accept the risk based on the low rating of the vulnerabilities allowing teams to standardise on releasing products and services that contain many known defects. However, normalising deviance in this way exposes the organisation to a significant risk of a potential catastrophic security incident.

There are further complications associated with product vulnerabilities relating to the normally high quantity of false positives reported from various security testing processes. Many high priority critical defects are red herrings that have to be investigated and justified as false positives before the product is released. This is a lengthy process distracting staff from resolving genuine issues and working on value added development. The high number of vulnerabilities managed within some organisations, often numbering several thousands, has necessitated the building of teams to focus exclusively on managing them.

In my opinion, there is too much wasted effort in identifying, prioritising and fixing vulnerabilities, with very little gain to the business. I would go even further to ask whether vulnerability management improves the security of the organisation?

What is a way out of this situation? I offer three ways to improve the way organisations can manage the security of the products and services they develop.

1. First, ask the right questions: why are security vulnerabilities being identified? There are many root causes to explore including: checking the configuration of security tooling to ensure it is contextualised and not overly sensitive; assessing whether staff have the relevant skills to build security into the products and services they are developing; and ensuring there is adequate learning opportunities for everyone involved in product delivery.
2. Second, avoid normalising deviance. This means that every defect should be taken seriously and organisations should stop accepting that a vulnerability is okay to pass on to customers because it is considered safe to do so.
3. Finally, simplify and standardise on the tools, frameworks and languages used within the product delivery organisation. Many organisations increase complexity unnecessarily by allowing too much autonomy without a cohesive alignment to business goals. This results in engineering teams choosing tools, frameworks and languages because they look good on the CV or are the coolest ones to use rather than because they provide business value and security for customers.

Each of these suggestions will reduce effort and eliminate a lot of waste within the organisation allowing teams to prioritise on the features that add value to the business. They are not simple ‘fixes’ but should be considered as part of a longer term strategy to develop secure software. Too often, organisations use business risk as measure to manage vulnerabilities, without considering the impact data breaches and ransomware attacks may have on individual customers. By working on ways to eliminate defects by understanding root causes, risk management and product delivery teams are afforded the capacity focus on true business value.