The help file in the program contains the best answers to this question, so I'm going to link to the relevant sections in the answer below as well:

 

1. PC Security... Quarantine... Detection Configuration

- If it was set to Allow in this area, it ignores it during scans and shield actions, meaning if it's a virus that has been allowed, it can continue acting as a virus acts.

 

2. Identity & Privacy... Protected Applications

- Setting it to Allow in this area means it's not protected against things like keyloggers.  Some programs do not access sensitive data on the system so they don't show up in this list at all.  Other programs might inadvertantly access such data.  This is the setting that causes the padlock to show up when you are using a protected application.  If you trust a program with the contents of that data, you can allow it.

 

3. System Tools... System Control... Control Active Processes

- Allowing it here means it's allowed to run at all.  Whereas if you monitored it, it would journal what that program is doing and keep a very close eye on it for any suspicious activity.  Basically it would treat it as if it wasn't already sure about it one way or the other.  It's important to note that if an item is already Allowed here, that's because Webroot knows already from seeing the file before that it's ok to Allow.  If it was set to Block, it couldn't run.

---

Thanks!



If I want to set exclusions between the security products on my computer, I would set it in the PC Security... Quarantine... Detection Configuration.



For MS Security Essentials v4 (current version), what is the executable(s) would I be excluding - MsMpEng.exe, msseces.exe, or both?



For Webroot SA, WRSA.exe is the executable for exclusion within MS Security Essentials?



Reason I'm thinking of doing this is that when I was trying to get rid of Smart HDD malware from my brother's computer, I let Malwarebytes Free do it's thing when I ran it on-demand, and when rebooting to finish its cleanup, I think MSSE was interfering with the cleanup process by giving it's own warnings...

 

--Patrick  

---

While you could do what you're talking about doing, there really isn't any good reason to do that unless Webroot is already false-positiving on MSE.  Detection Configuration would be useful in correcting such an FP locally if one were to occur.  Apart from that however, pre-emptively whitelisting a program we already know not to mess with would not be a useful action.  One of the best things about Webroot is that it already knows who the good guys are.  It should not be interfering with MSE, Malwarebytes, or any other legitimate anti-virus solution.

 

The situation you're describing sounds like MSE was blocking something Malwarebytes was doing, but I'm not really sure how that relates to anything Webroot was doing or if Webroot is on that computer at all yet.  Could you explain why you think Webroot was involved in that problem?  Also, is the Smart HDD malware still present?  If you haven't tried running Webroot on the infected computer yet, you could always download a trial for your brother.

 

To answer your questions however, both of the names you provided for MSE are associated with MSE, and yes WRSA.exe is Webroot.

---

The situation I was describing is not related to Webroot since it happened on my brother's machine last month and as a result of having him take it to Best Buy and getting it cleaned up from the malware, and they installed Webroot as a new antivirus solution as part of the maintenance package he subscibed to.  Which in turn got me to trying WSA out and getting a subscription for WSA Complete so it can also protect my Android tablet :)

 

But it did get me thinking about setting up exclusions since what happened to medical practices using an Electronic Medical Records (EMR) application that we also use.  A couple of years ago an antivirus vendor (begins with an A) had a signature database update that deleted / quarantined one of the key files of the EMR - I think it was a srvany.exe file.  So the system was down, doctors and staff at a standstill since they can not setup appointments and view patient's medical records, and the vendor's support line was innundated with calls.  

 

For a couple of hours everyone didn't know what was going on but those looking at the user forum for the application, the common denominator was that they all were using the same antivirus from a specific vendor and the scenario started from the database update. They mentioned it to the EMR vendor's tech support and antivirus vendor.  It took a minimum half a day for those affected to "fix" it manually via the vendor's tech support or small practices calling in a tech support firm to fix it.  The antivirus vendor also ended up releasing a database signature update later on in the day to resolve it.

 

