Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Mods for precise mapping in Related Guidelines and Mapping Notes

...

Severity—How serious are the consequences of the rule being ignored?

Value

Meaning

Examples of Vulnerability

1

Low

Denial-of-service attack, abnormal termination

2

Medium

Data integrity violation, unintentional information disclosure

3

High

Run arbitrary code

Likelihood—How likely is it that a flaw introduced by violating the rule can lead to an exploitable vulnerability?

Value

Meaning

1

Unlikely

2

Probable

3

Likely

Remediation Cost—How expensive is it to comply with the rule?

Value

Meaning

Detection

Correction

1

High

Manual

Manual

2

Medium

Automatic

Manual

3

Low

Automatic

Automatic

The three values are then multiplied together for each rule. This product provides a measure that can be used in prioritizing the application of the rules. The products range from 1 to 27, although only the following 10 distinct values are possible: 1, 2, 3, 4, 6, 8, 9, 12, 18, and 27. Rules and recommendations with a priority in the range of 1 to 4 are Level 3 rules, 6 to 9 are Level 2 , and 12 to 27 are Level 1 . The following are possible interpretations of the priorities and levels.

Priorities and Levels

Level

Priorities

Possible Interpretation

L1

12 , 18 , 27

High severity, likely, inexpensive to repair

L2

6 , 8 , 9

Medium severity, probable, medium cost to repair

L3

1 , 2 , 3 , 4

Low severity, unlikely, expensive to repair

Specific projects may begin remediation by implementing all rules at a particular level before proceeding to the lower priority rules, as shown in the following illustration:

...

Related vulnerability sections are included only for specific rules in this standard, when the information is both relevant and interesting.

Related Guidelines

...

For each entry in a Related Guidelines table, CERT has determined that there is some code flaw for which there is both a violation of some condition of the CERT guideline and a condition of the external-to-CERT guideline, where that condition is violated or that condition is described as a flaw.

Related Guidelines Table headings definitions

  • Taxonomy: A named set of coding rules, weaknesses, standards, or guidelines such as Information Technology—Programming Languages, Their Environments and System Software Interfaces—C Secure Coding Rules [ISO/IEC TS 17961:2013]; Information Technology—Programming Languages —Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use [ISO/IEC TR 24772:2013]; MISRA C 2012: Guidelines for the Use of the C Language in Critical Systems [MISRA C:2012]; and CWE IDs in MITRE’s Common Weakness Enumeration (CWE) [MITRE 2010].

You can create a unique URL to get more information on CWEs by appending the relevant ID to the end of a fixed string. For example, to find more information about CWE-192, Integer Coercion Error,” you can append 192.html to http://cwe.mitre.org/data/definitions/ and enter the resulting URL in your browser: http://cwe.mitre.org/data/definitions/192.html.

The other referenced technical specifications, technical reports, and guidelines are commercially available.

 

  • Taxonomy item: A single named (and/or numbered) item in a taxonomy

  • Relationship: For each entry in a Related Guidelines table, CERT has determined that there is some code flaw for which there is both a violation of some condition of the CERT guideline and a condition of the external-to-CERT guideline, where that condition is violated or that condition is described as a flaw.

...

These relationships may be defined in a precise or imprecise way. For Common Weakness Enumeration (CWE), CERT has made precise mappings between CERT guidelines C rules and CWEs, as described below. For other taxonomies of coding flaws or secure coding (such as MISRA or ISO/IEC TR 24772:2013), so far, CERT has made only imprecise (“Unspecified Relationship”) mappings.. An “Unspecified Relationship” label indicates there is some overlapping code flaw condition, but the extent is unspecified.

If the mapping was made using an automated process developed by CERT, and not yet verified manually, the mapping is marked at the end with “(A)”. 

Precise relationships explain more about the extent to which conditions of the CERT guideline and external guideline match.

In the simplest case, the guidelines are exactly equal (the relationship is labelled “Exact”). CERT's “partial mapping” terms {“Partial overlap”, “Guideline subset of <EXTERNAL_GUIDELINE>”, “<EXTERNAL_ GUIDELINE > subset of rule”} describe relationships between the guideline items using the language of sets, where the guideline item (a CERT guideline or an <EXTERNAL_ GUIDELINE> entry) is a set that holds one or more conditions. By subset we mean a proper subset, that A = subset(B) means “A ⊂ B”  means every element (meaning, every condition) in A is also in B, but there exists at least one element in B that is not in A. If a condition of a program violates a CERT rule “R” and also exhibits an <EXTERNAL_ GUIDELINE> “E”, that condition is in the overlap between “R” and “E”. 

For each CWE that has a partial mapping to a CERT rule, we have documented the nature of what the rule and CWE have in common, what is exclusive to the rule, and what is exclusive to the CWE, in a section titled “CERT-CWE Mapping Notes”.

