2014 News & Events (Archive)

CVE is mentioned in a December 11, 2014 article entitled "ICS-CERT: BlackEnergy Attacks on Critical Infrastructure" on
Infosecurity-Magazine.com. The main focus of the article is a
"sophisticated malware campaign that has compromised numerous industrial control systems (ICS) environments using a variant of the BlackEnergy malware appears to be targeting internet-connected human-machine interfaces (HMIs). The BlackEnergy campaign has been ongoing since at least 2011, and the United States'
ICS-CERT recently published information and technical indicators about it… "

CVE is mentioned when the author states: "Typical malware deployments have included modules that search out any network-connected file shares and removable media for additional lateral movement within the affected environment. Analysis suggests that the actors likely used automated tools to discover and compromise vulnerable systems as an initial vector. For instance, the organization's analysis has identified that systems running GE's Cimplicity HMI with a direct connection to the internet are being targeted using an exploit for a vulnerability in GE's Cimplicity
HMI product that has been known since at least January 2012. GE has
patched the
vulnerability,
CVE-2014-0751, so users should update their systems immediately."

CVE is mentioned at the very beginning of the article when the author states:
"Microsoft came out with its December Patch Tuesday update, marking the final
set of regularly scheduled security updates for 2014. In total, Microsoft is
fixing 24 unique Common Vulnerabilities and Exposures (CVEs) this month, across
seven security advisories. Of those seven security advisories, Microsoft rated
only three as critical. One of the critical advisories is MS14-080, which
patches 14 CVEs in Microsoft's Internet Explorer (IE) Web browser. The December
CVE count in IE is actually a decline from the 17 CVEs patched in November's
Patch Tuesday update."

CVE is mentioned in a November 25, 2014 article entitled "The branded bug: Meet the people who name vulnerabilities" on
ZDNet.com. The main topic of the article is that
"As 2014 comes to a close, bugs are increasingly disclosed with catchy names and logos. Heartbleed's
branding changed the way we talk about security, but is making a bug 'cool'
frivolous or essential?"

CVE is first mentioned in a section of the article entitled "Can attackers be thwarted with marketing?",
as follows: "Heartbleed — birth name CVE-2014-0160 — became a household term overnight, even though average households still don't actually understand what it is. The media mostly didn't understand what Heartbleed was either, but its logo was featured on every major news site in the world, and the news spread quickly. Which was good, because for the organizations who needed to remediate Heartbleed,
it was critical to move fast."

CVE is mentioned again when the author states: "The next "big bug" after Heartbleed was Shellshock — real name CVE-2014-6271 [and CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, and CVE-2014-6278]. Shellshock didn't have a company's pocketbook or marketing team behind it. So, despite the fact that many said Shellshock was
worse than Heartbleed (rated high on severity but low on complexity, making it easy for attackers),
creating a celebrity out of Shellshock faced an uphill climb."

Four different CVE IDs are cited in the article as follows: "Security researchers at Rapid7 discovered that 150,000 of Hikvision DVRs devices could be accessed remotely. Rapid7 warns that DVRs exposed to the internet are routinely targeted for exploitation.
"This is especially troubling given that a similar vulnerability (CVE-2013-4977) was reported last year, and the product still appears unpatched out of the box today," researchers at the firm behind the Metasploit penetration testing tool conclude. A
blog post (extract below) by Rapid7, the firm behind the Metasploit penetration testing tool, explains the vulnerabilities at play in greater depth.
"[Hikvision] DS-7204 and other models in the same product series that allow a remote attacker to gain full control of the device. More specifically, three typical buffer overflow vulnerabilities were discovered in Hikvision's RTSP request handling code: CVE-2014-4878, CVE-2014-4879 and CVE-2014-4880. This blog post serves as disclosure of the technical details for those vulnerabilities. In addition, a remote code execution through a Metasploit exploit module has been published." No authentication (login) is required to exploit this vulnerability. The Metasploit module demonstrates how unpatched security bugs would enable hackers to gain control of a vulnerable device while sitting behind their keyboard, potentially
thousands of miles away."