So once that was done, practices have now been setting antivirus exclusions on the EMR's application's folder to prevent the drastic effect on the business as a result of false positives on their key application software.   Which is one of the reason why there should be a folder based exclusion since most people would not know specifically what to exclude. 

 

 

--Patrick

 

 

 

---

That's a fascinating story, and given your experience, I can see why you would want to preemptively whitelist those files.  Sadly, what you're trying to do doesn't work as you may presently think it does.  If you were to go into Webroot right now, whitelist every file associated to your program (which is presumably not already having troubles at the moment), and then the program updates tomorrow, you will essentially have a whole new set of files Webroot is going to see on write and on execution.  They may have the same naming convention, but at their core the code is different.  Thus they are treated as wholly separate entities due to their unique file signatures.  By the time you open the Webroot settings screen to go whitelist those new files, Webroot would have already quarantined the files in question if it was going to do so because it scans the files when they are written to the hard drive.

 

Regarding whitelisting based on a name or whitelisting an entire directory, it is very common for a virus to give itself a name that is normally a good name.  I used to see this quite a bit with iexplore, svchost, and csrss just to name a few.  Usually those files are fine.  However, if a lazy anti-virus program declares "All instances of iexplore are fine!" that means all a crafty virus has to do is name itself iexplore to get by that piece of software.  Similarly, if you whitelist an entire directory, a crafty virus might try to insert itself into every directory on your computer until it lands in one that isn't protected due to whitelisting.

 

The question in a case like this is "Is my anti-virus software going to false positive on my medical software more often than it is going to pick up a threat that could land in that directory?"

 

With "company A," that may have been the case.  With Webroot, that's not very likely.  Our heuristics models are smart enough to know the difference between a harmless new program and a dangerous new program.  A lot of anti-virus programs on the other hand just see "NEW FILE!" and quarantine it "to be on the safe side," which is also often "the annoyingly over-protective and obtrusive side" for them.  And worst case scenario, assuming you did need to call, just to give you an idea of how often people need to call support here, our call queue hit 0 at least twice this morning already, so we are well-equipped to take that call in the unlikely event you ever needed to ring in.

---

Adding a little bit of related extra information.

 

First thing of note is that we have seen threats in the wild that actively seek excluded folders or files to get their foothold from.  This just goes to show that not only is making exclusions a security hole, but it's actively exploited.  That is why we don't allow excluding things by folder.

 

The second thing of interest is the control an admin has over the Business version of SecureAnywhere.  Let's take the theoretical case where an update starts to come in for the EMR software in a 50-computer organization, say, to three or four computers at a time, and SecureAnywhere hits an FP on it and quarantines it.  An admin can be alerted to the perceived infections in realtime, even via external sources like email, and evaluate the activity immediately.  A quick observation that it's the update to the EMR software and the admin can immediately and simultaneously whitelist it across all SecureAnywhere systems on the business license as well as restore it from quarantine on all machines that have already been affected.  All this from anywhere on the internet.

 

And the final thing that is quite nice is that our threat research teams can work wih any business to create custom psuedo-whitelist solutions for their specific circumstance that doesn't blindly ignore everything in a folder or with a specific name.  These solutions will still check the files for known malware, but they will evaluate unknowns based on specific rules and intelligence that allows them to be given more leeway specifically in that business environment.  It's even smart enough that if somebody like a developer abuses this to try to get a threat whitelisted by us, the moment it misbehaves outside their environment, it's killed globally anyway and can be traced back to its origin.

 

Whitelisting is a very insecure way to solve a problem.  It's like leaving a key under the doormat with the idea that "Anybody who knows to look under the mat is whitelisted to enter the building".  Sadly, thieves can easily take advantage of this "whitelisting", just like threats currently take advantage of traditional AV whitelisting.  True, our method is slightly more complex, and requires a moment of thought, but it's more like giving a personal key to people who really should have access.  The security improvement is tremendous.

---

In the EMR vendor's case, at least back then, they were using srvany.exe to help them run one of their programs as a service.



