Is it acceptable to exclude folders in antivirus?

Question

A technical problem has arisen, and the vendor's first suggested solution is to exclude the program's folders from our antivirus. There are multiple reasons I am hesitant to do so:

1. Primarily: If a malicious file finds its way into those folders, either via vendor patching or unrelated actions, said file will be ignored by the antivirus whereas it may otherwise have been immediately neutralized.
2. We currently only exclude specific files by their SHA256 hash. This program set, however, contains far too many files for this to be feasible.
3. This can not be scalable. If we excluded every folder for every approved application, the threat surface would be colossal.

And so forth. In this specific instance, it's something we can do for a specific set of machines to test. The situation did bring forth the general question, however I'm curious to know what the larger community thinks about when is it acceptable to exclude folders in antivirus, and why? The short answer, I would argue, is "as little as possible" for the reasons I listed above and more, but I came to realize that I can't think of a single scenario where it would be a good idea. The functionality is common in antivirus applications, which suggests that there are legitimate reasons to do so, but I can't think of an instance where we would want to leave an entire folder free to become infected.

I struggle to put this into precise words, but it feels like violating some analogue to the least-trust principle -- it'd be a lot smoother day-to-day to give all employees full admin access to everything, until it goes horribly wrong; similarly, it'd be really easy to just exclude folders from antivirus at the first sign of false positive, until that backfires when there really is something malicious in there.

Are there examples I'm not thinking of where it really is the best solution, where this would be the advisable choice? Example scenarios and research are welcome.

Answer 1

Ah yes, ye olde problem of security tools making a system unusable. My arch nemesis.

when is it acceptable to exclude folders in antivirus, and why?

Short answer:

There's an old adage on this site that "Security at the expense of usability comes at the expense of security" -- ie if your security controls make a system unusable, then people will find cheeky ways around your controls (like CTRL+ALT+DEL killing the anti-virus agent, or doing their work on a machine that does not have the AV installed), often resulting in bigger security holes than what you were trying to prevent in the first place.

Not to mention that an entire company's worth of lost productivity due to fighting with sec tools can add up to be as expensive as the breach they're trying to prevent. Remember that the goal of infosec is to add value to the company's bottom line; if you hurt productivity too much then you're actually doing tho opposite.

Dialing back security tools so that people can actually get their jobs done is often necessary. Examine your options, do some trials with a few volunteers, and then re-engage the tool in a less disruptive way.

---

Longer answer:

Primarily: If a malicious file finds its way into those folders, either via vendor patching or unrelated actions, said file will be ignored by the antivirus whereas it may otherwise have been immediately neutralized.

And of course if it becomes known that this folder is excluded, then malicious files may intentionally find their way there!

We currently only exclude specific files by their SHA256 hash. This program set, however, contains far too many files for this to be feasible.

This can not be scalable. If we excluded every folder for every approved application, the threat surface would be colossal.

Some options to consider:

• If those application folders are super locked down (like read-only by local accounts, writable only by some domain super user account), and you AV those applications before deploying them, then maybe excluding the whole folders is reasonable.
• Many AVs now support code-signing-based allow lists. So for example at the time that you approve Firefox, you could add Mozilla's code signing cert to your allow list. This approach has drawbacks because not all vendors code-sign, and just because you trust one app from a given vendor, you may not want to trust everything they produce.
• Keep an in-house code-signing CA to sign files that you want the AV to ignore. That way the AV's allow list consists only of your in-house CA. This still has the drawback that you can only codesign binaries, so if the AV is causing problems with config and data files then this won't help.

Answer 2

It is often necessary if performance matters.

I work in HPC, developing software for computer simulations of chemical processes. Just like the vendor you're talking about, we would often recommend our Windows users to add the directory of our SW to the antivirus exclusion list. Why? Because it's the only reasonable response to any support question along the lines of "I just noticed my calculations are twice as slow on Windows than they are on Linux on the same machine. What gives? Please kindly fix your software."

Just like your vendor, we distribute something that consists of tens of thousands of files of all sorts, totaling over 6 GiB in a fresh base install. When you start a calculation, the antivirus will typically decide to scan all those files, which understandably takes ages (and it also often does it synchronously, so our application just has to sit there waiting for the antivirus to finish scanning one file, then work for a few microseconds and wait for another file, ad nauseam).

Also, running a calculation typically produces up to tens of gigabytes of files, some of which are scratch files that get rewritten over and over. Letting the antivirus scan all that easily slows everything down by a factor of two or more.

So in the end, it's up to the user to decide whether they prefer getting the results in 4 hours without an antivirus or next day with one.

Answer 3

One example I recall as a software developer is the exclusion of "build" folders. In these folders, the compiler creates new executables. New executables are of course suspect to virus scanners, and the build process also generates a lot of intermediate files. At the same time, quite often this disk I/O slows down the developers . Excluding these build folders will make developers a lot more productive.

What's the risk? Is this a good place for a virus to hide? Not exactly. These build folders are frequently cleaned out, if not removed altogether.

However, you should have a discussion with the developers about writing software installers. These installers should install only your own software; one of the biggest risks is that they unintentionally distribute a virus. The folders used to build the installer should absolutely be checked. But additionally the installer definition should be rather explicit. Don't include *.exe; your developers should know their own executables.

Answer 4

I've encountered a number of cases where excluding a folder was the right (or sometimes only) option. It shouldn't be your default solution to problems, but it does have legit use cases.

