Bugs Framework (BF) Features
Irena Bojanova, Inventor/Creator, PI & Lead, NIST Bugs Framework (BF), 2014 – ~~~~ #

Current State of the Art #

The current state of the art in describing and linking software security weaknesses and vulnerabilities are the Common Weakness Enumeration (CWE), the Common Vulnerabilities and Exposures (CVE), and the National Vulnerabilities Database (NVD). CWE is community-developed list of software and hardware weaknesses types, CVE is a catalog of publicly disclosed cybersecurity vulnerabilities, and NVD links CVEs to CWEs and assigns ‘Common Vulnerability Scoring System’ (SVCC) severity scores.

CWE, CVE, and NVD are widely used, but they have some problems. Many CWEs and CVEs have imprecise descriptions and unclear causality. CWE also has gaps and overlaps in coverage. Additionally, there is no strict methodology for tracking a vulnerability’s weaknesses, nor tools to aid users in the creation and visualization of weakness and vulnerability descriptions.

The Bugs Framework (BF) aims to address all these CWE and CVE problems. It has the expressiveness power to clearly describe any software bug or weakness, underlying any vulnerability.

BF Features #

To solve the CWE and CVE problems of imprecise descriptions and unclear causality, BF is being developed as a formal classification system. The BF description of a vulnerability provides causal relationships – forming a chain of underlying weaknesses, leading to a failure. To avoid CWEs gaps and overlaps, BF is being developed as a complete, orthogonal taxonomy with strict causation and propagation rules. The BF Formal Language and tools guide streight frward weakness and vulnerability specification or backtracking based generation of pre-labeled datasets of vulnerability specifications.

Classification #

The Bugs Framework (BF) approach is different from the CWE exhaustive list approach. BF is a classification system!

The taxonomy of a particular bug or weakness is based on one BF class. Its description is an instance of a taxonomic BF class with one cause, one operation, one consequence, and their attributes. The operation binds the cause→consequence relation – e.g., deallocation via a dangling pointer leads to a failure known as Double Free.

So, each BF class is a taxonomic category of a weakness type, defined by:

• A set of operations
• Cause→consequence relations
• A set of attributes
• Sites.

It relates to a distinct phase of software execution, the operations specific for that phase and the operands required as input to those operations. Operations or operands improperness define the causes.

Causation #

BF describes a bug or a weakness as an improper state and its transition. The transitions is to another weakness or to a failure. An improper state is defined by an (operation, operand1, ···, operandn) tuple, for which at least one element is improper.

The initial state (depicted in blue on Figure 1) is always caused by a bug; a code or specification defect within the operation, which if fixed will resolve the vulnerability. A propagation (intermediate) state (in light purple) is caused by at least one faulty (ill-formed) operand. The final state results in a final exploitable error (usually directly relates to a CWE) that leads to a failure. An error is the result of an improper state from the operation over the operands. It propagates to an improper operand for a next improper state. For example, on Figure 1, Operation 1 from Improper State 1 is improper, due to a Bug, and results in Improper Operand 2i, leading to Improper State 2. The last operation results in an Exploitable Error, leading to a failure.

Figure 1. BF Causality -- a bug or a weakness relates to an improper state and its transition. The transition is to another weakness or to a failure..

A consequence is the result of the operation over the operands (see figure 2). It becomes the cause for a next weakness or is a final error, leading to a failure. The attributes describe the operations and the operands. They help us understand the severity of the bug or the weakness. The BF description of a weakness is an instance of a taxonomic BF class with one operation, one cause, one consequence, and their attributes. Any vulnerability then can be described as a chain of such instances and their consequence–cause transitions.

Figure 2. A consequence is the result of the operation over the operands. It becomes the cause for a next weakness or is a final exploitable error, leading to a failure..

Propagation #

BF describes a vulnerability as a chain of improper states and their transitions (see Figure 3). Each improper state corresponds to an instance of a BF class. The initial state has an improper operation over proper operands. The transition states have proper operations with at least one improper operand. All improper states propagate by the error from one state becoming the fault for the next state. I other words, the transition from the initial state is by improper operation (an operation that has a bug) over proper operands; the transitions from intermediate states are by proper operations with at least one improper operand (the operand is at fault).

Figure 3. BF features: Chaining weaknesses – A vulnerability as a chain of improper states and their transitions.

Converging #

In some cases, several vulnerabilities must be present for an exploit to be harmful. The final errors resulting from different chains converge to cause a failure (see Figure 4). The bug in at least one of the chains must be fixed to avoid that failure. Operations or operands improperness define the causes. A consequence is the result of the operation over the operands. It becomes the cause for a next weakness or a failure.

Figure 4. Converging software security vulnerabilities, leading to a security failure..

Backtracking #

The improper operation or improper operand is the cause for that weakness. The improper result from an operation over its operands is the consequence from that weakness, and it becomes a cause for a next weakness or a failure. Knowing the failure and all the transitions at execution, we should be able to find the bug (see Figure 5) – simply go backwards by operand until an operation is improper – fixing the bug within that operation will resolve the vulnerability.

Figure 5. BF features: Backtracking from a failure to the bug – knowing the failure, go backwards by improper operand until an operation is improper – fixing the bug within that operation will resolve the vulnerability..