Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
1009 Views 7 Replies Latest reply: Mar 29, 2014 1:28 PM by wwarren RSS
dnf Apprentice 99 posts since
Jun 22, 2012
Currently Being Moderated

Jul 31, 2013 6:29 AM

VSE 8.8 persistent caching

Hi all,

 

I´ve been reading "VSE 8.8 - What's New.pdf" and thinking about the new behaviour with persistent caching feature. Basically, VSE won´t scan a file that has been cached as clean, ok so far.

My question: Does this behaviour only happen when accessing the file for reading but still scanning the file when writing? Otherwise I think it might be a "problem" cos it won´t scan a cached file again that it might have been infected.

 

And when the cached list is regenerated or deleted? In VSE 8.7 it was when evey new session.

  • Laszlo G Veteran 1,213 posts since
    May 23, 2007
    Currently Being Moderated
    1. Jul 31, 2013 6:40 AM (in response to dnf)
    Re: VSE 8.8 persistent caching

    Hi dnf, I think an item won't be analyzed again unless it has been changed. When a file has been infected then its hash changes and VirusScan detects it so it analyzes it again

  • rmetzger Champion 566 posts since
    Jan 4, 2005
    Currently Being Moderated
    3. Aug 2, 2013 10:46 AM (in response to dnf)
    Re: VSE 8.8 persistent caching

    Hi dnf,

     

    Yes, the cache is flushed and files re-scanned upon DAT version changes.

     

    However, this applies to On-Demand Scanner and has nothing to do with On-Access scans.

     

    From the Best Practices Guide, page 32, Configuring the scan cache:

    http://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/2 2000/PD22940/en_US/vse_880_best_practices_guide.pdf

    [quote]Configuring the scan cache

     

    The VirusScan Enterprise scan cache saves a list of scanned files that are clean. This improves

    your system performance by saving this clean file scan cache information during a system

    reboot. This also allows the on-demand scanner to use this clean file cache information to

    reduce duplicate file scanning.

     

    These options should remain enabled for the best boot time and overall system responsiveness

    during on-demand scans.

     

    NOTE: Disable these settings during a malware outbreak or if your security requirements are

    high. [/quote]

     

    Page 33: [quote]Configuring the scan cache

     

    To configure the scan cache settings using the ePolicy Orchestrator, access the VirusScan

    Enterprise 8.8.0, General Options Policies, and click the Global Scan Settings tab.

     

    Enable the following scan cache settings:

     

    • Enable saving scan data across reboots

    Allow On-Demand Scans to utilize the scan cache

     

    The following ePolicy Orchestrator 4.5 shows the scan cache enabled.

    [/quote]

     

    The caching applies to On-Demand Scans, not to On-Access reads and writes.

     

    Hopefully this clarifies expectations of Scan Caching

     

    Ron Metzger

     

    Message was edited by: rmetzger (redact incorrect info) on 8/2/13 11:41:29 AM EDT

     

    on 8/2/13 11:46:01 AM EDT
  • wwarren McAfee SME 765 posts since
    Nov 3, 2009
    Currently Being Moderated
    4. Jul 31, 2013 9:07 AM (in response to dnf)
    Re: VSE 8.8 persistent caching

    Hi Folks,

     

    I need to correct some comments and add clarity here -

     

    1. The scan cache is used by OAS, and optionally by ODS (you configure it to use the cache with the "Allow On-Demand Scans to utilize the scan cache" option).
    2. The scan cache is cleared on DAT update. Not all data is lost due to the update occurring - we remove the data that needs to be removed; and so the cache can still be of use post update.
    3. A file that is in cache that has been modified is always removed from cache
    4. The persistent cache setting is there to improve boot times primarily
    5. Getting benefit from the cache is only possible if the files being touched are still in the cache . The size is limited to avoid exhausting non-page pool memory.
  • rmetzger Champion 566 posts since
    Jan 4, 2005
    Currently Being Moderated
    5. Jul 31, 2013 9:16 AM (in response to wwarren)
    Re: VSE 8.8 persistent caching

    I stand corrected! Thank you William.

     

    Ron Metzger

  • zeb Newcomer 13 posts since
    May 8, 2012
    Currently Being Moderated
    6. Mar 28, 2014 4:51 AM (in response to wwarren)
    Re: VSE 8.8 persistent caching

    Hi William,

     

    If I may bump this old ticket.. (It's the best reference I've found in a long time).

     

    We are still discussing this here internally, and we never agree on the details :-)

     

    "2. The scan cache is cleared on DAT update. Not all data is lost due to the update occurring - we remove the data that needs to be removed; and so the cache can still be of use post update."

    Wat is remaining... How to interpret what is still in the 12MB cache after the new DAT arrives? What's the influence on the incremental scan that has been running today at for example 1AM, and will be resumed tonight at 1AM**

     

    "3. A file that is in cache that has been modified is always removed from cache"

    Can you define what McAfee's comphrehension is regarding 'Modified' (I assume you do not solely rely on Microsoft ?)

     

    "4. The persistent cache setting is there to improve boot times primarily"

    Great remark. We probably all hope for a massive featureset, so this tempered the expectations a lot ;-)

     

    And perhaps too far away from the Cache function:

    **an Incremental scan resumes his scan from a certain point (KB78969), does it rely on the scan cache's list of files that are already scanned and/or it's own list ?

     

    Hope you can help!

     

    Greetings,

    Zeb

  • wwarren McAfee SME 765 posts since
    Nov 3, 2009
    Currently Being Moderated
    7. Mar 29, 2014 1:28 PM (in response to zeb)
    Re: VSE 8.8 persistent caching

    zeb wrote:

     

    "2. The scan cache is cleared on DAT update. Not all data is lost due to the update occurring - we remove the data that needs to be removed; and so the cache can still be of use post update."

    Wat is remaining... How to interpret what is still in the 12MB cache after the new DAT arrives? What's the influence on the incremental scan that has been running today at for example 1AM, and will be resumed tonight at 1AM**

    What we cache about a file isn't just its name and if it is clean, or excluded. We also know what settings it was scanned with, and if the file is from a trusted provider. With this and other meta-data we can more intelligently deterine when/if a file needs to be removed from the cache when an update occurs, or when we see it next. We also have a mechanism within the DAT update itself for purging the cache if we have reason to suspect persistent data is compromised.

    "3. A file that is in cache that has been modified is always removed from cache"

    Can you define what McAfee's comphrehension is regarding 'Modified' (I assume you do not solely rely on Microsoft ?)

    There are better ways to determine a file has changed than a modified timestamp, yes. I won't go into the details though of what methods we use. You are welcome to poke it and see if you can break something . The most common thing to trip people up is they disable our scan-on-read setting, what defeats the purpose of the cache and is also suicidal. I expect at some point in future releases we'll just hide that setting from the UI so folks can't shoot themselves in the foot... as easily.

    "4. The persistent cache setting is there to improve boot times primarily"

    Great remark. We probably all hope for a massive featureset, so this tempered the expectations a lot ;-)

    It has excellent practical use also for most devices if sharing the scan cache data with our On Demand Scanner, allowing it to potentially complete faster, even a lot faster.

    And perhaps too far away from the Cache function:

    **an Incremental scan resumes his scan from a certain point (KB78969), does it rely on the scan cache's list of files that are already scanned and/or it's own list ?

    Its own list. A scheduled ODS keeps track of the last file it has scanned.

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points