CrashPlan complements the functionality of many security endpoint detection and response (EDR) applications. Typically these applications work seamlessly with CrashPlan and do not require any configuration changes.
However, if an EDR application generates a false positive alert that appears to be caused by CrashPlan's software, use this article to determine whether you need to create any exceptions in your EDR.
Example endpoint detection and response (EDR) applications include: Carbon Black, CrowdStrike, ESET, Kaspersky, McAfee, SentinelOne, Sophos, and Symantec. For consistency, the term EDR tools is used throughout this article to describe these types of applications, and includes antivirus applications.
Information about products from other manufacturers is intended as a resource to help you get the most out of CrashPlan products. However, our Customer Champions cannot provide direct assistance for these products. For assistance with products not developed by CrashPlan, contact the product's manufacturer.
- The exact set of CrashPlan paths and files will change from release to release.
- The user detection execution during CrashPlan app deployment can trigger an alert for some systems (due to a shell execution in PowerShell or batch script). User detection only occurs during deployment and has several mitigations that do not require setting global exceptions. For help with CrashPlan app deployment, contact your CSM to engage our Professional Services team.
CrashPlan's EDR support policy
The CrashPlan app does not require specific exceptions or configuration in EDR tools in order to function. Most of our customers run it this way. Your best practice is to:
- Inform your security and endpoint management teams about the CrashPlan app at deployment time. Tell them to refer to this article if they have questions.
- Do not proactively create exclusions for the CrashPlan app.
If you encounter false positive alerts that appear to occur because of the CrashPlan app, use this article to identify CrashPlan file paths and executable names. Then use that information to help you decide if you need to create any exceptions based on the specific event in your environment. Avoid adding wholesale exceptions for all CrashPlan folders.
EDR policies, practices, and configurations are very complex and subjective to each organization's goals, objectives and risk tolerance. While CrashPlan is the expert on how our CrashPlan app is packaged, distributed, and how it operates at runtime, we cannot advise on other solutions. We can assist in diagnosing legitimate behavior, but it is not CrashPlan's goal to dictate how to manage other vendors' products.
Why might CrashPlan generate EDR false positive alerts?
The CrashPlan app requires full disk access, reads many files, and auto-updates itself. These are all valuable features that enable CrashPlan to provide continuous backup. However, these activities may initially be identified as suspicious behavior by EDR tools that use heuristics and machine learning to augment content definitions and policy.
In most cases, EDR tools don't necessarily categorize the CrashPlan app as malware or a virus, but CrashPlan activity without context may appear suspicious enough to generate an alert the first time it occurs. Depending on how your EDR tool is configured and how you respond to the initial alert, the tool may learn to correctly categorize CrashPlan activity as approved and trusted behavior, or it may incorrectly generate more alerts.
False positive alerts are not unique to the CrashPlan app. Many other endpoint applications are subject to this same scrutiny by EDR tools and may require administrator action upon initial installation or after an upgrade. If other endpoint applications in your environment require similar permissions as CrashPlan, you may be able to use them as a template for responding to alerts and applying exceptions for the CrashPlan app.
Add EDR exceptions
In some cases, even known and expected activity may cause events and alarms in some EDR tools. If a detection or alert is a false positive that appears to be caused by the CrashPlan app, consult the documentation from the EDR vendor and use it to craft a minimal exception for the triggering behavior on a case-by-case basis, as opposed to broad visibility exclusions.
If you decide to create exceptions in your EDR applications, use the following guidelines.
Add EDR exceptions for the CrashPlan app
Most EDR tools allow you to create exception policies to suppress alerts for specific behaviors or trusted applications. Common criteria for defining exception policies include:
- File hash: Uses the hash value of the CrashPlan app executable file. This is generally the most secure and restrictive approach, because it uses a file hash for a specific instance of an executable file. However, since the hash changes with each new CrashPlan app patch or update, this method requires ongoing maintenance.
Digital signer: Uses the thumbprint, hash, or common name of the signing certificate for the CrashPlan app bundle or executable. This method cryptographically proves CrashPlan built and signed the application, regardless of its file name, version number, or file path location on the endpoint.
Note: The CrashPlan app uses documented best practices for signing our application. For Windows, binaries are signed with Authenticode consistent with the requirements for Windows and AppLocker. For Mac, digital signing, including app notarization, is implemented consistent with the requirements for Gatekeeper.
- File path or pattern: Uses the CrashPlan app file path, directory, or related pattern. This is less likely to change with each CrashPlan app release, but still may change as new functionality, branding, or operating system changes occur. This method presents the greatest security risk, because trusting an entire directory or a file name without specifying a digital signature or hash provides the potential for untrusted applications to also be launched from that location. CrashPlan-specific file paths are listed below.
Your EDR tool may provide additional or different options for creating exception policies; consult with your EDR vendor and your own security team to construct appropriate policy and configuration to avoid excessive alerting.
Depending on your risk tolerance, create policies based on the most long-lived attributes you are willing to accept.
New CrashPlan app versions
The criteria used for each type of exception above can change when a new CrashPlan app version is released. To help you prepare for upcoming changes, CrashPlan's delayed client upgrade settings allow you to test new CrashPlan app versions on a small group of devices to make sure your exception policies are up-to-date.
By testing a small group of devices first, you can respond to alerts and adjust your EDR policies as necessary before updating all users in your CrashPlan environment.
Add EDR exceptions for CrashPlan backup archives and caches
Exclude the CrashPlan archive and cache files from EDR monitoring. It's not useful to include these files because:
- Backup archives are compressed and encrypted. Even if a backup archive contains a malicious file, EDR software cannot inspect the contents of an archive. Furthermore, malicious files cannot activate or spread while in a compressed and encrypted form. Most importantly, backup archives only contain data that is already stored elsewhere. To detect malicious files, scan the source, not the backup archive.
- Cache files are benign records of CrashPlan operations. They only contain information about CrashPlan activity, and therefore they can be ignored by scans.
Add CrashPlan backup exclusions for EDR cache files
As EDR tools scan user devices, they create cache files. Depending on your backup file selection, CrashPlan may attempt to back up these cache files. Exclude these cache files from your selection because:
- The need to restore these cache files is very unlikely.
- EDR tools might attempt to scan CrashPlan's cache files of their cache, which causes an endless loop.
To exclude the cache from your backup:
- Consult your EDR tool's documentation to find the app's cache location.
- Sign in to the CrashPlan console.
- Go to Administration > Environment > Organizations.
- Verify that the Use device defaults from parent setting is enabled for all of the organizations under the parent.
- Select the parent organization.
- Click the action menu, and choose edit.
- Click the Backup tab.
- Use the File Selection settings to exclude the cache location for all devices in your CrashPlan environment.
- Click Save.
Restoring a large number of files might cause your EDR program to examine each file as CrashPlan restores it. This causes your restore job to take longer than usual. To speed up the restore, consider temporarily pausing the EDR application.
CrashPlan file paths
To create exceptions based on file paths or directories, selectively allow activity from these locations:
|Service log files||C:\ProgramData\CrashPlan\log|
|UI log files||
If the CrashPlan app is installed per user, exclude these folders instead.
|Service log files||/Library/Logs/CrashPlan|
UI log files
To view this hidden folder, open the Finder, press Command-Shift-G, and enter the folder path.
|CrashPlan app configuration file||
|Identity file||/Library/Application Support/CrashPlan/.identity|
If the CrashPlan app is installed per user, exclude these folders instead.
|Service log files||/usr/local/crashplan/log|
|UI log files||
|CrashPlan app configuration file||/usr/local/crashplan/bin/run.conf|
CrashPlan configuration files
To view this hidden folder, open a file browser and paste the path in the address bar. If you installed per user, see the file and folder hierarchy for file locations.
Mac: /Library/Application Support/CrashPlan/conf/
If you installed per user, see the file and folder hierarchy for file locations.
- Linux: /usr/local/crashplan/conf