CVE is mentioned in section 4 of the article, "Master navigation of vendor vulnerability databases and tools to minimize vulnerability windows," in which the author states:
"When a data center is vulnerable to security flaws, the window of attack needs to be patched immediately. The best way to do so is to choose software that is officially compatible with
CVE, the set of standard identifiers for publicly known security vulnerabilities and exposures. When a vulnerability is recognized, it's assigned a CVE number. This gives multiple vendors a single identifier to determine their vulnerability in a consistent and measurable way. Many open source projects and communities don't consistently track against CVEs, but several companies who commercialize these projects do, so choose wisely. In addition to tracking the CVEs, admins can use OpenSCAP to do vulnerability scans. OpenSCAP can use Open Vulnerability and Assessment Language (OVAL) content to
scan systems for known vulnerabilities where remediation is available. The trick is to ensure your chosen
vendors provide OVAL content consistently, so again,
choose wisely."

The total number of CVE IDs assigned in 2014 has surpassed 9,000, indicating that a CVE ID number in the
new CVE ID numbering format with 5 digits (e.g., CVE-2014-XXXXX) will be issued before the middle-to-end of December 2014.

However, if not issued before the end of December, a CVE ID with
5 digits will definitely be issued no later than Tuesday, January 13, 2015 (read
our
press release). The new format provides for arbitrary digits at the end as
needed (e.g., CVE-2014-XXXXXX with 6 digits at the end, CVE-2014-XXXXXXX with 7
digits at the end, and so on), but we expect to only reach CVE ID numbers with 5
digits at the end this calendar year.

Please report any problems, or anticipated problems, that you encounter with CVE IDs issued in the new format to
cve-id-change@mitre.org.

CVE is first mentioned after the author compliments Microsoft for the quality of the information it reports, then discusses Google:
"I can't tell you a whole lot about the vulnerabilities in Chrome. Google almost never publishes minor details or even meaningful ones like CVE numbers, unless there was a bug bounty on the vulnerability. In that case, they brag about it in the blog. The October 7 report is a good example of this: It lists 12 bounties paid for a total of $52,633.70. That's nice, and they include CVEs for those vulnerabilities, but that's still just 12 of the 159 vulnerabilities. The blog lists one more CVE for
"[v]arious fixes from internal audits, fuzzing and other initiatives." Does this last CVE refer to more than one vulnerability? That's not clear. If you click the
"159 security fixes" link in the blog, you get to
a database of bug reports which are not very informative and don't
include CVEs, at least not that I can find."

The author mentions CVE again with regard to Apple, when he states:
"Apple does give individual CVEs for each vulnerability and usually credits them, but they don't provide severity information." The author concludes the article by stating that the number of vulnerabilities being reported in browsers is up in 2014, but that
"…it's actually a good thing. All those bugs were always there; it's just that now testers are getting better at finding them. It might mean browsers will be harder to attack over time, but let's
not get our hopes too high yet."

CVE is mentioned throughout a November 11, 2014 article entitled
"Microsoft Patches 33 Vulnerabilities in November Patch Tuesday Update" on
eWeek.com. CVE is first mentioned at the beginning of the article, when the author states:
"The [November] Patch Tuesday update fixed 24 Common Vulnerabilities and Exposures (CVEs), including CVE-2014-4114, the flaw known as Sandworm that was used in attacks against NATO and the European Union. On Oct. 21, Microsoft warned its users about CVE-2014-6352, which is another flaw in the Microsoft Object Linking and Embedding (OLE) technology that is at the root of the Sandworm vulnerability. Microsoft provided a
"Fix-it" for CVE-2014-6352, though a full patch was not made available until
today. The CVE-2014-6352 vulnerability is being patched inside of the MS14-064
advisory, which actually patches an additional OLE vulnerability identified as
CVE-2014-6332."

CVE is mentioned again when the author states: "Among the interesting flaws that Microsoft is patching this month is CVE-2014-6321, a remote code execution vulnerability in the Microsoft Secure Channel (Schannel) security technology.
Schannel is a security package that enables
SSL/TLS for Windows. The article quotes Senior Manager of Security Engineering at Rapid7, Ross Barrett with regard to this CVE ID, who said:
" … right now the impact from CVE-2014-6321 is low, but if exploit code leaks and
this proves to be a serious issue, then the impact will increase."

