Chapter 8. Cisco AMP for Endpoints
In this chapter, you will learn the following:
Introduction to Cisco AMP for Endpoints
Custom detections
Application control
AMP for Windows
AMP for Mac
AMP for Linux
AMP for Android
Installing all flavors of AMP for Endpoints
Using the AMP cloud console
This chapter provides an overview of Cisco Advanced Malware Protection (AMP) for Endpoints. This chapter looks at where AMP for Endpoints fits into the AMP architecture. You’ll also learn about the types of AMP for Endpoints connectors, how to create policies for them, and how to install them. The chapter describes how to use the AMP cloud console, and you will even get a look at AMP detecting and remediating malware.
After Cisco acquired SourceFire, the solution previously known as FireAMP was renamed AMP for Endpoints. Throughout the console interface and even within the connectors, you will see a confusing mix of terminology, and in a number of place, you will still see the term FireAMP. The figures in this chapter even show some instances of this. Cisco is updating its products all the time, though, so expect that the user interface will be updated at some point.
Introduction to AMP for Endpoints
Throughout this book, you have been learning about the various Cisco next-generation security products and technologies. You have learned that security technologies and processes should not just focus on detection but should also provide the capability to mitigate the impact of an attack. Organizations must maintain visibility and control across the extended network during the full attack continuum:
Before an attack takes place
During an active attack
After an attacker starts to damage systems or steal information
In Chapter 5, “Introduction to and Architecture of Cisco AMP,” you learned all about the components that make up the AMP architecture and the AMP cloud. You learned that the AMP solution enables malware detection, blocking, continuous analysis, and retrospective views with the following features:
File reputation: AMP allows you to analyze files inline and block or apply policies.
File sandboxing: AMP allows you to analyze unknown files to understand true file behavior.
File retrospection: AMP allows you to continue to analyze files for changing threat levels.
Remember that the architecture of AMP can be broken down into three main components: the AMP cloud, AMP client connectors, and intelligence sources. This chapter focuses on the AMP for Endpoints client connector.
Figure 8-1 illustrates the cloud architecture, showing how AMP receives intelligence from many sources and a variety of client connectors.
AMP for Endpoints provides more than just endpoint-level visibility into files. It also provides cloud-based detection of malware, in which the cloud constantly updates itself. This enables very rapid detection of known malware because the cloud resources are used instead of endpoint resources. This architecture has a number of benefits. With the majority of the processing power being performed in the cloud, the endpoint software remains very lightweight. The cloud is able to provide a historical view of malware activity, segmented into two activity types:
File trajectory: What endpoints have seen the files
Device trajectory: Actions the files performed on given endpoints
With the data storage and processing in the cloud, the AMP solution is able to provide powerful and detailed reporting, as well as provide very robust management.
The AMP for Endpoints agent is also able to take action. For example, it can block malicious network connections based on custom IP blacklists or intelligent dynamic lists of malicious IP addresses.
What Is AMP for Endpoints?
AMP for Endpoints is the connector that resides on—you guessed it—endpoints. It resides on Windows, Mac, Linux, and Android endpoints. Unlike traditional endpoint protection software that uses a local database of signatures to match a known bad piece of software or a bad file, AMP for Endpoints remains lightweight, sending a hash to the cloud and allowing the cloud to make intelligent decisions and return the verdicts Clean, Malware, and Unknown.
Figure 8-2 illustrates the AMP for Endpoints architecture.
Connections to the AMP Cloud
AMP for Endpoints connectors must be able to reach the AMP cloud. That means the agents may have to be able to go through firewalls and proxy servers to reach the Internet.
Firewalls, Destinations, and Ports, Oh My!
If traversing a firewall and/or web proxy to reach the Internet, those products must allow connectivity from the AMP connector to the following servers over HTTPS (TCP 443):
Event Server: Enterprise-event.amp.sourcefire.com (for US), enterprise-event.eu.amp.sourcefire.com (for Europe)
Management Server: Enterprise-mgmt.amp.sourcefire.com (for US), enterprise-mgmt.eu.amp.sourcefire.com (for Europe)
Policy Server: policy.amp.sourcefire.com.s3.amazonaws.com (for US), policy.eu.amp.sourcefire.com.s3.amazonaws.com (for Europe)
Error Reporting: crash.immunet.com (for US), crash.eu.amp.sourcefire.com (for Europe)
Endpoint IOC Downloads: https://endpoint-ioc-prod-us.s3.amazonaws.com (for US), https://endpoint-ioc-prod-eu.s3.amazonaws.com (for Europe)
To allow a connector to communicate with Cisco cloud servers for file and network disposition lookups, a firewall must allow the clients to connect to the following server over TCP 443 by default or TCP 32137:
Cloud Host: cloud-ec.amp.sourcefire.com (for US), cloud-ec.eu.amp.sourcefire.com (for Europe)
In order to upload files for analysis, clients must be able to access the following server over TCP 80:
Submission Server: submit.amp.sourcefire.com (for US), submit.eu.amp.sourcefire.com (for Europe)
If you have TETRA enabled on any of your AMP Connectors, you must allow access to the following server over TCP 80 for signature updates:
Update Server: update.immunet.com (for both US and Europe)
Outbreak Control
With a solution as powerful and extensive as AMP for Endpoints, it is difficult to determine where to start describing how to configure and use the system; however, it makes logical sense to begin with Outbreak Control because the objects you create within Outbreak Control are key aspects of endpoint policies.
Outbreak Control allows you to create lists that customize AMP for Endpoints to your organization’s needs. You can view the main lists from the AMP cloud console by clicking the Outbreak Control menu, which offers options in the following categories: Custom Detections, Application Control, Network, and Endpoint IOC (indicators of compromise), as shown in Figure 8-3.
Custom Detections
You can think of custom detections as a blacklist. You use them to identify files that you want to detect and quarantine. When a custom detection is defined, not only do endpoints quarantine matching files when they see them, but any AMP for Endpoints agents that have seen the file before the custom detection was created can also quarantine the file through retrospection, also known as cloud recall.
Simple custom detection allows you to add file signatures for files, while the advanced custom detections are more like traditional antivirus signatures.
Simple Custom Detections
Creating a simple custom detection is similar to adding new entries to a blacklist. You define one or more files that you are trying to quarantine by building a list of SHA-256 hashes. If you already have the SHA-256 hash of a file, you can paste that hash directly into the UI, or you can upload files directly and allow the cloud to create the SHA-256 hash for you.
To create a simple custom detection, navigate to Outbreak Control > Custom Detections > Simple, and the list of all existing simple custom detections appears, as shown in Figure 8-4. To add a new one, you must type it in the Name box and click Save, as shown in Figure 8-4. The detection is then added to the list, as shown in Figure 8-5, and automatically edited—with the contents displayed on the right side.
If you already have the SHA-256 hash of a file, simply paste it in, add a note, and click Save; otherwise, you can upload a file, add a note, and click Upload, as shown in Figure 8-5. Once the file is uploaded, the hash is created and shown on the bottom-right side, as shown in Figure 8-6. You must click Save, or the hash will not be stored as part of your simple custom detection.
Advanced Custom Detections
Simple custom detections just look for the SHA-256 hash of a file. Advanced custom detections offer many more signature types to the detection, based on ClamAV signatures, including the following:
File body-based signatures
MD5 signatures
MD5, PE section–based signatures
An extended signature format (with wildcards, regular expressions, and offsets)
Logical signatures
Icon signatures
To create an advanced custom detection, navigate to Outbreak Control > Custom Detections > Advanced, and the list of all existing advanced custom detections appears, as shown in Figure 8-7.
To add a new custom detection, you must type it in the Name box and click Save, as shown in Figure 8-7, to add it to the list, as shown in Figure 8-8. Click Edit to display the contents of the new advanced detection object on the right side.
As shown in Figure 8-8, the ClamAV signature types can be auto-detected, or you can manually select them from the drop-down list. In Figure 8-9, the ClamAV signature string 5d47b318b55c130ef30702026605ed6b:35411:Exploit.PDF-28520 was pasted in with a type Auto Detect, and the Create button was clicked. You can see there that the UI correctly converted it to hdb: Exploit.PDF-28520.UNOFFICIAL.
Next, you click the Build Database From Signature Set, and a success message is displayed, showing the successful creation of the advanced custom detection signature set, as shown in Figure 8-10.
A View Changes link is visible with every custom detection, both simple and advanced. The AMP cloud maintains an audit log for each of the detection lists, and you can view it by clicking that link. Figure 8-11 shows an example of the audit log.
Android Custom Detections
Android detections are defined separately from the ones used by Windows or Mac. These detections provide granular control over Android devices in an environment. The detections look for specific applications, and you build them by either uploading the app’s .apk file or selecting that file from the AMP console’s inventory list.
You can choose to use Android custom detections for two main functions: outbreak control and application control.
When using an Android custom detection for outbreak control, you are using the detection to stop malware that is spreading through mobile devices in the organization. When a malicious app is detected, the user of the device is notified and prompted to uninstall it.
You don’t have to use these detections just for malware, but you can also use them to stop applications that you don’t want installed on devices in your organization. This is what SourceFire refers to as application control. Simply add apps to an Android custom detection list that you don’t want installed, and APM notifies the user of the unwanted application and prompts the user to uninstall it, just as if it were a malicious app.
To create an Android custom detection, navigate to Outbreak Control > Custom Detections > Android to display the list of all existing Android custom detections, if any exist. Click Create to add a new one, and give it a name, as shown in Figure 8-12. Then click Save.
Once the new Android detection is created, you click Edit to add the Android apps that you wish to detect as either malware or unwanted.
IP Blacklists and Whitelists
You can use outbreak control IP lists in conjunction with device flow correlation (DFC) detections. DFC allows you to flag or even block suspicious network activity. You can use policies to specify the behavior of AMP for Endpoints when a suspicious connection is detected and also to specify whether the connector should use addresses in the Cisco intelligence feed, the custom IP lists you create yourself, or a combination of both.
You use an IP whitelist to define IPv4 addresses that should not be blocked or flagged by DFC. AMP bypasses or ignores the intelligence feeds as they relate to the IPv4 addresses in the whitelist.
You use IP blacklists to create DFC detections. Traffic that matches entries in the blacklist are flagged or blocked, as the DFC rule dictates.
To create an IP list, navigate to Outbreak Control > Network > IP Blacklists & Whitelists, as shown in Figure 8-13.
Here you click Create IP List to start a new IP list, and you’re brought to the New IP List configuration screen, where you can either create an IP list by typing the IPv4 addresses in classless interdomain routing (CIDR) notation or by uploading a file that contains a list of IPs. You can also specify port numbers to block or allow. After the list is created, you can edit it only by downloading the resulting file and uploading it back to the AMP console. Figure 8-14 shows the New IP List screen, with a mixture of entries entered as text.
You name the list, choose whether it is a whitelist or a blacklist, and enter a series of IPv4 addresses, one line at a time. Each line must contain a single IP or CIDR. Acceptable formats include the following:
10.1.100.0/24: A standard network range designated by network-/mask-length CIDR notation
192.168.26.26: A single IPv4 address
10.1.250.254:443: A single IPv4 address with a port specified (UDP and TCP)
10.250.1.1/16:8443: A CIDR-notated network range with a port specified (UDP and TCP)
You click Create IP List to create the text file in the cloud console, and your new IP list is shown on the screen. If you click Edit, you can change the name of the IP list. To update the contents of the list, you must click Download and then delete the list. Then you create a new list with the same name and upload the modified file. An IP list can contain up to 100,000 lines or be a maximum of 2 MB in size.
As for custom detections, the AMP console maintains an audit trail for IP lists that you can view by clicking View Changes.
Application Control
Like files, applications can be detected, blocked, and whitelisted. As with the other files, AMP does not look for the name of the application but the SHA-256 hash.
To create a new application control list for blocking an application, navigate to Outbreak Control > Application Control > Blocking. One thing you must credit the SourceFire AMP team with is that it sure understands the concept of consistency in GUIs. This GUI works just like so many other areas of the interface. If any existing blocking lists exist, they are displayed here, as shown in Figure 8-15. As you would expect, to create a new list, you click Create. You must name the list and click Save before you can add any applications to the blocking list.
Once the list has been created and saved, click Edit to add any applications. If you already have the SHA-256 hash, add it. Otherwise, you can upload one application at a time and have the AMP cloud console calculate the hash for you, as long as the file is not larger than the 20MB limit. You can also upload an existing list. Figure 8-16 shows a blocking list with an existing application hash shown at the bottom of the right-hand column, while another file is being uploaded for hash calculation.
Application whitelists work the same way. Navigate to Outbreak Control > Application Control > Whitelisting to see a list of any existing whitelists. Click Create to add a new one, provide it a name, and click Save, as shown in Figure 8-17.
Once the list has been created and saved, click Edit to add any applications. If you already have the SHA-256 hash, add it. Otherwise, you can upload one application at a time and have the AMP cloud console calculate the hash for you, as long as the file is not larger than the 20 MB limit. You can also upload an existing list. Figure 8-18 shows a whitelist with an existing application in the list (SafeGuardPDFViewer.exe).
Don’t forget to click Save after adding the hash to the list.
Exclusion Sets
There is one more object that you should try to create before you build your policies, and that is an exclusion set. An exclusion set is a list of directories, file extensions, or even threat names that you do not want the AMP agent to scan and definitely not to convict as malware.
You can use an exclusion set to resolve conflicts with other security products or mitigate performance issues by excluding directories that contain large files that are frequently written to, like databases. If you are running an antivirus product on computers with the AMP for Endpoints connector, you should exclude the location where that product is installed.
It’s important to remember that any files stored in a location that has been added to an exclusion set will not be subjected to application blocking, simple custom detections, or advanced custom detections.
These are the available exclusion types:
Threat: This type excludes specific detections by threat name.
Extension: This type excludes files with a specific extension.
Wildcard: This type excludes files or paths using wildcards for filenames, extensions, or paths.
Path: This type excludes files in a given path.
For Windows, path exclusions may use constant special ID lists (CSIDL), which are Microsoft given names for common file paths. For more on CSIDL, see https://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx.
To create a new exclusion set, navigate to Management > Exclusions. Here you see a list of any existing exclusions and can create new ones. Click Create Exclusion Set, provide a name, and click Save. The contents of the exclusion set are automatically listed on the right side.
As shown in Figure 8-19, new exclusion sets are created with some default exclusions. Many of these exclusions are specific to the default installation paths of antivirus products and designed to cover a large variety of installations. Figure 8-19 shows an example of a Windows exclusion set. Figure 8-20 shows a Mac exclusion set, and Figure 8-21 shows a Linux exclusion set.
The Many Faces of AMP for Endpoints
AMP for Endpoints is available for multiple platforms: Windows, Android, Mac, and Linux. You can see the available connectors from the cloud console by navigating to Management > Download Connector. Here you see the types of endpoints, as shown in Figure 8-22.
The following sections go through the options for each of the operating systems shown in Figure 8-22.
AMP for Windows
The Windows AMP connector supports many different flavors of Windows in both 32-bit and 64-bit variants of those Windows platforms. The following are the minimum system requirements for the Windows AMP agents, based on the operating system version:
Microsoft Windows XP with Service Pack 3 or later:
500 MHz or faster processor
256 MB RAM
150 MB available hard disk space for cloud-only mode
1 GB available hard disk space for TETRA
Microsoft Windows Vista with Service Pack 2 or later:
1 GHz or faster processor
512 MB RAM
150 MB available hard disk space for cloud-only mode
1 GB available hard disk space for TETRA
Microsoft Windows 7:
1 GHz or faster processor
1 GB RAM
150 MB available hard disk space for cloud-only mode
1 GB available hard disk space for TETRA
Microsoft Windows 8 and 8.1 (requires AMP Connector 3.1.4 or later):
1 GHz or faster processor
512 MB RAM
150 MB available hard disk space for cloud-only mode
1 GB available hard disk space for TETRA
Microsoft Windows 10 (requires AMP Connector 4.3.0 or later):
1 GHz or faster processor
1 GB RAM (32-bit) or 2 GB RAM (64-bit)
150 MB available hard disk space for cloud-only mode
1 GB available hard disk space for TETRA
Microsoft Windows Server 2003:
1 GHz or faster processor
512 MB RAM
150 MB available hard disk space for cloud-only mode
1 GB available hard disk space for TETRA
Microsoft Windows Server 2008:
2 GHz or faster processor
2 GB RAM
150 MB available hard disk space for cloud-only mode
1 GB available hard disk space for TETRA
Microsoft Windows Server 2012 (requires AMP Connector 3.1.9 or later):
2 GHz or faster processor
2 GB RAM
150 MB available hard disk space for cloud-only mode
1 GB available hard disk space for TETRA
Windows Policies
There are many policy options for Windows. From the AMP cloud console, navigate to Management > Policies > Windows, where you can see existing AMP policies for Windows as well as create new ones (see Figure 8-23).
Click Create Policy and then select FireAMP Windows from the drop-down as shown in Figure 8-24, and click Create Policy.
In the New Policy Window, select the custom detections, app blocking, whitelists, and exclusions created earlier, as shown in Figure 8-25. When they are all selected, click Create Policy to save the policy.
Click Edit for the newly created Windows policy and scroll to the bottom. This is where a lot of the AMP agent configuration and customization takes place. There are three tabs for AMP connector configurations: General, File, and Network.
General Tab
The General tab for a Windows policy has the basic settings for the AMP for Endpoints connector, such as proxy settings and update schedules. There are five component areas within the General tab: Administrative Features, Connector Identity Persistence, Client User Interface, Proxy Settings, and Product Updates. Each of these areas is explained in the sections that follow. One very nice UI feature here is that a blue informational icon appears whenever a default setting is changed, as shown in Figure 8-26.
Administrative Features
As you can see in Figure 8-26, there are nine configurable settings in the Administrative Features section of the General tab:
Send User Name in Events: This relates to the username that has launched the process. This setting is useful for tracking down who was on a system that may be seeing malware.
Send Filename and Path Info: This setting enables the AMP agent to send the filename and path information to the AMP cloud so that they are visible in the Events tab, device trajectory, and file trajectory. Unchecking this option stops this information from being sent.
Heartbeat Interval: This option sets how often the AMP agent should call home to the AMP cloud. During the call home connection, the agent checks whether there are any policy updates, any updates or scans to perform, or any files to restore via cloud recall or by the administrator.
Confirm Cloud Recall: Cloud recall (also known as retrospection) can find every connector that has seen a specific file and attempt to quarantine it when the connector calls home on its heartbeat interval. This check box adds a required action for a system admin to confirm before recalling any files.
Connector Log Level and Tray Log Level: This option allows you to change the default log level to debug, when directed by Cisco Technical Assistance Center (TAC).
Connector Protection: Selecting this check box requires a password for stopping the AMP service or the uninstalling the AMP agent.
Connector Protection Password: This option sets the password for the connection protection.
Automated Crash Dump Uploads: When this option is enabled, the connector automatically sends crash dumps to Cisco for analysis in the event of connector crashes.
Connector Identity Persistence
Connector Identity Persistence is an odd section to show in the interface. It is actually not available unless enabled by TAC. Identity persistence is used in virtual environments when systems are cloned or reimaged. This setting maintains a consistent event log by binding a connector to a MAC address or hostname so that a new event log is not created every time a new virtual session is started or a computer is reimaged. You can choose to apply this setting with granularity across different policies or across your entire organization. There are five configuration options for identity persistence, as shown in Figure 8-27:
None: Connector logs are not synchronized with new connector installs under any circumstance. This is the default setting unless changed by support.
By MAC Address across Business: New connectors look for the most recent connector that has the same MAC address to synchronize with across all policies in the business that have Identity Synchronization set to a value other than None.
By MAC Address across Policy: New connectors look for the most recent connector that has the same MAC address to synchronize with within the same policy.
By Hostname across Business: New connectors look for the most recent connector that has the same hostname to synchronize with across all policies in the business that have Identity Synchronization set to a value other than None.
By Host name across Policy: New connectors look for the most recent connector that has the same hostname to synchronize with within the same policy.
Client User Interface
The Client User Interface section allows you to configure what the end user sees on the Windows system. Many organizations prefer to show the agent icon in the system tray, so it is obvious that the agent is running, but they often choose to hide all notifications so that users are not bothered by the connector. There are six different options, as shown in Figure 8-28:
Start Client User Interface: Simply put, this option hides the user interface or shows it. The agent is running either way. This setting offers you the option of keeping it out of the system tray. When you change this option, it takes effect at the next agent restart.
Cloud Notifications: This option controls whether you see those fun balloon pop-ups from the agent icon in the Windows system tray. When this option is selected, a pop-up appears when the agent is successfully connected to the cloud, and it displays the number of users and detections registered to the cloud.
Verbose Notifications: When this option is enabled, the end user is completely harassed by a series of text boxes that pop up from the Windows system tray icon, telling about nearly every file that traverses the AMP connector. Leave this option unselected unless you are in the process of active troubleshooting or you just want to punish your end users.
Hide Cataloging Notifications: This option relates to endpoint IOC scans and hides the user notification about cataloging. Note that when you select this option, you hide a disk-intensive process of cataloging artifacts from the system to be used in comparisons with IOCs.
Hide File Notifications: Selecting this option keeps malicious file notifications from being displayed when a file is convicted or quarantined by the AMP agent.
Hide Network Notifications: Selecting this option causes messages to not display when a malicious network connection is detected or blocked by AMP.
It is highly recommended that you keep any interactivity with the end user to an absolute minimum. End users often get frustrated and annoyed when burdened by notifications that they don’t understand or don’t care to understand.
Proxy Settings
In today’s world of mobile workstations, configuring a hard-coded proxy server may not always be the best-practices configuration. However, with the wonderful cloud-based technologies available, such as the Cisco Cloud Web Security solution (blatant plug), you may wish to configure the AMP agent to always use that cloud proxy solution. Proxy servers and some of the complications they bring are covered in more detail later in this chapter, but in the meantime, let’s take a look at the Proxy Settings section in the General tab, as displayed in Figure 8-29.
By populating the Proxy Settings sections of the General tab, you can configure a hard-coded proxy server for the agents that receive this policy. As you can see in Figure 8-29, basic and NT LAN Manager (NTLM) authentications are both supported, as are straight HTTP proxy and Secure Sockets (SOCKS) proxy. If you use NTLM, be sure to use the DOMAINUSER notation for the account.
Product Updates
The policy that is applied to the AMP connector determines whether and when to update to a newer version. You select the version from the Product Version drop-down, choose a time window for the updates to occur, and tell the agent how often to check for updates. Figure 8-30 shows the Product Updates settings.
A reboot is required for the running AMP agent to reflect an upgrade. The Product Updates section lets you specify whether to not reboot the system, to ask the user if it’s okay to proceed with a reboot, or to simply reboot the system, as shown in Figure 8-30.
File Tab
You use the File tab to configure the settings and behavior of file scanning in the AMP for Endpoints agent. For example, you can specify which engines to use, set up scheduled scans, and specify cache settings. There are six component areas of the File tab: Modes, Cache Settings, Engines, Ethos, Cloud Policy, and Scheduled Scans. Figure 8-31 shows the File tab with the Modes component area expanded.
Modes
The Modes section of the File tab allows you to specify how the AMP connector should behave during file moves or copies as well as how it should behave when a file is executed. These are the available options in the Modes section:
Monitor File Copies and Moves: This option is either selected or not. It determines whether AMP should care about files when they are moved or copied within or off the system.
File Conviction Mode: This option is set to either Audit or Quarantine. In other words, is this a monitor-only deployment, or should the AMP agent take action?
Monitor Process Execution: This option is set to either on or off. This setting determines whether AMP should care about executable files when they are run.
On Execute Mode: This option is set to either Passive or Active. In other words, should the file lookup happen before the executable is allowed to run, or should they occur in parallel? When the endpoint has another antivirus product installed, it is best to leave this set to Passive to avoid performance issues.
Maximum Scan File Size: Any file larger than this setting will not be scanned by AMP.
Maximum Archive Scan File Size: Any archive file (ZIP, TAR, etc.) larger than this setting will not be scanned by AMP.
Cache Settings
As you know, the AMP connector focuses on the disposition that the AMP cloud assigns to the SHA-256 hash of a file. The hash and the disposition are stored in a local cache for better performance and to reduce redundant lookups of the same hash value. The settings in the Cache Settings section of the File tab determine how long the hashes should remain in the cache. As Figure 8-32 shows, there are four different cache settings, all of which are configured as the number of seconds before checking those file hashes again:
Malicious Cache TTL: This setting specifies how long to hold on to the disposition of a file hash when it has been deemed malicious. The default is 1 hour.
Clean Cache TTL: This setting specifies how long to hold on to the information when a file has been assigned a clean disposition. The default is 7 days.
Unknown Cache TTL: This setting specifies how long to store the disposition of files that receive an Unknown disposition. The default is 1 hour.
Application Blocking TTL: This setting specifies how long an outbreak control blocking list is cached. The default is 1 hour.
Engines
As shown in Figure 8-33, the Engines section is used to configure the use of one or all of the three engines:
Offline Engine (TETRA): This setting is configured to be disabled (default) or TETRA, which is a full client-side antivirus solution. Do not enable the use of TETRA if there is an existing antivirus product in place. The default AMP setting is to leave TETRA disabled, as it changes the nature of the AMP connector from being a very lightweight agent to being a “thicker” software client that consumes more disk space for signature storage and more bandwidth for signature updates. When you enable TETRA, another configuration subsection is displayed, allowing you to choose what file scanning options you wish to enable, as shown in Figure 8-34.
Spero: Spero is a machine learning–based technology that proactively identifies threats that were previously unknown. It uses active heuristics to gather execution attributes, and because the underlying algorithms come up with generic models, they can identify malicious software based on its general appearance rather than basing identity on specific patterns or signatures.
Ethos: Ethos is a “fuzzy fingerprinting” engine that uses static or passive heuristics. Disabling Ethos in this section hides the Ethos menu from the File tab altogether.
Ethos
As just mentioned, Ethos is a “fuzzy fingerprinting” engine that uses static or passive heuristics. Think of it as Cisco’s file-grouping engine. It groups families of files together, and when variants of a malware are detected, it marks the Ethos hash as malicious and instantly detects entire families of malware.
Ethos can be a bit resource intensive, and therefore it is enabled only for file move and copy by default, as shown in Figure 8-35. When scanning on copy or move, AMP allows the copy or move action to finish and then queues another thread to calculate the Ethos for a file. That same passive performance luxury is not available for the On Execute or On Scan settings.
Cloud Policy
The Cloud Policy settings refer to the Ethos and Spero engines. Because both Ethos and Spero are classified as generic engines, you can tune how false-positive-prone an Ethos or Spero hash is. The Cloud Policy section provides up to three configurable thresholds, as shown in Figure 8-36.
Detection Threshold per Ethos Hash: When this option is selected, a single Ethos hash can convict a single SHA of unknown disposition a maximum number of times. The default is 10, meaning that Ethos will not convict any SHA-256 seen 10 times in 24 hours by the entire community. If you encounter a situation where the detection threshold has been reached but feel that the detection is not a false positive and want to keep convicting the particular SHA, you should add it to an advanced custom detection list.
Detection Threshold per Spero Hash: This is exactly like the Detection Threshold per Ethos Hash option, except it refers to Spero.
Step-Up Enabled: When this option is selected, additional Spero groupings can be turned on if the network is considered “massively infected.” These Spero groupings, or trees, are more false positive prone but do a better job of detecting malware. The definition of “massively infected” is based on the Step-Up threshold setting.
Step-Up Threshold: This option’s setting determines whether a connector is “massively infected.” The default is 5, meaning that if 5 SHA one-to-one detections are found in 30 seconds, the system is considered “massively infected,” and additional Spero trees are enabled for the next 30 seconds.
Scheduled Scans
Scheduled scans are typically deemed unnecessary with AMP for Endpoints. This is because files are being scanned as they are moved, copied, or executed. So to keep the processing low and the performance higher, no scans are scheduled by default. This does not, however, preclude you from configuring some scheduled scans per policy, as shown in Figure 8-37.
Multiple scans can be configured to occur daily, weekly, and/or monthly. Scans can be flash, full, or custom scans, and they can be configured to occur at specific times. A flash scan examines the processes running in memory, along with the files and registry settings associated with those running processes. A full scan examines the processes running in memory, their associated registry settings, and all the files on the entire disk. A custom scan is configured to look at files in a specific path. Figure 8-38 shows an example of the configuration window that pops up when you add a scheduled scan.
Network Tab
You use the Network tab to configure device flow correlation (DFC) and, in fact, DFC is the only configuration section in the Network tab. As described earlier in this chapter, DFC allows you to flag or even block suspicious network activity.
As you can see in Figure 8-39, you can enable or disable DFC from the Network tab. In addition, you specify here whether the detection action should be Audit or Blocking. In other words, you specify whether this policy should dictate a monitor-only mode or actually take action on the file. If you select Blocking, you can choose to terminate the parent process of the network connection and quarantine the malicious file. Finally, you can set Data Source to SourceFire, Custom, or both.
Known Incompatible Software
At this writing, AMP for Windows has interaction incompatibility with the following security software:
Check Point’s ZoneAlarm
Carbon Black
Res Software’s AppGuard
AMP for Mac
Unlike AMP for Windows, AMP for Mac is supported only on 64-bit versions of the popular Mac OS. The following are the minimum system requirements for the Mac AMP agents, based on the operating system version:
Apple OS X 10.7:
2 GB RAM
65 MB available hard disk space
Apple OS X 10.8:
2 GB RAM
65 MB available hard disk space
Apple OS X 10.9:
2 GB RAM
65 MB available hard disk space
Apple OS X 10.10 (requires AMP Mac Connector 1.0.6 or later):
2 GB RAM
65 MB available hard disk space
Apple OS X 10.11 (requires AMP Mac Connector 1.0.7 or later):
2 GB RAM
65 MB available hard disk space
MAC Policies
There are many policy options for Macs. From the AMP cloud console, navigate to Management > Policies > Mac to see existing AMP policies for Mac and create new ones, as shown in Figure 8-40.
Click Create Policy and then select FireAMP Mac from the drop-down, as shown in Figure 8-40, and click Create Policy.
In the New Policy Window that appears, provide a name and select the custom detections, app blocking, whitelists, and exclusions created earlier, as shown in Figure 8-41. When they are all selected, click Create Policy to save the policy.
Click Edit for the newly created Mac policy and scroll to the bottom. This is where a lot of the AMP agent configuration and customization takes place. Just as with a Windows policy, the AMP connector configurations are presented in three tabs for Mac: General, File, and Network.
General Tab
The General tab for a Mac policy provides the basic options for the AMP for Endpoints connector, such as proxy settings and update schedules. As shown in Figure 8-42, there are four component areas in the General tab: Administrative Features, Client User Interface, Proxy Settings, and Product Updates. These areas are explained in the following sections.
Administrative Features
As you can see in Figure 8-42, there are five configurable settings in the Administrative Features section of the General tab:
Send Filename and Path Info: This option enables the AMP agent to send the filename and path information to the AMP cloud so that they are visible in the Events tab, device trajectory, and file trajectory. Unchecking this option stops this information from being sent.
Heartbeat Interval: This option sets how often the AMP agent should call home to the AMP cloud. During the call home connection, the agent checks whether there are any policy updates, any updates or scans to perform, or any files to restore via cloud recall or by the administrator.
Confirm Cloud Recall: Cloud recall (also known as retrospection) can find every connector that has seen a specific file and attempt to quarantine it when the connector calls home on its heartbeat interval. This check box adds a required action for a system admin to confirm before recalling any files.
Connector Log Level: This option allows you to change the default log level to debug, when directed by Cisco TAC.
Tray Log Level: This option allows you to change the default log level to debug, when directed by Cisco TAC.
Note
This section has no options for sending the username, connector protection options, or crash dumps. Those are Windows-specific options.
Client User Interface
The Client User Interface section of the General tab allows you to configure what the end user sees on a Mac system. Many organizations prefer to show the agent icon in the menu bar, so it is obvious that the agent is running, but they often choose to hide all notifications so that the users are not bothered by the agent. There are four different options, as shown in Figure 8-43:
Start Client User Interface: Simply put, this option hides the user interface or shows it. The agent is running either way. This setting offers you the option of keeping it out of the menu bar. When you change this option, it takes effect at the next connector restart.
Cloud Notifications: This option controls whether you see those fun notification pop-outs that come from the upper-left side of the screen on a Mac (the Notification Center). When this option is selected, a pop-out appears when the agent is successfully connected to the cloud, and it displays the number of users and detections registered to the cloud. Your end users will normally not thank you for these messages, which don’t make any sense to them.
Hide File Notifications: Selecting this option hides malicious file notifications from being displayed when a file is convicted or quarantined by the AMP agent.
Hide Network Notifications: Selecting this option hides messages when a malicious network connection is detected or blocked by AMP.
It is highly recommended that you keep any interactivity with the end user to an absolute minimum. End users often get frustrated and annoyed when burdened by notifications that they don’t understand or don’t care to understand.
Proxy Settings
The options in the Proxy Settings section for Mac are exactly the same as for the Windows connector. To do our part to save the planet and use less paper, please see the “Proxy Settings” section for Windows, earlier in this chapter.
Product Updates
The options in the Product Updates section for Mac are exactly the same as for the Windows connector. Please see the “Product Updates” section for Windows, earlier in this chapter.
File Tab
You use the File tab to configure the settings and behavior of file scanning in the AMP for Endpoints agent, such as which engines to use, setting up scheduled scans, and cache settings. There are five component areas of the file tab: Modes, Offline Engine—ClamAV, Cache Settings, Engines, and Scheduled Scans.
Modes
The options in the Modes section for Mac are exactly the same as for the Windows connector. Please see the “Modes” section for Windows, earlier in this chapter.
Offline Engine—ClamAV
This section is available only when ClamAV has been selected for the Offline Engine option in the Engines portion of the File tab.
The Windows connector uses TETRA for offline scanning. The Mac connector uses ClamAV, which is an open source full antivirus product, owned by Cisco SourceFire. Just like TETRA, ClamAV is signature based and takes up more disk space and processor power on the Macs.
As shown in Figure 8-44, the only configurable option for ClamAV is Content Update Interval. By default, it checks for new or updated AV signatures to be downloaded every 24 hours. Just as on Windows, compatibility with other antivirus software solutions can be an issue, so never enable Offline Engine—ClamAV if another antivirus product is installed on the computer.
Cache Settings
The options in the Cache Settings section for Mac are exactly the same as for the Windows connector. Please see the “Cache Settings” section for Windows, earlier in this chapter.
Engines
As stated in the “Offline Engine—ClamAV” section, the Engines section of the File tab is where you enable or disable ClamAV in the Mac connector policy.
Scheduled Scans
The options in the Scheduled Scans section for Mac are exactly the same as for the Windows connector. Please see the “Scheduled Scans” section for Windows, earlier in this chapter.
Network Tab
Just as with the AMP for Windows connector, you use the Network tab to configure DFC. As described earlier in this chapter, DFC allows you to flag or even block suspicious network activity.
As you can see in Figure 8-45, the options here are even fewer for Mac than they are for Windows. DFC can be enabled or disabled, and Detection Action may be set to Audit or Blocking.
AMP for Linux
AMP for Linux gets a bit interesting. First of all, there are more flavors of Linux than you can count, and Cisco certainly cannot be expected to support and test every one. At this writing, only the CentOS and Red Hat Linux variants are supported, and only the 64-bit versions of those Linux flavors are supported. The system requirements are as follows:
CentOS 6.4/6.5/6.6:
1 GB RAM
400 MB available hard disk space
Red Hat Enterprise Linux 6.5/6.6:
1 GB RAM
400 MB available hard disk space
Note
AMP for Linux may not install properly on custom kernels.
Linux Policies
Just as with the Windows and Mac operating systems, there are many policy options for Linux. From the AMP cloud console, navigate to Management > Policies > Linux, where you can see existing AMP policies for Linux and create new ones.
Click Create Policy and then select FireAMP Linux from the drop-down and click Create Policy.
In the New Policy window that appears, provide a name and select the custom detections, app blocking, whitelists, and exclusions created earlier, as shown in Figure 8-46. When they are all selected, click Create Policy to save the policy.
Click Edit for the newly created Linux policy and scroll to the bottom to find the three tabs General, File, and Network.
General Tab
Just as for Windows and Mac, the General tab for a Linux policy has the basic settings for the AMP for Endpoints connector, such as proxy settings and update schedules.
There are only four component areas in the General tab: Administrative Features, Client User Interface, Proxy Settings, and Product Updates. Only the items that are different from the Windows and Mac policy options are discussed here. You can look to earlier sections for descriptions of any other options.
Administrative Features
The only difference in configuration of administrative features on Linux as compared to Mac is the lack of a system tray log for which to set the level. Only the connector log exists, and therefore only connector log settings can be changed from Default to Debug.
Client User Interface
The Client User Interface section provides two options: Hide File Notifications and Hide Network Notifications. As always, silence seems to be golden for the AMP connector, so hiding notifications may be wise for your environment.
File Tab
The File tab for Linux is exactly the same as it is for the Mac connector. ClamAV is the antivirus product for Linux that is built into the AMP connector, and it can be enabled and configured for periodic updates, just as the Mac connector can.
Network Tab
Just as with the Mac and Windows connectors, the Network tab for Linux is used to enable or disable DFC. However, Linux does not have a blocking mode for DFC; it is only capable doing audits.
AMP for Android
The AMP for Android connector requires Android 2.1 or higher running on ARM and Intel Atom processors with 4 MB of free space on the device.
Unlike with Windows and Mac, there are not many policy options for Android. From the AMP cloud console, navigate to Management > Policies > Android, where you can see existing AMP policies for Android and create new ones.
Click Create Policy and then select FireAMP Android from the drop-down and click Create Policy.
In the New Policy window that appears, provide a name and select the custom detection created earlier, as shown in Figure 8-47. There is only one option to configure at the bottom of the policy, Heartbeat Interval, as shown in Figure 8-47.
Installing AMP for Endpoints
You have created policies for the different endpoints. The next step is to assign those policies to groups so you can begin to deploy the AMP connectors to the many endpoints in your organization.
Groups, Groups, and More Groups
Before you move on to installing AMP for Endpoints onto hosts, we should really discuss an important organization component: groups. The AMP administrative console uses groups to organize and manage computers according to function, location, or other criteria that you determine. Policies get assigned to groups and can inherit from parent groups for greater control.
For example, you might create a group for each department of line of business; however, there could be additional controls required, based on the country of origin in which the computer normally resides.
Navigate to Management > Groups, where you see a list of all the top-level groups in your organization. You can create, edit, or delete the groups from this screen. If a group has child groups within it, this is indicated as shown in Figure 8-48.
To create a new group, click the Create Group button shown in Figure 8-48. To create a new group, you provide a group name, description, and parent group (if any) and you can assign existing known computers to it, as shown in the upper right of Figure 8-49. At the bottom of the screen, you can make this new group a parent by assigning other existing groups to it as children.
In addition, as you can see in Figure 8-49, you can assign existing policies to the group. This is where you select the policies you just created in this chapter.
Click Save to save the new group.
Download Connector
Earlier in the chapter you saw the Download Connector screen, located at Management > Download Connector (see Figure 8-50). Here you can download installation packages for each type of AMP for Endpoints connector, or you can copy the URL from where those connectors can be download. Before downloading a connector, select the appropriate group so the correct policies will be assigned and the installed computers will appear in the correct group.
The installer may be placed on a network share, distributed via management software, or distributed via the Cisco AnyConnect Secure Mobility Client. The download URL can be emailed to users so they can download and install it themselves; this can be convenient with remote users.
Distributing via Cisco AnyConnect
At this writing, the AMP connector is not part of the Cisco AnyConnect Secure Mobility Client, but you can use the AMP Enabler add-on to AnyConnect to aid in the distribution of the AMP connector to clients who use AnyConnect for remote access VPN, secure network access, posture assessments with Cisco’s Identity Services Engine, and more. Figure 8-51 shows the AnyConnect Secure Mobility Client with the AMP Enabler tile.
Installing AMP for Windows
On the Download Connector screen shown in Figure 8-50, Windows is the first operating system. As you can see in Figure 8-52, there are a few options to select when choosing to download the AMP installer for Windows.
There is an option to have the connector perform a flash scan during the install process. The flash scan checks processes currently running in memory and should be performed on each install.
The second check box is an option to enable a redistributable file. This option is not enabled by default, and when you click Download with this disabled (the default), you download a very small (around 500 KB) bootstrapper file to install the AMP connector. This type of installer is also referred to as a “stub installer.”
A stub installer determines whether a computer is running a 32- or 64-bit operating system and connects to the cloud to download and install the appropriate version of the AMP connector. The connector is configured with your policies, based on the group assignment.
If you select the Redistributable option and then click Download, you download a much larger executable (around 30 MB) that contains the full installation, both 32- and 64-bit versions.
You can place the executable file on a network share or push it to all the computers in a group via a tool like Microsoft System Center Configuration Manager (SCCM) or Active Directory Group Policies in order to install the AMP connector on multiple computers. The bootstrapper and redistributable installer also both contain a policy.xml file, which contains your assigned policies and is used as a configuration file for the install. Administrative rights are required for installing the connector interactively.
Figure 8-53 shows the UI displaying the URL to send to the end users. Figure 8-54 shows an end user connecting to the installer stub through the download URL entered into their browser. The stub installer is downloaded, and when it’s executed, the Windows security subsystem asks for permission to run the installer, as shown in Figure 8-55. You click Yes to continue with the installation and download the full agent with the policies, as shown in Figure 8-56.
When the agent is installed on a Windows endpoint and the user interface is configured to be visible, the AMP icon is in the system tray; clicking that system tray icon brings up the summary window. Both the system tray icon and the summary window are shown in Figure 8-57.
As shown in Figure 8-57, the summary window includes the current status of the connection to the AMP cloud, the last date the system was scanned, and the assigned policy. If you click Settings, you see the settings that are configured in the policy, as shown in Figure 8-58.
Installing AMP for Mac
The process of installing AMP for Mac is very similar to the installation process for Windows. First, you select the group, but instead of downloading a Windows executable file, you download a PKG file to install the AMP connector. Or you can copy the URL, just as with Windows. Also as with Windows, a Mac user must have admin privileges to install the connector. Figure 8-59 shows the downloading of the PKG file.
The PKG file is only about 7 MB, as there is no “redistributable” equivalent. When the end user runs the PKG file, the step-by-step installation begins, as shown in Figure 8-60.
When the agent is installed, if the user interface is configured to be visible, there is an AMP icon in the menu bar. Clicking the menu bar icon allows you to trigger an on-demand scan, sync the policy to the cloud, or get into the settings, as shown in Figure 8-61.
You can click Settings to bring up the main AMP for Mac GUI. As you can see in Figure 8-62, this GUI has four sections: Events, Policy, Scan, and About. This is quite different from the Windows agent: You cannot see or change the policy in the Mac GUI.
The Events tab in the GUI lists all the logged activities for quarantines, detection, update, and scans.
Figure 8-63 shows the Policy section of the GUI, which provides some visibility into the configuration, but not any settings to change.
Figure 8-64 shows the Scan section of the GUI, which allows you to initiate a flash, full, or custom scan. It also shows any scans scheduled from the centralized policy.
Figure 8-65 shows the About section of the GUI, which lists the AMP connector version.
Installing AMP for Linux
Downloading the Linux connector provides you with an RPM (Red Hat Package Manager, aka RPM Package Manager) file to be installed. The installer is about 16MB and also contains the policy.xml file, which is used as a configuration file for your settings. There is also a link to download the GPG key, which is required for connector updates via the central policy. Figure 8-66 shows the screen where the GPG key can be copied or downloaded.
You can install the RPM via rpm or the yum toolset. To install via RPM, you use the rpm -i command and option. For yum, use sudo yum localinstall [install-file] -y. Figure 8-67 shows an example of using the rpm command.
If you plan on pushing connector updates via policy, you need to import the GPG key into your RPM DB. Here’s how you do this:
Step 1. Verify the GPG key by clicking the GPG Public Key link on the Download Connector page, as shown in Figure 8-66. Compare the key from that link to the one at /opt/cisco/amp/etc/rpm-gpg/RPM-GPG-Key-cisco-amp. Figure 8-68 shows the contents of that public key file, for comparison.
Step 2. Run the following command from a terminal to import the key: [sudo] rpm --import /opt/cisco/amp/etc/rpm-gpg/RPM-GPG-KEY-cisco-amp
Step 3. Verify that the key was installed by running the following command from a terminal: rpm -q gpg-pubkey --qf ‘%{name}-%{version}-%{release} --> %{summary} ’
Step 4. Look for a GPG key from SourceFire in the output.
The Linux connector has a command-line interface (CLI), as shown in Figure 8-69.
Installing AMP for Android
AMP for Android comes in the form of an app. An end user can obtain the app if you send a link to the app, send the app directly, or allow the user to download the app from the Google Play Store.
Android Activation Codes
Before you can successfully install the app on an Android endpoint, an activation code is required. Activation codes are generated in the console GUI and do not have expiration dates by default.
In the Download Connector screen, click Activation Codes in the FireAMP Android box, as shown in Figure 8-70.
In the Android Activation Codes screen, click Create to generate a new code, and you get a small form to fill out, including the new code value. The Activation Limit setting is how many connectors may be activated using this license code. You can choose an expiration date for the use of the code to prevent any new activations with the code from that date forward. An expiration date does not disable the connectors that were previously activated by the code. Finally, you select the group that will use the activation code. Only a single activation code can be applied to a group at a time, so make sure you have assigned a high enough activation limit for the number of devices in the group you are applying the code to. Don’t worry, though: You can later return to the screen and edit the code to extend the activation limit. You can also delete the old code and create a new code for the same group. Again, deleting a code does not deactivate the connectors that were previously activated; it simply prevents any new users from activating their app with that code.
Click Create at the bottom of the screen to create the new activation code and ensure that you notate the code for use in the next steps. Figure 8-71 shows the connector code being generated.
Deploying the AMP for Android Connector
AMP for Android comes in the form of an app. An end user can obtain the app if you send a link to the app, send the app directly, or allow the user to download the app from the Google Play Store. Using the Google Play Store is often considered the easiest method, since it is trusted to all Android devices by default and doesn’t require changing security settings on the device to allow apps to be installed from other sources.
Figure 8-72 shows the app in the Google Play Store. Click Install to download and install it. When the installation is complete, open the app. You are prompted to accept the license agreement, as shown in Figure 8-73.
Next, you are asked to enter the activation code and provide an identifying name for the Android device, as shown in Figure 8-74. If the code is active and valid, you see a success message and then the main AMP app window, as shown in Figure 8-75.
Clicking Settings in the Android AMP connector is a bit different from clicking Settings in the other connectors, as the only option displayed is to change the device name, as shown in Figure 8-76.
Proxy Complications
AMP for Endpoints needs to reach the AMP cloud through an Internet connection, and that connection may require traversing a proxy server. Sometimes there are complications with this process.
Proxy Server Autodetection
AMP for Endpoints can use multiple mechanisms to support anonymous proxy servers. A specific proxy server or path to a proxy auto-config (PAC) file can be defined in Policies, or the connector can discover the endpoint proxy settings from the Windows registry.
The FireAMP connector can be set to discover endpoint proxy settings automatically. When the connector detects proxy setting information, it attempts to connect to the FireAMP management server to confirm that the proxy server settings are correct. The connector first uses the proxy settings specified in the policy. If the connector is unable to establish a connection to the FireAMP management server, it attempts to retrieve proxy settings from the Windows registry on the endpoint. The connector attempts to retrieve the settings only from systemwide settings and not from per-user settings.
If the connector is unable to retrieve proxy settings from the Windows registry, it attempts to locate the PAC file. This can be specified in policy settings or determined using Web Proxy Auto-Discovery (WPAD). If the PAC file location is specified in policy, it has to begin with http or https. Note that the PAC files supported are only ECMAScript based and must have a .pac file extension. If the PAC file is hosted on a web server, the proper MIME type, application/x-javascript-config, must be specified. Because all connector communications are already encrypted, https proxy is not supported. For version 3.0.6 of the connector, a SOCKS proxy setting cannot be specified using a PAC file.
The connector attempts to rediscover proxy settings after a certain number of cloud lookups fail. This ensures that when laptops are outside the enterprise network, the connector is able to connect when network proxy settings are changed.
Incompatible Proxy Security Configurations
Some proxy and web security configurations are incompatible with AMP:
Websense NTLM credential caching: The currently supported workaround for AMP is either to disable NTLM credential caching in Websense or to allow the AMP connector to bypass proxy authentication exception.
HTTPS content inspection: HTTPS content inspection breaks the AMP endpoint agent’s communication with the cloud due to certificate pinning and strong authentications. The currently supported workaround is either to disable HTTPS content inspection or to set up exclusions for the AMP connector.
Kerberos/GSSAPI authentication: The AMP connector does not work with these authentication methods. The currently supported workaround is either to use basic or NTLM authentication or to set up an authentication exception.
Using the Cloud Console
When endpoints are running and reporting to the cloud, you see a populated dashboard and can look for malware, threats, and indicators of compromise.
Figure 8-77 shows the AMP dashboard, indicating that one of the computers with an AMP connector loaded has indicators of compromise, five counts of malware detected on it, and even a list of the malware threats.
If you click Threat Detected link in the Indications of Compromise section on the dashboard (see Figure 8-77), you are taken to the Events tab, but the filters are prepopulated, as shown in Figure 8-78.
Immediately, you can see that all the malware has the status Quarantine: Success. This means AMP was able to isolate and block the malware. If you drill into one of the pieces of malware detected, you can get more information about the filename, the path, the parent, and more. You can also look into the file trajectory and computer trajectory (see Figure 8-78) to attempt to see where else the file has been and where else the infected computer has been.
If you navigate to Analysis > Events, you get an unfiltered view of all events. If you scroll down, you can see vulnerable applications being reported. As you can see in Figure 8-79, the Windows client that AMP was installed on had a vulnerable version of Java on it, and the vulnerability CVEs are listed.
Upon recognizing systems with vulnerable applications, you can contact the desktop team to have the system updated. Or you can have an indicator of compromise trigger a correlation action in the Firepower Management Center (FMC) that uses a remediation with Cisco Identity Services Engine (ISE) to quarantine the endpoint on the network. This type of solution is known as rapid threat defense with Firepower Management Center and ISE.
Summary
This chapter provides more than an overview of Cisco’s AMP for Endpoints. It reviews the overall AMP architecture and where AMP for Endpoints fits into that architecture. You have learned about the types of AMP for Endpoints connectors, created policies for each of them, and gone through their installations. You have used the AMP cloud console to see whether AMP has detected and remediated malware and detected and reported on threats, and you have seen how to follow file and computer trajectories.