Common Malware Enumeration Initiative 112
LogError writes "The Common Malware Enumeration Initiative was just announced. Headed by the United States Computer Emergency Readiness Team (US-CERT) and supported by an editorial board of anti-virus vendors and related organizations it should provide a neutral, shared identification method for malware outbreaks."
Which Platforms? (Score:3, Interesting)
Re:Which Platforms? (Score:3, Insightful)
Re:Which Platforms? (Score:2)
Because no-one of any consequence runs Linux, MacOS, or a BSD? ;-)
Re:Which Platforms? (Score:4, Insightful)
From the article it sounds like it's an issue of malware outbreaks in general without regard to platform. Since it's simply about having a common name for malware, there's no reason why it should be platform specific.
Re:Which Platforms? (Score:2)
As in
"We have this great program that does XYZ"
"Sounds nice what does it run on ?"
"Oh it run on anything"
"I mean what system ?"
"Uh ?" *blink*blink* "Oh, yes, sorry, just Windows, but we're looking into porting it for the Mac"
"How about Unix and Linux"
"Oh yeah, I've heard of those"
To the world at large, except for the crowd here, a PC runs Windows and that's it. A sele
Simple (Score:4, Insightful)
Re:Simple (Score:4, Insightful)
Re:Simple (Score:3, Insightful)
Most of the "development" was probably talking to industry execs and getting them all to agree. It's all about politics.
Re:Simple (Score:2)
Re:Simple (Score:2)
This is absolutely true. Not only are there the politics external to US-CERT that have to be considered when developing this, remember this is the federal government, and internal politics and red tape must be fought the entire time as well.
Having worked with the US-CERT folks directly (no I'm not a gov't employee), I can say that the people I've worked with have been competent, headstrong individuals genuinely interested in their initiatives to improve security. This *is* atypica
Default Permit (Score:5, Insightful)
Re:Default Permit (Score:5, Insightful)
Default Deny is good. Centralized lists of "good" software is bad. Think about it for a second and you'll realize why.
Multiple Sources (Score:5, Insightful)
He never said "centralized". Default deny is secure, but cumbersome to work with. People find ways around things that are cumbersome (like taping passwords on monitors when they are too strong to be remembered). Outsourcing the decission of what software to trust to a third party is a good compromise, as long as you can freely chose the parties you trust.
What I'm imagining is something like APT repositories. You trust the maintainers to put up good software, and you verify it was really put there by the maintainers by checking the signatures. If, one day, you decide you don't trust some server anymore, you just remove it from your sources.list.
Re:Multiple Sources (Score:1)
Sorry, but that's just as daft. And your point about "centralized" is just picking at symantics. He said "centralized lists" so this could be on a single server or multiple servers manage by different people. Either way, each individually maintained list faces the same problems as a single list created by a single authority, and changing it to a system where you have to aggregate multiple lists from different sites(creating your own centralized list) doesn't do much to solve the problem that you, or the sys
Re:Multiple Sources (Score:2)
``your point about "centralized" is just picking at symantics. He said "centralized lists" so this could be on a single server or multiple servers manage by different people.''
Alright, so maybe I mistook the gist of his post. So then lets reframe the discussion: my claim is that a centralized trust database would be a bad idea, but a number
Re:Multiple Sources (Score:2)
Anyway, I skimmed through much of what you wrote, because to me it's all pretty simple.
One way the developer has to apply to an instititution in order to publish software, and it's probably going to have a nearly prohibitally high pricetag for a middle class
Re:Multiple Sources (Score:2)
(This also screws with the idea of Open Source in it's current context)
The other way we have viruses.''
I think you're seeing it too much as absolutes. It's not a matter of _either_ all software completely audited by a single authority _or_ we're stuck with all v
Thought about it! (Score:1)
Re:Thought about it! (Score:1)
Centralization (Score:1, Insightful)
If you trust the few, it has the benefit of being more efficient. (Instead of everyone needing to put the effort into making correct decisions, only a small group needs to do so.)
Unfortunately, people have demonstrated throughout history that small, powerful groups are almost always untrustworthy. They end up using the power for their own benefit.
Re:Centralization (Score:1)
Re:Thought about it! (Score:2)
Re:Thought about it! (Score:1)
Re:Thought about it ! (Score:2)
Re:Default Permit (Score:2)
While it may work for some very controlled corporate environments where every executable is checked, default deny is un
Re:Default Permit (Score:3, Insightful)
Enumerating both good and bad programs is probably a good idea. It's usually pretty obvious if something is malware. How do we say for sure that something is a "good" program though? Who decides if it's a "good" program? How long does it take my software to get listed as a "good" program? Do I have to pay a licensing fee? Is it a big expense to get it certified as "good" because I have to pay for all sorts of independent testing? I
Re:Default Permit (Score:2)
Exactly. Which is why the National Software Repository Library [nist.gov] exists.
From the site:
The National Software Reference Library (NSRL) is designed to collect software from various sources and incorporate file profiles computed from this software into a Reference Data Set (RDS) of information. The RDS can be used by law enforcement, government, and industry organizations to review files on a computer by matching file profiles in the RDS. This will h
Re:Default Permit (Score:1)
Re:Default Permit (Score:1)
Also, it'd leave a way to see what sites you've visited, if the browser keeps "Accept Always" records, as anything in there
Required reading (Score:5, Informative)
This document on viruses should be required reading for anyone who uses a computer.
http://www.us-cert.gov/reading_room/virus.html [us-cert.gov]
Most common malware can be stopped with the same virus-avoidance techniques listed in this brief document.
As for this initiative, it's not explained very well, that's for sure. It seems like a simple naming convention for viruses as well as a central location for all virus information. I'm not big on the government taking away such a role from private industry, but with the threat of viruses affecting everyone, it makes sense that the government provide a baseline starting point for all antivirus companies to start from. It is not in the best interest of the public to have a single private company hoard virus information.
Re:Required reading (Score:2)
Re:Required reading (Score:2)
Problems? (Score:5, Insightful)
It's much easier when there's an actual name to refer to like Blaster or Sasser than referring to the distinctions between CME-46 and CME-50. While the automated system seems to make sense to prevent slowdowns by having people discuss naming, this doesn't seem like a great solution. Many people may even think: I've heard of that CME thing before, I'm already protected.
communication between anti viri companies is great (Score:3, Insightful)
Re:communication between anti viri companies is gr (Score:1)
</pedant>
Re:Problems? (Score:1)
In a previous incarnation, I ran the IT division of a major medical-professional organization; I wonder how much success I would have giv
Re:Problems? (Score:2)
This isn't the primary benefit of such a system. The benefit is that, as an administrator with systems running differen anti-virus software for reasons beyond my control, I can tell what is running around on my network without having to play the name-matching game. Or, while resea
Wrong approach to the problem (Score:5, Interesting)
Re:Wrong approach to the problem (Score:2, Insightful)
Re:Wrong approach to the problem (Score:2)
good software (Score:1)
When I started writing 8086 (pc assembly code) all my executables were detected by antivirus as infected (i think it was FProt).
Turns out that my prefered location of storing data in my code looked like it was a virus burrowing its way into legitimate code.
So considering the number of people that code and the amount of code that is out there in the wild how the hell would you ID good code and bad code ?
another case in point I downloaded tiny
Really Don't Like the Format (Score:5, Insightful)
Now that being said I 100% agree that we need a methodology in place to ensure that malcode names follow a fixed format. There have been too many times that we have had to research viruses and it is annoying as all hell to see a worm as Variant B on one site and Variant C on another. It adds to the confusion during an outbreak, which in turn usually costs more research and fix time... But saying that I do not like the naming format because it doesn't clearly identify similar variants... On the site it shows an example of two variants of Zotob. One is CME-164 and one is CME-243. For tracking purposes I would much rather see something along the lines of Zotob-A being named CME-164A and Zotob-B being CME-164B. Or better yet as numbers don't stick in your head as well as words IMO stick to names like Zotob but ensure the major AV vendors follow the CMEI variant guidance...
Re:Really Don't Like the Format (Score:1)
What I'd like to see is something like the hurricane naming thing. This could have a list of names, and each virus name would be the next name on the list with the year and a code for variant. For instance, the first virus of 2006 could be Albert-06-A. This allows us to generalize to the Albert-06 group if we want to, and also allows laypeople to discuss simply "this year's first virus, named Albert by the CMEI...". T
Re:Really Don't Like the Format (Score:1)
It's the same reason we shouldn't publish the names of serial killers...because they want us to. They want to be famous, they want their name everywhere.
Well, fuck that. We'll just make up a name and give it to you.
Rock you like a hurricane. (Score:2)
+5 Awesome Idea right there, seriously...
Understanding Identifiers. (Score:5, Insightful)
Most identifiers are just for reference, but may not be intended for the type of indexing that you're expecting.
Consider the following situation:
We now have two options -- change the identifier from 'x' to 'p.1' or leave some sort of note attached to 'x' that it's a derived from 'p'. (well, there's two other options -- don't try to identify them, or don't assign identifiers until all research is done, which defeats the whole purpose of building the system in the first place)
The list they're making is more like a glossary -- a flat list of items, as opposed to something which might have a concept of heirarchy. (but that's not to say that some other values in the descriptions can't be used to generate a heirarchy).
If you'd like an even worse example of selecting identifiers -- imagine if you found a worm 'y' that used the same code for vulnerability exploits as 'c', but carried the same payload as 'g' ... is it 'c.1' or 'g.1' or 'c.g.1'?
Sequential identifiers may seem like a bad choice, but they're so much easier to maintain in the long run, and handle the heirarchy through some other field.
Re:Really Don't Like the Format (Score:2)
The problem with these centralized naming systems is that they lag behind the real world somewhat. There has to be incentive for the vendors to cre
Will they include this one? (Score:3, Funny)
May 22, 1990. A day that will live in computer science infamy.
Re:Will they include this one? (Score:1)
Re:Will they include this one? (Score:1)
To paraphrase a line from... (Score:3, Funny)
I don't know what's scarier, Windows malware or that there's so much of it that they need a naming body to keep track of it all.
Biggest malware is missing... (Score:1, Funny)
There's malware and then there's malware (Score:2, Funny)
We could call this a starting point.
First policy decision: (Score:2)
Choice of members (Score:1)
It's more important than you realize (Score:2)
Why is this important in this case? Think about it. For one, it clearly identifies malware entities leaving their status unambiguous. Ambiguity and status disputes have been an area of concern and contempt for many people including the courts, the systems administrators and the 'marketters' responsible for their deployment. Further, one of the biggest problems in the anti-malware area has been that various products seem to omit prote
Re:It's more important than you realize (Score:1)
Poor naming... (Score:3, Interesting)
I think the solution is to handle things the same way that we handle hurricanes. Keep a big list of names and iterate through that for each new virus.
In that vein I would like to now suggest that viruses be given the dumbest names possible as a means of discouraging stupid kids from writing them to seek publicity. After all who would want to see themselves listed as the author of ChickenChaser
Re:Poor naming... (Score:2)
Only one problem with that. 90% of malware isn't written by "stupid kids" seeking publicity. It's written by criminal organizations.
http://news.zdnet.com/2100-1009_22-5486201.html [zdnet.com]
http://antivirus.about.com/b/a/056373.htm [about.com]
The st
Re:Poor naming... (Score:1)
But that didn't stop some other sonovabitchwhowilldiediedieslowwwwwwwwly (haven't decided yet between impalement, draw-and-quartering, rabid dingos, or some combination thereof (Why, yes, I work at a tech desk. However did you
an integer between 1 and 999 (Score:1)
Re:an integer between 1 and 999 (Score:2)
It also seems to ignore the existing CVE numbering scheme [mitre.org] which surely was designed with similar intent.
This all reminds me somewhat of the patch numbering schemes developed by different software vendors. The one that I've found best in practice comes from Sun Microsystems. Rather than being a plain integer or some equally cryptic enumerator
Re:an integer between 1 and 999 (Score:1)
B1. What is a CME identifier?
CME identifiers are assigned in the format 'CME-N' where N is an integer between 1 and 999, for example, "CME-123". To accommodate space-deprived anti-virus products, CME identifiers can be abbreviated (e.g., M123 or M-123), but the official format (i.e., CME-123) should be used in places such as Web pages, alerts, encyclopedias, etc. Additional digits will be added when the remaining unused identifier space becomes too small. For the sake of successful te
Re:an integer between 1 and 999 (Score:1)
Oh, great. (Score:2)
Gator is now Microsoft (Score:1)
Release the Flying Monkeys!! [Lawyers]
Fly my prettys Fly!!!
The second dumbest idea? (Score:1)
Bad Thing? (Score:3, Interesting)
Didn't we already decide, that enumaration, amongst other things [slashdot.org] was a Dumb Idea?
One man's spyware... (Score:2, Funny)
why isn't this tied into nvd instead? (Score:5, Informative)
Re:why isn't this tied into nvd instead? (Score:2)
But these are details. Your comments are in the right spirit. Of course it makes sense for the same institution to resource these two highly related activities. With a commitment to a common, stable nomenclature, the two databases will be able to reference each other.
Re:why isn't this tied into nvd instead? (Score:2)
NVD (Score:2)
The NVD isn't all that crash hot, actually.
While it does a good job in terms of listing vulnerabilities that exist in various software applications, it can lag other public disclosure by up to a week.
The argument of it providing information that has been vetted doesn't necessarily gel, given that sometimes it leads the disclosure with some fairly vague reports.
Having said that, it is one of the sources that we use for our Information Security Advisory mailing list, but it isn't really one of the primary
Cataloged, ey? (Score:2)
Yeesh.
I nominate Windows Vista as Malware. (Score:1)
[/sarcasm]
Virii (Score:1)
Microsoft Support? (Score:2)
Re:Microsoft Support? (Score:1)
Re:Microsoft Support? (Score:2)
Mutating viruses (Score:2)
Re:The first virus I encountered... (Score:2, Funny)
Re:The first virus I encountered... (Score:1, Interesting)
Re:The first virus I encountered... (Score:4, Insightful)
The second virus I encountered (same machine) was just as interesting: a tiny helicopter flew onto your screen, dropped a grappling hook to grab your pointer, and fly off with it, never to be seen again.
I tell ya, those were the days, when men were men, gurus meditated, and virus writers were... but I digress.
Today, those guys probably are making a fortune somewhere writing video DRM for Vista.
Re:The first virus I encountered... (Score:2)
Hey, if you're going to write a virus, at least be clever and entertaining. Your data may be gone, but now you have a funny anecdote!
Re:The first virus I encountered... (Score:2)
When men were men, women were too, and little girls were FBI agents?
Oh wait no, that was the golden age of the Internet. Sorry...
Re:I have to say... (Score:1, Funny)
Re:I have to say... (Score:4, Insightful)
Re:I have to say... (Score:3, Insightful)
A plot to reduce the number of known viruses (Score:2)