The Common Weakness Enumeration (CWE) system categorises software weaknesses and vulnerabilities, with an aim to help create automated tools that can both fix and prevent them from happening. The CWE Top 25 "Most Dangerous Software Errors" list has just been updated for the first time since 2011. So, what's changed and does it actually matter to enterprise security teams?
The CWE project, sponsored by the US National Cybersecurity Federally Funded Research and Development Centre, which is owned by the not-for-profit MITRE Corporation, has support from both US-CERT and the National Cyber Security Division of the US Department of Homeland Security. It acts as a "demonstrative list" of what have been calculated to be the "most widespread and critical weaknesses" leading to serious software vulnerabilities.
The previous list was compiled with the use of surveys and interviews with analysts, developers, researchers and vendors. However, the 2019 list took a data-driven approach using both published Common Vulnerabilities and Exposures (CVE) information along with their associated Common Vulnerability Scoring System (CVSS) scores. This gives the list much more of a real-world perspective, or at least that is the aim.
By applying a formula that determines the level of prevalence and danger, each of the entries in the list were given a ranking score. Using data from 2017 and 2018, a total of around 25,000 CVEs, revealed a new most dangerous weakness to topple the previous number one of SQL Injection (which fell back to sixth place): CWE-119 "Improper Restriction of Operations within the Bounds of a Memory Buffer."
Other changes from the 2011 list include the appearance of class level CWEs for "broad error types" such as CWE-119 itself, but also CWE-20 (improper input validation), CWE-200 (information exposure) and CWE-287 (improper authentication).
Because researchers often use these to describe a vulnerability root when reported, they are prevalent in the data-driven analysis. This has caused some interesting changes in the list itself, such as CWE-119 being at number one while CWE-120 (Buffer Copy without Checking Size of Input) which was number three previously has now vanished from the list completely.
Interesting, because CWE-119 is the "high-level" parent of the more detailed CWE-120. Similarly, CWE-787 (Out-of-bounds Write) is a new entry at number 12. This can often be found as part of a chain of weaknesses that starts with the now absent CWE-120.
So, what do infosec professionals make of the new list bearing all this in mind? Are these really the most dangerous software errors, or has MITRE got it wrong?
Israel Barak, chief information security officer at Cybereason, agrees in general with the new CWE classifications, but argues that the "CVE database has a bias built into it that might make the CWE scoring mechanism less effective in the real world".
The bias is that the information in the CVE data is contributed by the good guys and not the bad guys, he explains. "Very often, the good guys encounter the vulnerabilities that are easier to find. Hence the good guys are likely to report a larger number of less impactful findings."
The flip side of this is that adversaries often invest more time and effort in discovering harder to find and more impactful vulnerabilities that can remain unknown to the good guys for years.
Javvad Malik, security awareness advocate at KnowBe4, worries that the list will actually be "encouraging to attackers", as even the lesser-skilled ones will now know that "without advanced techniques or custom malware abilities, they can still take advantage of age-old flaws to breach many companies".
Richard Gold, director of security engineering at Digital Shadows, doesn't think there will be any great surprises in the list for most security professionals. "The challenge is bringing the vendors, suppliers, developers and administrators on-board to develop effective technology and processes to mitigate the risk caused by these errors," said Gold.
Gold suggests that the list is really mainly useful for security professionals who are involved in the development of software systems, such as the Secure Software Development Lifecycle (S-SDLC). "It provides a good starting point for investigating if a software system has the necessary mitigations in place to deal with the common set of threats," he said.
Chris Bates, VP of security strategy at SentinelOne, is hopeful that as the current version of the MITRE list is detailed enough to be "adopted into secure coding practices and Secure Software Development Lifecycles", by security vendors and professionals as a "common vocabulary" and framework. In other words, the real world value becomes clearer if it can get baked into both static and dynamic code review products along with vulnerability assessment tools.
So, as it stands now, is the CWE list of any real use to enterprise security teams? "I think it can be very useful, particularly from a software security perspective, to be able to prioritise the work on improving the security of the enterprise software," said Oleg Kolesnikov, VP of Threat Research at Securonix.
At the same time, Kolesnikov warns that the list isn't applicable in all cases. "Some organisations may have a different set of priorities when it comes to software security issues," he said.
SentinelOne’s Bates, meanwhile, would downgrade that "very useful" rating to slightly or moderate at best. "If it can become more widely adopted and maintained like ATT&CK, it will become very useful."
Cybereason’s Barak agrees that the MITRE ATT&CK framework is "one of the most effective ways to improve enterprise security operations, as adversaries become increasingly sophisticated."
Synopsys senior security strategist Jonathan Knudsen, who says studying the list in isolation is like comparing the risk of death by heart attack, shark bite or being hit by a falling vending machine. "The world is full of things that can go wrong," Knudsen said. "The real question is how do we reduce risk?" While lists such as these aren’t intended to be a catch-all, Knudsen concludes, "they should inform security teams and the security initiative in place within their business.