New to CAPEC? Start Here
Home > News > News & Events - 2018 Archive  

News & Events

2018 Archive

CAPEC List Version 3.0 Now Available

July 31, 2018 | Share this article

CAPEC Version 3.0 has been posted on the CAPEC List page. A detailed report is available that lists specific changes between Version 2.11 and Version 3.0.

The main changes for CAPEC 3.0 include:

Attack Patterns

Categories

Views

Mappings

Schema

Summary

There are now 519 total attack patterns listed.

Changes for the new version include the following:

  • New Attack Patterns Added:
21
  • Existing Attack Patterns Updated:
228
  • Attack Patterns Deprecated:
10
  • Existing Categories Updated:
6
  • Existing Views Updated:
1
  • CAPEC-to-CWE Mapping Added:
99
  • CAPEC-to-CWE Mapping Removed:
13

See the complete list of changes at https://capec.mitre.org/data/reports/diff_reports/v2.11_v3.0.html.

Comments are welcome on the CAPEC Research Email Discussion List. Future updates will be noted here and on the CAPEC Research list.

IMPORTANT: Release of CAPEC 3.0 Includes Major Changes to CAPEC Schema

July 31, 2018 | Share this article

The release of CAPEC Version 3.0 includes major changes to the CAPEC Schema, which was updated from v2.7.1 to v3.0. A detailed report is available that lists specific changes between Version 2.7.1 and Version 3.0 of the schema.

The main changes for the CAPEC Schema Version 3.0 include:

  • Made the <Attack_Pattern_Catalog> the only valid root element. The previous 2.7.1 schema allows any number of elements to be valid root elements. As part of this change, the other children (Attack_Patterns, Views, Categories, and External_References) become optional. The previous <Attack_Pattern_Catalog> requires the existence all of the child element, even if they are empty.
  • Added the <External_References> element to the attack pattern catalog. In the previous 2.7.1 schema, references were defined inside an individual attack patterns, but assigned an ID so that they could be reused if the reference was used elsewhere.
  • Simplified seven element names: (1) Solutions_and_Mitigations to Mitigations, (2) Attack_Prerequisites to Prerequisites, (3) Attack_Motivation_Consequences to Consequences, (4) Attack_Execution_Flow to Execution_Flow, (5) Indicators-Warnings_of_Attack to Indicators, (6) Typical_Likelihood_of_Exploit to Likelihood_Of_Attack, and (7) Attacker_Skills_or_Knowledge_Required to Skills_Required.
  • Tweaked the child elements of the <View> and <Category> elements to simplify them.
  • For attack patterns, the “Description” element is now a simple string. Previously there was a <Description> element with two children; a short description was named <Summary>, and the other was named <Attack_Execution_Flow>. The 3.0 schema removes the subelement <Summary> and changes the name of <Attack_Execution_Flow> to <Execution_Flow>, which has been repurposed as a top-level element.
  • For attack patterns, the “Description” element is now a simple string. Previously there was a <Description> element with two children; a short description was named <Summary>, and the other was named <Attack_Execution_Flow>. The 3.0 schema removes the subelement <Summary> and changes the name of <Attack_Execution_Flow> to <Execution_Flow>, which has been repurposed as a top-level element.
  • Changed the RelationshipsType complex type to only be used for categories and views (for views, the element name has been changed to <Members>). Also limited the values to memberOf and hasMember since these are the only ones that are appropriate for views and categories. For attack patterns, added a new <Related_Attack_Pattern> element that holds all the different types of relationships that attack patterns can have with each other.
  • Combined all the different note elements are now combined into a single <Notes> element. Added a type attribute that allows for a distinction between: maintenance, relationship, research gap, terminology, and other. This was done to simplify the schema and the resulting XML by having less elements.
  • StructuredTextType now leverages the existing XHTML standard.
  • Vulnerabilities are no longer included in a CAPEC. CAPECs should reference Common Weakness Enumeration (CWE™) entries, when possible. CWEs are associated with Common Vulnerabilities and Exposures (CVE®) entries.

See the complete list of changes at https://capec.mitre.org/data/reports/diff_reports/xsd2.7.1_xsd3.0.html.

Comments are welcome on the CAPEC Research Email Discussion List. Future updates will be noted here and on the CAPEC Research list.