The 10 precise relationship labels CERT uses are mostly the same as the 10 CWE Mapping Fit relationship labels, with 3 different labels.

Different but related terms:

CERT term

MITRE term

Rule subset of CWE

CWE_More_Abstract

CWE subset of rule

CWE_More_Specific

Partial overlap

Imprecise


Table column formats:

  • Taxonomy: Taxonomy name (e.g., “CWE”) followed by version name that was mapped, if that is known (e.g., “CWE 2.11”, “CERT 2016”, or “MISRA”)

  • Taxonomy item: A single named (and/or numbered) item in a taxonomy, sometimes with the full title text of the item and sometimes with a hyperlink to the item.

  • Relationship: A combined entry with fields for date mapped, organization that did the mapping, and relationship (all in same cell for one mapping, separated by a colon, with one entry per line): <(Optional “Prior to ”)YYYY-MM-DD: ORGANIZATION: RELATIONSHIP(Optional “(A)”)>.  Where specified by mapping day, precise mappings done by CERT use the latest published edition of a non-CERT taxonomy along with the latest published edition of the CERT standard plus changes on the CERT wiki. Precise mappings done by an external organization use the latest published edition of the CERT standard and their own latest published edition. Examples below:
    • Example entries below, in the same cell on different lines: 2017-10-31: CERT: CERT Subset of CWE 2017-05-04: CWE: Exact
    • Example entry for a different mapping, where the exact mapping date is unknown but is known to be before October 03, 2017:

      Prior to 2017-10-03: CERT: Unspecified Relationship

    • Example entry for a different mapping that was made using an automated process and not yet manually verified:

      Prior to 2017-09-05: CERT: Unspecified Relationship (A)

The related guidelines sections contain links to guidelines in related standards, technical specifications, and guideline collections such as Information Technology—Programming Languages, Their Environments and System Software Interfaces—C Secure Coding Rules [ISO/IEC TS 17961:2013]; Information Technology—Programming Languages —Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use [ISO/IEC TR 24772:2013]; MISRA C 2012: Guidelines for the Use of the C Language in Critical Systems [MISRA C:2012]; and CWE IDs in MITRE’s Common Weakness Enumeration (CWE) [MITRE 2010]. 

You can create a unique URL to get more information on CWEs by appending the relevant ID to the end of a fixed string. For example, to find more information about CWE-192, Integer Coercion Error,” you can append 192.html to http://cwe.mitre.org/data/definitions/ and enter the resulting URL in your browser: http://cwe.mitre.org/data/definitions/192.html

The other referenced technical specifications, technical reports, and guidelines are commercially available.

CERT-CWE Mapping Notes

CERT's “partial mapping” terms {Partial overlap, Rule subset of CWE, CWE subset of rule} describe relationships between the taxonomy items using the language of sets, where the taxonomy item (a CERT rule or a CWE weakness) is a set that holds one or more conditions. If a condition of a program violates a CERT rule “R” and also exhibits a CWE weakness “W”, that condition is in the overlap between the rule and weakness.

For each CWE that has a partial mapping to a CERT rule, in this section we document the nature of what the rule and CWE have in common, what is exclusive to the rule, and what is exclusive to the CWE. Sometimes what is exclusive or shared is simply described by set equations using taxonomy items, but other times documentation of what is shared may include function names or data types, or some prose description of shared characteristics.

Notation: “Intersection(A, B) =” the right side of the equals sign defines if there is an overlap between A and B, meaning if a condition of a program exists with an overlapping area between A and B.

Notation:  “A ⊂ B” means every element in A is also in B, but there exists at least one element in B that is not in A. (It means A is a “proper subset” of B.)

Notation:  “A ⊄ B” means A is not a proper subset of B.

Notation:  “Intersection(A, B) = ∅” means no element in A is also in B. (It means the intersection is the empty set.)

Notation:  “A - B =” the right side of the equals sign defines what element(s), if any, exist in A that are not also in B.

No CERT C rule or recommendation is identical to any other CERT C rule or recommendation.

In this section, Independent() means all the rules listed within are independent: that is, every pair of two rules listed they have an empty intersection. Most CERT rules are designed to be independent, that is, they have no overlap. (This applies only to rules, not recommendations).

For CWE that have been identified as having at least a partial overlap with another CERT rule R1, for current mapping to CERT rule R2: In the Mapping Notes section we consider C’s possible overlap or exclusion of the CWE overlap area with R1.  We also consider the relationship of R1 and R2, if any. (By defining the relationship between the CERT rules that separately have at least some overlap with the CWE of interest, the mapping notes further define the conditions of overlap and/or non-overlap between the primary CWE-to-CERT-rule mapping of interest.)

Bibliography

Most guidelines have a small bibliography section that lists documents and sections in those documents that provide information relevant to the guideline.

...