Prioritizing Common Weaknesses Based Upon Your EnvironmentThere are a wide variety of ways software and hardware can become exploitable to an attacker, allowing them to make use of the software/hardware in ways that was never intended. The CWE Program offers several approaches for prioritizing the weaknesses so that you can focus on the appropriate subset and have the most improvement in the resilience, reliability, and integrity of your software/hardware as soon as possible. If you do not have the time to do a deeper analysis of how certain weaknesses would impact your software (as it is in use for a particular mission of your organization) you can make use of the CWE Top 25 list of the most widespread and critical CWEs. If you have some time and resources to focus on a specific subset of weaknesses (by looking at their technical impacts and the ways you can detect them), you should explore our Technical Impact & Detection Method approach. Finally, if you would like to use a consistent risk scoring methodology that was created out of the investigation of these first two approaches, look into the Common Weakness Scoring System (CWSS) for scoring CWEs and Common Weakness Risk Analysis Framework (CWRAF). This last approach allows one to prioritize CWEs most relevant to the organization's business, mission, and deployed technologies by applying CWSS using specialized scenarios, or "vignettes". Technical Impact & Detection MethodsWhile there are a large number of weaknesses in CWE, there appear to be only eight different consequences or technical impacts to which these failures lead (see the table below). In other words, if a weakness manifests itself in a product in an exploitable manner and an attacker successfully exploits it, then there will be one of eight technical impacts or consequences from that weakness. Technical Impacts of Software Weaknesses:
Within each CWE entry the "common consequences" field lists the "technical impacts" that can result from each weakness in CWE. The technical impact and its translation into an impact to the mission are important criteria that can be useful to any organization needing reasonable assurance that their software-based capabilities do what is intended and nothing more. The collapsing of the hundreds of types of errors into a small set of technical impacts offers a simplification to the question, "What should my organization focus on to gain assurance in our software?". Instead of trying to remove all weaknesses, you can decide which of the eight impacts are either more or less dangerous to you, given what the software product is doing for your organization. For example, a public website utilizing distributed hosting/mirroring to provide information may not worry about weaknesses that lead to resource consumption/denial-of-service exploits, but could be extremely concerned about weaknesses that can lead to someone modifying the data. Using this approach assurance activities can be focused on weaknesses that can lead to this unacceptable failure mode. This Technical Impact information can be leveraged in combination with the Detection Methods information in CWE entries to make a second simplification where weaknesses can be matched against assessment activities that can detect them. This exercise may improve insights into whether that weakness is still an issue, or whether it has been mitigated or removed. Common Weakness Scoring System (CWSS™)When a security analysis of a software application is performed, such as when using an automated code auditing tool, developers often face hundreds or thousands of individual bug reports for weaknesses that are discovered in their code. In certain circumstances, a software weakness can lead to an exploitable vulnerability. 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. This weakness only contributes to a vulnerability if the input can be influenced by a malicious party, and if that malicious input can copied to an output buffer that is smaller than the input. Due to the high volume of reported weaknesses, developers are forced into a situation in which they must prioritize which issues they should investigate and 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. Finally, 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. Further complicating the problem, the importance of a weakness may vary depending on business or mission needs, the kinds of technologies in use, and the threat environment. In short, people need to be able to reason and communicate about the relative importance of different weaknesses. While various scoring methods are used today, they are either ad hoc or inappropriate for application to the still-imprecise evaluation of software security. CWSS provides a mechanism for scoring weaknesses in a consistent, flexible, open manner while accommodating context for the various business domains. It is a collaborative, community-based effort that is addressing the needs of its stakeholders across government, academia, and industry. CWSS:
Common Weakness Risk Analysis Framework (CWRAF™)CWRAF, used in conjunction with CWSS, will provide your organization with a tailored "Top XX" list of common weaknesses. The list generated for your environment can be further decomposed into three groups:
Looking first at group one (above), there is no single software tool/program that can identify all of the common weaknesses. You will need several tools working together in order to cover the set of weaknesses identified in this group. Several available tools are inexpensive while others are very expensive. As a general rule of thumb, the more expensive tools provide a more comprehensive look at your software. If you are looking for an inexpensive quick "first steps":
Properly embracing Software Assurance within your organization will require a culture shift. This culture shift entails the understanding that software weaknesses will be exploited at some time and that new weaknesses may be discovered at any time. Build new rules into your software development processes to educate developers, testers, and contractors that software assurance is 5 parts software quality and 2 parts software security — and that software assurance is everybody's job. To begin with, compiler "warnings" should not be turned off or ignored.
|