CVE is mentioned a third time in a section near the end of the article regarding fixes for Internet Explorer, when the author states:
"As is typical in most Microsoft Patch Tuesday updates, the Internet Explorer
(IE) Web browser is responsible for a largest number of reported CVEs. For
November, the MS14-065 advisory for IE includes fixes for 17 CVEs. The
vulnerabilities include multiple memory corruption and information disclosure
flaws."

CVE is mentioned in a November 11, 2014 article entitled "Microsoft Patches 19-Year-Old Windows Flaw" on
NewsFactor.com. CVE is mentioned in the opening of the article when the author states:
"IBM's X-Force has uncovered a flaw that has gone unpatched for at least 19 years. Big Blue researcher Robert Freeman called it a
"significant
data manipulation vulnerability that impacts every version of Microsoft Windows from Windows 95 onward. The good news is Microsoft issued a patch for CVE-2014-6332 on Tuesday. The bad news is hackers have had the ability to exploit it remotely since the days of Internet Explorer 3. Freeman described the complex vulnerability as a
"rare, unicorn-like bug" that's found in code on which IE relies but to which it
doesn't necessarily belong."

The CVE Web site now contains 65,764 unique information security issues with publicly known names. CVE, which began in 1999 with just 321 common names on the
CVE List, is considered the international standard for public software vulnerability names. Information security professionals and product vendors from around the world use CVE Identifiers (CVE IDs) as a standard method for
identifying vulnerabilities; facilitating their work processes; and
cross-linking among products, services, and other repositories that use the identifiers.

Each of the 65,000+ identifiers on the CVE List includes the following: CVE Identifier number, brief description of the security vulnerability, and pertinent references such as vulnerability reports and advisories. Visit the
CVE List page to download the complete list in various formats or to look-up an individual identifier.

REMINDER: The deadline for compliance with the
new CVE ID numbering format is rapidly approaching. A CVE ID number using the new format will be issued either before the end of 2014 and no later than Tuesday, January 13, 2015. Read our
press release.

CVE began 15 years ago this month with 321 entries on the
CVE List. Since then, CVE has truly become the international standard for public software
vulnerability identifiers with more than 64,000+ unique entries listed on the CVE Web site. Information security professionals and product vendors from around the world use CVE Identifiers (CVE IDs) as a standard method for identifying vulnerabilities; facilitating their work processes; and
cross-linking among products, services, and other repositories that use the identifiers.

Initially intended as a source of mature information, the immediate success of
CVE IDs in the community required that the initiative quickly expand to address new security issues that were appearing almost daily. As a result, the CVE List grew quickly to 7,191 CVE IDs after five years, 38,727 CVE IDs at 10 years, and at 15 years now includes
64,492 CVE IDs. CVE IDs are now assigned not only by
MITRE but also by
CVE Numbering Authorities (CNAs), which are major OS vendors, security researchers, and research organizations that assign CVEs to newly discovered issues and include the CVE IDs in the first public disclosure of the vulnerabilities.

Latest Milestones

And CVE continues to evolve. In December 2013, the CVE List began publishing CVE content using the
Common Vulnerability Reporting Framework (CVRF), an XML-based standard that enables software vulnerability information to be shared in a machine-parsable format between vulnerability information providers and consumers. CVE took this important step because having vulnerability information in a single, standardized format speeds up information exchange and digestion, while also enabling automation.

In January 2014, the syntax of CVE IDs themselves was changed from the original format of four digits at the end (e.g.,
CVE-2014-0160) to accommodate five, six, or more end digits at the end so that CVE can track 10,000 or more vulnerabilities for a given calendar year. The previous four-digit restriction only allowed up to 9,999 vulnerabilities per year, but the change allows CVE to keep pace with the growing number of vulnerabilities being reported annually. The new CVE ID syntax was determined in a
vote by the
CVE Editorial Board.

And the milestone is rapidly approaching for when the first CVE ID with 5 digits will be issued. A CVE ID number using the new syntax will be issued either before the end of 2014 and no later than Tuesday, January 13, 2015. Organizations that use CVE IDs that have not already done so need to
take action now to ensure their products, tools, websites, and processes continue to work properly once CVE ID numbers with 5 digits are issued. Read our
press release.

Impact of CVE on the Information Security Landscape

