Common Attack Pattern Enumeration and Classification

Requirements and Recommendations for CAPEC Compatibility

Requirements and Recommendations for CAPEC Compatibility

Document version: 1.0    Date: August 30, 2012

This is a draft report and does not represent an official position of The MITRE Corporation. Copyright © 2012, The MITRE Corporation. All rights reserved. Permission is granted to redistribute this document if this paragraph is not removed. This document is subject to change without notice.

Authors:
Robert A. Martin, CAPEC Program Manager - ramartin@mitre.org
Sean Barnum, CAPEC Technical Lead - sbarnum@mitre.org

View as PDF

Accuracy Percentage - The percentage of security elements in the Review Sample that reference the correct CAPEC identifiers.

Attack Instance - A specific detailed attack against an application or system targeting vulnerabilities or weaknesses in that system.

Attack Pattern - An abstraction of common approaches of attack observed in the wild against applications or systems (e.g. SQL Injection, Man-in-the-Middle, Session Hijacking, etc.). A single attack pattern may potentially have many varying attack instances associable with it.

Capability - An assessment tool, dynamic application security testing (DAST) tool, penetration testing tool, exploit framework tool, threat modeling tool, database, Web site, advisory, or service that provides information about attack instances and patterns.

Map/Mapping - The specification of relationships between attack pattern elements in a Repository and the CAPEC items that are related to those elements.

Owner - The custodian (real person or company) having responsibility for the capability.

Repository - An implicit or explicit collection of attack pattern elements that supports a capability, e.g., a database of attack patterns, the set of attack instances in a DAST tool, or a Web site.

Review - The process of determining whether a capability is CAPEC-Compatible.

Review Authority - An entity that performs a Review and is authorized to grant CAPEC-Compatible status (MITRE is the only Review Authority at this time).

Review Version - The dated version of CAPEC that is being used for determining CAPEC compatibility of a capability.

Security Element - A database record, assessment probe, attack instance, exploit, payload, etc., that is related to a specific attack pattern.

Task - A tool’s probe, check, signature, etc., that performs some action that produces security information (i.e., the security element).

Tool - A software application or device that tests the security properties of an application or system through simulation, emulation or characterization of potential attacks against that system, e.g., an assessment tool, dynamic application security testing (DAST) tool, penetration testing tool, exploit framework tool, threat modeling tool

User - A consumer or potential consumer of the Capability.

Vulnerability - Any weakness in software that could be exploited to violate a system or the information it contains (based upon ITU-T X.1500).

Weakness - A shortcoming or imperfection in the software code, design, architecture, or deployment that, could, at some point become a vulnerability, or could contribute to the introduction of other vulnerabilities.

The following items define the concepts, roles, and responsibilities related to the proper use of CAPEC Identifiers to share data across separate security analysis, security testing, security operations and security management capabilities (tools, repositories, services, and standards) to allow these capabilities to be used together, and to facilitate the comparison of security-relevant tools and services.

Prerequisites

2.1) The capability owner MUST be a valid legal entity, i.e., an organization or a specific individual, with a valid phone number, email address, and street mail address.

2.2) The capability MUST provide additional value or information beyond that which is provided in CAPEC itself (i.e., name, description, risks, references, and associated weakness information).

2.3) The capability owner MUST provide the Review Authority with a technical point of contact who is qualified to answer questions related to the mapping accuracy and any CAPEC-related functionality of the capability.

2.4) The capability MUST be available to the public, or to a set of consumers, in a production or public version.

2.5) For CAPEC compatibility the capability owner MUST provide the Review Authority with a completed "CAPEC compatibility Requirements Evaluation Form."

2.6) The capability owner MUST provide the Review Authority with free access to the Repository so that the Authority can determine that the Repository satisfies all associated mapping accuracy requirements.

2.7) The capability owner MUST allow the Review Authority to use the Repository to identify any attack pattern that should be added to CAPEC.

2.8) The capability owner MUST agree to abide by all of the mandatory CAPEC compatibility Requirements, which includes the mandatory requirements for the specific type of capability.

Functionality

2.9) For CAPEC compatibility the capability MUST allow users to locate security elements using CAPEC identifiers ("CAPEC-Searchable").

