This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How do I determine if Sophos is up-to-date? VLD.dat not updating.

I'm using labtech to monitor my customer's systems. To determine if the Anti-virus is updating it's virus definitions regularly, it typically looks at a specific file that we are able to define. To date, for Sophos that file has been the vld.dat. However approximately a month ago the program was updated to Sophos Antivirus v 9.5.5, and now that file is no longer changing dates. This customer is being dual monitored (they are affiliated with a financial advisory firm that controls Sophos updates on their machines). I'm trying to determine what file (if any) updates now to show the latest virus definition update date. Can someone help me understand if there is such a file now and if so what file that is?

Thanks for any help in advance.

This thread was automatically locked due to age.

Parents

0 jak over 13 years ago

Hi,

Up-to-dateness can be a tricky concept as you need something to compare with that's authoritative and trustworthy. You also potentially need to decide an acceptable grace period. For example it might be alarmist for a system to flag a client as out of date, two seconds after the source is updated especially if the client only checks for new updates every hour. Technically it's out of date but you might be raising flags against machines that are updating fine.

In the case of clients updating directly from Sophos, up-to-dateness is not so bad, you are assuming that, "Sophos" as an update source is up-to-date. This is a fair assumption, so as long as the client is updating AND installing (within x minutes of the current time) you're up-to-date. The AND is important here for the following reason:

AutoUpdate pulls down updates to its cache directory, so in the case of the SAV package:
"C:\Program Files\Sophos\AutoUpdate\Cache\savxp"
so you could monitor that timestamp but it really just tells you that AutoUpdate is downloading new files, not that it's successfully installing the updates. In this case, SAV could be broken or disabled but AutoUpdate is still updating the cache and attempting installs, so in this scenario, the last download time looks good, but the last install time could be bad. From a security perspective, the last install time is a more important time stamp to monitor.
You can equally argue that even if the software is up-to-date it could be disabled. Surely a machine with out-of-date software that is on, is more secure than a machine with up-to-date software where the detection is disabled. For that reason up-to-dateness AND on-access state need to be considered which is what is essentially performed by Windows Security Center, it's just that the grace period is long, as last time I looked into it, it was just checking VDL.dat. So you get approx. a month grace I suspect.

Also, in the GUI of SAV, the "Status" area (top left) details the last update time, not install. This time is the same as the value stored in:
HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\AutoUpdate\UpdateStatus?\LastUpdateTime? (convert the decimal value from Epoch time http://www.epochconverter.com/?)

If you look in the "View Product Information" in SAV however, under the SAV section, there is a "Last updated" time, this is when SAV actually installed an update.
I wrote a script to obtain this along with a couple of other things which is here: /search?q= 7513 if they might be useful.

The degree of accuracy or grace period as mentioned before is another question, is the version of VDL.dat sufficient, if this only gets up dated once a month is that ok? Would the most recent date created time of a .ide be better? How accurate do you need to be? That the client is updated within the last day?

So it's complicated enough when you're updating from an authoritative source directly. If you switch to the model where SUM maintains a update location for clients to check, it gets even harder at the client to determine if it's up to date as you have to assume SUM is working, there is an extra layer now between the client and the authoritative source. The client could be updating fine, it could be installing new updates fine but is the location it's updating from correct and essentially up-to-date by Sophos standards?

So on the client in this scenario you can really only check for markers that give you confidence something is changing. Maybe it's sufficient to assume if the SAV package is updating within a dayt it's up-to-date and consider this in combination with on-access status.

Hope this adds something to the discussion.

Regards,
Jak
:26299
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 jak over 13 years ago

Hi,

Up-to-dateness can be a tricky concept as you need something to compare with that's authoritative and trustworthy. You also potentially need to decide an acceptable grace period. For example it might be alarmist for a system to flag a client as out of date, two seconds after the source is updated especially if the client only checks for new updates every hour. Technically it's out of date but you might be raising flags against machines that are updating fine.

In the case of clients updating directly from Sophos, up-to-dateness is not so bad, you are assuming that, "Sophos" as an update source is up-to-date. This is a fair assumption, so as long as the client is updating AND installing (within x minutes of the current time) you're up-to-date. The AND is important here for the following reason:

AutoUpdate pulls down updates to its cache directory, so in the case of the SAV package:
"C:\Program Files\Sophos\AutoUpdate\Cache\savxp"
so you could monitor that timestamp but it really just tells you that AutoUpdate is downloading new files, not that it's successfully installing the updates. In this case, SAV could be broken or disabled but AutoUpdate is still updating the cache and attempting installs, so in this scenario, the last download time looks good, but the last install time could be bad. From a security perspective, the last install time is a more important time stamp to monitor.
You can equally argue that even if the software is up-to-date it could be disabled. Surely a machine with out-of-date software that is on, is more secure than a machine with up-to-date software where the detection is disabled. For that reason up-to-dateness AND on-access state need to be considered which is what is essentially performed by Windows Security Center, it's just that the grace period is long, as last time I looked into it, it was just checking VDL.dat. So you get approx. a month grace I suspect.

Also, in the GUI of SAV, the "Status" area (top left) details the last update time, not install. This time is the same as the value stored in:
HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Sophos\AutoUpdate\UpdateStatus?\LastUpdateTime? (convert the decimal value from Epoch time http://www.epochconverter.com/?)

If you look in the "View Product Information" in SAV however, under the SAV section, there is a "Last updated" time, this is when SAV actually installed an update.
I wrote a script to obtain this along with a couple of other things which is here: /search?q= 7513 if they might be useful.

The degree of accuracy or grace period as mentioned before is another question, is the version of VDL.dat sufficient, if this only gets up dated once a month is that ok? Would the most recent date created time of a .ide be better? How accurate do you need to be? That the client is updated within the last day?

So it's complicated enough when you're updating from an authoritative source directly. If you switch to the model where SUM maintains a update location for clients to check, it gets even harder at the client to determine if it's up to date as you have to assume SUM is working, there is an extra layer now between the client and the authoritative source. The client could be updating fine, it could be installing new updates fine but is the location it's updating from correct and essentially up-to-date by Sophos standards?

So on the client in this scenario you can really only check for markers that give you confidence something is changing. Maybe it's sufficient to assume if the SAV package is updating within a dayt it's up-to-date and consider this in combination with on-access status.

Hope this adds something to the discussion.

Regards,
Jak
:26299
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data