The widespread impact of CVE in enterprise security is illustrated by the numerous
CVE-Compatible Products and Services in use throughout industry, government, and academia for vulnerability management, vulnerability alerting, intrusion detection, and patch management. The information security community endorsed the importance of
"CVE-Compatible" products from the moment CVE was launched in 1999. As quickly as December 2000 there were 29 organizations participating with declarations of compatibility for 43 products. Today, there are
153 organizations and 300 products and services listed on the CVE site. Of these,
143 products and services from 77 organizations have completed the formal
CVE Compatibility Process and are considered as
"Officially CVE-Compatible."

The success of CVE and the other standards it inspired also eventually enabled the creation of NIST's
Security Content Automation Protocol (SCAP). SCAP employs existing community standards, including CVE, to enable
"automated vulnerability management, measurement, and policy compliance evaluation (e.g., FISMA compliance)." In addition, the U.S.
Federal Desktop Core Configuration (FDCC) requires verification of compliance with FDCC requirements using SCAP-validated scanning tools. CVE has also been a requirement in U.S. Department of Defense contracts.

CVE is an international information security community effort. It is your past and ongoing participation, endorsement, and support that have made CVE the community standard for vulnerability identifiers. We thank all you who have in any way used CVE IDs in your products or research, promoted the use of CVE, assigned CVE IDs as a CNA, and/or adopted CVE-compatible products or services for your enterprise.

CVE is mentioned when the author states: "ONG companies are attractive targets to attackers keen on stealing IP and sensitive data.
"This particular example took our attention as the attackers targeted the ONG tech start-up company days after they were in the news for having secured new funding for their technology," Rahul Kashyap Chief Security Architect & Head of Security Research at Bromium, told SCMagazine.com in a Wednesday email correspondence.
"Ultimately, the user who visited this site was someone in a U.S. Fortune 1000 manufacturing company who was viewing this company after the announcement. This shows a classic end-to-end scenario of how such attacks proliferate organizations." What Bromium found was malware that leveraged the CVE-2013-7331 vulnerability, which at that time was unpatched and had already been exploited in the wild by various exploit kits.
"The trojan dropped was fairly sophisticated. It had obfuscation, anti-debugging, vm-detection, used an unpatched IE vulnerability (CVE-2013-7331) and some classic social engineering tricks," said Kashyap.
"The dropped malware was a tool for installing other malicious programs on the infected system." Its authors, he said,
"could sell the infected systems as a 'vacant spot' for further malware
installs."

CVE is mentioned when the author states: "Sensys Networks, a supplier of wireless traffic detection and integrated traffic data systems, has issued updates to address vulnerabilities in its VSN240-F and VSN240-T vehicle traffic sensors operating software versions prior to VDS 2.10.1 and prior to TrafficDOT 2.10.3. Vulnerability CVE-2014-2378 involves traffic sensors accepting software modifications without properly checking the integrity of the new code, meaning the sensors could be damaged if improperly modified, an ICS-CERT
advisory indicates. Vulnerability CVE-2014-2379 involves the potential for unencrypted wireless traffic between a traffic sensor and access point being intercepted and
"replayed to influence traffic data," meaning traffic control could be impacted
at an intersection, according to the advisory."

Several leading software vendors and cybersecurity organizations have declared that they are now consuming or producing CVE Identifier numbers—also called
"CVE IDs"—in the
new numbering format. By taking this important step, these organizations ensure that their products, tools, and processes that use CVE will continue to work properly once CVE ID numbers are issued using the new syntax, which could happen before the end of 2014, and no later than Tuesday, January 13, 2015. Read the
press release.

The syntax of CVE ID numbers (e.g., "CVE-2014-0160", which has four digits at the end) was changed in January 2014 so that CVE can track 10,000 or more vulnerabilities for a given calendar year. The previous four-digit restriction only allowed up to 9,999 vulnerabilities per year, but a change was needed to keep pace with the growing number of vulnerabilities being reported each year. It is possible that 10,000 CVE IDs will be necessary before the end of 2014. Now identifiers can accommodate five, six, or more digits at the end.

Compliant Organizations Recognized

If the format change is not implemented in a timely manner, it
could significantly impact users' vulnerability management practices. To
encourage industry and other CVE users to accommodate the new format, CVE is
recognizing those organizations that have declared that they are, or will be,
compliant with the new CVE ID numbering format on an "Organizations Compliant with the New CVE ID Syntax" page on the CVE Web site.

