This document provides a guideline on how to find detected files and describes a process to exclude them. When you run Cisco AMP for Endpoints (also known as FireAMP) on a computer, you might experience performance issue on an application or on the computer itself. This might occur due to excessive read/write operations, paging, or journaling. This can cause issues with applications that require exclusive file handles, such as database application or reporting software.
Caution: Exclusion reduces your coverage area. When you exclude a folder or file, FireAMP does not scan within that folder. In order to avoid exclusion of excessive files, you should be specific whenever possible.
How to Find Detected Files
When you want to exclude files, you can take a broad approach or write a very specific exclusion with a wildcard in order to cover just an affected file. This document starts with a basic identification of Microsoft Windows directories.
Most of the applications are installed in this directory. This folder is often the source for file activity on the system and is the primary focus. Cisco will be on the lookout for database applications and other antivirus programs as well as proprietary or in-house software.
This directory is sometimes used to cache or store temporary files. In this folder, you might notice a lot of activities which are dependent on applications.
This directory accommodates various user folders, such as desktop, documents, downloads, and appdata. The appdata folder is universally used for temporary files, Internet browsing files, history, and so on.
Caution: Due to the number of files and data that are downloaded in this directory, you should be careful when you specify an exclusion, and try to be as specific as possible to match the "safe" files.
This directory has the system files. You generally do not need to exclude much from this directory as it is handled by the default exclusion set. You might want to exclude this folder for caching, such as caching for System Center Configuration Manager (SCCM) and Windows log files.
Supported Exclusion Types
Threat: This is the name of a threat that is not quarantined. Any file that triggers a particular threat name would not be quarantined. An example is Win.Malware.PDF
Path: This is a single file system location. Here you can use a specific path such as C:\Program Files\Cisco, or you can use the constant special item ID list (CSIDL).
Note: A CSIDL is a built-in variable that is recognized by Windows and can be useful in scenarios where a path could reside on different drive letters. An example is CSIDL_PROGRAM_FILES\Cisco. This example covers C:\Program Files\Cisco and D:\Program Files\Cisco. CSIDLs only work in Path exclusions. Refer to Windows documentation for a full list of available CSIDLs.
Wildcard: This type must be used whenever a wildcard (*) is desired within the exclusion. For example: C:\Program Files\Cisco\*.tmp
File Extension: This is a simple exclusion for a file extension of file type. An example is .txt.
When to Exclude
If you run FireAMP and experience performance issues with the system or with a specific application, this could be an indication of lack of response to user input, slow performance of an automated process, crashes, or errors. Sometimes the application displays a specific error.
In order to determine the files or directories that are scanned and how frequently, follow these steps:
Step 1: The first step is to generate the diagnostic package and extract it. This is a 7zip archive and requires an application to extract it.
Step 2: The second step is to access the history.db file from the diagnostic file.
The history.db file is a SQLite database file that keeps track of all of FireAMP detected files. Each row includes the disposition, file name, file SHA, source file, and source SHA. The source is the file that created/accessed the file itself. This lets us see how the application behaved and what it did.
In this example, the SQLite3 command is used in order to convert the history database into a Comma Separated Value (CSV) file.
Download the pre-compiled SQLite3 binary for your operating system.
Extract the FireAMP Diagnostic package with an application such as 7zip.
Navigate to the extracted diagnostic folder and find the history.db file within the C_\Program Files\Sourcefire\fireAMP\ directory.
Within a terminal or command prompt, call the SQLite3 binary you downloaded and provide the history.db file with this command. (This command assumes that SQLite3 is in a location specified in your environment variables for your operating system, or it needs to be placed within the diagnostic folder.)
sqlite3 -csv -header history.db "select created_at,file,filename,source,sourcename from history" > history.csv
You will not see confirmation or output if the command is successful.
If the command failed, be sure you have specified the location of the SQLite3 binary. If you see any other messages in regards to the history.db file, you might need to clear the four history files from the affected host machine while the service is stopped, which allows it to generate a fresh set of files the next time the service is started.
Step 3: Once the CSV file has been generated you can open it with your preferred spreadsheet application. Applications such as Microsoft Excel might allow you to convert the CSV file to a table, which allows you to filter/sort. Review the Microsoft documentation for how to use Excel.
The primary columns to use are:
filename: This field shows the file is scanned by FireAMP.
sourcename: This field shows the process or executable that grabbed the handle (read/write and so on). This data is used in order to determine whether the files are handled by a trusted application or otherwise.
created_at: This is the timestamp on the event for the detection of the file.
At this point there are a couple of options:
If you just experienced the performance issue, you can sort the table by created_at which is the scanned timestamp and see the most recent events. You can browse the detections and work backwards in order to see what happened.
You can also search or browse for the applications that might have recently been impacted by FireAMP.
What you want to look for is something like the same file that is scanned repeatedly which might have different SHA values. You also want to look at the file type in order to see if this is expected behavior.
In this example, the file has been searched for "Office". The results show the files that FireAMP scanned that had the word "Office" in the file name or path. You can also see the source process that handled the corresponding file.
In this example, FireAMP scans a file related to a Microsoft Office service. If you want to exclude this, you could create a simple path exclusion such as the one shown here:
This example excludes cache files for the temp application. However, you do not want to exclude the temp folder as Internet cache files as downloads/images could reside in this directory. You can also narrow down the directory to the test folder, however the application might connect to the Internet as well, or have other cache files that do not harm performance or could potentially be open to risk. A wild card is used to exclude this.
As you see, a wildcard (*) was used to account for anything between the letters and dot in the file name. This wildcard excludes any file that matches this expression. This is an example of how you can narrow down exclusions in order to prevent too much risk.
You can also use wild cards for full path names. Here is a similar example;
Wildcard exclusions - The exclusions can be done on a wildcard expression where both the path and the filename can be expressed. That is, if the filename is constant, then it is best to “constrain” the wildcard to a specific path. So if AIM.exe always exists in C:\Program Files (x86)\*\AIM.EXE would look in any subdirectory.
After you find your desired FireAMP exclusions, you can follow the steps listed in this article in order to implement them in your dashboard and perform testing.
In Version 5.0+, the file activities are no longer logged into history.db. A new structure for scanned files and paths are located in historyex.db. A python script, not supported by the Cisco Technical Assistance Center (TAC), is available in the Cisco Support Community. On a Linux environment, the script is able to convert the historyex.db to a Comma Separated Value (CSV) file. It allows you to review the activities for exclusions.