Common Weakness Enumeration

CWE Glossary Definition

Name of Your Organization:

Cybellum

Web Site:

http://www.cybellum.com/

Compatible Capability:

Cybellum Product Security Platform

Capability home page:

http://www.cybellum.com/

Product Accessibility <CR_2.4>

Provide a short description of how and where your capability is made available to your customers and the public (required):

We have a digital web platform, to which our clients can upload firmware files. We are crating a Digital Twin out of it, which is the digital replica of the firmware. Out of the Digital Twin, our clients can create Zero Day assessment, which will scan the different executable files for CWE violations.

Map Currency Indication <CR_6.1>

Describe how and where your capability indicates the most recent CWE content used to create or update its mappings (required):

We used https://cwe.mitre.org/ as our primary information source, to traverse the different CWEs that we want to support in our product.

Map Currency Update Approach <CR_6.2>

Indicate how often you plan on updating the mappings to reflect the current CWE content and describe your approach to keeping reasonably current with the CWE content when mapping them to your repository (recommended):

We constantly receive updates from the MITRE site, news feeds, and various information sources across the web, including Dark Reading, The Hacker News, and different news lists and blogs from industry companies.

MAP CURRENCY UPDATE TIME <CR_6.3>

Describe how and where you explain to your customers the timeframe they should expect an update of your capability’s mappings to reflect newly available CWE content (required):

Mostly we update about new supported CWEs in the release notes.

CWE AND COMPATIBILITY DOCUMENTATION <CR_5.1>

Provide a copy, or directions to its location, of where your documentation describes CWE and CWE compatibility for your customers (required):

Zero Days weaknesses supported

Zero Days Assessments

Supported Weaknesses

Last updated: Apr 23, 2021

Cybellum Technology

Most components are built using a combination of open-source software (OSS) and some proprietary code - either first-party, written by the vendor itself, or third-party, written by external parties, such as commercial SDKs and software libraries.

Conventional detection of the software bill of materials is therefore incapable of providing any visibility to software risks of this part of the software. At the core of the Cybellum platform is the Cybellum ZD detection technology. At the basis of this technology are a set of parallel scanners capable of identifying unknown (unofficial), zero day types of vulnerabilities. Using unique analysis of the Assembly code within the binary, various software issues and hacks can be detected within the code. These issues are not only identified but rather validated by running a simulation of the affected Assembly code.

The Cybellum Platform supports the detection of zero day vulnerabilities in all major platforms - Intel x86/64, ARM 32/64, MIPS, PowerPC/PowerPC VLE and MIPS, as well as the leading microcontroller architectures in automotive - Renesas RH850/V850 and Infineon TriCore.

Supported Weaknesses (Rich OS)

The Cybellum Platform can detect the following code weaknesses from the supported rich OS components. The weaknesses can be detected in executables from any of the supported CPU architectures - mainly Intel x86/x64, ARM, PowerPC and MIPS.

These weaknesses can be detected in UNIX/Linux ELF and Microsoft Windows PE executable files.

CWE	Description
CWE-20	(similar to CWE-77) Improper Input Validation
CWE-22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CWE-23	Relative Path Traversal
CWE-36	Absolute Path Traversal
CWE-76	Improper Neutralization of Equivalent Special Elements
CWE-77	Command Injection
CWE-78	OS Command Injection
CWE-94	(similar to CWE-77)Improper Control of Generation of Code ('Code Injection')
CWE-119	(similar to CWE-120) Improper Restriction of Operations within the Bounds of a Memory Buffer
CWE-120	Classic Buffer Overflow
CWE-121	Stack-based Buffer Overflow
CWE-122	Heap-based Buffer Overflow
CWE-124	Buffer Underflow
CWE-125	(similar to CWE-120) Out-of-bounds Read
CWE-126	Buffer Over-read
CWE-127	Buffer Under-read
CWE-134	Use of Externally-Controlled Format String
CWE-170	Improper Null Termination
CWE-195*	Signed to Unsigned Conversion Error
CWE-242	Use of Inherently Dangerous Function
CWE-252	Unchecked Return Value
CWE-253*	Incorrect Check of Function Return Value
CWE-364	Signal Handler Race Condition
CWE-366	Race Condition within a Thread
CWE-367	Time-of-check Time-of-use (TOCTOU) Race Condition
CWE-369*	Divide By Zero
CWE-377	Insecure Temporary File
CWE-391	Unchecked Error Condition
CWE-400*	Uncontrolled Resource Consumption
CWE-401*	Missing Release of Memory after Effective Lifetime
CWE-415	Double Free
CWE-416	Use After Free
CWE-426*	Untrusted Search Path
CWE-427	Uncontrolled Search Path Element
CWE-457*	Use of Uninitialized Variable
CWE-475*	Undefined Behavior for Input to API
CWE-476	NULL Pointer Dereference
CWE-477	Use of Obsolete Function
CWE-478	Missing Default Case in Switch Statement
CWE-479*	Signal Handler Use of a Non-reentrant Function
CWE-484*	Omitted Break Statement in Switch
CWE-562	Return of Stack Variable Address(only supported in ARM)
CWE-590	Free of Memory not on the Heap
CWE-666*	Operation on Resource in Wrong Phase of Lifetime
CWE-667*	Improper Locking
CWE-675*	Duplicate Operations on Resource
CWE-690	Unchecked Return Value to NULL Pointer Dereference
CWE-758*	Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
CWE-772*	Missing Release of Resource after Effective Lifetime
CWE-773*	Missing Reference to Active File Descriptor or Handle
CWE-775*	Missing Release of File Descriptor or Handle after Effective Lifetime
CWE-787	(similar to CWE-120) Out-of-bounds Write
CWE-789*	Memory Allocation with Excessive Size Value
CWE-824*	Access of Uninitialized Pointer
CWE-832*	Unlock of a Resource that is not Locked
CWE-833	Deadlock

