alfred Posted September 25, 2010 Report Share Posted September 25, 2010 All, Over the next few weeks I'll be posting more about our detection strategy and our general position on the subject of detections and reviewing 'efficacy'. I hope to speak to how we measure it, how I think the public should measure such things and in general how I would like to see you measure it. If I'm lucky I'll coax other Immunet staff to post as well. This is a topic we all feel passionately about and time permitting we'll write on it here. Now, onto our detection efficacy. The Fall months, here at Immunet, are being dedicated to increasing our overall efficacy. To us this means increasing our detection rates on threats which are actively in-field in our Community. This does not mean we are trying to excel at gaming reviewers. Please note, the industry spends far more time focusing on the latter than the former. Our goal is to stamp out threats actively wandering about in our user community and this is not a simple task for a couple of reasons. The first reason is, it's not time spent gaming reviewers. Sound confusing? Let me explain. All of you know where the common websites are for listing websites carrying malware, many of you have access to malware sample sharing sites (private and public both) and more of you share samples amongst yourselves. It's likely not a surprise to you that most AV vendors know this too and they focus on it. They crawl those sites, seed the sharing networks and spend time (a lot of time) building out sharing networks (we also work hard on sharing networks to be fair). All of the files they receive as a bounty of this work are typically fast-lined to a set virus definitions. It means that average youtube reviewers and folks from Wilders get threats which standard AV products crush. Well of course they do. This application of energy takes a lot away from innovation. This is not to say the big guys are not innovating, they obviously do, they have large teams and can generally bifurcate their energy and do both things. Ultimately though, they still concentrate on the review/reviewers because it is what, like it or not, drives sales of their products. Regrettably it also means that you have a tougher slog unless you go this route because it's where the public focuses. Immunet is not large and does not have the luxury of doing both so instead we focus on trying to find new ways to detect malware, from the cloud, and push hard so that our innovation will intersect with the need to satisfy external reviewers as well. Having said all of this, our goal is to double our in-field convictions by November 15, 2010. This begs to question - then, what is the raw number of daily convictions we see so we can have a baseline. The below chart shows our detection rates up to September 1. Our rates for August put us somewhere around 10,000 convictions in-field a day. Therefore our goal is be consistently over over 20K (hopefully 25K) by November 15, 2010. What will take us there is SPERO and ETHOS being applied more aggressively as the fall progresses. The chart below actually shows SPERO during a trial where we enabled a highly aggressive version for a week. As you can see, the results are dramatic. This particular tree though is not in general production but instead a more conservative version rolled instead. Current trees are: W32.SPERO.Startpage W32.SPERO.SillyFDC W32.Generic-0922 W32.SPERO.Allapple By December we'll have 10 or 12 of these trees into production. The aggressive tree will also come back into production as well after some tuning, likely by Wednesday of next week. As I mentioned earlier, we also are enabling ETHOS this week into a much more aggressive posture. ETHOS is best described a 'generic detection' it's designed to catch whole families or clusters of threats from specific families. This week I will be moving about 1,000,000 such ETHOS detections into production, tonight in fact I will be firing up 100,000 of them. An ETHOS detection from this grouping would look something like this: W32.ETHOS.SEP.02EE7W SEP denotes the month the detection was enabled, the 6 characters after are the actual first 6 characters of the hash for the detection itself. These are not the only things we're doing, by any means, but hopefully this provides a little more insight into our current approach to increasing detection rates in the IMP Free product. al Link to comment Share on other sites More sharing options...
This topic is now archived and is closed to further replies.