Engineering for Attacks
Attacker |
Weaknesses Identified By Attack Patterns |
Creating Your Program |
U.S Federal Reporting Requirements & Responsibilities
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 AttackerBy 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. 
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 PatternsAs 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 ProgramThe 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 IdentifiersFor 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 IdentifiersCWE 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 IdentifiersCAPEC 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 & ResponsibilitiesThe 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:
|
