Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > Community > Software Assurance > Engineering for Attacks  

Engineering for Attacks

The greatest impact to software assurance activities comes from thinking about how an attacker will try to gain access, control, or influence over a system once it is operational. For far too long, the thinking about this has been relegated to the "Security Experts," yet they aren't the ones that can actually do anything about it in a timely and efficient manner—you are.

Subtle changes in the design, architecture, and operational concepts are one way, along with adding security features that address specific attacks. Not to be overlooked is a focused analysis of what the software will be doing for the organization and what kinds of failure would be most damaging if not removed or blocked during software development.

Considering the Attacker

By considering the attacker and using the collection of attack patterns available in the Common Attack Pattern Enumeration and Classification (CAPEC™)initiative, we can help identify opportunities for improving the resilience, integrity, and reliability of our software-based mission capabilities, as well as make our software less susceptible to attack.

CAPEC is a list of patterns attacks tend to follow that can exploit vulnerable weaknesses in systems software, network traffic, supply chain, and even the humans using the systems. For those CAPEC entries that deal with attacks against software, the weaknesses they exploit are listed by CWE Identifier and name. Likewise, these CWEs list CAPEC entries that they are susceptible to.

Engineering For Attacks

As shown in the figure above, a software assurance evaluation should be conducted to identify applicable attack patterns from CAPEC that the "system" could be subjected to, and weaknesses in CWE that those attack patterns are effective against. Next, the results and a documented set of recommended approaches should be provided, outlining how to effectively eliminate and mitigate the CWEs through architecture and design choices, inclusion of security controls and features. Also to be included is an assessment with source code analysis, dynamic analysis, penetration testing and any other method for addressing those weakness. This is the basic methodology described in the new ISO/IEC Technical Report 20004, "Refining software vulnerability analysis under ISO/IEC 15408 and ISO/IEC 18045".

Above, the red shading and lines show the path connecting an attacker with the targeted weaknesses, and control items that could mitigate or avoid the technical impacts that would have an operational impact to the organization's mission and operation.

We have used the word "system" above because the first iteration of the analysis should take place when only the operational concept and a notional architecture is defined. Though the fidelity of the analysis may be fairly rough, this early stage is the perfect time to be considering what attacks your system could be facing, and whether there are design, architecture, physical composition choices or changes in operational concepts that could dramatically help to mitigate, manage, or control those attacks with minimal cost and schedule impact.

Later in the program's evolution the details of implementation will allow a much finer grained analysis of the weaknesses and potential attacks your system could face. Choices have been made or are being made to minimize the attack surface, and supporting evidence shows that you have mitigated or eliminated the weaknesses that some of the attacks could leverage. At this point, a variety of detection methods can be applied to your project, such as running static code analysis tools, having design reviews that address design, dynamic security analysis and test case completion. All add evidence and reasons for confidence that the risk of exploit has been mitigated to an acceptable level.

As part of this assurance analysis you would want to describe how you are using CAPEC to track the coverage of potential attacks as you analyze your system. Using an attacker's destructive perspective helps assure that the weakness assessment and mitigation strategies utilized have not missed commonly used attack approaches or techniques.

Potentially Exploitable Weaknesses Identified by the Attack Patterns

As you examine the systems' potential software architectures/designs and prototype source code for weaknesses, those identified as being potentially exploitable by attack patterns should employ CWE to describe and track issues. Describe how you will use CWE to 1) better understand and manage software weaknesses related to architecture and design, and 2) enable more effective selection and use of software security tools and services to find weaknesses in source code and operational systems that are analyzed during development and sustainment.

Creating Your Program

The approach described above is also in alignment with the requirements for systems being developed for the U.S. Department of Defense (DoD). In 2011, the Program Protection Plan (PPP) was revised to require programs to provide specific Software Assurance progress information utilizing CWEs and CAPECs, as well as Common Vulnerabilities and Exposures (CVE®) Identifiers. Basically, the DoD is positioning these three as the vocabulary for discussion about assurance activities and measurement tools for reporting and tracking/managing risks to the systems during development and sustainment.

CVE Identifiers

For the PPP responses the DoD projects will need to discuss (as a program) how CVE Identifiers are being utilized to coordinate and address software security vulnerabilities and exposures in the system's commercial software and open source software, components or libraries. Topics would include how they use CVE Identifiers to identify and prioritize based on 1) mitigation, 2) potential vulnerabilities in the developer environment, test environment, or the system being developed that would allow an attacker to execute commands as another user, 3) access to data that is contrary to the specified access restrictions for that data, 4) pose as another entity, and/or 5) conduct a denial of service.

Often people use the Common Vulnerability Scoring System (CVSS) to help prioritize and rank the severity of the issues that have CVE Identifiers. Many vendors include CVSS scores with their CVE Identifiers in their public advisories.

CWE Identifiers

CWE and CAPEC are primarily meant to analyze/assess the software that they are developing/having developed, versus CVE's focus on commercial and open source software mistakes. The mistakes in commercial and open source products that lead to vulnerabilities (i.e., CVEs) are from the collection of weaknesses in CWE; but the buyer/user of those packages won't necessarily have insights into the CWEs—just the publicly known vulnerabilities (i.e., CVEs) that result from them.

Symantec, Apple, HP, and EMC have publicly declared that they use CWE in their software development lifecycles (SDLC). CWE Identifiers are used to track the issues that they have addressed during their development activities.

Likewise, the members of SAFECode (Microsoft, Adobe, Siemens, Juniper, SAP, Symantec, Nokia, and EMC) advocate using CWE in their Fundamental Practices for Secure Software Development 2nd Edition: A Guide to the Most Effective Secure Development Practices in Use Today.

CAPEC Identifiers

CAPEC Identifiers are being used to help developers, testers, and systems engineers to understand the complexities of how their systems can be attacked.

U.S Federal Reporting Requirements & Responsibilities

The U.S. Federal Government, under the Federal Information Security Management Act (FISMA), must now report some specifics about their software assurance activities. The FY2012 and FY2013 CIO FISMA Reporting Metrics issued by DHS asks, in section 4.2, that CIOs utilize CWE, CAPEC and CWSS to discuss what was done to search for weaknesses in non-COTS before release. The document also asks for a description of the methods used to assess for these issues, offering several possibilities. Specifically:

  • Web scanners for web-based applications
  • Static Code Analysis Tools
  • Manual code reviews (especially for weaknesses not covered by the automated tools)
  • Dynamic Code Analysis Tools
  • PEN testing for attack types not covered by the automated tools
Page Last Updated: April 02, 2018