5

For as long as can remember, EICAR has been used to test for the presence of Antivirus systems in email, the file system, or other places.

Sometimes the AV solution is so far out of date, that its efficacy is basically zero.

That leads me to question why have support for EICAR at all? Is this test obsolete, and should it be removed?

To me it seems logical to extend that line of questioning with this:

Would it be beneficial for EICAR to also test for the freshness of the AV update files?
Perhaps effectively saying "Only trigger AV alerts if signatures are newer than x/x/x date"?

Improve this question

4 Answers 4

Reset to default
8

I think, the main motivation to create Eicar in the first place was this: Stopping random people begging anti virus vendors for virus samples on the pretext of testing their own installation of the virus scanner.

A new test that ensure that signatures are up to date, sounds interesting. I suggest, however, not to use the original Eicar file for that, but something different. This way you can be sure that the expire algorithm is implemented, unless the vendor plays foul. Using daily/weekly released files might be even better, but this causes a lot of additional costs.

Improve this answer
1
  • Hmm... I think that that the argument can be made that the same group of people may be asking for almost zero day viruses under the pretext of "testing" their scanner. Perhaps rather than updating EICAR every day with a secret string, what do you think about just append a human readable date after the string (or variant thereof), and the engine responds accordingly?
    – makerofthings7
    Nov 7, 2011 at 0:20
15

The purpose of EICAR is to provide a cross vendor file that will be detected as a virus. Why? Well, imagine you are building a web application that allows user uploaded content, for example. Into this solution, because you are security-conscious, you might want to scan the uploaded files and remove those files that are malicious before you spread them to other users in your userbase. Many antivirus vendors provide command-line executables and solutions that can do this; what you then need, as a software engineer, is something to test this construction with, either automatically as part of unit/functionality/UI testing or just plain old "did it work" testing.

Enter the EICAR test file - a file all virus vendors have agreed will produce a positive response. As the intended use page puts it:

Using real viruses for testing in the real world is rather like setting fire to the dustbin in your office to see whether the smoke detector is working. Such a test will give meaningful results, but with unappealing, unacceptable risks.

Since it is unacceptable for you to send out real viruses for test or demonstration purposes, you need a file that can safely be passed around and which is obviously non-viral, but which your anti-virus software will react to as if it were a virus.

My understanding is that you do not use the EICAR test file to audit the status of your antivirus products and how up to date they are; you use them to test, in integration scenarios, a case where malware exists without using real, actual malware.

Improve this answer
3
  • Regarding your last paragraph, if the EICAR "status audit" in theory might return a successful cleaning from 15 year old AV signatures, what practical use are those results? As far as I can tell it's either has AV or doesn't have AV. Even if it has AV it doesn't have meaning without regard to checking the date of the AV signature. Seems like an irrelevant, outdated, useless test result to me.
    – makerofthings7
    Nov 6, 2011 at 23:18
  • 1
    @makerofthings think software engineering - the practical use is to prove that when bad stuff has passed through your app, it gets removed and your app handles the disappearance correctly. I agree, in terms of verifying the antivirus is fit for purpose, up to date etc, it's useless. It's just a convenient test file. Hendrik also make a good point about it being a way to defuse malware requests.
    – user2213
    Nov 7, 2011 at 0:02
  • The software engineering perspective makes a ton of sense, though I've seen too many people rely on this as a way of testing effectiveness (Google / Postini support reps have done this, and permitted viruses to come through to my server).
    – makerofthings7
    Nov 7, 2011 at 15:51
7

The purpose of EICAR is not to test how well the AV solution is at detecting viruses - because it's a long standing standard, we assume that anything that considers itself AV will catch it. The purposes it to test what the AV solution does when it determines a positive match against a virus.

You can have a solution configured so that it will send email whenever it catches something - but maybe you entered the wrong mail gateway, or maybe no one added the AV solutions address to the SMTP sending whitelist. How will you know if your alerting works? Only by testing, and as Ninefingers pointed out, it's a heck of a lot less trouble to test with something that a) you know will "hit" and b) you know won't blow up in your face.

Improve this answer
5

It's just an on/off indicator light, like the LED that indicates that your computer is on. But nobody expects it to be a good indicator, just like the LED can't tell if your computer has crashed.

It has a myriad of uses. For example, you send it through your e-mail gateway to see if it's blocked. Then you ZIP it up, to see if it's blocked. Then you ZIP the ZIP file again, 100 times in a row, to detect if it's still blocked. You are testing a feature, like n-level-deep-zip, not the quality of virus detection.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .