Overview
Incydr complements the functionality of many security endpoint detection and response (EDR) applications. Typically these applications work seamlessly with Incydr and do not require any configuration changes.
However, if an EDR application generates a false positive alert that appears to be caused by Incydr, 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-Incydr products
Information about products from other manufacturers is intended as a resource to help you get the most out of our products. However, our Technical Support Engineers cannot provide direct assistance for these products. For assistance with products not developed by Incydr, contact the product's manufacturer.
Considerations
- The exact set of agent paths and files will change from release to release.
- The user detection execution during agent 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.
Incydr's EDR support policy
Incydr agents do 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 agent at deployment time. Tell them to refer to this article if they have questions.
- Do not proactively create exclusions for the agent.
If you encounter false positive alerts that appear to occur because of the agent, use this article to identify agent 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 Incydr folders.
EDR policies, practices, and configurations are very complex and subjective to each organization's goals, objectives and risk tolerance. While we are the expert on how our agent 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 our goal to dictate how to manage other vendors' products.
Why might Incydr generate EDR false positive alerts?
The agent requires full disk access, reads many files, and auto-updates itself. These are all valuable features that enable Incydr 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 agent as malware or a virus, but Incydr 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 Incydr activity as approved and trusted behavior, or it may incorrectly generate more alerts.
False positive alerts are not unique to the agent. 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 Incydr, you may be able to use them as a template for responding to alerts and applying exceptions for the agent.
Add EDR exceptions
If you decide to create exceptions in your EDR applications, use the following guidelines.
Insider risk agent
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 Incydr 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 versionsThe 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,
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 environment.
Insider risk agent 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:
- Version 1.9.0 and later: C:\ProgramData\Code42-AAT\logs\
- Version 1.8.x and earlier: 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:
- Version 1.9.0 and later: /Library/Application Support/Code42-AAT/logs/
- Version 1.8.x and earlier: /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:
- Version 1.9.0 and later: /var/opt/code42-aat/logs/
- Version 1.8.x and earlier: /var/opt/code42-aat/data/logs/
-
Process name: Code42 AAT Service
-
Executable name: code42-aat
Backup agent
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 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.
Add EDR exceptions for the 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 backup 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 backup agent bundle or executable. This method cryptographically proves Incydr 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 backup 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 agent versionsThe criteria used for each type of exception above can change when a new agent version is released. To help you prepare for upcoming changes,
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 environment.
Add EDR exceptions for backup archives and caches
Exclude the backup 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 backup agent operations. They only contain information about backup activity, and therefore they can be ignored by scans.
Add backup exclusions for EDR cache files
As EDR tools scan user devices, they create cache files. Depending on your backup file selection, the agent 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 the backup agent'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 Incydr 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 environment.
- Click Save.
Restore considerations
Restoring a large number of files might cause your EDR program to examine each file as it's restored. This causes your restore job to take longer than usual. To speed up the restore, consider temporarily pausing the EDR application.
Backup agent 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 agent 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 |
| agent configuration file |
/Library/LaunchDaemons/com.code42.service.plist
|
| Identity file |
/Library/Application Support/CrashPlan/.identity |
If the agent 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 |
| agent configuration file |
/usr/local/crashplan/bin/run.conf |
| Identity file |
/var/lib/crashplan/.identity |