Vulnerability scoring has an important role in most enterprise threat and vulnerability management programmes because it provides multiple benefits to internal security teams when identifying any weaknesses. Additionally, it can also help verify control performance.
The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system insecurities and attempts to assign scores to them, allowing responders to prioritise their feedback and resources according to the threat.
CVSS is an open industry standard for assessing the severity of computer system insecurities |
This system, among similar others, has gained widespread industry adoption because it is simple to understand and usually produces repeatable results. However, adopting such systems can also result in failures to detect, manage and respond to security defects. The main reason for this is that vulnerability scoring systems are pretty good at measuring vulnerabilities, yet are unsuited to handling weaknesses.
The Difference between Vulnerabilities and Weaknesses
The MITRE Corporation (an American not-for-profit organisation which manages federally-funded research and development centres) simply defines a weakness as “a type of mistake in software that, in proper conditions, could contribute to the introduction of vulnerabilities within that software”. This definition can be expanded to a general notion that “weaknesses are errors that can lead to vulnerabilities”, making it applicable to other assets, not just software and including systems, networks and controls.
CVSS v3, for example, cannot really be used to measure the characteristics and severity of a weakness that has no currently defined vulnerability. We encounter this problem routinely when customers request CVSS ratings for application penetration tests where weaknesses are usually more evident.
Manage the Weaknesses
How weaknesses are managed alongside vulnerabilities is critical to the success of technical risk management programmes. It is common to see weaknesses inadequately assessed, measured and remediated and they are often overlooked, or fall off the radar completely. This is because remediation of critical and high severity vulnerabilities with verified scores are prioritised by overstretched security teams.
Let’s consider BlueKeep, a security vulnerability discovered in Microsoft’s Remote Desktop Protocol (RDP) implementation, which allows for the possibility of remote code execution. It is a remotely-exploitable, wormable vulnerability present in older versions of the RDP implementation.
If we ran a perimeter vulnerability scan today, which identified a notably unpatched RDP service, it would be scored by CVSS as 9.8 or in other words, ‘critical’. But how would the vulnerability scanner report the exposure of the same RDP service prior to BlueKeep’s public disclosure? Potentially in several different ways, but more than likely it would misclassify the exposure, despite it requiring immediate treatment as an obvious weakness, given its poor security reputation alone.
Another example where problems arise is in unsupported systems where vulnerabilities have not yet surfaced. The weakness here is obvious, but unsupported systems alone cannot be systematically scored. We often find that vulnerability scanners fudge high CVSS values to compensate, so perhaps this is a pragmatic, qualitative approach to handling weaknesses which cannot be measured. But if this qualitative approach is not applied to all weaknesses, unidentified gaps and inconsistencies, will be inevitable in the assurance activity.
Both examples consider vulnerability scanners, which are intrinsically affected by vulnerability scoring, but any service or security process that uses vulnerability scoring at its core is at risk of mishandling the weaknesses.
The Advice
It is important to review any tools and internal processes which assess security defects by vulnerability scoring at their core. Understand how they identify and interpret the severity of weaknesses alongside vulnerabilities. And remember that CVSS assumes that a vulnerability has already been discovered and verified; anything outside of this scope may be misrepresented or missed entirely.
Also, do not dismiss qualitative approaches in your threat and vulnerability management programme because they can be invaluable in gaining a comprehensive view of technical security issues and assurance. Although qualitative assessments are also subject to bad press, they can be pragmatic, particularly when conducted by someone who is an authority in a particular subject area.
A varied programme of technical assessments should provide a broader view of priorities, both short and long term. Make sure your assurance programme delivers across all your particular objectives, by reviewing your vendor’s way of working carefully. For example, high-quality penetration tests should provide context and visibility of application and system weaknesses over a longer-term, not just a snapshot of the verified vulnerabilities.
Pandemic Working and Remote Access Vulnerability Trends
The continued working from home protocol has meant organisations’ IT systems are still being stretched to the limit, with many new challenges coming to the fore and without the traditional visibility into their infrastructures. Solutions that were rolled out in an emergency when the COVID-19 pandemic hit are still in use nearly a year on. Perimeters have become more porous, and in many cases, rarely-used remote access systems became critical business infrastructure overnight. These business trends provide opportunities for adversaries, who will be looking for vulnerabilities in remote access software and remote access components.
Considering weaknesses pragmatically, and the possible exposure if a vulnerability is identified, is crucial to maintaining information security and managing the commensurate risks in the current environment. A simple score from a vulnerability scan of the perimeter simply does not capture the risk.
Additional sources:
No comments:
Post a Comment