CWSS - Common Weakness Scoring System
CWSS - Common Weakness Scoring System
When a security analysis of an application is performed, such as when
using a code auditing tool, developers often face hundreds or thousands
of individual bug reports for their source code. Due to the volume, this
forces developers into a situation where they must prioritize which
issues they should fix first. Similarly, when assessing design and
architecture choices and their weaknesses there needs to be a method for
prioritizing them relative to each other and with the other issues of
the application. Also, software consumers want to know what they should
worry about the most and what to ask for to get a more secure product
from their vendors and suppliers.
So for each weakness in the architecture, design, code or implementation
that might be introduced into an application, which in some cases can
contribute to a vulnerability within that software, we need to be able to
reason and communicate about the relative importance of different
weaknesses.
For example, a "buffer overflow" vulnerability might arise from a
weakness in which the programmer does not properly validate the length
of an input buffer, and that input buffer can be influenced by a
malicious party, and that malicious buffer is copied to a smaller buffer.
As we develop CWSS we will explore what others have done in codifying
and communicating about severity. For example, Common
Vulnerabilities Scoring System (CVSS) may offer a structured
approach for capturing and communicating about the relevant factors for
describing and discussing the seriousness of a weakness by sub-dividing
it into the same type "Temporal", "Base" and "Environment" vectors.
"Temporal" might, for example, give higher scores to buffer overflows
and SQL injection because they're currently very well-known, whereas
"SQL column truncation" is brand-new and thus less likely to be
exploited by most attackers.
"Base" could be scored by the relative risk inherent in the weakness
being evaluated. If the range of possible impacts were less severe for
one weakness versus another then it would have a lower score.
"Environment" could reflect various aspects of the risk of a weakness
including where the weakness is in the application, what the application
is doing for the organization, whether that part of the application
handles important data or processes, how exposed the application is to
attacks and so forth. "Environment" could also capture organizational
goals in a way that weaknesses, for example, that an organization wants
to eliminate would have a higher score than otherwise.
Contact Us
To discuss the CWSS effort, offer ideas, or any other questions or
concerns, please email us at cwss@mitre.org.
|
