PDF(126.9 KB) View with Adobe Reader on a variety of devices
ePub(91.8 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(80.6 KB) View on Kindle device or Kindle app on multiple devices
Updated:March 23, 2022
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the best practices to locate and create exclusions on the Secure Endpoint.
Contributed by Caly Hess, Mathew Huynh and Matthew Franks, Cisco Engineers.
Cisco recommends that you have knowledge of these topics:
Access to the Secure Endpoint portal
Account with administrator privileges
A working knowledge of the customer environment.
The information in this document is based on Windows, Linux and MacOS operating systems.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
How to understand Exclusions
An exclusion set is a list of directories, file extensions, or threat names that you do not want the Secure Endpoint Connector to scan or convict. Exclusions are a necessity to ensure a balance of performance and security on a machine when endpoint protection such as Secure Endpoint is enabled. This article describes exclusions for Secure Endpoint Cloud, TETRA, SPP, and MAP.
Every environment is unique as well as the entity which controls it, varying from stringent to open policies, where the latter would be classified as a honeypot. As such exclusions are defined must be uniquely tailored to each situation.
Different exclusions can be categorized in two ways, obvious exclusions and indistinct exclusions.
Obvious Exclusions are exclusions that have been created based on research and test for commonly used operating systems, programs, and other security software. These exclusions can be found on the Cisco-Maintained Exclusion List in your console.
Note: It is recommended to contact other Anti-Virus (AV) vendors and request their recommended exclusions to be added, this ensures the Secure Endpoint and AV to function in tandem also minimize performance impact.
It is recommended to create a duplicate policy to avoid business security concerns and disruptions to identify Computers with performance issues indicators and separate them into a group to use this duplicate policy.
Caution: Configuration changes on the dashboard requires time to allow connectors to sync the policy. Please allow for a heartbeat update or manually sync the policies on the connectors.
Select from the drop-down menu for the operating system.
Provide it a meaningful name to allow you to distinguish this policy and description (optional).
Select the policy actions to your requirements, use the default exclusions for now.
Important In Advanced Settings > Administrative Features, set the Connector log level to Debug.
Click Save to complete the policy creation.
Secure Endpoint Console > Management Tab > Groups
Click on Create Group
Provide it a meaningful name to allow you to distinguish this group and description (optional).
Select the duplicate policy you have created.
Click Save to complete the group creation.
How to identify Exclusions
After the duplicate policy and group creation,with the debug log level on the connectors run the Computers as per normal business operations. Allow time to obtain sufficient connector log data while programs and processes have been accessed, generate a support diagnostic bundle to review and identify exclusions.
Guide to create diagnostic bundles for different operating systems available:
Extract the compressed debug diagnostic bundle. The file fileops.txt lists the paths where files create, modify and rename activities triggered Secure Endpoint to perform file scans. Each path has an associated count that indicates how many times it was scanned and the list is sorted in descending order. While a high count does not necessarily mean the path should be excluded (e.g., a directory that stores e-mails may be scanned often but must not be excluded), the list provides a starting point to identify exclusion candidates.
Windows operation system is more complicated, more exclusion options are available due to the parent and child processes. This indicates that deeper review is required to identify the files which had been accessed, but also the programs which generated them. Please refer to this Windows Tuning Tool from Cisco Security’s GitHub page to obtain more details about how to analyze and optimize Windows performance with Secure Endpoint.
How to create Exclusions
This section covers the best practices to write exclusions for your environment.
Caution: Always understand the files and processes before writing an exclusion to avoid security vulnerabilities to the computer.
Note: Additional details available in the User Guide, Review Chapter 3 Here. This chapter covers the types of exclusions, implementation, and navigation of the Secure Endpoint portal.
CSIDL Path and Process
CSIDL is an accepted and encouraged way to write exclusions. CSIDL allows for process exclusions that can be acknowledged in environments that use alternate drive letters and can bypass the need for wildcard when that path is user-specific (as process exclusions do not allow for wildcard). More information about CSIDL . There are limitations, however, that need to be considered when CSIDL is used. If your environment installs programs on more than one drive letter, the CSIDL path only refers to the drive marked as the default installation location, e.g., if the OS is installed on C:\ but the installation path for Microsoft SQL was manually changed to D:\, the CSIDL based exclusion in the maintained exclusion list does not apply to that path. For process exclusions, this means one exclusion must be entered for every process not located on the C:\ drive as the use of CSIDL does not map it.
These exclusions are the most frequently used, application conflicts typically involve the exclusion of a directory. Create a path exclusion using an absolute path or the CSIDL.
For example, to exclude an antivirus application in the Program Files directory, the exclusion path would be either:
Without a trailing slash, Windows connector does a partial match on paths, while Mac and Linux do not.
Example if you apply the following Path exclusions"C:\Program Files" and as "C:\test":
C:\Program Files and C:\Program Files (x86) are excluded:
C:\Program Files C:\Program Files (x86)
C:\test is excluded, as C:\test123:
You can change the exclusion from "C:\test" to "C:\test\", this stops "C:\test123" from being excluded.
Note: Path Exclusions are recursive and exclude all sub-directories as well.
These exclusions allow the exclusion of all files with a certain extension.
Expected input on the connector side is .extension
The Dashboard automatically prepends a period to the file extension if none was added.
Extensions are not case-sensitive.
For example, in order to exclude all Microsoft Access database files, you can create the following exclusion:
Note: Standard exclusions are available in the default list, it is not recommended to delete these exclusions, doing so may cause performance changes on your computers.
These exclusions are the same as path or extension exclusions except using an asterisk (*) character triggers as a wildcard.
Caution: Wildcard exclusion does not stop at path separators, this can lead to unintended exclusions. Example: C:\*\test excludes C:\sample\test as well as C:\1\2\3\4\5\6\test123.
Warning: Beginning an exclusion with an asterisk(*) can cause major performance issues. With 7.5.3+, the addition of Wildcard Process Exclusions caused additional performance issues with asterisk-leading exclusions. Please remove or change all exclusions in this format to mitigate cpu impact.
For example, exclude virtual machines on a MAC from being scanned, enter this path exclusion:
This exclusion only work for johndoe, to allow multiple user matches, replace the username in the path with an asterisk(*) to a wildcard exclusion:
Write an exclusion for paths that exists in separate drives.
Example: C:\testpath and D:\testpath are:
The system automatically generates the ^[A-Za-z] when "Apply to all drive letters" is check boxed after wildcard is selected from the Exclusion Type dropdown, as shown in the image:
Process Exclusions allow admins to exclude running processes from normal File Scans (Secure Endpoint Windows Connector version 5.1.1 and later), System Process Protection (Connector version 6.0.5 and later), or Malicious Activity Protection (Connector version 6.1.5 and later).
Process exclusion is done by either: specifying the full path to the process executable, the SHA-256 value of the process executable, or both the path and the SHA-256. Paths allow both direct paths or use a CSIDL value.
Caution: Child processes created by an excluded process are not included in the exclusion by default. Example: Process exclusion for MS Word would not exclude by default any additional processes created by Word.exe and would be scanned. To include additional processes, click the checkbox Apply for Child Processes. Furthermore, excluding Word.exe is not suggested as malware regularly hides in modern .docx files.
Note: Specifying both Path and SHA-256 are required both conditions to be met to exclude the process.
If the file size of the process is greater than the maximum scan file size set in your policy, then the SHA-256 of the process does not be computed and the exclusion does not work. Use a path-based process exclusion for files larger than the maximum scan file size
Connector versions 5.x.x to 6.0.3 - a limit of 25 process exclusions across all process exclusion type
Connector versions 6.0.5+ - limit of 100 process exclusions across all process exclusion types.
Connector versions 7.x.+ - limit of 500 process exclusions across all process exclusion types.
The connector only honor the process exclusions up to the limit, from the top of the process exclusions list in policy.xml
Every policy has a process exclusion for sfc.exe, which counts against the limit
These exclusions allow a particular threat name to be excluded from triggering events. Threat exclusion should only be used when the scan result triggers false-positive detection and confirmed that they are not an actual threat.
Text box to add a threat exclusion is notcase-sensitive. Example: W32.Zombies.NotAVirus or w32.zombies.notavirus both match the same threat name.
Warning: Do not exclude threats unless investigation and confirmation into the threat name is deemed to be false positive. Threats excluded are no longer populate in the events tab for review and audit.
Endpoint 7.5.3+ allows for additional exclusions using the Wildcard functionality within the Process exclusions. This allows for broader coverage with less exclusions but can also be dangerous if too much is left undefined. You should only use the wildcard to cover the minimum number of characters required to provide the needed exclusion.
Use of (*) in Process Wildcard for Windows:
(*) Can be used in place of a single character or a full directory. It cannot be placed at the beginning of the path, it will be ruled invalid. The wildcard will work between two defined characters, slashes or alphanumeric. Placing it at the end of a path will exclude the processes in that directory but not subdirectories.
(**) Can be used at the end of a path to exclude all processes in that directory and the processes in the subdirectories. This allows for a much larger exclusion set with minimal input but also leaves a very large security hole for visibility. Use this feature with extreme caution.
C:\Windows\*\Tiworker.exe - Excludes all Tiworker.exe found in the subfolders of 'Windows' C:\Windows\P*t.exe - Excludes Pot.exe, Pat.exe, P1t.exe Etc. C:\Windows\*chickens.exe - Excludes all Processes in 'Windows' folder ending in chickens.exe C:\* - Excludes all Processes in the C: drive in the top layer of folders but not the subfolders. C:\** - Excludes every Process on the C: drive.
MacOS and Linux
Endpoint 1.15.2+ allows for additional exclusions using the Wildcard functionality within the Process exclusions. This allows for broader coverage with less exclusions but can also be dangerous if too much is left undefined. You should only use the wildcard to cover the minimum number of characters required to provide the needed exclusion.
Use of (*) in Process Wildcard for Mac:
(*) Can be used in place of a single character or a full directory. It cannot be placed at the beginning of the path, it will be ruled invalid. The wildcard will work between two defined characters, slashes or alphanumeric.
/Library/Java/JavaVirtualMachines/*/java - Excludes Java within all subfolders of JavaVirtualMachines /Library/Jibber/j*bber - Excludes the Process for jabber, jibber, jobber, etc.
Exploit Prevention Exclusions (Application)
Secure Endpoint 7.5.1+ uses V5 of the Exploit Prevention Engine and the console now allows for application exclusions to be configured within the currentl exclusion list functionality. This is currently restricted to applications only and any exclusions related to DLLs still must be done through opening a case with support.
Finding the correct exclusions for Exploit Prevention is a far more intensive process than any other exclusion type and requires extensive testing to minimize any detrimental security holes.