eicar-standard-anti-malware-test-file

ok, so i was either really early or a little late in saying something about the eicar standard anti-virus test file being repurposed for more general anti-malware usage...

this isn't an i told you so . . . ok, maybe just a little... but c'mon, it's not like this was ever rocket science... spycar, supposedly an homage to eicar, was never necessary to test if anti-spyware apps were installed properly when the eicar file was just as good for that purpose... and as i stated before, for any other sort of testing as spyware simulators really only tells you if your anti-spyware app can detect simulated spyware (and by simulated, i mean a rather poor simulation at that as none of it seems particularly targeted to any unique property of spyware)... i knew it was going to be misused in testing (just as virus simulators were and sometimes still are misused in anti-virus testing), which is why i said that good spyware simulators were still a bad idea, and of course i was proven right...

so, now that spycar is obsolete and the eicar test file (you can't just call it eicar, by the way, since that's the european institute for computer anti-virus research) has been renamed (the file itself remains unchanged, though, just in case that wasn't clear to everyone) so as to be used to test that anti-spyware (and other anti-malware) scanners are installed and operating properly (there's just no good way to test that for behaviour-based systems without real malware), maybe now we can put the whole 'lets make a new testfile for our new anti-[something-or-other] industry' notion to bed once and for all... yeah, and maybe i'll find the pot of gold at the end of a rainbow...

are good spyware simulators still a bad idea

so apparently someone came up with the idea of creating spyware simulators collectively known as spycar (apparently a play on the eicar test file) for testing the effectiveness of anti-spyware applications...

the idea, basically, is that a bunch of these tiny applications could be written that each do some small spyware-like thing... supposedly this is meant to test how well an anti-spyware app can detect spyware they don't already know about - the more of these spyware simulators the anti-spyware detects the better it is (in theory)...

this idea came up before in the virus realm years ago and i'll direct you now to sarah gordon's paper are good virus simulators still a bad idea... i suggest reading the entire thing through but for now just scroll down to the conclusion and replace "virus" with "spyware" and it will be about as valid...

essentially, for testing the effectiveness of your security app, using simulators only tells you how good the app is at detecting simulations rather than the real thing... to assume that anti-spyware vendors won't simply add signatures for the simulations is naive, especially when their work starts being judged on how well it detects the simulations... there's no way this effort on it's own is ever going to force the vendors to improve their generic detection techniques, it's just not a cost effective way for the vendors to deal with the simulations...

as for using these things as test files to see if your anti-spyware app is installed correctly (as their namesake the eicar standard anti-virus test file was intended for) the anti-spyware vendors could just as easily use the eicar test file directly for that purpose... there's no need to implement any particular behaviour in the test file if all you're doing is checking if the app can detect something it already knows about; it's not like the eicar test file has any virus-like behaviours, nothing of the sort was required to test the sanity of an installation, all it does is display a string of text on the screen (at the command prompt) when executed...

clearly, if folks in the anti-spyware field are just now coming up with an idea that was debunked in the anti-virus field over a decade ago, the anti-spyware field isn't anywhere near as mature... the question is are the anti-spyware principals looking into learning from what the anti-virus community and industry have already figured out?...

the adware comment thread to end all adware comment threads

story time folks... currently i'm embroiled quite the debate in the comments section of a posting over at sunbeltblog and in true vitalsecurity.org fashion i thought i'd offer up my observations here...

first i'll confess to making an error, i started out by misinterpreting the source material, i thought an anti-spyware app had been labelled rogue simply because it had been bundled with adware... the interesting thing is that people actually defended this interpretation - that is, if my interpretation had been what actually happened they would defend that action apparently just because the adware in question was produced by a company with a shady past...

now, i hate adware as much as the next guy and i certainly wouldn't touch this thing with a 10 foot barge pole (at least not outside of a virtual environment), but i'm honest enough with myself to admit that that is purely on suspicion alone, whereas the overwhelming opinion of the other participants seems to be that if the software is made by bad people or even people who have done bad things in the past then the software itself is bad... it's been these kinds of peculiar ideas that have kept me going back...

now i've known for a long time that the malware problem has many dimensions, it's not just the software that we need to concern ourselves with, but when we are dealing with the software part of the problem should we let things like the creator's past cloud the issue? no, of course not, that's a different part of the malware problem and it's best dealt with in a different way... when we classify malware we're concerned with whether or not the software itself poses a risk, not whether it further's some corporation's nefarious agenda... internet explorer furthered a corporation's nefarious agenda (just ask the department of justice) but that doesn't make it malware...

another peculiar idea i encountered was that if you don't deal with the question of whether the people who made the software are bad when you're deciding whether the software itself is bad then somehow you're not addressing the badness of the people at all... come on, the malware problem is a complex one, and the secret to dealing with complex problems is to break them into their component parts and deal with those parts separately... just because you aren't dealing with the people when you're dealing with the software doesn't mean you aren't dealing with the people at all, just that you've compartmentalized your efforts... is that a bad thing? no, certainly not, in fact it means you're much less likely to try and use your software solution on a people problem... and lets face it, software doesn't solve people problems - it solves problems for people, but not problems with people...