PING with Desiree Beck

The Common Malware Enumeration (CME) initiative makes no pretense that it's a cure for the multitude of virus naming conventions. Instead, CME assigns common identifiers to new virus threats similarly to its cousin, the ubiquitous CVE identifier included in most vulnerability alerts. CME officially kicked off in October, but it's been more than a year in the making, primarily under the sponsorship of US-CERT, the technical guidance of the Mitre Corp., and the participation of most of the leading antivirus software vendors. Desiree Beck, technical lead for the project, hopes CME becomes the common talking point when it comes to malicious code and that CME alleviates some of the confusion.

Why is CME necessary?

Beck: Different entities refer to threats differently; this leads to a lot of confusion. We're hoping a common ID for threats puts everyone on the same page.

Last January, we got a representative group together as our preliminary editorial board, which was tasked with defining procedures, discussing which threats to try to identify and how we'd share samples. Our submission server went online April 1. People have been submitting samples and we've been providing identifiers since. Now we want more involvement.

What's the process like for assigning an identifier?

Beck: The CME Sample Redistribution Group [the group authorized to use the CME Submission Server] evaluates top threats and submits a sample. If no other samples are submitted within two hours, it's automatically issued an identifier. If something else is submitted, it goes to resolution status where it's determined if the samples are different and if each needs its own identifier. Once it's reached accepted status, it's issued an identifier.

As far as our criteria for what gets an identifier, it's primarily about what's prevalent and discussed in the media, has the most potential for damage, and whether people are talking about it.

CME has no intention to serve as a naming convention for malware threats?

Beck: This is not a naming convention. In fact, identifiers are randomly generated and not sequential. This is not meant to solve the naming problem. It's more of an effort to coordinate things. People are going to continue to name threats, but if we provide and identifier, it's the glue to make things come together and serve as a talking point when referencing malware. I guess we figure it's indirectly going to help.

Who in the security community has to be involved for CME to be a success?

Beck: We definitely have to have the involvement of the vendors. We've had a positive response, and have most of the larger vendors on board. Recently, we've had inquiries from other companies that want to be involved, positive. Right now, it's an invitation-only working group. We want to incorporate other companies, AV or researchers; we want interest from a broad spectrum of people.

How does CME benefit a security manager?

Beck: If something is up on their network, they can go to the CME site (http://cme.mitre.org/) for information. With each identifier, there's a threat profile that includes key characteristics and alias information.

Security managers are certain to rely on their vendors for alerts and first-response information. How important is timeliness for CME?

Beck: Having the information the sooner the better is important. It's realistic, especially at first, to have an identifier the next business day. With CME identifiers included in alerts, managers are gong to turn there from the products they're using and work with their vendor. CME is going to be an overall collective informational point, providing the full spectrum of what's up with a threat.

What challenges do you anticipate?

Beck: Deconfliction is difficult. We have to make sure we're assigning an ID to things that are distinct and that there are not two IDs assigned to equivalent samples.

The other challenge is that when we've assigned an ID, now we need people to reference them, embed them in alerts and use them in product encyclopedias.

What lessons can the CME initiative learn from CVE?

Beck: Though I was not involved personally with CVE, there are a lot of people working on this project who were. There are a lot of lessons learned. One, before something was assigned a CVE identifier, it had a candidate CVE number -- a CAN number -- while the vulnerability was still in discussion. This turned out to be a bad thing because the candidate numbers stuck and were populated and embedded in text and content out there. One thing we're doing: it either has a CME number or it doesn't.

CVE numbers also used to have dates embedded in the numbers, but there was confusion over whether this was the date the number was assigned or the date the vulnerability was found. We found that anything that has meaning embedded in an ID is a bad thing. CME is a number, nothing more.

About the author
Michael S. Mimoso is Senior Editor of Information Security magazine.

This was first published in November 2005

Dig deeper on Security Industry Market Trends, Predictions and Forecasts

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close