One of the most common cases is for directories that are used for short-lived temporary files. For instance, I have a system that runs an FTP server that handles large files. When a file gets written to the server, data gets incrementally saved to a specific working folder as is it transferred. After the transfer finishes, the chunks get assembled into the completed file and written to its intended location. Scanning the files in the staging folder is largely pointless because they aren't complete files (thus more likely something gets misinterpreted), plus they'll get scanned once they get saved to the destination directory. The directory permissions were locked down so that only the FTP server process could write to it, so the security risk was minimal and the performance improvements were very noticeable. Ignoring the directory is better than whitelisting the program because you do want the files scanned when the server writes them to their final destination.

Another case is directories that aren't really directories. If you create a symbolic link to a directory, that directory's contents will show up in two places. There's no need to scan the files twice, so you can ignore the linked directory. Most AV clients have an option to blanket ignore all symbolic links, but disabling this feature globally isn't always appropriate. Similarly, it's often desirable to ignore mounted folders (network drive that's mapped to a directory instead of a drive letter). If you know that directory points to a trusted internal server that has its own security software running, there's no need to scan it twice. In some cases, the local and remote virus scanners can step on each other's toes and cause problems if they both try to scan the directory at the same time. At a minimum, scanning a file across a network will be extremely slow.

And of course, don't forget that security software is not perfect. False positives will exist. The creator of a program that triggered a false positive can't always resolve the issue because they have no insight into how the AV is making decisions. Ignoring the directory for a trusted program is sometimes the only way to be able to use that program at all. This tends to be particularly true for rare, niche programs that AV vendors wouldn't reasonably have access to for testing. In cases like this, thoroughly vet the program and vendor manually.

The general thread running through these is that every directory doesn't need a virus scanner. Every directory needs protection, and an antivirus is just one of many tools that can provide that protection. Use whichever tool is the simplest and least disruptive for the case at hand.

Answer 5

From a software developers perspective there are a lot of good reasons to disable intrusive AV solutions. You should always look for the threats you actually try to prevent. For user machines the solution might be entirely different than for hardend server machines running just a single specialized application.

So yes, there are absolutely cases when excluding a folder is the only viable and valid solution short of uninstalling the AV solution or the application.

Performance is the first big issue. AV solutions increase the latency for all calls intercepted, be it filesystem, network, syscalls or others. If the product in use is sensitive to latency the AV system may turn it from useful to useless easily. Some people try to run a full fledged Oracle database with AV scanning on the redo log and data files. That fails in astonishing ways and can easily waste huge amounts of company money.

Reliability is another big issue. AV solutions make certain file operations fail hard and require the application to handle it, e.g. any file access needs to do a few retries for trivial stuff. That is especially troublesome for cross platform software that also runs on Unix/Linux where such troubles are basically non-existant. So if the application tries to delete a folder and recreate it right away: AV has a race with the app and breaks it. Or the application tries to write a file and rename it right away, common pattern for atomic write. AV has a race with the app and breaks it. So the app needs to be coded as if running in a hostile environment.

AV solutions that inject random code into applications to hook APIs are also a great joy to work with. First it might trigger any anti-debug or integrity check features of the app, and break. Then it might wreak havok with a nice memory layout by placing its code right in the middle of the address space. Or it might even make any crash dumps unusable by breaking the global crash dump handlers, because the AV vendor considers his crash dumps to be more valuable than app crash dumps.

Answer 6

Just a few thoughts.

With exclusions, you really need to be clear as to why you are making an exclusion and is it the correct type for the security solution installed. Exclusions in one security product can mean something totally different in another.

Scenario for an issue:

C:\app1\Process1.exe repeatedly writes to C:\p1\temp\filex.dat.

The issues here could be:

1. Performance, as C:\p1\temp\filex.dat is repeatedly written to and potentially changing, then depending on the security product, as the file is closed/opened, this could result in a scan of the file. A hash exclusion here is of a little use.
2. In the past, the vendor of the application has seen corruption or deletion of C:\p1\temp\filex.dat by either a false positive and they are therefore "protecting" their product and their support department to some extent from potential future issues by creating a generic knowledgebase article, without any real regard for security.

The options:

Assuming the performance issue is bad enough to take action and the security vendor agrees there is not much that can be done within the product given the behaviour, the best option here is likely a full path exclusion for real-time scanning C:\p1\temp\filex.dat. You could still scan this file as part of a scheduled/on-demand scan but then issue 2 could be a problem. The nature of the file excluded is of interest here.

Some vendors might lazily advise through an article for the above scenario: Exclude C:\app1\Process1.exe from scanning.

What does that actually mean for the security product you have?

• Don't scan the file C:\app1\Process1.exe? This wouldn't help.
• Don't track the behaviour of the process C:\app1\Process1.exe. It would be insecure to allow a process to run unchecked. What if a malicious module was loaded into the process? What about a supply chain attack where the product updated the file C:\app1\Process1.exe with one that has malicious functionality?
• Don't scan the files "touched" by C:\app1\Process1.exe - As above, you don't need to exclude all files the process touches in this scenario.
• Don't inject any modules into it? Security products tend to rely on drivers to inject modules into processes as they start. Will this still happen with this exclusion? What functionality of the solution does that break?
• What about hashing it for EDR/XDR purposes? It is quite likely scanning and EDR is handled by different parts of the solution such that exclusions could be handled differently. Is this what you want?
• What about if the process loads the AMSI.dll and pulls in the security vendors AMSI provider? Is this OK?

It maybe the security product being used doesn't even scan .dat files, so the file type can be significant. How do you know it's even being scanned by security vendor A? Process Monitor, log files of the security product? What size is the file, how complex is the file to scan?

The point being, you have to know both why you are making or being recommended to make an exclusion and what is the appropriate exclusion(s) in the security product you are running as they all implement exclusions differently. The second is very hard not least due to security products being under constant development.