Which is a dictionary of common names for publicly known information security vulnerabilities
|
The CVE & CCE Lists view allows you to import downloaded CVE and CCE lists and display the imported lists in tabular format. Once imported, the content of these lists populates the Properties windows of the rules contained in a package or the rules of a scan result, to provide the available information about the CVEs and CCEs the rule contains. Both of these lists are part of the existing open standards used by NIST in its Security Content Automation Protocol (SCAP) program.
Both lists help, through the use of consistent identifiers, to improve data correlation; enable interoperability; foster automation; and ease the gathering of metrics for use in situation awareness, IT security audits, and regulatory compliance. CVE provides this capability for information security vulnerabilities, CCE assigns a unique, common identifier to a particular security-related configuration issue. The view shows the following information about the imported lists, which are
referenced by the SCAP rules and in visualizing the SCAP job results:
Parameter Description Name The name of the imported file. Type The type of the list, that is, if it is a CVE or CCE list. Integration Date The date at which the list was imported into the CM database. Publication Date The date at which this specific list was made publicly available by its owning organism. Entry Count The number of entries, that is, vulnerabilities or configurations that the list includes.
Was this page helpful? Yes No Submitting... Thank you Contact us Welcome, Log in to your Red Hat account Log in Your Red Hat account gives you access to your member profile and preferences, and the following services based on your customer status: Register now Not registered yet? Here are a few reasons why you should be:
For your security, if you're on a public computer and have finished using your Red Hat services, please be sure to log out. Log out Account Log in
OverviewCVE, short for Common Vulnerabilities and Exposures, is a list of publicly disclosed computer security flaws. When someone refers to a CVE, they mean a security flaw that's been assigned a CVE ID number. Security advisories issued by vendors and researchers almost always mention at least one CVE ID. CVEs help IT professionals coordinate their efforts to prioritize and address these vulnerabilities to make computer systems more secure.
How does the CVE system work?The CVE program is overseen by the MITRE corporation with funding from the Cybersecurity and Infrastructure Security Agency (CISA), part of the U.S. Department of Homeland Security. CVE entries are brief. They don’t include technical data, or information about risks, impacts, and fixes. Those details appear in other databases, including the U.S. National Vulnerability Database (NVD), the CERT/CC Vulnerability Notes Database, and various lists maintained by vendors and other organizations. Across these different systems, CVE IDs give users a reliable way to recognize unique vulnerabilities and coordinate the development of security tools and solutions. The MITRE corporation maintains the CVE List, but a security flaw that becomes a CVE entry is often submitted by organizations and members of the open source community. About CVE identifiersCVE identifiers are assigned by a CVE Numbering Authority (CNA). There are about 100 CNAs, representing major IT vendors—such as Red Hat, IBM, Cisco, Oracle, and Microsoft—as well as security companies and research organizations. MITRE can also issue CVEs directly. CNAs are issued blocks of CVEs, which are held in reserve to attach to new issues as they are discovered. Thousands of CVE IDs are issued every year. A single complex product, such as an operating system, can accumulate hundreds of CVEs. CVE reports can come from anywhere. A vendor, a researcher, or just an astute user can discover a flaw and bring it to someone’s attention. Many vendors offer bug bounties to encourage responsible disclosure of security issues. If you find a vulnerability in open source software you should submit it to the community. One way or another, information about the flaw makes its way to a CNA. The CNA assigns the information a CVE ID, and writes a brief description and includes references. Then the new CVE is posted on the CVE website. Often, a CVE ID is assigned before a security advisory is made public. It’s common for vendors to keep security flaws secret until a fix has been developed and tested. That reduces opportunities for attackers to exploit unpatched flaws. Once made public, a CVE entry includes the CVE ID (in the format "CVE-2019-1234567"), a brief description of the security vulnerability or exposure, and references, which can include links to vulnerability reports and advisories.
What qualifies for a CVE?CVE IDs are assigned to flaws that meet a specific set of criteria. They must be: 1. Independently fixable.The flaw can be fixed independently of any other bugs. 2. Acknowledged by the affected vendor OR documented.The software or hardware vendor acknowledges the bug and that it has a negative impact on security. Or, the reporter must have shared a vulnerability report that demonstrates the negative impact of the bug AND that it violates the security policy of the affected system. 3. Affecting one codebase.Flaws that impact more than one product get separate CVEs. In cases of shared libraries, protocols or standards, the flaw gets a single CVE only if there’s no way to use the shared code without being vulnerable. Otherwise each affected codebase or product gets a unique CVE. Stay informed about Red Hat security.
What is the Common Vulnerability Scoring System?There are multiple ways to evaluate the severity of a vulnerability. One is the Common Vulnerability Scoring System (CVSS), a set of open standards for assigning a number to a vulnerability to assess its severity. CVSS scores are used by the NVD, CERT and others to assess the impact of vulnerabilities. Scores range from 0.0 to 10.0, with higher numbers representing a higher degree of severity of the vulnerability. Many security vendors have created their own scoring systems, as well. Three key takeawaysKnow your deployments. Just because a CVE exists doesn’t mean the risk applies to your specific environment and deployment. Be sure to read each CVE and understand if it applies to your environment by validating that it applies (or partially applies) to the operating system, application, modules, and configurations of your unique environment. Practice vulnerability management. Vulnerability management is a repeatable process to identify, classify, prioritize, remediate, and mitigate vulnerabilities. This means understanding how a risk would apply to your organization so you can properly prioritize any outstanding vulnerabilities that need to be addressed. Be ready to communicate. CVEs will impact your organization’s systems, both because of the vulnerabilities themselves and any potential downtime required to address them. Communicate and coordinate with your internal customers and share the vulnerabilities with any central risk management function within your organization. How Red Hat works with CVEsAs a major contributor to open source software, Red Hat is continuously engaged in the security community. Red Hat is a CVE Numbering Authority (CNA) and uses CVE IDs to track security vulnerabilities. Red Hat Security maintains an open and frequently updated database of security updates, which you can view by CVE number.
What is the Red Hat Security Data API?Red Hat Product Security provides access to raw security data on its Security Data page and in a machine-consumable format with the Security Data API. In addition to the security reports and metrics which Red Hat produces, customers can use this raw data to produce their own metrics for their own unique situations. The data provided by the Security Data API includes OVAL (Open Vulnerability and Assessment Language) definitions, Common Vulnerability Reporting Framework (CVRF) documents, and CVE data. Data is available in XML or JSON format.
Learn about Red Hat’s approach to security and compliance
Article If you want to take full advantage of the agility and responsiveness of DevOps, IT security must play a role in the full life cycle of your apps.
Article What is different about cloud securityHigh-level security concerns impact both traditional IT and cloud systems. Find out what's different.
SOAR refers to 3 key software capabilities that security teams use: case and workflow management, task automation, and a centralized means of accessing, querying, and sharing threat intelligence. More about securityProductsA security framework that manages user identities and helps keep communications private.  An enterprise-ready, Kubernetes-native container security solution that enables you to more securely build, deploy, and run cloud-native applications. A predictive analytics service that helps identify and remediate security, performance, and availability threats to your Red Hat infrastructure. A single console, with built-in security policies, for controlling Kubernetes clusters and applications. Related articlesResources
Checklist 6 security benefits of cloud computing environments
E-book Simplify your security operations center
E-Book Boost hybrid cloud security
Keep exploringGet more content like thisSign up for our free newsletter, Red Hat Shares. Learn about Red Hat’s commitment to protecting customer data and privacy What is the most common security vulnerability?The most common software security vulnerabilities include:. Missing data encryption.. OS command injection.. SQL injection.. Buffer overflow.. Missing authentication for critical function.. Missing authorization.. Unrestricted upload of dangerous file types.. Reliance on untrusted inputs in a security decision.. What is a CVE name?CVE names (also called "CVE numbers," "CVE–IDs," and "CVEs") are unique, common identifiers for publicly known information security vulnerabilities. CVE names have "entry" or "candidate" status.
Is CVE a dictionary or database?The CVE list is defined by MITRE as a glossary or dictionary of publicly available cybersecurity vulnerabilities and exposures, rather than a database, and as such is intended to serve as an industry baseline for communicating and dialoguing around a given vulnerability.
What are the common vulnerabilities of information system?Network vulnerabilities come in many forms but the most common types are: Malware, short for malicious software, such as Trojans, viruses, and worms that are installed on a user's machine or a host server. Social engineering attacks that fool users into giving up personal information such as a username or password.
|