* Limited detection

Supported Weaknesses (Microcontrollers)

The Cybellum Platform can detect the following code weaknesses from the supported microcontroller components. The weaknesses can be detected in executables from any of the supported microcontroller architectures - mainly ARM, Renesas RH850/V850 and Infineon TriCore.

CWE	Description
CWE-119	(similar to CWE-120) Improper Restriction of Operations within the Bounds of a Memory Buffer
CWE-120	Buffer Overflow
CWE-124	Buffer Underflow
CWE-125	(similar to CWE-120) Out-of-bounds Read
CWE-126	Buffer Over-read
CWE-127	Buffer Under-read
CWE-200	Exposure of Sensitive Information to an Unauthorized Actor
CWE-209	Generation of Error Message Containing Sensitive Information
CWE-215	Insertion of Sensitive Information Into Debugging Code
CWE-242	Use of Inherently Dangerous Function
CWE-674	Uncontrolled Recursion
CWE-787	(similar to CWE-120) Out-of-bounds Write
CWE-835	Infinite Loop
CWE-1120	Excessive Code Complexity

Supported Weaknesses (Java files)

The Cybellum Platform can detect the following code weaknesses from the Java files.

CWE	Description
CWE-489	Active Debug Code
CWE-925	Improper Verification of Intent by Broadcast Receiver
CWE-927	Use of Implicit Intent for Sensitive Communication
CWE-1021	Improper Restriction of Rendered UI Layers or Frames

DOCUMENTATION OF FINDING ELEMENTS USING CWE IDENTIFIERS <CR_5.2>

Provide a copy, or directions to its location, of where your documentation describes the specific details of how your customers can use CWE identifiers to find the individual security elements within your capability’s repository (required):

In the Assessment page of our product, the different components could be viewed

In our product, we show a list of detected issues, together with its CWEs and the name of the vulnerable component.

DOCUMENTATION OF FINDING CWE IDENTIFIERS USING ELEMENTS <CR_5.3>

Provide a copy, or directions to its location, of where your documentation describes the process a user would follow to find the CWE identifiers associated with individual security elements within your capability’s repository (required):

In our product, we list the different vulnerabilities that were found in the digital twin.

DOCUMENTATION INDEXING OF CWE-RELATED MATERIAL <CR_5.4>

If your documentation includes an index, provide a copy of the items and resources that you have listed under "CWE" in your index. Alternately, provide directions to where these "CWE" items are posted on your web site (recommended):

Our CWE is a direct link to MITRE page with the required CWE.

Type-Specific Capability Questions

FINDING TASKS USING CWE IDENTIFIERS <CR_A.2.1>

Give detailed examples and explanations of how a user can locate tasks in the tool by looking for their associated CWE identifier (required):

After creating assessments, the user can filter the different findings according to specific CWEs. Each filtered finding, is a task that the user should do, in order to enhance the security standards of its product. Each item is trackable, and includes state and history.

FINDING CWE IDENTIFIERS USING ELEMENTS IN REPORTS <CR_A.2.2>

Give detailed examples and explanations of how, for reports that identify individual security elements, the tool allows the user to determine the associated CWE identifier for the individual security elements in the report (required):

We support the process of exporting a report based on the digital twin. The report, lists the different issues and tasks, together with the relevant CWE identifiers.