2.10) For CAPEC compatibility when the capability presents security elements to the user, it MUST allow the user to obtain the associated CAPEC identifiers ("CAPEC-Output").

2.11) For CAPEC compatibility the capability’s mapping MUST accurately link security elements to the appropriate CAPEC identifiers ("Mapping Accuracy").

2.12) For CAPEC compatibility the capability’s documentation MUST adequately describe CAPEC, CAPEC compatibility, and how the CAPEC-related functionality in the capability is used ("CAPEC-Documentation").

2.13) For CAPEC compatibility the capability’s publicly available documentation MUST explicitly list the CAPEC identifiers that the capability owner considers the capability to cover as part of its functionality ("CAPEC-Coverage").

2.14) For CAPEC compatibility the capability’s publicly available web site SHOULD provide the capability’s CAPEC-Coverage as a CAPEC Coverage Claim Representation (CCR) XML document(s).

2.15) The capability MUST denote the dated CAPEC version used ("Version Usage").

2.16) The capability MUST satisfy any additional requirements for the specific type of capability, as specified in Appendix A.

2.17) The capability MUST satisfy all requirements for its distribution media, as specified in Appendix B.

2.18) The capability is NOT REQUIRED to do any of the following:

Miscellaneous

2.19) If the capability does not satisfy all of the applicable requirements above (2.1 through 2.18), then the capability owner shall not advertise that it is CAPEC-compatible.

CAPEC compatibility only facilitates data sharing and correlation if the capability’s mapping is accurate. Therefore, CAPEC-compatible capabilities must meet the following minimum accuracy requirements.

3.1) The Repository MUST have an accuracy of 100 percent.

3.2) During the review period, the capability owner MUST correct any mapping errors found by the Review Authority.

3.3) After the review period, the capability owner SHOULD correct a mapping error within a reasonable time frame after the error was initially reported, i.e., within two (2) versions of the capability repository or six (6) months, whichever is shorter.

3.4) The capability owner SHOULD prepare and sign a statement that, to the best of the capability owner’s knowledge, there are no errors in the mapping.

3.5) If the capability is based on, or uses, another CAPEC-compatible capability (the "Source" capability), and the capability owner becomes aware of mapping errors in the Source capability, then the capability owner MUST report those errors to the capability owner of the Source capability.

The following requirements apply to documentation that is provided with the capability.

4.1) The documentation MUST include a brief description of CAPEC and CAPEC compatibility, which can be based on verbatim portions of documents from the CAPEC Web site.

4.2) The documentation MUST describe how the user can find individual security elements in the capability’s repository by using CAPEC identifiers.

4.3) The documentation MUST describe how the user can obtain CAPEC identifiers from individual elements in the capability’s repository.

4.4) If the documentation includes an index, then it SHOULD include references to CAPEC-related documentation under the term "CAPEC."

Users must know what version of CAPEC is used in a capability’s repository with respect to its mapping to CAPEC. The capability owner can indicate the currency of a mapping by referencing the relevant CAPEC version and optionally, the date the mapping was updated.

5.1) The capability MUST identify the CAPEC version or update date that was used in creating or updating the mapping through at least one of the following: change logs, new feature lists, help files, or some other mechanism. The capability is "up-to-date" with respect to that version or update date.

5.2) Each new version of the capability SHOULD be up-to-date with respect to a CAPEC version that was released no more than four (4) months before the capability was made available to its users. If a capability does not satisfy this requirement, then it is "out-of-date."

5.3) The capability owner SHOULD publicize how quickly it will update the capability’s repository after a new CAPEC version or update becomes available on the CAPEC Web site.

6.1) If a review authority has verified that a capability is CAPEC-compatible, but at a later time the Review Authority has evidence that the requirements are not being met, then the Review Authority MAY revoke its approval.

6.1.1) The review authority MUST identify the specific requirements that are not being met.

6.2) The review authority MUST determine if the actions or claims of the capability owner are "intentionally misleading."

6.2.1) The review authority MAY interpret the phrase "intentionally misleading" at its discretion.

6.3) The review authority SHOULD NOT consider revoking CAPEC compatibility for a particular capability more often than once every six (6) months.

Warning and Evaluation

6.4) The review authority MUST provide the capability owner and technical POC with a warning of revocation at least two (2) months before revocation is scheduled to occur.

