0

The EICAR test file was used to functionally test an antivirus system. As it stands today almost every AV system will flag EICAR as being a "test" virus. For more information on this historic test virus please click here.

Currently the EICAR test file is only good for testing the presence of an AV solution, but it doesn't check for engine file or DAT file up-to-dateness. In other words, why do a functional test of a system that could have DAT files that are more than 10 years old. With the quantity of viruses released daily, over time, the EICAR signature loses value as a testing tool.

That being said, I think EICAR needs to be updated/modified to be effective test that works in conjunction with an AV management solution.

Some people on serverfault responded to an earlier revision of this question.

To answerers: Please focus on the point:

This revised question is about testing the functionality of an AV system.

Please don't respond with management solutions since they don't test what's deployed and in the field. Management solutions report and that may be flawed in one way or another for example: sometimes a machine may not be included in routine AV administration by operator error. Sometimes AV is managed by a different company or group. No matter what your stance is on 'management', this does not count at a post-deployment "test" IMHO. This question is about real world testing, without using live viruses... which is the intent of the original EICAR.

I'm proposing a new EICAR file format with the appendage of an XML blob that will conditionally cause the Antivirus engine to respond.

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-EXTENDED-ANTIVIRUS-TEST-FILE!$H+H*
<?xml version="1.0"?>
<engine-valid-from>2010-1-1Z</engine-valid-from>
<signature-valid-from>2010-1-1Z</signature-valid-from>
<authkey>MyTestKeyHere</authkey>

In this sample, the antivirus engine would only alert on the EICAR file if both the signature or engine file is equal to or newer than the valid-from date. Also there is a passcode that will protect the usage of EICAR to the system administrator.

If you have a backgound in "Test Driven Design" TDD for software you may get that all I'm doing is applying the principals of TDD to my infrastructure.

Based on your experience and contacts how can I make this idea happen?

makerofthings7
  • 8,911
  • 34
  • 121
  • 197
  • 3
    I think you misunderstand why the eicar signature exists. – Sirex Sep 09 '10 at 14:15
  • @Sirex - Please explain. The alternative is to test using a near-zero day virus. That is exactly why EICAR was created. – makerofthings7 Sep 09 '10 at 14:20
  • As several answers here explain (better), eicar was created with the view to test if virus catching was present in an enviroment using a safe definition with no payload. It has nothing to do with the up-to-dateness of any virus solution, which is completely dependant upon the correct management of the solution once deployed. The solution you seek is already in existance, but if your rly on a third party which isnt keeping its definitions up to date, run your own or ditch them – Sirex Sep 09 '10 at 14:49
  • @Sirex - It is bad to assume that every AV deployment of scale has a corresponding management solution, that solution is working, or that solution is maintained. This grey area requires a functional test similar to what I propose. I believe there are enough companies in this situation to warrant the update to EICAR. – makerofthings7 Sep 09 '10 at 15:41
  • 2
    If your AV deployment is not giving you the visibility you need, then you need a different deployment or a different vendor. – Joe Sep 09 '10 at 16:02
  • @Joe - If you're a consultant in a new shop, or testing hosted/cloud services aside from using live virus samples, there is no other functional test. – makerofthings7 Sep 09 '10 at 16:52
  • 1
    @Sirex - I understand why the EICAR signature exists. It exists to safely test the presence of an AV solution. Some people erroneously think that also means they are safe. There is almost no safety in an out of date AV product. That is the reason of my proposal. – makerofthings7 Sep 09 '10 at 17:07
  • EICAR is waste of time, but if your worried about 0day's then your also wasting your time, as Donald Rumsfield said "you can't know the unkown!" – tony roth Sep 09 '10 at 18:35

7 Answers7

2

What you are after (in the context of a system not under your control) is unlikely to ever become viable simply because it would open yet another vulnerability against the AV software itself. i.e. It would become possible to probe a system to determine whether or not it is capable of detecting the latest virus. If the test fails the virus could be sent through undetected without arousing undue suspicion.

As for the EICAR test, it's high time that was abandoned. Most AV software I've seen is either hard coded to detect it or has a signature for it, making the "test" absolutely worthless.

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109
  • I agree that EICAR is currently mostly worthless, unless you want to prove the lack of AV scanning. If my proposed idea was implemented there would have to be a means to protect against "snooping". – makerofthings7 Sep 08 '10 at 22:10
  • +1, Additionally if you use any sort of pattern for the newly updated files, AV makes will catch on and simply "detect" anything that matches the pattern; making the newer test files detectably by old software. – Chris S Sep 09 '10 at 17:07
  • -1 There is no case of probing since a password is in the EICAR file. Also old AV won't catch on to this nonsense string that does nothing. To those engines, this should be a string no different than your email signature... just an ASCII blob – makerofthings7 Sep 09 '10 at 17:17
  • 2
    John, there's nothing "worthless" about the EICAR test, if you understand what it is supposed to do. It isn't supposed to be an up-to-date test of how good AV software is, but simply whether or not it is deployed and configured correctly. This is explained clearly enough on the eicar.org website. – Rob Moir Sep 09 '10 at 18:47
1

I doubt the industry is going to make a new EICAR file monthly for you. Its a waste of time and resources. The solution to your problem is buying a centralized AV like Symantec or Sophos so you can run a report and see which clients need updating.

DrZaiusApeLord
  • 1,174
  • 2
  • 9
  • 18
1

The EICAR file itself doesn't test for the presence of anti-virus. It is simple used as a tool for testing purposes (so you're not you know testing against live viruses).

