Overview
Code42 complements the functionality of many security endpoint detection and response (EDR) applications. Typically these applications work seamlessly with Code42 and do not require any configuration changes.
However, if an EDR application generates a false positive alert that appears to be caused by Code42's software, use this article to determine whether you need to create any exceptions in your EDR.
Third-party applications
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.
Non-Code42 products
Information about products from other manufacturers is intended as a resource to help you get the most out of Code42 products. However, our Technical Support Engineers cannot provide direct assistance for these products. For assistance with products not developed by Code42, contact the product's manufacturer.
Need help?
For assistance, contact your Customer Success Manager (CSM) to engage the Code42 Professional Services team. If you don't know who your CSM is,
contact our Technical Support Engineers.
Considerations
- The exact set of Code42 paths and files will change from release to release.
- The user detection execution during Code42 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 Code42 app deployment, contact your CSM to engage our Professional Services team.
Code42's EDR support policy
The Code42 app does not require specific exceptions or configuration in EDR tools in order to function. Your best practice is to:
- Inform your security and endpoint management teams about the Code42 app at deployment time. Tell them to refer to this article if they have questions.
- Do not proactively create exclusions for the Code42 app.
If you encounter false positive alerts that appear to occur because of the Code42 app, use this article to identify Code42 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 Code42 folders.
EDR policies, practices, and configurations are very complex and subjective to each organization's goals, objectives and risk tolerance. While Code42 is the expert on how our Code42 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 Code42's goal to dictate how to manage other vendors' products.
Why might Code42 generate EDR false positive alerts?
The Code42 app requires full disk access, reads many files, and auto-updates itself. These are all valuable features that enable Code42 to provide continuous monitoring. 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 Code42 app as malware or a virus, but Code42 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 Code42 activity as approved and trusted behavior, or it may incorrectly generate more alerts.
False positive alerts are not unique to the Code42 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 Code42, you may be able to use them as a template for responding to alerts and applying exceptions for the Code42 app.
Add EDR exceptions
If you decide to create exceptions in your EDR applications, use the following guidelines.
Incydr Professional, Enterprise, Horizon, and Gov F2
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 insider risk agent, 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.
Temporary files
The insider risk agent creates temporary data files within its directories as it executes, and may also use Volume Shadow Copy Service (VSS) to access locked files on Windows.
Add EDR exceptions for the insider risk agent
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 insider risk agent 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 patch or update, this method requires ongoing maintenance.
- Digital signer: Uses the thumbprint, hash, or common name of the signing certificate for the insider risk agent bundle or executable. This method cryptographically proves Code42 built and signed the application, regardless of its file name, version number, or file path location on the endpoint.
Note: We use documented best practices for signing our applications. 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 insider risk agent file path, directory, or related pattern. This is less likely to change with each 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 also to be launched from that location.
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.
Test new insider risk agent versions
The criteria used for each type of exception above can change when a new insider risk agent version is released. To help you prepare for upcoming changes,
Code42's delayed client upgrade settings allow you to test new 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 Code42 environment.
Code42 file paths
To create exceptions based on file paths or directories, selectively allow activity from these locations:
Windows
- Application: C:\Program Files\Code42-AAT\
- Application data: C:\ProgramData\Code42-AAT\
- Logs: C:\ProgramData\Code42-AAT\Data\logs\
- Process name: Code42 AAT Service
- Executable name: Code42-AAT.exe
Mac
- Application: /Applications/Code42-AAT.app/
- Application data: /Library/Application Support/Code42-AAT/
- Logs: /Library/Application Support/Code42-AAT/Data/logs/
- Process name:
- Launcher: Code42 AAT Service
- System extension: com.code42.agent.extension
- Executable name: Code42-AAT
Linux
- Application: /opt/code42-aat/
- Application data: /var/opt/code42-aat/
- Logs: /var/opt/code42-aat/data/logs/
- Process name: Code42 AAT Service
- Executable name: code42-aat
Incydr Basic, Advanced, and Gov F1
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 Code42 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.
Add EDR exceptions for the Code42 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 Code42 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 patch or update, this method requires ongoing maintenance.
- Digital signer: Uses the thumbprint, hash, or common name of the signing certificate for the Code42 app bundle or executable. This method cryptographically proves Code42 built and signed the application, regardless of its file name, version number, or file path location on the endpoint.
Note: We use documented best practices for signing our applications. 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 Code42 app file path, directory, or related pattern. This is less likely to change with each 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 also to be launched from that location.
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.
Test new Code42 app versions
The criteria used for each type of exception above can change when a new Code42 app version is released. To help you prepare for upcoming changes,
Code42's delayed client upgrade settings allow you to test new 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 Code42 environment.
Add EDR exceptions for Code42 backup archives and caches
Exclude the Code42 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 Code42 operations. They only contain information about Code42 activity, and therefore they can be ignored by scans.
Add Code42 backup exclusions for EDR cache files
As EDR tools scan user devices, they create cache files. Depending on your backup file selection, Code42 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 Code42'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 Code42 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 Code42 environment.
- Click Save.
Restore considerations
Restoring a large number of files might cause your EDR program to examine each file as Code42 restores it. This causes your restore job to take longer than usual. To speed up the restore, consider temporarily pausing the EDR application.
Code42 file paths
To create exceptions based on file paths or directories, allow activity from these locations:
Windows
| Use |
Folder |
| Main application |
C:\Program Files\Code42
|
| Service log files |
C:\ProgramData\CrashPlan\log |
| UI log files |
C:\Users\<USERNAME>\AppData\Local\CrashPlan\log
|
| Transient caches |
C:\ProgramData\CrashPlan\cache |
| Identity file |
C:\ProgramData\CrashPlan\.identity |
If the Code42 app is installed per user, exclude these folders instead.
Mac
| Use |
Folder |
| Main application |
/Applications/Code42.app/
|
| Service log files |
/Library/Logs/CrashPlan |
|
UI log files
|
~/Library/Logs/CrashPlan
To view this hidden folder, open the Finder, press Command-Shift-G, and enter the folder path.
|
| Transient caches |
/Library/Caches/CrashPlan |
| Code42 app configuration file |
/Library/LaunchDaemons/com.code42.service.plist
|
| Identity file |
/Library/Application Support/CrashPlan/.identity |
If the Code42 app is installed per user, exclude these folders instead.
Linux
| Use |
Folder |
| Main application |
/usr/local/crashplan |
| Service log files |
/usr/local/crashplan/log |
| UI log files |
~/.code42/logs
|
| Transient caches |
/usr/local/crashplan/cache |
| Code42 app configuration file |
/usr/local/crashplan/bin/run.conf |
| Identity file |
/var/lib/crashplan/.identity |