6.4.1) If the review authority has found that the capability owner’s actions or claims are intentionally misleading, then the Review Authority MAY disregard the warning period.

6.5) If the capability owner believes that the requirements are being met, then the capability owner MAY respond to the warning of revocation by providing specific details that indicate why the capability meets the requirements under question.

6.6) If the capability owner modifies the capability so that it complies with the requirements in question during the warning period, then the Review Authority SHOULD end the revocation action for the capability.

Revocation

6.7) The review authority MAY delay the date of revocation.

6.8) The review authority MUST publicize that CAPEC compatibility has been revoked for the capability.

6.9) If the review authority finds that the capability owner’s actions with respect to CAPEC compatibility requirements are intentionally misleading, then revocation SHOULD last a minimum of one year.

6.10) The review authority MAY publicize the reason for revocation.

6.11) The capability owner MAY post a public statement regarding the revocation on the same site.

6.12) If the approval is revoked, the capability owner MUST NOT apply for a new review during the period of revocation.

7.1) A Review Authority MUST review the Capability for CAPEC compatibility with respect to a specific CAPEC version, i.e., the Review Version.

7.2) A review authority MUST clearly identify the Review Version that was used to determine compatibility for the capability.

7.3) A review authority MUST clearly identify the version of the CAPEC compatibility requirements document that was used to determine compatibility for the capability.

7.4) A review authority MUST review every element in the capability’s repository for CAPEC mapping accuracy.

7.5) A review authority SHOULD review a capability for mapping accuracy at least once per year.

Since a wide variety of capabilities use CAPEC, certain types of capabilities may have unique features that require special attention with respect to CAPEC compatibility.

A.1) The capability MUST satisfy all additional requirements that are related to the specific type of capability.

A.1.1) If the capability is an assessment tool, dynamic application security testing (DAST) tool, penetration testing tool, exploit framework tool, threat modeling tool, or a product that integrates the results of one or more of these types of items, then it must satisfy the Tool Requirements, A.2.1 - A.2.8.

A.1.2) If the Capability is a service (such as a security assessment service and training service, or a code and design review service) then it must satisfy the Security Service Requirements, A.3.1 - A.3.5.

A.1.3) If the Capability is an online security issues or weaknesses in code database, Web-based resource, or information site, then it must satisfy the Online Capability Requirements, A.4.1 - A.4.3.

Tool Requirements

A.2.1) The tool MUST allow the user to use CAPEC identifiers to locate associated tasks in that tool ("CAPEC-Searchable") by providing at least one of the following: a "find" or "search" function, a mapping between that tool’s task names and CAPEC identifiers, or another mechanism determined to be sufficient by the review authority.

A.2.2) For any report that identifies individual security elements, the tool MUST allow the user to determine the associated CAPEC identifiers for those elements ("CAPEC-Output") by doing at least one of the following: including CAPEC identifiers directly in the report, providing a mapping between the tool’s task names and CAPEC identifiers, or using some other mechanism determined to be sufficient by the review authority.

A.2.3) The publicly available documentation MUST explicitly list the CAPEC identifiers that the capability owner considers the tool effective at instantiating ("CAPEC-Compatibility Claim Coverage").

A.2.4) The capability’s publicly available web site MAY provide the capability’s CAPEC-Compatibility Claim Coverage as a CAPEC Coverage Claim Representation (CCR) XML document(s).

A.2.5) Any required reports or mappings MUST satisfy the media requirements as specified in Appendix B.

A.2.6) The tool, or the capability owner, SHOULD provide the user with a list of all CAPEC identifiers that are associated with the tool’s tasks.

A.2.7) The tool SHOULD allow the user to select a set of tasks by providing a file that contains a list of CAPEC identifiers.

A.2.8) The interface of the tool SHOULD allow the user to browse, select, and deselect a set of tasks by using individual CAPEC identifiers.

A.2.9) If the tool does not have a task that is associated with a CAPEC identifier as specified by the user in the A.2.5 or A.2.6 tool requirements, then the tool SHOULD notify the user that it cannot perform the associated task.

Security Service Requirements