There are plenty of ways to monitor and manage engine and definition updates (I'm assuming you are using McAfee since you are using the DAT terminology)

Every enterprise anti-virus has a central management console available. For McAffee check out ePolicy Orchestrator (or whatever the current SMB software is called).

Zypher
  • 37,405
  • 5
  • 53
  • 95
1

The EICAR file only tests for the presence of AV, it isn't used for currentness. I believe the EICAR file itself is over a decade old at this point and is therefore 'supported' by everything.

Solving the currentness problem is one that all enterprise grade AV products have solutions for. McAfee has the ePolicy Orchestrator. Symantec has System Center. Microsoft ForeFront also has a reporting console. They all rely on the AV engines themselves to report back to homebase about what they're currently running in regards to both definitions and engines. The more sophisticated Desktop Inventory products out there can also provide this kind of service.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
  • I understand that EICAR only tests for the existance of AV, not it's currentness and therefore it not a good choice for my test. My real issue is that I rely on an external system that I don't manage, and viruses come through because of out of date DAT files – makerofthings7 Sep 08 '10 at 20:21
0

The answers above are pointing you towards a centralized management console. That's usually the best answer. I take your point about passive monitoring, but I think you're slightly off-base. The central solutions I've worked with don't assume that the client got the update; they update the information in the console with what the client says its definition date/version is. That's exactly as accurate as you asking the client machine yourself in some other way. In fact, the worst that can happen is a breakdown in the console, still sending updated DATs but losing return communication from a client, and showing an older definition date in the console than the client actually has.

However, if you can't do that (machines aren't going to stay under your control after deployment, etc) then you can try to find out where the AV software you use keeps that information.

When I had to do this for SAV CE, you could query the registry of the client machine to find the current AV definition version, and I think the date as well. For McAfee DAT files, you might be able to find out where the directory the DATs are kept, and have a script that looks for the created or last-modified date of the newest DAT file in that directory.

mfinni
  • 36,144
  • 4
  • 53
  • 86
  • Thank you but this does not help me in a hosted / cloud solution... where functional testing is my only choice. – makerofthings7 Sep 08 '10 at 22:42
  • Then put the onus on the people managing your systems, for crap's sake. Your not managing them, you're paying someone else to do it. Say that you want a daily report from the managed hosting company of the AV definitions on the servers you rent. – mfinni Sep 09 '10 at 01:08
  • From a management perspective you have a point, however, I edited this question and content. EICAR needs updating in order to be relevant. If you agree please upvote. – makerofthings7 Sep 09 '10 at 11:41
0

Consider submitting this idea to http://www.eicar.org/contact/

TLDR
  • 301
  • 2
  • 9
0

If I understand what you're asking for is a third party tool to test whether or not a third party tool is doing what they say they're doing? If so, why would you propose relying on a third party tool when you haven't been able to rely on third parties thus far? o_O

I'm not sure we can help you "make it happen". I can't "make" eicar do anything anymore than I can "make" you do something for me. I've found that when I can't get something accomplished through a reliable third party, I do it myself or not at all.

If you wish to test email security, you could try GFIs email security test, although I believe it's a bit out-dated.

Edited to add:

You keep arguing that "EICAR needs updating in order to be relevant." No, it doesn't. Their AV test file only has one purpose and that is "produce a file that their (and many other) products "detect" as if it were a virus. " That's it. In that respect, they remain relevant.

If you have a third-party vendor that isn't performing to your expectations, then you fall back on an SLA. Your SLA should state what they're doing to maintain current AV and how they're going to prove that to you to your satisfaction. Nothing you have another party "do" (in this case you're asking for EICAR to make another test file to test whether your AV is up-to-date) is going to make up for the fact that you don't have this spelled out in an SLA.

GregD
  • 8,713
  • 1
  • 24
  • 36
  • I'm well aware of GFI's email test. They use EICAR as well and I'm addressing that test's issues here. To address your other point... aren't we all 3rd parties when you think of it? It takes one person to "do" something to make change happen. Often it requires working with other people. That's what I'm trying to do, first on Serverfault, and in other venues. I'd appreciate your support if you want to effect change. – makerofthings7 Sep 09 '10 at 14:06
  • We both agree that the EICAR test today is pretty much inconclusive. I also feel pretty unpopular now, but I stand by my idea. It seem rational, logical, and an effective test. I do not understand why no-one is focusing on the testing aspect, which is what I want to do. Just test. All the other points are valid, but I only care about testing in this specific case and no-one is paying attention to that. – makerofthings7 Sep 09 '10 at 17:38
  • ..what is the point of detecting a virus if the engine is too old. You might as well not have any AV at all. EICAR is irrelevant today, since a positive test result means you have AV software.. but it could be from 1996. Which is a useless test result. – makerofthings7 Sep 09 '10 at 17:42
  • 1
    I'm sorry MakerOfThings, but you keep insisting that EICAR is "irrelevant" and needs to be updated because it doesn't solve *your* problem. This is, with all due respect, either rude or ignorant. It doesn't do a good job of testing what you want to test because *it isn't supposed to test that*. A chainsaw doesn't make a very good toothpick either and for much the same reason. – Rob Moir Sep 09 '10 at 18:45
  • 1
    I believe it's true to say (1) EICAR tests for the presence of AV software, (2) perhaps to the advantage of malicious hackers, (3) where the AV software *could be* functionally ineffective or out-of-date... therefore making the test useless. The combination of points 1,2, and 3 is not self-focused. I've already fixed my issue and migrated to another vendor. However EICAR is at most ineffective, at at worst a tool for hackers since the help text for quarantined messages can be used for social engineering and SMTP header tracing. – makerofthings7 Sep 09 '10 at 19:00