Organizations that do not update to the new CVE ID format risk the imminent possibility that their products and services could break or report inaccurate vulnerability identifiers. To make it easy to update, the CVE Web site provides free
technical guidance and
CVE test data for developers and consumers to use to verify that their products and services will work correctly. In addition, for those who use National Vulnerability Database (NVD) data, NIST provides test data in NVD format at
http://nvd.nist.gov/cve-id-syntax-change.

Deadline Rapidly Approaching

The clock is ticking. If CVE do not move to the new syntax before the end of 2014, we will ensure that we issue at least one 5-digit CVE ID by Tuesday, January 13, 2015. All organizations that use CVE IDs need to take action now and make the upgrade before this rapidly-approaching deadline.

CVE is mentioned as an example when the author states: "Another
vulnerability worth discussing is CVE-2014-1776 (unfortunately, not all
vulnerabilities get a cool name). This exploit uses an Internet Explorer
vulnerability of the use after freed type. In this case, software can be made to
reuse an address after this has been freed and, generally, causes the program to
crash. If this is coupled with a heap spray (loading specific shell code on the
heap and then having that freed pointer jump to your shell code) it is possible
to have the target software execute code of your choice. This is how
CVE-2014-1776 was exploited. The vulnerability is exploited when the victim
visits a malicious HTML page while browsing. Once again, the firewall is not
designed to block browsing traffic; no software is used that an AV can scan
because the shell code is injected directly into memory. What happens next?
Anything the attacker wants to do; provided there is enough space. The attacker
can siphon information, install a backdoor or use the code to create a new
account."

The author concludes the article by stating: "Vulnerabilities
are found in all software and they are not limited to servers and enterprise
software. They can be found in the smallest program as well as in the most
complex systems. Any data that passes through your hardware / software, whether
it is permanently stored or not, is at risk. The last thing any business, small
or large, wants is their data falling into the wrong hands. Vulnerability
management should be high up on the list of every sys admin or IT team. Ignore
it at your own peril."

CVE is mentioned when the author states: "Customers of JPMorgan Chase are the target of a massive multifaceted phishing campaign impacting mostly people in the U.S., according to security firm Proofpoint. The campaign is noteworthy because of how
"unsubtle" it is, Kevin Epstein, VP of advanced security and governance with Proofpoint, told SCMagazine.com on Friday, explaining that roughly 500,000 phishing emails have been sent out so far, with about 150,000 going out in the first wave. The phishing email looks quite legitimate and asks recipients to click to read a secure and encrypted message from JPMorgan Chase, according to a
Thursday post. Clicking on the email will bring users to a phishing page requesting credentials; however, the phishing page also hosts the RIG Exploit Kit, which aims to take advantage of numerous vulnerabilities to download a variant of Dyre
malware that was initially undetected by anti-virus. Among those vulnerabilities
are CVE-2012-0507 and CVE-2013-2465 for Java, CVE-2013-2551 for Internet
Explorer 7, 8 and 9, CVE-2013-0322 for Internet Explorer 10, CVE-2013-0634 for
Flash, and CVE-2013-0074 for Silverlight, Epstein said."

CVE is mentioned at the outset of the article, when the author states:
"According to a blog post from TrustedSec, an information security consultancy in Ohio, the breach at Community Health Systems (CHS) is the result of attackers targeting a flaw OpenSSL, CVE-2014-0160,
better known as Heartbleed. The incident marks the first case Heartbleed
has been linked to an attack of this size and type."

The author concludes the article as follows: "Unfortunately, CHS may just be the latest, most public victim. Research released on Tuesday by Websense shows an increase in the number of attacks hitting hospitals and medical groups since last October. According to their research, the majority of the attacks are delivered via Heartbleed."

CVE was mentioned in an August 7, 2014 article entitled "NAS
boxes more vulnerable than routers, researcher finds" on
PCWorld.com. The main
focus of the article is that "A security review of network-attached storage
(NAS) devices from multiple manufacturers revealed that they typically have more
vulnerabilities than home routers, a class of devices known for poor security
and vulnerable code."

CVE is mentioned as follows: "So far, the security organization
MITRE has assigned 22 CVE (Common Vulnerabilities and Exposures) identifiers for
the issues the researcher has found, but the [NAS device evaluation] project has
just begun and [many more are expected to be found] by the end of the year."

One additional information security product has achieved the final stage of MITRE's formal
CVE Compatibility Process and is now officially "CVE-Compatible." The product is now eligible to use the CVE-Compatible Product/Service logo, and a completed and reviewed "CVE Compatibility Requirements Evaluation" questionnaire is posted for the product as part of the organization's listing on the
CVE-Compatible Products and Services page on the CVE Web site. A total of
143 products to-date have been recognized as officially compatible.

The following product is now registered as officially "CVE-Compatible":

Use of the official CVE-Compatible logo will allow system administrators and other security professionals to look for the logo when adopting vulnerability management products and services for their enterprises and the compatibility process questionnaire will help end-users compare how different products and services satisfy the CVE compatibility requirements, and therefore which specific implementations are best for their networks and systems.

Previously, CVE IDs could only have 4 digits at the end such as
"CVE-2014-0160", but that syntax limited the number of IDs that could be issued in a calendar year to 9,999. Now, unlimited CVE IDs can be issued in a given year because with the new format they can have 4 digits at the end or more such as
"CVE-2014-99999" with 5 digits at the end, "CVE-2014-456123" with 6 digits at the end, and so on as needed. The number of vulnerabilities being reported each year is growing rapidly, so the change was very much needed.

Technical guidance and
test data is available on the CVE Web site for developers and consumers to help you update your tools, web sites, and other capabilities to accept the new CVE ID numbering format. Questions or concerns may be sent to
cve-id-change@mitre.org.

This three-day event is geared towards security automation tool vendors, end users, and other related stakeholders. The agenda includes sessions that illustrate operational gaps and issues, as well as challenges with the current security automation efforts. Documents associated with the IETF SACM group will be discussed as well as other related standards work. In addition to U.S. Government-led sessions, other select industry and end users will be asked to share their experiences and challenges with the group. The intent is to have open and productive discussions about how to collect, evaluate, and report standardized data that is needed to identify software vulnerabilities, detect software tampering, and defects in software configurations to support a number of operational and security processes.

As this event is designed to foster collaborative conversation between government and industry, the targeted audience is those key stakeholders within vendors, end user groups, and select government agencies that bring deep existing domain knowledge to the discussions. This is not intended to serve as an introduction for those that wish to learn about this landscape, and as such those that require introductory information are asked to pursue that in a different venue. Attendees for the event should be prepared to share their experiences and ideas for the future state of security automation and should be directly involved with the related topics.

CVE-2014-0224 was cited in numerous major advisories, posts, and articles related to the most recent critical OpenSSL vulnerability since Heartbleed—an SSL man-in-the-middle (MITM) vulnerability—including the following examples:

CVE, CWE, and CAPEC are the main topics of an article "Security Standards Help Stop Heartbleed" by CAPEC Technical Lead Drew Buttner on MITRE's
Cybersecurity blog on May 7, 2014. "Heartbleed," or
CVE-2014-0160, is a serious vulnerability in
"certain versions of OpenSSL where it enables remote attackers to obtain
sensitive information, such as passwords and encryption keys. Many popular
websites have been affected or are at risk, which in turn, puts countless users
and consumers at risk."

In sections entitled "CVE and Heartbleed," "CWE and Heartbleed,"and
"CAPEC and Heartbleed," the article describes how CVE helped when the issue became public by assigning CVE-2014-0160 to what also was referred to as the Heartbleed bug, and how CWE and CAPEC can help prevent future Heartbleeds.

The author then concludes the article as follows: "Security automation efforts such as CVE, CWE, and CAPEC can help reduce the possibility of similar severe vulnerabilities such as Heartbleed in the future. But it is incumbent upon developers and other security professionals to actively leverage resources such as these to be better prepared for the next Heartbleed."

The CVE Identifier assigned to the "Heartbleed" vulnerability—CVE-2014-0160—was released on April 7, 2014, the same day that the vulnerability was made public. The existence of this identifier has enabled the worldwide community to converse and share information about this vulnerability in a rapid an efficient manner.

CVE-2014-0160 was cited in nearly every major advisory, post, article, and response related to Heartbleed, including the following examples:

The preface was written by Roberta Stempfley, Acting Assistant Secretary at the
U.S. Department of Homeland Security's
Office of Cybersecurity and Communications, and CVE is mentioned as follows:
"How can we collaboratively orchestrate industry and government response to these attacks
[on information and communications technology (ICT) assets]? One way is through the Common Vulnerabilities and Exposures (CVE) List, which is an extensive listing of publicly known vulnerabilities found after ICT components have been deployed. Sponsored by the Department of Homeland Security (DHS), the ubiquitous adoption of CVE has enabled the public and private sectors to communicate domestically and internationally in a consistent manner the vulnerabilities in commercial and open source software. CVE has enabled our operations groups to prioritize, patch, and remediate nearly 60,000 openly reported vulnerabilities. Unfortunately, vulnerabilities are proliferating rapidly thus stretching our capabilities and resources. As we seek to discover and mitigate the root causes of these vulnerabilities, sharing the knowledge we have of them helps to mitigate their impact. In order to keep pace with the threat, we must facilitate the automated exchange of information. To achieve that, DHS sponsors
"free for use" standards, such as: Common Weakness Enumeration (CWE), which provides for the discussion and mitigation of architectural, design, and coding flaws introduced during development and prior to use; Common Attack Pattern Enumeration and Classification (CAPEC), which enables developers and defenders to discern the attacks and build software resistant to them; Malware Attribute Enumeration and Characterization (MAEC), which encodes and communicates high-fidelity information about malware based upon behaviors, artifacts, and attack patterns; Structured Threat Information eXpression (STIX), which conveys the full range of potential cyber threat information using the Trusted Automated eXchange
of Indicator Information."

CVE and CWE are mentioned in a section entitled "Making Change through Business Value," as follows:
"For an example of a behavior change in an industry motivated by a new perceived
business value, consider that many of the vendors currently doing public
disclosures are doing so because they wanted to include CVE [14] Identifiers in
their advisories to their customers. However, they could not have CVE
Identifiers assigned to a vulnerability issue until there was publicly available
information on the issue for CVE to correlate. The vendors were motivated to
include CVE Identifiers due to requests from their large enterprise customers
who wanted that information so they could track their vulnerability
patch/remediation efforts using commercially available tools. CVE Identifiers
were the way they planned to integrate those tools. Basically the community
created an ecosystem of value propositions that influenced the software product
vendors (as well as the vulnerability management vendors) to do things that
helped the community, as a whole, work more efficiently and effectively.
Similarly, large enterprises are leveraging CWE Identifiers to coordinate and
correlate their internal software quality/security reviews and other assurance
efforts. From that starting point, they have been asking the Pen Testing
Services and Tools community to include CWE identifiers in their findings. While
CWE Identifiers in findings was something that others had cited as good
practice, it was not until the business value to Pen Testing industry players
made sense that they started adopting them and pushing the state-of-the-art to
better utilize them."

CWE is also mentioned in a section entitled "Assurance for the Most Dangerous Non-Malicious Issues"
that explains what CWE is and how the information "can assist project staff in
planning their assurance activities; it will better enable them to combine the
groupings of weaknesses that lead to specific technical impacts with the listing
of specific detection methods. This provides information about the presence of
specific weaknesses, enabling them to make sure the dangerous ones are
addressed."

One additional information security product has achieved the final stage of MITRE's formal
CVE Compatibility Process and is now officially "CVE-Compatible." The product is now eligible to use the CVE-Compatible Product/Service logo, and a completed and reviewed "CVE Compatibility Requirements Evaluation" questionnaire is posted for the product as part of the organization's listing on the
CVE-Compatible Products and Services page on the CVE Web site. A total of
161 products to-date have been recognized as officially compatible.

The following product is now registered as officially "CVE-Compatible":

Use of the official CVE-Compatible logo will allow system administrators and other security professionals to look for the logo when adopting vulnerability management products and services for their enterprises and the compatibility process questionnaire will help end-users compare how different products and services satisfy the CVE compatibility requirements, and therefore which specific implementations are best for their networks and systems.

CVE IDs are included in annual "Secunia Vulnerability Review 2014" report by
Secunia that
"analyzes the evolution of software security from a global endpoint perspective. It presents data on vulnerabilities and the availability of patches, and correlates this information with the market share of programs to map the security threats to IT infrastructures." The report also explains what CVE is and how common identifiers improve security.