CAPEC Version 2.12 Released

July 31, 2018 | Share this article

As part of preparation for the release of CAPEC Version 3.0 (see news article above), CAPEC Version 2.12 was released to support changes for CAPEC 3.0. A detailed report is available that lists specific changes between v2.11 and v2.12. As an added benefit, CAPEC 2.12 also provides CAPEC Version 3.0 updated content in the older schema format.

How “Meltdown” and “Spectre” Can Be Defined by CWE and CAPEC

January 31, 2018 | Share this article

There has been a lot of press (rightly so) regarding the “Meltdown”- and “Spectre”-style attacks. The CAPEC and CWE teams have been reviewing the available information and trying to determine if new weaknesses or attack patterns should be added. Below are our current thoughts. We welcome additional discussion.

Common Weakness Enumeration (CWE™)

Both Meltdown and Spectre are technically attacks. They take advantage of a processor executing instructions out of order, in a way that causes some instructions to be executed even though the logic of the original code would not execute these instructions. This condition leads to a case where data in memory is cached before a permission check is performed. The end result is the ability to perform side-channel style attacks against the cache to learn the exact value of data.

The root cause of both of these attacks is the out of order execution. The processor uses this feature to increase the speed at which a program can be executed. This is very similar to compiler optimizations where a compiler makes changes to the source code to improve performance. In both instances, the computer is no longer executing exactly what the developer told it to execute, but rather is executing a variation that the processor/compiler thinks is “better.”

Unfortunately, these optimizations can sometimes lead to an exploitable weakness. There already exists a base-level CWE for the compiler version of this:

CWE-733: Compiler Optimization Removal or Modification of Security-critical Code

A new base-level CWE should be added to cover the case where the processor changes the order of security-critical code.

In addition, a new class-level CWE should also be considered around the topic of “Insecure Optimizations.” This class-level CWE would be a member of the Behavioral Problems category in the Development Concepts view, and a child of Interaction Error in the Researcher view. Both the existing compiler optimization (CWE-733) weakness and the new processor execution order weakness would be children of this new class.

CWE CATEGORY: Behavioral Problems

CWE-435: Improper Interaction Between Multiple Entities

Finally, there should be a CanFollow relationship between the existing class CWE-696: Incorrect Behavior Order and this new class “Insecure Optimizations”. We see this relationship in Meltdown/Spectre with the optimizations resulting in a change in the order of execution.

One last note, many discussions of Meltdown and Spectre focus on the side channel attack that arises from timing discrepancies. In this case, the timing discrepancy is not a weakness as it is legitimate behavior (since caching improves efficiency) and is not introduced by choices made by the application developer. Therefore, this is not a focus from the CWE classification perspective; the ability to see this (legitimate) timing discrepancy arises from the insecure optimization.

Common Attack Pattern Enumeration and Classification (CAPEC™)

Shifting to the attack pattern side of things, both the compiler and processor weaknesses are not currently well represented in CAPEC.

The compiler weakness (CWE-733) is not directly attacked, but rather results in a different weakness (e.g., buffer overflow) being present in the software, and that weakness is the one that is used in an attack. CWE thinks of this as a chain. The processor weakness can be thought of in the same way. Even though an adversary can manipulate when/how a processor decides to execute out of order, it is the resulting exposure of data that contributes to the vulnerability. See CWE-668: Exposure of Resource to Wrong Sphere.

For both the Meltdown and Spectre attacks, CAPEC already has a relevant standard-level attack pattern that can be leveraged:

CAPEC-141: Cache Poisoning

This attack pattern has a detailed-level child that covers the DNS version of cache poisoning. Meltdown and Spectre expose a different type of cache poisoning where the adversary doesn't insert malicious data into the cache, but rather cause the cache to contain data that shouldn’t be allowed. CAPEC-141 needs to be cleaned up a bit, but the overall idea behind it is valid. A new detailed-level pattern should be added to cover the Flush+Reload attack pattern (and potentially others) that are leveraged by the Meltdown and Spectre attacks.

What do you think?

Please let us know your thoughts on the above by sending an email message to the CAPEC Researcher community discussion list, or directly to capec@mitre.org.

We look forward to hearing from you!

More information is available — Please select a different filter.
Page Last Updated or Reviewed: January 03, 2020