Security services might use CAPEC-compatible tools in their work, but they may not provide their customers with direct access to those tools. Thus it could be difficult for customers to identify and compare the capabilities of different services. The Security Service Requirements address this potential limitation.

A.3.1) The Security Service MUST be able to use CAPEC identifiers to tell a user which security elements are tested or covered by the service offering ("CAPEC-Searchable") by doing one or more of the following: providing the user with a list of CAPEC identifiers that identify the elements that are tested or covered by that Service, providing the user with a mapping between the Service’s elements and CAPEC identifiers, responding to a user-supplied list of CAPEC identifiers by identifying which of the CAPEC identifiers are tested or covered by the Service, or by using some other mechanism.

A.3.2) For any report that identifies individual security elements, the Service MUST allow the user to determine the associated CAPEC identifiers for those elements ("CAPEC-Output") by doing one or more of the following: allowing the user to include CAPEC identifiers directly in the report, providing the user with a mapping between the security elements and CAPEC identifiers, or by using some other mechanism.

A.3.3) The publicly available documentation MUST explicitly list the CAPEC identifiers that the capability owner considers the Security Service to effectively cover in its offering ("CAPEC-Compatibility Claim Coverage").

A.3.4) The capability’s publicly available web site MAY provide the capability’s CAPEC-Compatibility Claim Coverage as a CAPEC Coverage Claim Representation (CCR) XML document(s).

A.3.5) Any required reports or mappings that are provided by the Service MUST satisfy the media requirements as specified in Appendix B.

A.3.6) If the Service provides the user with direct access to a product that identifies security elements, then that product SHOULD be CAPEC-compatible.

Online Capability Requirements

A.4.1) The online capability MUST allow a user to find related security elements from the online capability’s repository ("CAPEC-Searchable") by providing one of the following: a search function that returns CAPEC identifiers for related elements, a mapping that links each element with its associated CAPEC identifier(s), or some other mechanism.

A.4.1.1) The online capability SHOULD provide a URL "template" that allows a computer program to easily construct a link that accesses the search function as outlined in online capability Requirements A.4.1.

A.4.1.2) If the site is publicly accessible without requiring login, then the cgi program SHOULD accept "GET" method.

A.4.2) For any report that identifies individual security elements, the online capability MUST allow the user to determine the associated CAPEC identifiers for those elements ("CAPEC-Output") by doing at least one of the following: by allowing the user to include CAPEC identifiers directly in the report, providing the user with a mapping between the security elements and CAPEC identifiers, or by some other mechanism.

A.4.3) The publicly available documentation MUST explicitly list the CAPEC identifiers that the capability owner considers the online capability’s repository to cover ("CAPEC-Compatibility Claim Coverage").

A.4.4) The capability’s publicly available web site MAY provide the capability’s CAPEC-Compatibility Claim Coverage as a CAPEC Coverage Claim Representation (CCR) XML document(s).

A.4.5) If the online capability does not provide details for individual security elements, then the online capability MUST provide a mapping that links each element with its associated CAPEC identifier(s).

B.1) The distribution media that is used by a CAPEC-compatible capability MUST use a media format that is covered in this appendix.

B.2) The media format MUST satisfy the specific requirements for that format.

Electronic Documents (HTML, word processor, PDF, ASCII text, etc.)

B.3.1) The document MUST be in a commonly available format that has readers which support a "find" or "search" function ("CAPEC-Searchable"), such as raw ASCII text, HTML, or PDF.

B.3.2) If the document only provides short names or titles for individual elements, then it MUST list the CAPEC identifiers that are related to those elements ("CAPEC-Output").

B.3.3) The document SHOULD include a mapping from elements to CAPEC identifiers, which lists the appropriate pages for each element.

Graphical User Interface (GUI)

B.4.1) The GUI MUST provide the user with a search function that allows the user to enter a CAPEC identifier and retrieve the related elements ("CAPEC-Searchable").

B.4.2) If the GUI lists details for an individual element, then it MUST list the CAPEC identifiers that map to that element ("CAPEC-Output"). Otherwise, the GUI MUST provide the user with a mapping in a format that satisfies the B.3.1 Electronic Documents requirement.

B.4.3) The GUI SHOULD allow the user to export or access CAPEC-related data in an alternate format that satisfies the B.3.1 Electronic Documents requirement.