How CVE IDs are used in the report is explained as follows: "CVE has become a de facto industry standard used to uniquely identify vulnerabilities which have achieved wide acceptance in the security industry. Using CVEs as vulnerability identifiers allows correlating information about vulnerabilities between different security products and services. CVE information is assigned in Secunia
Advisories. The intention of CVE identifiers is, however, not to provide
reliable vulnerability counts, but is instead a very useful, unique identifier
for identifying one or more vulnerabilities and correlating them between
different sources. The problem in using CVE identifiers for counting
vulnerabilities is that CVE abstraction rules may merge vulnerabilities of the
same type in the same product versions into a single CVE, resulting in one CVE
sometimes covering multiple vulnerabilities. This may result in lower
vulnerability counts than expected when basing statistics on the CVE
identifiers."

CVE is mentioned when the author references the talk about the impact of the uncertainty in vulnerability statistics entitled
"Buying into the Bias: Why Vulnerability Statistics Suck" at Black Hat Briefings 2013 that was co-presented by CVE List Editor Steve Christey and Brian Martin of the Open Security Foundation in Las Vegas, NV, on July 31, 2013.

The author states: "If a vulnerability report is misleading, then I can only imagine the amount of aggravation it causes some people, such as the gentlemen who presented
"Buying Into the Bias: Why Vulnerability Statistics Suck" at Black Hat 2013. At that time,
Jericho, the content manager of the Open Source Vulnerability Database (OSVDB), and
Steve Christie, the editor of the Common Vulnerabilities and Exposures (CVE) list, announced,
"Most of these statistical analyses are faulty or just pure hogwash. They use the easily-available, but drastically misunderstood data to craft irrelevant questions based on wild assumptions, while never figuring out (or even asking us about) the limitations of the data. This leads to a wide variety of bias that typically goes unchallenged, that ultimately forms statistics that make headlines and, far worse, are used for budget and spending." During their presentation, they added,
"As maintainers of two well-known vulnerability information repositories, we're sick of hearing about sloppy research after it's been released, and we're not going to take it any more." The author then discusses Brian Martin's (aka Jericho's) review of the Secunia report.

CVE is mentioned in a March 21, 2014 article entitled "When software development produces a lemon, make lemonade" on
GCN.com. CVE is mentioned when the author states: "the Secure Development Lifecycle (SDL) that grew out of the Microsoft initiative has helped to change the way developers think about software security. The SDL process now shows up as a requirement in government procurements, and the National Security Agency says it has made an impact on OS security.
"A fundamental goal of the SDL process is to reduce the attack surface,"
NSA said
in an evaluation of Windows 7 security for the Defense Department and the
intelligence community. "Since adoption of the SDL process, the number of Common
Vulnerabilities and Exposures on Microsoft products in the National
Vulnerability Database has declined." "A preliminary System and Network Analysis
Center analysis has determined that the new Windows 7 security features, coupled
with the use of the SDL process throughout the development cycle, has assisted
in the delivery of a more secure product," the assessment concluded. We still
are a long way from being as secure as we want to be or can be. But there has
been progress."

One additional information security product has achieved the final stage of MITRE's formal
CVE Compatibility Process and is now officially "CVE-Compatible." The product is now eligible to use the CVE-Compatible Product/Service logo, and a completed and reviewed "CVE Compatibility Requirements Evaluation" questionnaire is posted for the product as part of the organization's listing on the
CVE-Compatible Products and Services page on the CVE Web site. A total of
160 products to-date have been recognized as officially compatible.

The following product is now registered as officially "CVE-Compatible":

Use of the official CVE-Compatible logo will allow system administrators and other security professionals to look for the logo when adopting vulnerability management products and services for their enterprises and the compatibility process questionnaire will help end-users compare how different products and services satisfy the CVE compatibility requirements, and therefore which specific implementations are best for their networks and systems.

IMPORTANT:
The variable length arbitrary digits will begin at four (4) fixed digits and expand with arbitrary digits
only when needed in a calendar year, for example, CVE-YYYY-NNNN and if needed CVE-YYYY-NNNNN, CVE-YYYY-NNNNNNN, and so on. This also means there will be no changes needed to previously assigned CVE IDs, which all include 4 digits.