I looked back at the EMR user thread back from 2008 and about a year before I was experimenting how to use srvany.exe since it was mentioned by Microsoft as a utility available in their Windows Resource Kit.



Since I was using the free version of the antivirus "A", I did get the pop-up that morning and attributed it to a false positive. After all, it was on my personal computer for awhile and have not been using it, I do not have the EMR software, and I got the srvany file from the Windows Resource Kit itself. It's only when I was on the EMR user forum a few hours later there was an active topic of the EMR vendor software having a virus.



Unfortunately, once it was determined it was isolated to a particular antivirus vendor, some businesses particularly small ones with no IT had the EMR vendor get them up and running ASAP and as a result, the antivirus was turned off so that the EMR vendor can remotely replace back their file, and with instructions to turn the antivirus back on when the anti-virus vendor released an updated signature db.



So I agree with you that we all should do as much as possible for security. But people are people and alot of times we accept various levels of risk. I still see people writing down passwords near their computers, people talking on their phone or texting while driving, router passwords are still from the manufacturer default...



Since I am a recent user of WSA, I have been reading alot on the WSA and Wilders Security forums just to get a handle of how your approach differs from the traditional one. I'm getting more and more confident of WSA's capabilities in additional of learning how certain settings work.



--patrick

---

WebRoot needs to support both.  Unfortunately it either doesn't... or the feature is so well hidden... that no one can ever find it.

 

1. Whitelist a file based on its full path and filename... regardless of how many times it changes or is updated.

2. Whitelist a file based on its internal datestamp, size, checksum, etc (Or whatever method WebRoot uses.)

 

Without support for #1... I was unable to EVER convince any of the dept heads at my company to EVER use WebRoot 2013.

 

Programs change.  People update their files.  #1 is *VERY* much needed.  Without it... every executable that is ever updated renders the whitelist totally useless.  WebRoot *AGAIN* marks the file as quarantined, again deletes it, you have to again undelete it, then re-re-re-re-re-re-add it to the whitelist again and again forever.  Ugh.

 

Who never updates any of their programs, anywhere on their system????

 

---

Should -never- happen for exactly the reason you point out: If the file changes, it may not be considered safe anymore. Keep in mind that "legitimate updates" are not the only thing that will change a file.



There also seems to be a misunderstanding that "Changed file will get quarantined". It shouldn't unless it is actually bad. Otherwise, it just spends a short time being monitored, which has no detrimental effect on properly-written software. Anything that is not a legitimate threat should never have to spend more than a day (or even more than a few hours) on the whitelist, since any false positives pointed out to Threat Research are handled centrally.



So, in reality, "without #1", every executable that is ever updated is usually whitelisted globally before you even get the update. To have otherwise would have thousands of people complaining on this forum that their Firefox updated and was quarantined, for example.



Knowledge is power, and the more you have, the more power you have. If your lack of ability to convince anybody at your company to use Webroot was due to both them and you having the misunderstanding and impression that "all changed files get quarantined", then that was simply an error on your part. While it costs Webroot a bit, sadly it ends up costing you and the company you work for more as you are stuck using something inferior. But now you know.

---

Whitelisting everything in a path is not required for antivirus that is based around protecting against execution like WSA, rather than scanning every file regardless of type with large sets of AV signatures.



 

False positives should pretty much never be an issue on end-user systems and if they are you should investigate why with the help of support.

 

The only use case for blind whitelisting I found in a year and a half of running WSA across 1400 clients is for application developers. However, I've been able to change policies in WSA and recommend certain practices to the engineers to make false positives much less of an issue. I do want the ability to whitelist and I am a little miffed it's still not a feature in their enterprise product.

 

So while I agree with you that these whitelisting features are needed, I do not think they should be used in ways to compromise the quality of protection when something else seems to be going on. I highly encourage you to get with support because your experience with false positives is not normal based on my experience.

---