Scanning entire USB (flash) drives 'automatically' is not very effective at stopping malware. It is very effective at killing performance and making USB drives impractical. Performance issues with the USB interface, coupled with the recent incredible sizes of new USB attached drives can make scanning the entire drive so painfully slow that your users would find the system unusable.
A better strategy is to scan all files upon Read and Write to the drive. As long as this is done, scanning the entire external drive is simply redundant without value. The On-Access Scanner can handle this nicely without the performance penalty of scanning the entire drive. Scanning the entire external drive before allowing access is simply a plecebo scan, used to placate the uninformed or the paranoid. If you find it necessary, those workstations can have the heuristics scan set to High, though expect false positives at this level.
Make sure that from the Control Panel:
On-Access Scan Properties>All Processes>Scan Items>Scan Files
Check "When reading from disk"
Make the equivalent settings change from ePO if available.
This will ensure that any file on the USB drive is scanned prior to execution (autorun or otherwise).
This setting should be in place regardless of external drives as this is an Absolute Requirement for stopping many forms of malware, for internal drives too.
In addition, make sure that from the Control Panel:
On-Access Scan Properties>All Processes>Scan Items>Scan Files
Check "When writing to disk"
to ensure that files written to the USB drive are scanned during the write process.
These 2 settings should protect against spreading malware when keeping the signature files completely up to date.
As for only allowing .doc or .docx files to be used from the USB attached drive: This is not easy via VSE. A better approach would be to look a DLP to limit what can be written to the attached drive.
Creating a filter that limits reading only .doc or .docx files from the USB attached drive may create more problems than you solve. That filter might cause problems when Word is used to modify any .doc or .docx file, where Word creates temporary files that the filter might block. This could interfere with Word's normal working process. I am not sure how VSE could actually do this anyway.
A broader solution might be McAfee Device Control (DEC).
• DEC features:
–– Visibility and manageability of data copied to removable media
–– Monitor and regulate data transfer
I hope this is helpful.
Thank you for your answer and my apologies for not responding earlier.
I know it isn't good for performance, however in this case we're not looking for performance, we're looking for maximum protection.
We have considered banning USB sticks altogether (McAfee Device Control) but that is impractical yet. So we do want to scan the USB sticks (minimize risks).
Presently, we have to rely on the user's understanding of security (?) so they will scan USB sticks systematically when they bring them back from "outside". But they sometimes "forget"... And I know that we do catch nasty stuff every one and then (weekly).
I didn't think it was necessary to specify that we already have rather strict VSE policies in ePO.
We have set the scanning of files on R&W, however there are exceptions (*) on some folders etc. (some files/folders are scanned only on R, some files/folders only on W) and the number of "exceptions" mean that we cannot be really certain any more and we're concerned that some combination of exception may create a hole.
Plus, I disagree with your assertion that "scanning the entire external drive is simply redundant without value". I am OK with being called paranoid, it comes with the job. I've been doing this long enough and have seen what happens when one isn't paranoid enough.
Scanning on Write (on the USB stick) won't protect you from stuff that is brought from the outside if the USB disk has been infected outside.
Scanning on Read may/should protect you. I'll add that McAfee "minimal practices" (2010) recommend scanning on read as a minimum and scanning on read rather than on write whenever one cannot scan on read and write.
But again, we are looking for increased protection & security for some of our systems.
Thank you for your time and best regards
(*) some exceptions are required by MSFT themselves - I've been wondering whether these are already included by default in VSE default (internal) settings.
Thanks for your reply. Let me clarify my perspective.
To me, Good Security is a 'Process' not a result. The process must include all involved. Performance and useability go hand-in-hand. Even in the most secure environments, a computing environment that can't get things done is unuseable to most users. Mandatory secondary scanning of external drives for 'Maximum Protection' does not necessarily increase protection but does increase frustration. Users typically attempt to bypass this extra scan. In my experience, this creates a rift between Security/Network Administrators and the end-user groups. Rather than partnering with the Administrators, they avoid the Administrators. Certainly this is not 'Maximum Protection.' The secondary scan will find infected files even if they are not otherwise accessed. If your purpose is to expose individuals who have these detections, so be it. However, my suggestions were targeting prevention of further infection within your network. So, are you trying to catch people, prevent infection, or both? The choice is yours.
Consider this situation (of Automatic Scanning):
User A inserts their USB drive into the system. Scans occur, it's clean. Now the user makes a change to a document, saves it, then removes the drive. So far all is good.
User A's manager informs him/her of additional changes to the document.
User A inserts their USB drive into the system (to make the required changes) and has to wait for another scan, even though it was clean 2 minutes ago.
Now consider doing this using a nearly full 128GB flash drive. Time lost will be substantial.
This assumes everything runs perfectly. When things don't run perfectly, files and directories may stay locked, and the drive may not 'Eject' properly. This can cause file/directory corruption. These scans may actually increase the risk of data loss. (I have observed this form of data loss with other AV software that automatically scans the inserted flash drive. Not good!)
If you have certain workstations with extremely sensitive processes, consider disabling the USB ports entirely, then locking the BIOS. Maybe even disconnecting the cables leading to the USB Ports, then physically locking access to the insides of the system. McAfee Application Control may be an alternative to those highly secure systems, where only White-Listed apps can run. This may be more practical in places where an infection is just not an option. Of course, a good backup strategy is essential. By that I mean a regularly practiced means of restoring a system back to a safe point in time.
So, the default Scan on Read is catching things? Again, are you trying to catch people or prevent infection. If you catch the same people repeatedly, education and accountability may be a good deterrent. Like I said before, Good Security is a Process. Forgetting to scan is an excuse. They didn't want to. Educating these users of the importance of the scan is probably a better approach. Holding them accountable for failing to scan will get compliance.
Once you get buy-in from the users,
In Explorer, Computer -> Right-Click on the new drive -> 'Scan for threats'
Regularly reviewing the ePO logs can document compliance.
Understood. However, in a public forum such as this, there are at least 2 audiences: The OP (you) and everyone else who may be lurking. I cannot know either group, nor whatever settings are in place. To that end I cannot Assume anything. I am glad that you have a fairly strict VSE policy, but others reading these suggestions might not.
"Exceptions" always expose holes. Consider implementing High/Low Risk Process policies that mediate the 'holes' while allowing and controlling the exceptions.
These exceptions should NOT impact external drives inserted into a system. In this case, Scan on Read should be required.
Having been 'Audited' in the past, I had to Justify every Exception created. I have used this experience to flavor my need for exceptions. (I go through the exercise of justifying each one, on a regular basis, documenting and reviewing the policy each time. Keeps me honest. This is especially true when software changes remove the need for the exception.) Again, good Security is a Process.
I guess we can agree to respectfully disagree here. If the value is to catch people's bad behavior, great. But stopping infections - I don't see the value.
By the way, I don't mind being called paranoid either; sometimes it is necessary. (And no offense was intended.) I simply want to caution against breaking partnerships (trust) between the Security/Network Administrators and the end user groups.
When the end user groups are educated and understand the reasons for your concerns, the behavior usually changes for the better. Regularly reviewing ePO logs can often highlight areas of weakness that need to be addressed. Targeted remediation sometimes works better than network wide changes. It's a balancing act.
I usually recommend working quietly daily, raising my voice when needed, and only Yelling when absolutely necessary. When a real outbreak occurs, your voice getting louder will not be perceived as the 'boy crying wolf.' Hopefully that will not be needed. But, like you, I have had to deal with outbreaks. "It comes with the job." But getting buy-in for remediation from management, is not always as immediate as needed.
Choose your battles and reserve your weapons, both professional and technical.
Correct, which is one of many reasons why Scan on Read is essential.
Agreed. In fact, since then, William Warren (of McAfee) has suggested that this setting (Scan on Read) should not even be an option anymore, it's that important. (It should be ON, for those who might misunderstand what I am saying.)
It's always a balancing act between Practical Security and Practical Computing. Each environment is unique and I trust your expertise can balance this well. As you said, this increased protection and security is for some of your systems, not necessarily for all.
Good point. Maybe someone from McAfee can enlighten us as to the required/default included OS exclusions. However, that may divulge info that we may not entirely want in the open.
I personally don't need changes made to security software, simply because some other security software has a 'feature' to overcome it's inferior scanning. Others security software may need this feature, but in my humble opinion, VSE does not. Education may be the best solution. Otherwise, we placate the uninformed.
The point of my comments is that there are more than one Right answer and that I do not mean that my comments are The Right Answer. Quite to the contrary, I find these exchanges of perspectives valuable and only hope that my comments are taken constructively.
I find your comments valuable and I appreciate hearing what works for you.
Since opening up the topic "Automati scan of any external storage (aka USB stick)" I hoped that my perspective may be useful to some.
Thank you for your time and best regards,
We could, but we won't - for all the reasons mentioned above - it makes for an awful user experience and adds almost zero protection.
Data stored on a removable drive which is not read, might as well not exist.
The only reason to scan data you're not intending to read, would be to protect a subsequent reader of that data who was not protected by VSE - a "gatekeeper" function so to speak.
That can be achieved just by right-clicking on the stick and selecting "scan", before handing it on to a user who does not have VSE installed.
Much better for everyone though simply to have VSE installed everywhere.
It sounds like you're trying to create an exception to your exceptions - you've exempted some folders from realtime scanning but now you want those folders scanned on insert (which could take 30min etc..)
Much better just to revisit all your scan-on-read exceptions - they are probably for perceived performance reasons anyway, and as you mention - You're looking for increased security, not user experience.