Understanding CVEs & CWEs

MITRE

MITRE is a government-funded organization that establishes standards for the information security community. By far the most popular standards used here are the CWE and CVE. For obvious reasons, these are often used interchangeably…and wrongly. Below, we’ll explain what CWE and CVE stand for and how each are utilized in the world of information security.

CWE

CWE is the standard acronym for Common Weakness Enumeration. This deals with the vulnerability itself and not the instance within the scope of a product or system. CWE is extensively used in vulnerability management as it makes the whole process more streamlined and easily accessible. The open source CWE catalog enumerates hardware and software weaknesses and is often used as a measuring scale for the effectiveness of security tools and provides an easily accessible baseline for identifying, mitigating, and preventing vulnerabilities.

CVE

CVE, on the other hand, is the common acronym for Common Vulnerabilities and Exposures. This deals with the specific instance within a product or system and not the vulnerability itself. CVE can be best understood as a glossary for the classification of vulnerabilities. The CVE glossary provides an analysis of vulnerabilities and applies the Common Vulnerability Scoring System (CVSS) to assign the relevant threat level to the vulnerability. The CVE score is a commonly used reference for assigning the priority for the security threat posed by vulnerabilities.

The CVE glossary is an ongoing project that tries to accurately track and catalog vulnerabilities in consumer software and hardware. Again, this standard is maintained by the MITRE Corporation that is partially funded by the US Division of Homeland Security. The glossary uses the Security Content Automation Protocol (SCAP) to collect and catalog vulnerabilities. SCAP is used to not only evaluate the vulnerability information but also to assign each vulnerability with its own unique identifier.

Once the evaluation and identification processes are over, vulnerabilities become listed in the glossary and made publicly available by MITRE. It’s only after the vulnerabilities are listed that the National Institute of Standards and Technology (NIST) jumps into action to analyze them. The results of the analysis and other vulnerability information are all recorded under NIST’s National Vulnerability Database (NVD). For more information on understanding existing vulnerabilities in your enterprise software and hardware, please refer Cloud Direct Connect.

What Is a CVE Identifier?

All publicly known cybersecurity vulnerabilities are assigned with unique CVE Identifiers. These identifiers come in handy as the set method for identifying vulnerabilities. These can also be used for cross-linking with other repositories.

Identifier include a set of characteristics:

• An unique identifier number.
• Current status such as “entry” or “candidate”
• Detailed description of the security vulnerability
• Relevant references

When a vulnerability is scoped out and verified, a CVE Numbering Authority (CNA) assigns a unique number to it. This CVE identifier is in the format of — CVE-{year}-{ID}. CVE identifiers can be assigned by a cumulative number of 114 organizations spread across 22 countries. These organizations have the CNA certification and include research organizations, security and IT vendors. MITRE is capable of granting both the status of CNAs to organizations as well as retains the ability to assign CVE numbers directly.

CNAs, in turn, get their vulnerability information from researchers, vendors, or users. A large number of vulnerabilities also come up thanks to bug bounty programs initiated by different vendors. These programs reward users for discovering vulnerabilities and reporting them to the vendor without public discovery. Vendors then pass along the information to a CNA to be cataloged and also supply the CNA with any available patch information. Once reported, the vulnerability gets assigned a unique CVE identifier. The CNA further reports the vulnerability information with the identifier to MITRE. The latter further verifies this information during which reported vulnerabilities may get waitlisted before they are made public. This time gap also gives vendors some breathing space to quickly develop patches and mitigate the scope of harm from the vulnerability once it is discovered by others. The public listing of a CVE vulnerability includes its ID, a description of the vulnerability, and other relevant references that may include additional information or reports. Since the discovery process is ongoing, newer references and other findings are subsequently added to the entry as they are discovered.

What’s Included in the CVE List?

Enterprise software and hardware are always prone to the discovery of new vulnerabilities. In order to stay safe, companies must take a proactive approach in identifying and mitigating vulnerabilities. For more information and guidance on this, please reach out to Cloud security solution.

The types of software vulnerabilities in a CVE list can include:

• SQL Injection
• Cross-Site Scripting (XSS)
• Directory Traversal
• HTTP Response Splitting
• Denial of Service (DoS)
• Code Execution
• Buffer Overflow
• Memory Corruption

How to Fix Common Vulnerabilities and Exposures?

Fixing common vulnerabilities and exposures can be addressed by companies using the following steps:

• Companies must take care to define software design requirements. This includes both defining and enforcing secure coding principles. This can help provide a structure to how to write, test, inspect, analyze, and demonstrate your code effectively.
• Companies should make use of a coding standard such as OWASP, CWE, and CERT. These can help organizations prevent, detect, and mitigate the impact of vulnerabilities.
• Teams should also take care to include security checks into the organization’s CI/CD pipeline so they can detect software security vulnerabilities well in advance. This also enforces beneficial coding practices.
• Finally, companies should take care to test their code early and often with an eye to detecting the maximum possible number of vulnerabilities early. The goal must be to find and eliminate these vulnerabilities at the earliest.