Fresh Thoughts #70: 250,000 False Positives?
- Newsletter
I've found cybersecurity folk become incredibly confrontational about some odd things...
250,000 False Positives?
At a recent security conference - a speaker triumphantly declared that he had led a small team to tackle a list of 250,000 security vulnerabilities.
Murmurs of approval and surprise rippled around the room. A few "Oofs" - and "That's a lot" could be heard.
If we pause briefly - saying there are 250,000 security vulnerabilities means there are 250,000 ways that assist or enable a hacker to break into that business.
It is - by any analysis - a Herculean task. Just think of an Excel spreadsheet with 250,000 lines... 😬
The speaker went on to explain the team's risk-based approach. Which ensured the most severe vulnerabilities were addressed first.
Vulnerability Scores
A standard 10-point scale is used to score how severe a vulnerability is - called the CVSS score.
The scoring process considers whether the vulnerability can be used to steal secrets or can be exploited remotely across the internet - amongst other things. And a score of 7 or above means it is a high or critical vulnerability that should be addressed quickly.
This is the approach the team took.
But quick as a flash, parts of the audience switched to disapproval - "That's a legacy approach." Indeed - the worst insult.
You see - a new, different score can be used... The EPSS model.
While there are many vulnerabilities, not all have been industrialised, and not all will be exploited by hackers. The EPSS model uses threat intelligence to predict how likely a particular vulnerability will be exploited.
The more likely to be exploited - the sooner the vulnerability should be fixed.
And so, when it came to Q&A, the inevitable EPSS vs CVSS questions ensued.
But the whole exchange left me puzzled...
To have 250,000 vulnerabilities… There's a much bigger problem afoot.
Fixing Underlying Processes
There is no doubt that the infrastructure must have been enormous. The most vulnerabilities I have seen (recently) on a single application is 183. This means there must be thousands of systems in the speaker's example.
But it struck me that underlying issues must exist.
Firstly, this situation couldn't have happened overnight. It is reasonable to assume that, as fixes and workarounds were released over the years, they were not applied.
In rare situations - this is understandable. A business-critical feature may no longer be supported. Or two business-critical systems may not work together correctly after an upgrade. But these are exceptions, not defaults.
Therefore - I wondered - was there a regular, efficient process to apply software fixes and updates?
It is vital to make software updates as efficient as possible. It is merely a cost of using IT. So automatic patching of Windows, Chromebooks, and Apple devices - is the way to go...
For the speaker - if this fundamental issue wasn't addressed as a priority - the security fixes would no doubt be short-lived.
A second possible reason for this situation is a lack of ongoing infrastructure maintenance spend. While the capital costs of projects are always considered, I have seen times when the continuing financial and labour costs of maintaining a system are missed, deprioritised or reallocated.
This is undoubtedly a structural issue - requiring buy-in from procurement, finance, staffing and operations. If you find yourself in this space - it is worth considering moving to cloud-based applications or a managed service to maintain the long-term operation of a system.
Finally - there is an altogether different approach to resolving this situation.
In the case of the application with 183 vulnerabilities, there was a misalignment between the output of a vulnerability scanner and the risk the business was prepared to accept.
The specific version of the application in question was known to have no formal support agreement. Fixes were provided on a "best endeavours" basis.
From the vulnerability scanner view - unsupported meant unsupported. And every vulnerability released after the official end-of-support date was automatically marked as applicable. Regardless of whether a best endeavours fix was applied.
In contrast, the business decided "best endeavours" was good enough support for them. It took several conversations - and board-level approval to formalise this acceptance - but overnight… 183 vulnerabilities were removed and classed as false positives.
None of these fixes have anything to do with scoring algorithms, but I argue they are much more critical.
June 13, 20234 Minutes Read