GETTING A LIST OF CLAIMED CWE IDENTIFIER COVERAGE <CR_A.2.3>

Give detailed examples and explanations of how a user can obtain a listing of all of the CWE identifiers that the owner claims the tool is effective at locating in software (required):

Attached in Question number 6 the list that we provide to the users.

GETTING A LIST OF CWE IDENTIFIERS ASSOCIATED WITH TASKS <CR_A.2.6>

Give detailed examples and explanations of how a user can obtain a listing of all of the CWE identifiers that are associated with the tool's tasks (recommended):

It’s visible in the different pages of the assessment.

SELECTING TASKS WITH A LIST OF CWE IDENTIFIERS <CR_A.2.7>

Describe the steps and format that a user would use to select a set of tasks by providing a file with a list of CWE identifiers (recommended):

The user will create a DT with the file as the firmware. Then create Zero Day assessment, which will scan the file for potential CWE violations. The results will be displayed as tasks in the system.

SELECTING TASKS USING INDIVIDUAL CWE IDENTIFIERS <CR_A.2.8>

Describe the steps that a user would follow to browse, select, and deselect a set of tasks for the tool by using individual CWE identifiers (recommended):

User can filter the data using the different filters, including the CWE filter, which will narrow down to the relevant issues only for this CWE.

NON-SUPPORT NOTIFICATION FOR A REQUESTED CWE IDENTIFIER <CR_A.2.9>

Provide a description of how the tool notifies the user that a task associated with a selected CWE identifier cannot be performed (recommended):

There are different statuses of the task that cold be chosen, including accept risk.

ELECTRONIC DOCUMENT FORMAT INFO <B.3.1>

Provide details about the different electronic document formats that you provide and describe how they can be searched for specific CWE-related text (required):

We provide an access to our Wiki based on confluence.

ELECTRONIC DOCUMENT LISTING OF CWE IDENTIFIERS <CR_B.3.2>

If one of the capability’s standard electronic documents only lists security elements by their short names or titles provide example documents that demonstrate how the associated CWE identifiers are listed for each individual security element (required):

N/A

ELECTRONIC DOCUMENT ELEMENT TO CWE IDENTIFIER MAPPING <CR_B.3.3>

Provide example documents that demonstrate the mapping from the capability's individual elements to the respective CWE identifier(s) (recommended):

Provided in the previous questions.

FINDING ELEMENTS USING CWE IDENTIFIERS THROUGH THE GUI <CR_B.4.1>

Give detailed examples and explanations of how the GUI provides a "find" or "search" function for the user to identify your capability’s elements by looking for their associated CWE identifier(s) (required):

Users can filter the results of our scan by different CWE identifier. An example is attached in the previous questions.

GUI ELEMENT TO CWE IDENTIFIER MAPPING <CR_B.4.2>

Briefly describe how the associated CWE identifiers are listed for the individual security elements or discuss how the user can use the mapping between CWE identifiers and the capability’s elements, also describe the format of the mapping (required):

They are listed in a summary bar at the assessment landing page, and are listed for each finding in a dedicated line.

GUI EXPORT ELECTRONIC DOCUMENT FORMAT INFO <CR_B.4.3>

Provide details about the different electronic document formats that you provide for exporting or accessing CWE-related data and describe how they can be searched for specific CWE-related text (recommended):

We support exporting the information in pdf and csv formats.

STATEMENT OF COMPATIBILITY <CR_2.11>

Have an authorized individual sign and date the following Compatibility Statement (required):

"As an authorized representative of my organization I agree that we will abide by all of the mandatory CWE Compatibility Requirements as well as all of the additional mandatory CWE Compatibility Requirements that are appropriate for our specific type of capability."

Name: Roman Kesler

Title: VP of Research in Cybellum

STATEMENT OF ACCURACY <CR_3.4>

Have an authorized individual sign and date the following accuracy Statement (recommended):

"As an authorized representative of my organization and to the best of my knowledge, there are no errors in the mapping between our capability's Repository and the CWE identifiers our capability reports, and those CWE identifiers are as specific as possible within the available CWE repository."

Name: Roman Kesler

Title: VP of Research in Cybellum

STATEMENT ON FALSE-POSITIVES AND FALSE-NEGATIVES <CR_B.2.10> and/or <CR_B.3.7>

FOR TOOLS AND SERVICES ONLY — Have an authorized individual sign and date the following statement about your tools efficiency in identification of security elements (required):

"As an authorized representative of my organization and to the best of my knowledge, normally when our capability reports a specific security element, it is generally correct and normally when an event occurs that is related to a specific security element our capability generally reports it."

Name: Roman Kesler

Title: VP of Research in Cybellum