Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security United States

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."
This discussion has been archived. No new comments can be posted.

Common Malware Enumeration Initiative

Comments Filter:
  • Which Platforms? (Score:3, Interesting)

    by Brent Spiner ( 919505 ) on Wednesday October 05, 2005 @09:53AM (#13722205) Homepage
    I don't see any specifics. Is this going to be Windows-centric, or are they reporting on ALL malware, regardless of platform?
    • by sedyn ( 880034 )
      Like most outlets, I will bet that this site will focus mainly on windows. It just that this time, the attention is deserved.
    • by mysqlrocks ( 783488 ) on Wednesday October 05, 2005 @10:06AM (#13722299) Homepage Journal
      Is this going to be Windows-centric, or are they reporting on ALL malware, regardless of platform?

      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.
    • I know it's trendy to ask the question, especially on /. but any piece of software or computer related reporting is of course about Windows.

      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)

    by mysqlrocks ( 783488 ) on Wednesday October 05, 2005 @09:54AM (#13722216) Homepage Journal
    Seems like kind of a simple concept. "Let's make sure we're all using the same name." But I guess being able to identify a virus by name is a kind of important step in finding a fix for it.
    • Re:Simple (Score:4, Insightful)

      by mr. mulder ( 204001 ) on Wednesday October 05, 2005 @10:15AM (#13722366)
      the sad part is that several well-paid government employees spent 6 months developing this "solution".
      • Re:Simple (Score:3, Insightful)

        by mysqlrocks ( 783488 )
        the sad part is that several well-paid government employees spent 6 months developing this "solution".

        Most of the "development" was probably talking to industry execs and getting them all to agree. It's all about politics.
        • And by "talking", I'm sure you mean "giving the industry tax deductions and kickbacks." It is all about politics.
        • Please mod the parent up.

          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)

    by lapagecp ( 914156 ) on Wednesday October 05, 2005 @09:55AM (#13722220)
    This is just another example of getting entrenched in a default permit world which has proven itself time and again not to work. We need to be enumerating the good programs and not the other way around.
    • Re:Default Permit (Score:5, Insightful)

      by GigsVT ( 208848 ) on Wednesday October 05, 2005 @09:59AM (#13722249) Journal
      You've taken a good concept and turned it on its ear.

      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)

        by RAMMS+EIN ( 578166 ) on Wednesday October 05, 2005 @10:14AM (#13722355) Homepage Journal
        ``Default Deny is good. Centralized lists of "good" software is bad. Think about it for a second and you'll realize why.''

        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.
        • 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

          • Wow, that's a long post. Thanks for taking the time to write that. Still, I can't agree with many of your points. Perhaps a little more explanation on my part will help.

            ``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
            • Wowzors some ppl just wasted a few hours at work. (^^ I know I've been victim to the same trap, before >.>) No matter how much you write it always falls on deaf ears, and even if it doesn't it never really ties up all the points you wanted to make.

              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
              • ``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 freelance developer to afford. -- In the name of expenses for the reviewers.

                (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
      • Yeah I fail to see where you are going with the comment that centralized lists of "good" software are bad. If you had a system that blocked everything that wasn't on a list of good software what would be the problem? Maybe you are worried like some of the posters about getting on the list. All virus scanners have an option to ignore a program. Why couldn't you add your own software to your private list. I am THE IT guy for my company and if I had a place I could go to check what the industry thinks of
        • I think the only way this "good list" would be a "bad thing" is if it was forced upon you. Having it as a reference isn't a bad thing at all. The one concern I have is being that it is run (like most things) by corporations, there is a possibility for greed (read: money) to cause polution of the list. I also believe that in a world of default deny the usefulness of such a list would be limited. The few users/admins that actively changed their software configurations would be the only people to look at it wi
        • Centralization (Score:1, Insightful)

          by Anonymous Coward
          It's very simple. Centralization takes power from most and gives it to a few.

          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.
        • I write a useful program and post it on my website. How do I get it on this list? Now imagine that I'm a virus writer. What stops me from putting my program on the same list? Something or somebody has to decide whether a program is "good" or "bad". Who's going to do that and based on what criteria?
          • Take some of your own advice and think about it. Why did you write the program? If its for your own use then it doesn't need to be on the list. If its for someone else then they trust you and use the program even though its not on the list. Once they have been using it with no adverse side effects then they can recommend that it be added to the list. If we could do this think about how much time could be saved not cleaning up infected computers. The only possible down side is if you are trying to mark
      • Try to implement a "default deny" policy on a Windows machine and you'll soon get flooded by requests by the monitoring thingie to run "FROOMBLE.DLL" which might or not be part of the system, or of whatever and it means you're going to spend ages tracing the zillion bits and pieces of each and every bit of software with your hex editor and disassembler to check if you can allow them to run.

        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)

      by mysqlrocks ( 783488 )
      We need to be enumerating the good programs and not the other way around.

      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
      • Enumerating both good and bad programs is probably a good idea.

        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
    • I think part of the problem with Default Deny that people have is that there needs to be some sort of list, and some people have issues giving the right to review a site to somebody big. Who's to say that that somebody big doesn't discriminate against sites on some other basis? And it'd be a lot harder to make a new site, as you have to get it approved in order to get public access.

      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)

    by ReformedExCon ( 897248 ) <reformed.excon@gmail.com> on Wednesday October 05, 2005 @09:58AM (#13722247)
    This is the first time I've been to the US-CERT website, so please forgive my enthusiasm.

    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.
    • 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 i
    • Believe it or not, US-CERT is funded as part of Department of Homeland Security.
  • Problems? (Score:5, Insightful)

    by op12 ( 830015 ) on Wednesday October 05, 2005 @10:01AM (#13722263) Homepage
    From TFA: "During a virus outbreak, participants on the CME board request an identifier from an automated system by providing a sample of the virus and as much additional information as possible. An identifier in the format 'CME-N' where N is an integer between 1 and 999 is generated and distributed to the other participants. The participants then disseminate the CME identifier to their contacts in the industry and reference the CME identifier on their web pages, in their product, or when speaking to the press. "

    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, BUT I hope this doesn't turn into a type of "registry" that can be hacked or spoofed and allow networks to be compromised wholesale.
    • "I've heard of that CME thing before" -- just wait until this hits the healthcare community, where CME has a vastly different meaning. (In this case, "Continuing Medical Education" -- most US health professionals must earn a minimum number of CME credits, indicating completion of ongoing professional study, in order to maintain board certification and/or state licensure.)

      In a previous incarnation, I ran the IT division of a major medical-professional organization; I wonder how much success I would have giv
    • 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.

      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
  • by BierGuzzl ( 92635 ) on Wednesday October 05, 2005 @10:03AM (#13722277)
    It would be WAY easier to keep a list of names and heuristics for all of the legitimate code out there and have a default deny policy with a whitelist. The only condition that would need to be met is that no legitimate application is denied entry or the concept could become worse than DRM.
    • Congratulations, you've reinvented Palladium.
    • Maybe its just me, but I dont see how it would be way easier to keep a list of good code and deny all else? So basically you create software that says only allow these programs to work. Then someone creates a worm that uses buffer overflow YYY against Windows version whatever to grab root. How did your list of good software stop this attack from occurring. The person is executing an attack and having an application that says your software or code is good wouldn't do any good in my opinion?
    • I used to write assembly code on the Amiga on 68000 10+ years ago.
      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
  • by Evil W1zard ( 832703 ) on Wednesday October 05, 2005 @10:04AM (#13722283) Journal
    Firstly let me just say I thought this was going to be an initiative to create a working group to assist in identifying threats quicker, but as I RTFA I find out all this is really is just a control gate for naming malcode.

    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...
    • Or better yet as numbers don't stick in your head as well as words IMO stick to names
      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
    • by oneiros27 ( 46144 ) on Wednesday October 05, 2005 @10:25AM (#13722444) Homepage

      Most identifiers are just for reference, but may not be intended for the type of indexing that you're expecting.

      Consider the following situation:

      1. A new worm is sighted
      2. CERT's members agree it's a new worm, and assign it an identifier 'x'
      3. Researchers deconstruct the worm, and determine that 'x' is actually derived from 'p'.

      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.

    • What you're asking for is a mechanism that describes the evolution and relationships between malware entities. That's a different system that depends on an index/lexicon, such as the CME, to be cost effecive (otherwise you have to map the relationships for each different vendor). This is the first step to making the maintenance of such a mechanism cost effective.

      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
  • by Anonymous Coward on Wednesday October 05, 2005 @10:05AM (#13722294)
    Here. [wikipedia.org]

    May 22, 1990. A day that will live in computer science infamy.
    • I thought a more recent... and still more widely spread would be Win 98. http://www.compfused.com/directlink/849/ [compfused.com]
    • Funny, but I truly thought that Windows was a virus at one point. I used to only use DOS on a PC, and one day I got a new PC that came with Windows 3.1 preinstalled. I fired it up once to look at it, then removed it because I needed the disk space. Later on, I found a hidden file called WINA20.SWP in my C: root. I couldn't figure out what it was, and feared it might be a virus. I posted to usenet and was ridiculed because as it turns out, this was the Windows swap file (which of course I didn't know about t
  • by Anonymous Coward on Wednesday October 05, 2005 @10:11AM (#13722334)
    ..."Broken Arrow": [imdb.com]

    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.
  • I cannot see an entry for Windows in this malware enumeration. Am I missing something here?
  • enum malware { IE, PERL, EMACS, OUTLOOK, VB };
    We could call this a starting point.
  • (1) Windows Malware will be identified by a prefix of "" (without the quotes)
  • This strikes me as a bunch of pomp and circumstance to no real effect. So big viruses have common names now? Great. What about Trojan-downloader-delf.xxx that's still going to have a different name everywhere? What about nail.exe which will still be called VX2 by some, ABI by others. Pardon me for witholding my applause but if they only allow numbers up to 999, this is hardly comprehensive, and since Blaster and Zotob and SDBot are pretty similarly named already by most major vendors, I'm not sure I see
  • The most significant step to solving a problem is first to identify it.

    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
    • The most significant step to solving a problem is first to identify it.
      The underlying problem is still not identified here. At best, this will always be a reactionary stance for containment and triage purposes. There is no way to identify the problems before they're problems in this scenario. It's like the boss asking for a list of all unknown issues that might arise in a software project.
  • Poor naming... (Score:3, Interesting)

    by Senzei ( 791599 ) on Wednesday October 05, 2005 @10:30AM (#13722488)
    Like the half dozen or so other responses I have seen I think the naming system is a good idea, but the names generated for it would lead to confusion, especially amongst the less computer savvy.


    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 .5 or TinyPocketRocket 1.3"

    • 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 .5 or TinyPocketRocket 1.3"

      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

    • Personally, I'd not want to have my name connected to Bonzi Buddy, CoolWebSearch, MyFunWeb, PokaPoka, FunWebProducts, SuperSparklyHappyFunMagicWebTime (ok, so haven't seen that one yet, but I'm expecting it soon), or any of the 10,000 other similarly stupidly named ones we run into.

      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

  • 1000 pieces of malware should be enough for anybody!
    • Considering that The number of known viruses surpassed 70,000 in January 2002 [caida.org] it does seem a bit strange to deliberately set this sort of limitation in the design.

      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

    • From the CME site: [mitre.org]

      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

  • Now watch Gator sue them into oblivion!!!
  • Couldn't help noticing the similarity between this title and item number 2 on Marcus Ranum's list of the Six Dumbest Ideas in Computer Security [ranum.com]. :)
  • Bad Thing? (Score:3, Interesting)

    by Phreakiture ( 547094 ) on Wednesday October 05, 2005 @11:30AM (#13723020) Homepage

    Didn't we already decide, that enumaration, amongst other things [slashdot.org] was a Dumb Idea?

  • Is another man's Comet Cursor.
  • by pointbeing ( 701902 ) on Wednesday October 05, 2005 @11:38AM (#13723097)
    I'm a federal employee and information assurance is a huge part of my job. I don't understand why CERT needed another resource rather than tying things into NISTs shiny new National Vulnerability Database [nist.gov]. Seems to me that one-stop shopping for both software vulnerabilities and malware alerts would be the thing to do.
    • Actually this database isn't new, and isn't managed by NIST. CERT has been running the CVE database project for years, which makes the obvious limitations of this new virus naming scheme seem all the more strange.

      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.

    • I think that Pakistan and India have a better chance of cooperating on a nuclear weapons project than the Department of Homeland Security cooperating with the Commerce Department.
    • 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

  • So, now that we have people cataloging it... how about shutting down sites that are full of it, or blocking them from the 'net?

    Yeesh.
  • do I hear a second?

    [/sarcasm]
  • Sweet, a few million in research and a co-op of vendor neutral organizations and we'll have the Virii vs. Viruses debate figured out in no time !!!
  • Well damn, why are tax payers funding this - should it not be a function of Microsoft Support???
  • Hmm, how long till the first virus that is designed to mutate in order to make the naming system get a numeric overflow?

Your own mileage may vary.

Working...