Endpoint Admin Guide PDF
Endpoint Admin Guide PDF
4.0
paloaltonetworks.com/documentation
Table of Contents
Traps Overview....................................................................................................9
About Traps................................................................................................................................................11
Malware Protection Overview..................................................................................................11
Exploit Protection Overview..................................................................................................... 12
Traps Components....................................................................................................................................13
ESM Console................................................................................................................................. 13
ESM Server.................................................................................................................................... 13
Database......................................................................................................................................... 14
Endpoints........................................................................................................................................14
Traps Agent....................................................................................................................................14
External Logging Platform..........................................................................................................15
WildFire...........................................................................................................................................15
Forensic Folder............................................................................................................................. 16
Prerequisites.......................................................................................................29
Hardware Requirements..........................................................................................................................31
Standalone Endpoint Security Manager Hardware Requirements................................... 31
Distributed Endpoint Security Manager Hardware Requirements...................................31
Traps Hardware Requirements................................................................................................. 33
Software Requirements........................................................................................................................... 35
ESM Console Software Requirements.................................................................................... 35
ESM Server Software Requirements....................................................................................... 35
Database Software Requirements............................................................................................36
Traps Software Requirements...................................................................................................37
VDI........................................................................................................................63
VDI Overview............................................................................................................................................ 65
Virtualized Applications and Desktops................................................................................... 65
VDI Modes..................................................................................................................................... 65
VDI Installation Considerations............................................................................................................. 67
Set Up Traps in a VDI Environment Overview................................................................................. 68
Set Up the Golden Image....................................................................................................................... 70
Prerequisites for Configuring the Golden Image..................................................................70
Configure the Golden Image..................................................................................................... 71
Traps VDI Tool CLI...................................................................................................................... 73
Configure Traps VDI Settings................................................................................................................ 76
Configure Traps for a Non-Persistent Storage Scenario.................................................... 76
Configure Traps for a Persistent Storage Scenario..............................................................76
Tune and Test the VDI Policy............................................................................................................... 79
Monitoring........................................................................................................103
Maintain the Endpoints and Traps.....................................................................................................105
Use the Endpoint Security Manager Dashboard............................................................................ 106
Monitor Security Events....................................................................................................................... 107
Use the Security Events Dashboard..................................................................................... 107
View the Security Event History on an Endpoint..............................................................109
Monitor the Endpoints.......................................................................................................................... 111
iv TABLE OF CONTENTS
View Endpoint Health Details................................................................................................ 111
View Notifications About Changes in the Agent Status.................................................. 111
View the Status of the Agent from the Traps Console.................................................... 112
View the Rule History of an Endpoint................................................................................. 113
View Changes to the Security Policy from the Traps Console....................................... 113
View the Service Status History of an Endpoint............................................................... 114
Remove an Endpoint from the ESM Console..................................................................... 114
Monitor the ESM Servers.....................................................................................................................116
View the Health of the ESM Servers................................................................................... 116
View Notifications About the ESM Server..........................................................................116
View the Rule Summary....................................................................................................................... 117
Monitor Forensics Retrieval.................................................................................................................118
TABLE OF CONTENTS v
Add a New Restriction Rule....................................................................................................154
Manage Global Whitelists........................................................................................................156
Block Execution from Local and Network Folders............................................................ 157
Whitelist a Network Folder.....................................................................................................158
Define External Media Restrictions.......................................................................................159
Define Child Process Restrictions......................................................................................... 160
Define Java Restrictions...........................................................................................................161
WildFire Integration............................................................................................................................... 163
WildFire Integration Concepts............................................................................................... 163
Set Up the ESM to Communicate with WildFire...............................................................164
Set Up a Private WildFire Cloud........................................................................................... 166
Configure a WildFire Rule....................................................................................................... 167
Manage Hashes for Executable Files................................................................................................ 171
View and Search Hashes......................................................................................................... 171
Export and Import Hashes.......................................................................................................177
View a WildFire Report............................................................................................................178
View the History of a Verdict................................................................................................ 178
Override a WildFire Verdict....................................................................................................179
Recheck a WildFire Decision.................................................................................................. 180
Report an Incorrect Verdict.................................................................................................... 180
Upload a File to WildFire for Analysis................................................................................. 181
Manage Quarantine Settings.................................................................................................. 181
Restore a Quarantined File..................................................................................................... 182
Exploit Protection...........................................................................................185
Exploit Protection Rules....................................................................................................................... 187
Windows Exploit Protection Modules (EPMs)................................................................................ 188
Mac Exploit Protection Modules (EPMs)..........................................................................................190
Create an Exploit Protection Rule......................................................................................................191
Exclude an Endpoint from an Exploit Protection Rule.................................................................. 194
Forensics........................................................................................................... 215
Forensics Overview................................................................................................................................217
Forensics Flow............................................................................................................................217
vi TABLE OF CONTENTS
Forensic Data Types................................................................................................................. 218
Best Practices for Managing Forensic Data.................................................................................... 220
Manage Forensics Rules and Settings...............................................................................................221
Forensics Rules...........................................................................................................................221
Change the Default Forensic Folder.....................................................................................221
Create a Forensics Rule........................................................................................................... 223
Define Memory Dump Preferences...................................................................................... 224
Define Forensics Collection Preferences.............................................................................225
Retrieve Data About a Security Event................................................................................. 226
Agent Query............................................................................................................................................ 228
Agent Query Flow..................................................................................................................... 228
Search Endpoints for a File, Folder, or Registry Key........................................................ 228
View the Results of an Agent Query....................................................................................229
Troubleshooting.............................................................................................. 317
Traps Troubleshooting Resources...................................................................................................... 319
9
10 TRAPS ADMINISTRATOR'S GUIDE | Traps Overview
About Traps
Cyberattacks are attacks performed on networks or endpoints to inflict damage, steal information, or
achieve other goals that involve taking control over computer systems that do not belong to the attackers.
Adversaries perpetrate cyberattacks either by causing a user to unintentionally run a malicious executable
file or by exploiting a weakness in a legitimate executable file to run malicious code behind the scenes
without the knowledge of the user.
One way to prevent these attacks is to identify executable files, dynamic-link libraries (DLLs), or other
pieces of code as malicious and then prevent them from executing by testing each potentially dangerous
code module against a list of specific, known threat signatures. The weakness of this method is that it is
time-consuming for signature-based antivirus (AV) solutions to identify newly created threats that are
known only to the attacker (also known as zero-day attacks or exploits) and add them to the lists of known
threats, which leaves endpoints vulnerable until signatures are updated.
The Traps solution takes a more effective and efficient approach to preventing attacks thus eliminating the
need for traditional AV. Rather than try to keep up with the ever-growing list of known threats, Traps sets
up a series of roadblocks that prevent the attacks at their initial entry pointsthat point where legitimate
executable files are about to unknowingly allow malicious access to the system.
Traps targets software vulnerabilities in processes that open non-executable files using exploit prevention
techniques. Traps also uses malware prevention techniques to prevent malicious executable files from
running. Using this two-fold approach, the Traps solution can prevent all types of attacks, whether they are
known or unknown threats.
All aspects of endpoint security settingsthe endpoints and groups to which settings are applied, the
applications they protect, the defined rules, the restrictions, and the actionsare all highly configurable.
This allows each organization to tailor Traps to its needs so that Traps can provide maximum protection
with minimal disruption of day-to-day activities.
Malware Protection Overview
Exploit Protection Overview
To combat these types of attacks, Traps employs Exploit Protection. When a user opens a non-executable
file, such as a PDF or Word document, and the process that opened the file is protected, the Traps agent
seamlessly injects code into the software. This occurs at the earliest possible stage before any files
belonging to the process are loaded into memory. The Traps agent then activates one or more Exploit
Protection Modules (see Windows Exploit Protection Modules (EPMs) and Mac Exploit Protection Modules
(EPMs)) inside the protected process. The EPM targets a specific exploitation technique and is designed to
prevent attacks on program vulnerabilities based on memory corruption or logic flaws.
Examples of attacks that the EPMs can prevent include dynamic-link library (DLL) hijacking (replacing
a legitimate DLL with a malicious one of the same name), hijacking program control flow, and inserting
malicious code as an exception handler.
In addition to automatically protecting processes from such attacks, Traps reports any prevention events
to the Endpoint Security Manager, and performs additional actions according to the settings of the security
policy rules. Common actions that Traps performs include collecting forensic data and notifying the user
about the event. Traps does not perform any additional scanning or monitoring actions.
The default endpoint security policy protects the most vulnerable and most commonly used applications,
but you can also add other third-party and proprietary applications to the list of protected processes. For
more information, see Add a New Protected Process.
The following topics describe the Traps and other components in more detail.
ESM Console on page 13
ESM Server on page 13
Database on page 14
Endpoints on page 14
Traps Agent on page 14
External Logging Platform on page 15
WildFire on page 15
Forensic Folder on page 16
ESM Console
The Endpoint Security Manager (ESM) Console is a web interface that enables you to manage security
events, monitor endpoint health, and configure policy rules from a web browser. The ESM Console
communicates with the database independently from the ESM Server. You can install the ESM Console on
the same server as the ESM Server, on a separate server, or on a cloud-based server.
As a best practice, use a single ESM Console to manage the ESM Server(s) in your Traps
deployment. Using multiple ESM Consoles is not supported.
For information on hardware and software requirements for the ESM Console, see ESM Console Software
Requirements.
ESM Server
The Endpoint Security Manager (ESM) Server functions as the connection server that relays information
between the ESM components, including the Traps agent, and WildFire. Each ESM Server supports up to
Database
The database stores administrative information, security policy rules, endpoint history, and other
information about security events. The database is managed over the MS-SQL platform. Each database
requires a license and can communicate with one or more ESM Servers. The database may be installed on
the same server as the ESM Console and ESM Server, such as in a standalone environment, or the database
can be installed on a dedicated server. For information on hardware and software requirements for the
database, see Database Software Requirements.
During evaluation we recommend you use SQL Server Express which enables you to easily
migrate the database to SQL Server Standard or SQL Server Enterprise.
Endpoints
An endpoint is a Windows- or Mac-based computer, server, virtual machine, tablet, or mobile device
running the client-side protection application named Traps. For prerequisites, see Traps Software
Requirements.
Traps Agent
The Traps agent protects the endpoint by enforcing your organizations security policy as defined in
the Endpoint Security Manager. Depending on the configuration, Traps can protect against attempts to
exploit software vulnerabilities and bugs and can prevent malicious executable files from running on your
endpoints.
When a security event occurs on an endpoint, Traps collects forensic information about that event and,
optionally, can also notify the user about the event and even display a custom notification message. On
a regular basis, Traps communicates the status of the endpoint and transmits data related to any security
events to the Endpoint Security Manager. The following table describes the types of messages that the
Traps agent sends to the ESM Server:
Traps status The Traps agent periodically sends messages to the ESM Server to
indicate that it is operational and to request the latest security policy. The
Notifications and Health pages in the Endpoint Security Manager display
the status for each endpoint. The duration between messages, known as the
heartbeat period, is configurable.
Notifications The Traps agent sends notification messages about changes in the agent, such
as when a service starts or stops, to the ESM Server. The server logs these
notifications in the database and you can view the notifications in the ESM
Console.
Updates An end user can request an immediate policy update by clicking Check In
Now on the Traps Console. This causes the Traps agent to request the latest
security policy from the ESM Server without waiting for the end of the
heartbeat period.
Prevention reports If a prevention event occurs on an endpoint where the Traps agent is
installed, the Traps agent reports all of event-related information to the ESM
Server in real-time.
Traps also provides a user interface that you can use to view the protection status on the endpoint, security
event history, running processes, and current security policy rules. Usually, a user will not need to run the
Traps Console but the information can be useful when investigating a security-related event. If needed,
you can choose to hide the console icon that launches the console or prevent users from launching the
console from an endpoint altogether. If you provide access to the Traps Console, you can access it from the
notification area (system tray) on an endpoint.
WildFire
The Traps agent is designed to block attacks before any malicious code can run on the endpoint. While this
approach ensures the safety of data and infrastructure, it enables the collection of forensic evidence only
at the moment of prevention. And while Traps can prevent the attack, Traps alone cannot fully reveal the
purpose of the attack or its entire flow.
To provide more insight into malware activity, the Endpoint Security Manager supports WildFire
integration. This enables the Endpoint Security Manager to send any unknown executable files to WildFire,
a malware analysis environment that turns unknown threats into preventable incidents.
You can integrate WildFire with your Endpoint Security Manager using either of the following two options:
WildFire public cloudThe WildFire Virtual Environment analyzes and identifies previously unknown
malware and generates signatures that Palo Alto Networks firewalls and Palo Alto Networks Endpoint
Security Managers can use to detect and block the malware. When Traps detects an unknown sample
(an executable file or macro), the Endpoint Security Manager can automatically forward the sample for
WildFire analysis.
The local WF-500 appliance is ideal for deployments with privacy and legal regulations that restrict the
transfer of files outside your network. The WildFire-500 appliance queries the WildFire public cloud
to obtain the verdict and, if unknown, analyzes the executable file in the local sandbox. By default, the
WF-500 appliance does not send discovered malware outside your network, however, you can choose
to automatically forward malware to the WildFire public cloud to generate and distribute signatures to
all Palo Alto Networks firewalls with Threat Prevention and WildFire licenses. Otherwise, the WF-500
appliance only forwards the malware report (and not the sample itself) to the WildFire public cloud.
If WildFire integration is enabled in the ESM Console, the Status page of the Traps Console displays a
next to Forensic Data Collection. If WildFire is not enabled, the Traps Console displays an next to
Forensic Data Collection.
For more information, see Set Up the ESM to Communicate with WildFire and Malware Protection Flow.
Forensic Folder
When Traps encounters a security-related event, such as a file execution or an exploit attack, it logs real-
time forensic details about the event on the endpoint. The forensic data includes the memory dump and
other information associated with the event. You can retrieve the forensic data by creating an action rule to
collect the data from the endpoint. After the endpoint receives the security policy that includes the action
rule, the Traps agent sends all the forensic information to the forensic folder, which is sometimes referred
to as the quarantine folder.
During the initial installation, you specify the path of the forensic folder that the Endpoint Security Manager
uses to store forensic information it retrieves from endpoints. The Endpoint Security Manager supports
multiple forensic folders and enables the Background Intelligent Transfer Service (BITS) on the folder during
19
20 TRAPS ADMINISTRATOR'S GUIDE | Traps Deployment Scenarios
Standalone Deployment
For an initial proof of concept (POC) or a small site with fewer than 3000 Traps agents, use a standalone
deployment to install the following Endpoint Security Manager (ESM) components on a single server or
virtual machine:
ESM Server
ESM Console
Forensic (quarantine) folder
Database
(Recommended) WildFire integration
(Optional) Load balancer for distributing traffic across ESM Servers
(Optional) External logging platform, such as an SIEM or syslog
For best practices on using a phased approach for installing Traps on endpoints, see Recommended Traps
Deployment Process on page 53.
This single-site deployment scenario supports up to 16,000 Traps agents in Traps ESM 4.0.0 or up to
30,000 Traps agents in Traps ESM 4.0.1 and consists of the following components:
One dedicated database server
One ESM Console for managing the security policy and Traps agents
Two ESM Servers, one primary and one backup, on the same network segment as the database server
and ESM Console
One forensic folder accessible by all endpoints for storing real-time forensic details about security
events
(Recommended) WildFire integration
(Optional) Load balancer for distributing traffic across ESM Servers
(Optional) External logging platform, such as an SIEM or syslog
In this deployment scenario, a single site contains the database, ESM Console for managing local policies
and endpoints, and redundant ESM Servers. In the event that the primary ESM Server is inaccessible, Traps
agents connect to the Endpoint Security Manager using the backup server. Both servers obtain the security
policy from the database and distribute the policy to the agents.
This multi-site deployment scenario supports up to 32,000 Traps agents if using Traps ESM 4.0.0 or 60,000
Traps agents if using Traps ESM 4.0.1 and consists of the following components:
One dedicated database server at one of the sites
One ESM Console in the same location as the database for managing the security policy and Traps
agents
One ESM Server per site or two ESM Servers per site for redundancy
One forensic folder accessible by all endpoints for storing real-time forensic details about security
events
(Recommended) WildFire integration
(Optional) Load balancer for distributing traffic across ESM Servers
(Optional) External logging platform, such as an SIEM or syslog
In this deployment scenario, Site A contains an ESM Server, database, and ESM Console for managing local
policies and endpoints. Site B contains a second ESM Server that is capable of supporting up to 16,000
additional agents in Traps ESM 4.0.0 or 30,000 additional agents in Traps ESM 4.0.1. Both servers obtain
the security policy from the database located in Site A and distribute the policy to the agents. The agents
connect to the primary ESM Server on their site while the ESM Server in the other site acts as a secondary
backup server.
This single-site deployment scenario supports up to 80,000 Traps agents in Traps ESM 4.0.0 or 150,000
Traps agents in Traps ESM 4.0.1 and consists of the following components:
One dedicated database server
One ESM Console in the same location as the database for managing the security policy and Traps
agents
One ESM Server 4.0.0 for every 16,000 Traps agents (for a maximum of 80,000 agents) or one ESM
Server 4.0.1 for every 30,000 Traps agents (for a maximum of 150,000 agents).
One forensic folder for each ESM Server that is accessible by all endpoints for storing real-time forensic
details about security events
(Recommended) WildFire integration
(Optional) Load balancer for distributing traffic across ESM Servers
(Optional) External logging platform such as an SIEM or syslog
In this example, up to 80,000 (4.0.0) or 130,000 (4.0.1) Traps agents can connect to the Endpoint Security
Manager. To support this scenario, the endpoints connect to five ESM Servers through an optional load
balancer. Each ESM Server connects to a central database that is managed by a dedicated ESM Console.
This multi-site deployment scenario supports up to 80,000 Traps agents in Traps ESM 4.0.0 or 150,000
Traps agents in Traps ESM 4.0.1 and consists of the following components:
One dedicated database server
One ESM Console in the same location as the database for managing the security policy and Traps
agents
One ESM Server for every 16,000 Traps agents (for a maximum of 80,000 agents) in each 4.0.0 site or
30,000 Traps agents (for a maximum of 150,000 agents) in each 4.0.1 site
One forensic folder for each ESM Server that is accessible by all endpoints for storing real-time forensic
details about security events
(Recommended) WildFire integration
(Optional) Load balancer for distributing traffic across ESM Servers
(Optional) External logging platform such as an SIEM or syslog
In this example, Sites A, B, C, D, and E each need to support up to 16,000 Traps agents in Traps ESM 4.0.0
or 30,000 Traps agents in Traps ESM 4.0.1. To support this scenario, you must deploy an ESM Server in
each site that retrieves the security policy from the database located in Site A. The agents connect to the
Endpoint Security Manager using their local ESM Servers as the primary server and use the ESM Servers at
other sites as secondary servers.
One forensic folder for each ESM Server that is accessible by all endpoints for storing real-time forensic
details about security events
(Recommended) WildFire integration
(Optional) Load balancer for distributing traffic across ESM Servers
(Optional) External logging platform such as an SIEM or syslog
In this example, Sites A, B, C, and D each need to support up to 16,000 Traps agents in Traps ESM 4.0.0
or 30,000 Traps agents in Traps ESM 4.0.1. An additional site supports Traps agents that are roaming. To
support this scenario, each site contains an ESM Server that retrieves the security policy from the database
located at Site A. Internal endpoints connect to the Endpoint Security Manager using their local ESM
Servers. External endpoints connect through a publicly available ESM Server located in a DMZ or through a
port that is configured to allow traffic from external networks. If an endpoint is roaming and cannot connect
to the ESM Server, Traps collects prevention data locally until the agent can establish a connection to the
forensic folder.
In Traps ESM 4.0.1, this deployment scenario supports up to 90,000 Traps agents that can connect through
local sites and from off-site locations through a VPN tunnel. To support up to 150,000 Traps agents, you
can deploy two additional 4.0.1 ESM Servers.
In Traps ESM 4.0.0, this deployment scenario supports up to 48,000 Traps agents that can connect through
local sites and from off-site locations through a VPN tunnel. To support up to 80,000 Traps agents, you can
deploy two additional 4.0.0 ESM Servers).
This multi-site environment consists of the following components:
One dedicated database server
One ESM Console in the same location as the database for managing the security policy and Traps
agents
One ESM Server for every 30,000 Traps agents (for a maximum of 150,000 agents) in each 4.0.1 site or
16,000 Traps agents (for a maximum of 80,000 agents) in each 4.0.0 site
GlobalProtect or an alternative VPN gateway to provide roaming users with an internal IP address for
accessing the ESM Server
One forensic folder for each ESM Server that is accessible by all endpoints for storing real-time forensic
details about security events
(Recommended) WildFire integration
29
30 TRAPS ADMINISTRATOR'S GUIDE | Prerequisites
Hardware Requirements
Standalone Endpoint Security Manager Hardware Requirements on page 31
Distributed Endpoint Security Manager Hardware Requirements on page 31
Traps Hardware Requirements on page 33
In a Standalone Deployment on page 21, you install the Endpoint Security Manager componentswhich
consists of the ESM Server, ESM Console, and databaseon the same server. The following table displays
the hardware requirements for the standalone server.
Disk space for Traps First year: 250MB First year: 2.5GB
data Second year: 500MB Second year: 5GB
Third year: 1GB Third year: 10GB
Disk space 3GB plus 3GB plus 3GB plus 3GB plus 3GB plus 3GB plus
50GB for 50GB for 50GB for 50GB for 50GB for 50GB for
the forensic the forensic the forensic the forensic the forensic the forensic
folder folder folder folder folder folder
RAM 4GB RAM 8GB RAM 8GB RAM 8GB RAM 32GB RAM 32GB RAM
Disk space 3GB plus 3GB plus 3GB plus 3GB plus 3GB plus 3GB plus
50GB for 50GB for 50GB for 50GB for 50GB for 50GB for
the forensic the forensic the forensic the forensic the forensic the forensic
folder folder folder folder folder folder
RAM 4GB RAM 8GB RAM 8GB RAM 8GB RAM 32GB RAM 32GB RAM
Consult with the Palo Alto Networks support team if you require integration with an existing
database.
39
40 TRAPS ADMINISTRATOR'S GUIDE | Set Up the Traps Infrastructure
Set Up the Endpoint Infrastructure
Use the following workflow to set up the Endpoint infrastructure or, to upgrade your existing Endpoint
infrastructure, use the workflow to Upgrade to Traps 4.0 described in the Traps 4.0 New Features Guide:
STEP 1 | Log in to the Palo Alto Networks Support Site after you receive the electronic fulfillment email.
STEP 2 | (New license only) Select Assets > Advanced Endpoint Protections > Activate New Auth-Code.
STEP 3 | (New license only) Enter your Traps Auth-Code (found in your electronic fulfillment email) in the
Authorization Code field and then Agree and Submit.
STEP 4 | In the License column, click the download icon ( ) to download the license key.
STEP 5 | Select the version of Traps for which this license key will be used (Pre 3.3, 3.3-3.4, or 4.0) and
then click Download.
STEP 6 | Save the license key to a location you can access from the Endpoint Security Manager.
Enabling SSL for Traps components is a three step-process: First, you must request or issue a certificate
for each ESM Server and ESM Console. Note that traffic between the ESM Server and WildFire does not
require any additional configuration as the ESM Server encrypts traffic using the default trusted third-party
certificates that comes with Windows. Next, you enable SSL encryption during the installation of the ESM
STEP 1 | Request or generate a certificate for each ESM componentserver and consolewith a
purpose of server and client authentication. This certificate must be one that you can export
with a password.
The certificate can have a single name or a wildcard name. A single-name certificate requires the
Common Name (CN) of the certificate to match the fully qualified domain name (FQDN) of the ESM
component (for example, server.trapsserver.com). A wildcard-name certificate enables you to use
the same certificate for multiple ESM components that share the same sub-domain (for example,
*.trapsserver.com can be used for both server.trapsserver.com and console.trapsserver.com). Wildcard-
name certificates are also useful in deployments that use multiple ESM Servers.
STEP 2 | Install the ESM software and enable SSL encryption (for full installation instructions, see Install
the Endpoint Security Manager Server Software and Install the Endpoint Security Manager
Console Software).
1. During the installation of both the ESM Server and ESM Console, select the External Certificate (SSL)
option and browse to the PKCS#12 or PFX file containing the certificate and private key.
If you do not already have a PKCS#12 or PFX file, use your preferred method to
generate it. For example, to do this in IIS, you can use the Export function in the MMC
Console > Certificates snap-in. When you export the certificate and private key, it is
required to set a password to protect the private key.
2. Enter the certificate password.
The installer binds the certificate to the selected agent-ESM communication port.
If you install Traps on the ESM Server and ESM Console, and use either a self-signed or an enterprise
CA certificate, you must also install the certificate on the server as described in the following step.
STEP 3 | (Certificates issued by an enterprise CA and self-signed certificates) Install the certificate in the
trusted root certificate store (CA certificates and self-signed certificates) of the computer
account. Certificates issued by a trusted third-party CA are automatically trusted by the
endpoint due to the chain of trust and do not require installation.
1. Add the certificate to the endpoint using one of the following methods:
Copy the certificates manually.
Include the certificate in the master image for new endpoints.
STEP 2 | Initiate the ESM Server software installation. You can also install the ESM Server using Msiexec
(see Install Traps Components Using Windows Msiexec).
1. Double click the ESMCore installation file.
2. Click Next to begin the setup process.
3. On the End User License Agreement dialog, select the I accept the terms in the License Agreement
check box and then click Next.
4. Keep the default installation folder or click Change to specify a different installation folder and then
click Next.
STEP 3 | Specify the security level for communication between the ESM Server and the Traps agents.
To encrypt communication over SSL, use a server-client certificate file (PFX format) and supply the
password for decrypting the private key.
1. Specify the ESM Server port to use for access to the server or keep the default setting (2125).
2. Select the certificate configuration method:
External Certificate (SSL)Encrypt communication between the server and the agents over SSL
(default). Then Browse to the server-client certificate and enter the password required to decrypt
the private key.
No Certificate (no SSL)Do not encrypt communication between the server and the agents (not
recommended).
3. Click Next.
STEP 4 | Configure the settings that enable communication between the ESM Server and the database.
To set up access to the database, you must specify the authentication method and a user that has
administrative privileges to administer the database. The username (and password) that you enter
depend on the type of authentication method that you select: either Windows authentication
(recommended) or SQL server authentication.
Secure communication between the ESM Server and the database is supported with
only SQL Server Enterprise or SQL Server Standard.
5. Click Next.
If one or more ESM Servers already connect to the database, the installer prompts
you to join the database cluster of ESM Servers. If you select Yes, the installer obtains
the remaining installation settings from the database. Skip to step 7 to complete the
installation.
After installing the ESM Server software, you can Change the Uninstall Password at a
later date by creating an agent settings rule using the ESM Console.
2. Click Next.
STEP 6 | Import the Traps license. If you choose not provide a Traps license during installation, you will
have read-only access to the ESM Console until you add a valid Traps license.
1. Browse to the license file and then click Open. If you do not have a license, contact your Account
Manager, reseller, or go to https://support.paloaltonetworks.com.
The installer displays license details for the license file.
2. Click Next.
STEP 4 | Specify the security level for communication between the administrator and the ESM Console.
To encrypt communication over SSL, use a server-client certificate file (PFX format) and supply the
password for decrypting the private key.
STEP 5 | Configure the settings that enable communication between the ESM Console and the
database.
To set up access to the database, you must specify the authentication method and a user that has
administrative privileges to administer the database. The username (and password) that you enter
depend on the type of authentication method that you select: either Windows authentication
(recommended) or SQL server authentication.
1. Enter the fully qualified domain name or IP address of the database Server Name.
2. Enter the name of the Database Name. If your SQL Server uses an instance other than the default,
you must also include the instance name in the format <instance>/<databasename>.
3. Select the method of authentication and enter the account credentials. This account must also be
added as a database owner on the database server (for more information, see Configure the MS-SQL
Server Database).
Use Windows Authentication to authenticate using a Windows domain user account that
has privileges to administer to the database server and enter the Domain\User (for example,
mydomain\administrator) and Password.
Use SQL Server Authentication to authenticate using a local user that has privileges to administer
the database and enter the Login and Password.
4. (4.0.1 only) To enable secure communication between the ESM Console and the database using TLS/
SSL 1.2:
1. Select Secure DB Connection (SSL). This option enables the ESM Console to encrypt
communication between the ESM Console and the database.
2. For even stricter security, select the option to Validate SQL Server Certificate Signer. This
enables the ESM Console to validate that the certificate the database presents matches a specific
certificate. For validation to succeed, you must import the database certificate into Trusted Root
Certification Authorities.
Secure communication between the ESM Console and the database is supported with
only SQL Server Enterprise or SQL Server Standard.
5. Click Next.
STEP 6 | Configure the settings for the administrative user who will access the ESM Console.
2. Click Next.
STEP 9 | Launch the ESM Console using one of the following methods:
Double-click the icon on the desktop.
Open the program from the Start > All Programs menu.
1. Install Traps on endpoints. 1 week Install the Endpoint Security Manager (ESM), including
an MS SQL database, ESM Console, and ESM Server, and
install the Traps agent on a small number of endpoints (3 to
10).
Test normal behavior of the Traps agents (injection and
policy) and confirm that there is no change in the user
experience.
2. Expand the Traps 2 weeks Gradually expand agent distribution to larger groups that
deployment. have similar attributes (hardware, software, and users). At
the end of two weeks you can have Traps deployed on up
to 100 endpoints.
3. Complete the Traps 2 or more Broadly distribute the Traps agent throughout the
installation. weeks organization until all endpoints are protected.
5. Refine corporate policy Up to 1 Deploy security policy rules to a small number of endpoints
and protected processes. week that use the applications frequently. Fine tune the policy as
needed.
STEP 1 | Initiate the Traps software installation. You can also install Traps using Msiexec (see Install
Traps Components Using Windows Msiexec).
The version(s) of Traps that you install on your endpoints must be the same as or older
than the ESM Server and ESM Console version.
1. Obtain the software from your Palo Alto Networks Account Manager, reseller, or from https://
support.paloaltonetworks.com.
2. Unzip the zip file and double click the Traps installation file; choose either the x64 (64-bit) or x86 (32-
bit) version depending on your endpoints OS.
3. Click Next.
4. Select I accept the terms in the License Agreement and then click Next.
We recommend that you restart the endpoint after completing the installation.
STEP 1 | Download the Traps for Mac software ZIP file from the Supportportal.
The Traps for Mac software version must not exceed the current ESM version. For example, if you use
ESM 4.0.0, you cannot install Traps for Mac 4.0.2. Instead use Traps for Mac 4.0.0.
STEP 2 | Generate the installation package. This package specifies the ESM Server or ESM Servers to
which the agent can connect for the first time. After the first successful connection, the agent
receives a list of all available ESM Servers to use for future connections.
1. From the ESM Console, select Settings > Agent > Installation Package.
2. From the action menu , select Generate Package.
3. Select the ESM Server to which the Traps agent will first connect. The ESM Console automatically
populates the list with any enabled ESM Servers (to review your servers, select Settings > ESM >
Multi ESM).
STEP 4 | When the installation package has finished generating, save the installation package.
1. Select Settings > Agent > Installation Package.
2. Select the Download link next to the installation package and save it to a location that you can reach
from the Mac endpoint.
STEP 5 | Install Traps for Mac on the endpoint. Alternatively, you can use your preferred software
deployment tool to distribute the installation package to multiple Mac endpoints.
STEP 6 | To use SSL for secure communication between the Traps agent and the ESM Server, add the
trusted root CA certificate of the ESM Server on the Mac endpoint.
You must have administrative privileges on the endpoint to perform this step.
1. Export the trusted root CA certificate from the ESM Server and copy it to a location which you can
access from the Mac endpoint.
2. From a command prompt, use the following command to add the certificate with Always Trust
settings:
STEP 2 | Run the msiexec command followed by one or more of the following options or properties:
Install, display, and logging options:
/i <installpath>\<installerfilename>.msiInstall a package. For example,
msiexec /i c:\install\traps.msi.
/qnDisplays no user interface (quiet installation). At minimum, you must also specify the host
server name or IP address using the CYVERA_SERVER property.
/L*v <logpath>\<logfilename>.txtLog verbose output to a file. For example, /L*v c:
\logs\install.txt.
For a full list of Msiexec parameters, see https://www.microsoft.com/resources/documentation/
windows/xp/all/proddocs/en-us/msiexec.mspx
Public properties:
CYVERA_SERVER=<servername>Primary host server name or IP address (default is
ESMserver)
CYVERA_SERVER_PORT=<serverport>Primary host server port (default is 2125)
USE_SSL_PRIMARY=[0|1](Quiet installation only) Set encryption preferences on the primary
server by specifying 0 to not use SSL (not recommended) or 1 to use SSL (default)
We recommend that you restart the device after completing the installation.
STEP 2 | Run the msiexec command followed by one or more of the following options or properties:
Uninstall and logging options:
/x <installpath>\<installerfilename>.msiUninstall a package. For example,
msiexec /x c:\install\traps.msi.
/L*v <logpath>\<logfilename>.txtLog verbose output to a file. For example, /L*v c:
\logs\uninstall.txt.
For a full list of Msiexec parameters, see https://www.microsoft.com/resources/documentation/
windows/xp/all/proddocs/en-us/msiexec.mspx
Public properties:
UNINSTALL_PASSWORD=<uninstallpassword>Specify the administrator password.
To uninstall Traps and log verbose output to a file called uninstallLogFile.txt, enter the following
command:
STEP 2 | Verify the status of the server connection. If Traps is connected to the server, the Connection
status reports that the connection is successful. If the Traps agent is unable to establish a
connection with the primary or secondary server, the Traps Console reports a disconnected
status.
STEP 1 | From the ESM Console, select Monitor > Agent > Health.
63
64 TRAPS ADMINISTRATOR'S GUIDE | VDI
VDI Overview
Your rapidly changing business environment demands a flexible infrastructure to support the evolving
desktop, application, and data access requirements of your staff. By implementing a virtual desktop
infrastructure (VDI), you can empower your employees to work independent of location using a variety of
devices.
An individuals user interface in a virtualized environment is called a virtual desktop. Usually, the virtual
desktop is stored on a remote server rather than locally. Desktop virtualization software separates the
physical machine from the software and presents an isolated operating system for users. When a user logs
on to a VDI infrastructure, the infrastructure supplies the user a hosted desktop image.
A VDI environment usually involves running user desktops inside virtual machines that are hosted on
datacenter servers. In a VDI environment, each user is allotted a dedicated VM that runs a separate
operating system. This is different than a specific VM to which users can connect and from virtualized
applications that run in a regular environment.
Although a VDI solution presents many desktop security advantagesincluding centralized control, reduced
complexity, and efficient management of user access and privilegesit is critical to ensure that the entire
VDI is secure. Securing this new, centralized environment is increasingly difficult. A single IP address can
represent thousands of different users all accessing their applications and data using a variety of devices.
Users can also have access to other applications in your data center besides their virtual desktop. By using
Traps to secure your VDI environment, you can take advantage of the following benefits:
Advanced endpoint protection as part of the Traps solution that prevents sophisticated vulnerability
exploits and unknown malware-driven attacks.
A highly scalable, lightweight Traps agent that uses an innovative new approach for defeating attacks
without requiring any prior knowledge of the threat.
Software that is not dependent on scanning or maintaining external updates.
The following topics describe the VDI deployments in more detail:
Virtualized Applications and Desktops
VDI Modes
VDI Modes
A VDI environment can run in the following modes:
Non-Persistent VDI Mode
Persistent VDI Mode
STEP 5 | Allocate additional licenses to the general agent license pool, if needed.
Add a Traps License Using the ESM Console
STEP 6 | Install Traps on the golden image with the default policy.
Configure the Golden Image
STEP 7 | Configure additional Traps settings based on your VDI deployment scenario.
(Recommended) Configure Traps for a Non-Persistent Storage Scenario
or
Configure Traps for a Persistent Storage Scenario
STEP 1 | Install any software that you plan to have on the VDI instances.
If after completing the process to configure the golden image, you need to install
additional software, you must recreate the WildFire cache file using the Traps VDI tool.
This ensures that Traps obtains verdicts for the new software.
1. Install Traps on the golden image (see Install Traps on Windows Endpoints).
2. Install additional required software.
STEP 2 | Verify that the Traps agent on the golden image can access the ESM Server.
On the Traps agent, click Check In Now to obtain the latest verdicts from the ESM Server. If the ESM
Server is reachable, the status on the console displays Connected.
STEP 3 | Use Cytool to stop Traps services (including local analysis) on the endpoint.
See Start or Stop Traps Runtime Components on the Endpoint. Note that the Traps Reporting Service
remains running.
STEP 4 | Collect all PE files available on the golden image using Sigcheck. This tool creates a file for you
to use as input for the Traps VDI tool.
1. Download Sigcheck (a Windows Sysinternals utility) from https://technet.microsoft.com/en-us/
sysinternals/bb897441.aspx.
2. Open a command prompt as an administrator and navigate to the directory to which you downloaded
Sigcheck.
3. Run Sigcheck recursively to find executable files regardless of extension and output the hashes in
comma-separated format to a folder and file name of your choice.
The following examples show the commands you can use in two different versions of Sigcheck:
There are two versions of the VDI tool: 32-bit and 64-bit. Use the version of VDI tool that
matches the VDI architecture.
STEP 2 | Use the Traps VDI Tool to obtain verdicts for all PE files (collected in 4).
A command-line version of the Traps VDI tool is also available. See Traps VDI Tool CLI.
The Traps VDI tool communicates with the ESM Server to request any verdicts the server has stored
in its server cache. The Traps VDI tool then creates a WildFire cache which can contain any of the
following verdicts for each hash: malicious, benign, or unknown. A hash has an unknown verdict if the
ESM Server has not submitted the sample to or received an updated verdict from WildFire.
STEP 5 | Identify the golden image as a VDI instance. The method by which you identify the golden
image depends on the VDI mode.
STEP 1 | Download and unzip the Traps VDI Tool on the golden image.
STEP 3 | Navigate to the folder that contains the Traps VDI Tool CLI:
C:\Users\Administrator>cd C:\TrapsVDItool
TrapsVdiTool -s:password -m
Identify the computer as VDI without performing hash checks.
STEP 5 | Specify arguments to create the WildFire cache file or to mark the golden image as a VDI
instance. For example:
TrapsVdiTool -i:c:\temp\sig.csv -e:192.168.70.100 -ssl -to:1
The Traps VDI Tool requests verdicts for the hashes in the c:\temp\sig.csv input file, from the ESM
Server with the IP address 192.168.70.100, over a secure connection, and limits the execution time
to 1 hour.
All the other arguments are set to their default values.
TrapsVdiTool "-i:c:\temp\sig file.csv" -v -w
The Traps VDI Tool requests verdicts for the hashes in the c:\temp\sig file.csv input file from
the default ESM Server, and creates the cache file only after it has received verdicts for all hashes.
Note the file path is enclosed in quotes because the filename contains a space.
TrapsVdiTool -m:password
The Traps VDI Tool identifies the golden image as a VDI instance without performing hash checks.
STEP 1 | Open the Windows Registry and locate the CyveraService key in HKEY_LOCAL_MACHINE
\SYSTEM\CurrentControlSet\Services\
STEP 2 | Reset the services state before the image is sealed and migrated into a test or production
environment.
On the golden image, create a batch file using the Shutdown Script and then run it.
Startup Script
set drivepath=D:\
set datapath=%drivepath%\ProgramData\Cyvera
set policypath=%ProgramData%\CyveraNotInUse\LocalSystem\Data
\ClientPolicy.json
IF EXIST %drivepath% (
IF EXIST %ProgramData%\Cyvera (
rename %ProgramData%\Cyvera CyveraNotInUse
)
%windir%\system32\cmd.exe /c mklink /J %ProgramData%\Cyvera %datapath% 2>&1
IF NOT EXIST %datapath% (
mkdir %datapath%
)
IF NOT EXIST %datapath%\Everyone\Data (
mkdir %datapath%\Everyone\Data
)
IF NOT EXIST %datapath%\Everyone\Temp (
mkdir %datapath%\Everyone\Temp
)
IF NOT EXIST %datapath%\LocalSystem (
mkdir %datapath%\LocalSystem
)
IF EXIST %datapath%\LocalSystem\ClientPolicy.* (
del /F %datapath%\LocalSystem\ClientPolicy.*
)
IF NOT EXIST %datapath%\LocalSystem\Data (
mkdir %datapath%\LocalSystem\Data
copy %policypath% %datapath%\LocalSystem\Data\ClientPolicy.json
)
IF NOT EXIST %datapath%\Logs (
mkdir %datapath%\Logs
)
IF NOT EXIST %datapath%\Prevention (
mkdir %datapath%\Prevention
)
IF NOT EXIST %datapath%\Quarantine (
mkdir %datapath%\Quarantine
)
IF NOT EXIST %datapath%\Administrators\Temp (
mkdir %datapath%\Administrators\Temp
)
)
Shutdown Script
STEP 1 | Install Traps on a test machine (either the golden image or a non-VDI instance) and fine-tune
the exploit and malware protection policies.
Use the built-in VDI condition to apply rules to VDI instances only.
STEP 2 | Use the golden image to spawn a small pool of persistent sessions (2 or 3). Deploy the sessions
in a production environment and imitate the expected day-to-day user behavior, such as
browsing, development, and dedicated application usage).
STEP 3 | Gather additional information during this period to further optimize the default session policy
and test any special restrictions applied to the non-persistent sessions. Typically, clients
deployed in persistent mode enable better forensics collection than clients deployed in non-
persistent mode.
STEP 4 | Resolve any stability issues on the test machine and on the test VDI pool that were caused by
the exploit or malware protection policies.
STEP 5 | After the VDI server spawns a session from the golden image and connects to the ESM
Server, disconnect the golden image. Then revise the VDI policy so that WildFire integration
is enabled, EPM Injection is set according to the configuration tested on the golden image,
heartbeat and reporting settings use longer intervals (60 minutes is recommended), and
memory dumps are sent automatically.
Traps will replace the initial golden image with the revised VDI policy. Changing the VDI policy affects all
spawned session on the next restart.
STEP 6 | Log into the ESM Console and verify the health of the VDI instances on the Monitor > Agent >
Health page. If your organization uses a mixed environment, you can filter the machine Type
column to show only VDI instances. The status of the VDI instances should be connected.
81
82 TRAPS ADMINISTRATOR'S GUIDE | Administer the ESM Server
Manage ESM Server Settings
The ESM Server facilitates communication between Traps agents and WildFire.
The ESM Server periodically communicates with WildFire to:
Send unknown files for analysis
Request verdicts associated with executable files and files containing macros
Submit requests to reanalyze a file
The ESM communicates with Traps agents to perform three primary tasks:
Retrieve the operational status of the agent
Obtain reports on processes running on the endpoint
Send the latest security policy.
You can change the frequency of these communications between the server and the endpoint using the
Database (DB) Configuration Tool (see Configure ESM Server Settings Using the DB Configuration Tool) or
using the ESM Console.
STEP 1 | From the ESM Console, select Settings > ESM > Settings.
STEP 2 | Configure any of the following settings for the ESM Server:
Quarantine Network Path(Traps 3.1 and earlier versions) Default forensic folder to use when the
Traps agent cannot reach the folder associated with the ESM Server to which the agent is connected.
Inventory Interval (Minutes)Enter the frequency at which Traps sends a list to the ESM Server to
report the applications that are running on the endpoint.
Heartbeat Grace Period (Seconds)Enter the allowable grace period for a Traps agent that has not
responded (range is 300 to 86,400; default is 4200).
Forensic Folder URLBITS-enabled forensic folder URL.
To encrypt forensic data, we strongly recommend that you use SSL to communicate
with the forensic folder. To use SSL, include the fully qualified domain name (FQDN)
and specify port 443 (for example, HTTPS://ESMserver.Domain.local:443/
BitsUploads). If you do not want to use SSL, specify port 80 (for example, http://
ESMSERVER:80/BitsUploads).
Keep-alive Timeout (Minutes)Period of time (in minutes) after which the ESM sends a keep-alive
message to an external logging platform (range is 0 or greater; default is 0). The keep-alive message
alerts the external logging platform that the ESM component is up and collecting logs. The ESM
Console indicates the time at which each ESM Server sent the last keep-alive message in the Last
Heartbeat field on the additional details view of the ESM Server on the Settings > ESM > Multi ESM
page.
Update From Server Package AddressExternally accessible URL of the ESM Console used to host
upgrade packages for Traps agents. By default, when you configure an action rule to upgrade the
Traps software, the rule is configured to use the ESM Console hostname. If the ESM Console is
accessible by the DNS record only and not by the default ESM Console hostname, use this field to
specify a URL beginning with an HTTP or HTTPS prefix followed by the DNS record.
If you do not specify a server URL in this field, the action rule to upgrade agents uses
your current session to determine the SSL preference. For example, if you log into the
ESM Console using HTTP and create an action rule to upgrade the agents, the agents
receive an upgrade path with an HTTP prefix. If you log in using HTTPS, the agents
receive an HTTPS prefix.
STEP 3 | (Optional) For deployments that use multiple ESM Servers, you can also configure each ESM
Server to communicate with WildFire through a proxy server.
1. Select Settings > ESM > Multi ESM.
2. Select the row for the ESM Server for which you want to configure proxy communication. The ESM
Console displays the settings associated with the server.
3. Select Edit.
4. Enable Proxy communication.
5. Enter the FQDN or IP address of the proxy server in the Proxy Host/IP field and a Proxy Port
number (default is 8080). Optionally, enable Proxy Authentication and then enter the Username
and Passwordusing only ISO-8859-1 charactersthe ESM Server will use to authenticate with the
proxy server.
6. Save your changes to the ESM Server settings.
7. Repeat this process to configure proxy configuration for other ESM Servers, if desired. You can
configure the same proxy settings across multiple ESM Servers, or configure proxy settings that are
unique to each server.
For more information, see Manage Multiple ESM Servers.
STEP 1 | From the ESM Console, select Settings > ESM > Settings.
STEP 2 | Configure any of the following settings for the ESM Console:
Dashboard Display Period (Days)Number of days used to generate dashboard charts and graphs.
By default, the ESM Console displays information collected over the past 30 days (range 1-10,000).
User Authentication ModeMethod to authentication ESM Console users, either Machine (local), or
Domain.
ProxyEnter the FQDN or IP address of the proxy server in the Proxy Host/IP field and a Proxy Port
number (default is 8080). Optionally, enable Proxy Authentication and then enter the Username and
Passwordusing only ISO-8859-1 charactersthe ESM Console will use to authenticate with the
proxy server.
What Logic Does the Agent Use When Selecting an ESM Server?
At regular heartbeat intervals, the Traps agent receives a list of all known ESM Servers. To evaluate the
ESM Server to which the agent will connect, Traps considers the priority and TTL (in terms of number of
hops) for each server. Traps prioritizes the list of ESM Servers by internal IP address (priority 1), external
IP address (priority 2), followed by the ESM Server specified during the agent installation (priority 3). For
example, consider the following scenario with four ESM Servers:
A 2 3
B 1 4
C 2 5
D (default install) 2 5
After evaluating the TTL value for each ESM Server, Traps builds an ordered list:
Priority=1, TTL=1, Latency=10.00ms, Address=https://
esmserverB.example.com:2125/
Priority=1, TTL=2, Latency=20.00ms, Address=https://
esmserverA.example.com:2125/
Priority=1, TTL=2, Latency=20.00ms, Address=https://
esmserverC.example.com:2125/
If you remove or temporarily disable an ESM Server, the ESM Console removes the ESM
Server from the list of available ESM Servers and pushes it to Traps agents at the next
heartbeat. However, if you specified the (now disabled) ESM Server during the Traps
installation, those agents retain the (priority 3) ESM Server in the list of available ESM
Servers to which they can connect.
You can modify the configuration settings for the ESM Servers at any time. You can also temporarily
disable, activate, or remove an ESM Server, as needed.
Disable an ESM Server Select Disable Selected from the action menu at the top of the page.
The ESM Console changes the status of the server to Disabled. This action
temporarily removes the ESM Server from the available server pool of
ESM Servers to which the Traps agents can connect; However, if the ESM
Server was specified during the Traps installation, the agent retains the
ESM Server on its list of available servers.
This option also allows you to reactivate the ESM Server at a later date.
Delete an ESM Server To remove an ESM Server from service, select Delete Selected from the
action menu at the top of the page. This action permanently removes
the ESM Server from the ESM Console and from the available server
pool of ESM Servers to which the Traps agents can connect; However,
if the ESM Server was specified during the Traps installation, the agent
retains the ESM Server on its list of available servers. You cannot reactive
a deleted ESM Server unless you first reinstall it.
Activate an ESM Server Select Activate Selected from the action menu at the top of the page.
This action adds the disabled ESM Server back in to the available servers
pool.
In earlier Traps releases, the ESM Console maintained separate license pools for each
type of endpoint. To extend or allocate additional licenses to Traps agents running versions
earlier than Traps 4.0, make sure you select the appropriate agent version when requesting
new licenses from the Support portal.
STEP 1 | Before you begin: Obtain a license from your Palo Alto Networks Account Manager or reseller.
STEP 2 | Select Settings > Licensing and then Add a new license.
STEP 4 | (Optional) To verify the Traps license utilization, select Dashboard and view the License
Capacity.
STEP 5 | (Optional) To export the license information to a CSV file, select Settings > Licensing, click the
action menu , and then select Export Logs.
STEP 6 | (Optional) By default, the ESM Server automatically revokes the license from an agent which
has not connected to an ESM Server within a 90-day period. To change the number of days in
which the ESM Server revokes a license or to prevent Automatic Revocation, see Manage ESM
Server Settings.
All commands you run using the DB Configuration Tool are case sensitive.
STEP 1 | Before you begin: Obtain a license from your Palo Alto Networks Account Manager or reseller.
The DB Configuration Tool uploads the license file. To verify the license using the ESM Console, see Add
a Traps License Using the ESM Console.
Administrative Roles
Role-based access control (RBAC) enables you to use preconfigured or define custom roles to assign access
rights to administrative users. Each role extends specific privileges to users you assign to the role and
each privilege defines access to specific configuration settings and pages within the ESM Console. By
customizing a role and assigning specific privileges, you can enforce the separation of information among
functional or regional areas of your organization to protect the privacy of data on the ESM Console.
The way you configure administrative access depends on the security requirements of your organization.
Use roles to assign specific access privileges to administrative user accounts. By default, the ESM Console
has built-in roles with specific access rights that cannot be changed. When new features are added to the
product, the ESM Console automatically adds new features to the default role definitions. The following
table lists built-in roles and the access privileges associated with each:
Role Privileges
IT Administrator Read-write access to monitor and configuration settings pages and read-only
access to all other pages in the ESM Console; does not include the ability to
disable all protection.
Security Administrator Read-write access to policy configuration, monitoring, and settings pages in
the ESM Console, including the ability to disable all protection. This role also
includes read-only access to the agent health pages but no access to the server
health or licenses pages.
While you cannot change the privileges associated with the built-in roles, you can create custom roles that
provide more granular access control over the functional areas of the web interface. For these roles, you
Administrative Privileges
For each custom administrative role that you create, you can select the privileges and levels of access for
each privilege. The levels of access for each privilege are:
EnableAllow read/write access to a page in the ESM Console.
DisableHide access to a page.
Read OnlyAllow a user to view but not modify a page.
The following table describes the privileges that you can customize for each role.
Privilege Description
Is Active Users whom are assigned this role can log in to the ESM
Console.
Enable License Notifications The ESM Console displays license notifications to users
who have this privilege enabled when a license is due to
expire or has expired.
Exploit Access to all exploit protection rule pages where you can
view user-defined and default exploit protection rules. If
your access permits, you can also configure new or modify
existing rules and processes. For more granular control,
configure access by Exploit page:
Protection Modules (Application Protection Modules)
Kernel Protection Modules
Process Management
Data Retrieval Access to the data retrieval monitoring page where you
can monitor the status of data uploaded to the ESM
Server, and export or delete data.
Conditions Access to view and create conditions that you can use in
policy rules.
Administrative Users
An administrative user is a local or domain user account that has access to specific administrative or
reporting functions on the ESM Console. Using role-based access control (RBAC), you can assign specific
privileges and responsibilities to a role and then assign that role to one or more users who require the same
access permissions.
As a best practice, create a separate administrative account for each person who
needs access to the ESM Console. This provides better protection against unauthorized
configuration (or modification) and enables logging of all actions for each individual
administrator.
Use the ESM Console to assign administrative access to any of the following account types:
Organizational Unit (Domain authentication only) Extends administrative access to all members
of an organizational unit and uses the authentication credentials defined in
Active Directory to authenticates the user.
The ESM Console does not retain credentials for any administrative account. To change the
credentials of an administrative account, you must modify them on the local machine if using
machine authentication or in Active Directory if using domain authentication.
Administrative Authentication
When you install the ESM Console, you specify the administrative user and type of authentication that
the ESM Console uses to authenticate administrative users. You can change these preferences using
the Database (DB) Configuration Tool on page 323 (see Configure Administrative Access to the ESM
Console Using the DB Configuration Tool on page 324) or using the ESM Console (see Configure the
Authentication Mode on page 98). You can also specify a preexisting authentication group to use for
administrative access. By default, no groups are specified.
You can configure the following types of administrator authentication:
Machine Uses accounts that are local to the ESM Console server for administrative
access.
From the Administration > Roles page, you can see all the built-in and custom roles for your organization.
Creating custom roles enables you to tailor the access permissions around the security requirements for
your organization.
Each role shows the role name and description, the number of users that are assigned to the role, and the
date the role was created. Selecting the row for a role expands that row to display additional details and
actions. The actions you can perform on the role vary for both built-in and custom roles.
While you cannot modify or delete any of the built-in roles, you can view the access privileges that are
associated with the role. You can, however, add, modify, or delete a custom role. You can also block any
role to prevent users that are assigned to that role from logging in to the ESM Console. Similarly, deleting
a custom role removes the access privileges associated with that role from the ESM Console and prevents
users from logging in to the ESM Console if they are assigned to that role. The ESM Console displays
blocked roles with a red icon in the status column.
STEP 1 | From the ESM Console, select Settings > Administration > Roles. The ESM Console displays all
built-in and customized roles for your organization.
STEP 2 | Select and then Edit an existing role, or Add a new one.
STEP 4 | Select the Is Active option to enable the role or deselect the option to disable the role.
STEP 5 | Select a privilege to toggle through the different levels of access for that privilege. By default,
all privileges are disabled. Selecting the privilege once changes the setting to Read Only
access; selecting the privilege again changes the access level to read-write access (Enable); and
selecting the privilege from an enabled state disables the privilege.
STEP 6 | Click Save. The ESM Console displays the new or modified role in the table.
STEP 7 | Assign the role to a user. See Configure Administrative Users, Groups, or Organizational Units
on page 97.
From the Settings > Administration > Users page, you can view all the accounts that provide administrative
access to the ESM Console. An account can be a user, a group, or an organizational unit. To provide
administrative access to a group or organizational unit, the account must exist on the domain. To provide
administrative access to a user, you can add either a user on the local machine or a user on the domain. The
ESM Console uses the domain or the credentials defined on the local machine to authenticate the user.
As a best practice, create a separate account for each user that requires access to the ESM
Console.
For each account, the ESM Console displays the account status (Blocked or Unblocked), the account Name,
the assigned Role, and the date that the account was created. Selecting the row for an account will expand
the row to display additional details and actions, including who created the role (System, DbConfig, or the
administrative account that is logged into the ESM Console). The actions you can perform on a role vary
depending on where the role was created. If you have permissions to do so, you can edit, block, unblock, or
delete any account created by other administrative users but you cannot block or delete accounts that were
created from DBconfig.
Blocking an account prevents that account from logging in to the ESM Console. Similarly, deleting an
account removes the account and settings from the ESM Console and prevents the account from logging in
to the ESM Console. When a role that is associated with an account is blocked, the ESM Console displays
the Role as <role name> (inactive). When a role that is associated with an account is deleted, the
ESM Console displays the Role as N/A (inactive). The ESM Console also displays blocked accounts
with a red icon in the status column and indicates a deleted or blocked role with a red icon next to the
Role name.
STEP 1 | From the ESM Console, select Settings > Administration > Users. The ESM Console displays
the accounts for your organization, including users, groups, and organizational units.
If you cannot log into the ESM Console, use the Database (DB) Configuration Tool on
page 323 to verify, and optionally change, the users and groups that have access to the
ESM Console (see Configure Administrative Access to the ESM Console Using the DB
Configuration Tool on page 324).
STEP 2 | Click Add User, Add Group, or Add Organizational Unit to create a new account. Alternatively,
select the row of an existing account and click Edit to modify the account settings. From this
view, you can also Block, Unblock, or Delete an account.
STEP 3 | Enter the Name of an existing account. If you are using machine authentication, you can only
add existing users on the local machine. If you are using domain authentication, you can add
any existing domain user, group, or organizational unit.
The ESM Console truncates usernames over 20 characters. As a result, users must log in
to the ESM Console using only the first 20 characters of their username.
STEP 5 | Select the role from the list to assign access privileges to the account. To create a new role, see
Configure Administrative Roles on page 96.
STEP 6 | Save your changes. The ESM Console displays the new or modified account in the table.
STEP 1 | From the ESM Console, select Settings > ESM > Settings.
If you cannot log into the ESM Console, use the Database (DB) Configuration Tool on
page 323 to verify, and optionally change, the authentication mode (see Configure
Administrative Access to the ESM Console Using the DB Configuration Tool on page
324).
User-Defined Rules
A user-defined rule is a rule that youor additional administrators with access to the ESM Consolecreate
to manage the Traps security policy and agent settings, or to perform specific actions on the endpoint. A
user-defined rule can inherit or override the default security policy.
Content Updates
Content updates allow you to easily update your default security policy and settings. Content updates equip
the ESM Console with the most up-to-date best practices and threat information for accurate exploit and
malware protection and can include changes or additions to:
Compatibility rules for third-party products and platforms
Condition objects
Protected processes
Restriction settings
Trusted signers
Local static analysis logic
These files are packaged in a ZIP file and are hosted on the Support portal.
To manage content updates, use the following workflows:
Install a Content Update on page 101
Revert to the Previous Content Update on page 102
STEP 1 | Log in to the ESM Console and select Settings > ESM > Content Updates.
STEP 3 | Identify the content update for your ESM version (typically the latest available content update
version), and then review the associated Release Notes.
STEP 4 | Download the content update package to a location that is accessible from the ESM Console.
STEP 5 | From the ESM Console, select Update Content, Browse to the content update package, and
Apply.
If the content update is older than the current version, the ESM Console displays a
warning message.
STEP 1 | Log in to the ESM Console and select Settings > ESM > Content Updates.
STEP 2 | Review the Release Notes for the previous content update as needed and then Revert.
The ESM Console restores the previous set of default policy rules and distributes them to the endpoints
at the next heartbeat communication.
103
104 TRAPS ADMINISTRATOR'S GUIDE | Monitoring
Maintain the Endpoints and Traps
On a daily or weekly basis, perform the following actions:
Examine the Dashboard to verify that the Traps agent is active on all endpoints. See Use the Endpoint
Security Manager Dashboard.
Review Security Events reported by Traps. After analyzing a security event, you might want to do any of
the following tasks:
Investigate whether the indicators are related to malicious executable files and then use the Agent
Query to search for artifacts on Windows endpoints.
Disable rules temporarily that interfere with day-to-day work. In cases where a security event does
not indicate an attack and is interfering with day-to-day work, you can disable an exploit protection
or restriction rule on a specific endpoint. See Exclude an Endpoint from an Exploit Protection Rule.
Patch, upgrade, or fix a bug in software that indicates erroneous behavior or a security vulnerability.
Patching or upgrading third-party applications or fixing bugs in applications that are developed in-
house can reduce the number of security events reported to the ESM Console.
Activate protection for an unprotected application. See View, Modify, or Delete a Process.
Review post-detection events and take additional action to remediate the endpoint.
Examine the Monitor pages and investigate reports of crashes and security events.
If you configured your ESM Console to Collect New Process Information, review unprotected processes
and decide whether to enable protection on them. See View, Modify, or Delete a Process.
After a change in the organization or in available Traps software versions, you can:
Add a newly-installed application to the list of protected processes. See Add a New Protected Process.
Install Traps on a new endpoint. See Install Traps on Windows Endpoints and Install Traps on Mac
Endpoints.
Upgrade the Traps agent version on endpoints. See Uninstall or Upgrade Traps on the Endpoint.
Allocate additional licenses for Traps agents. See Add a Traps License Using the ESM Console.
SERVICE STATUS Displays the status of the Traps agent instances installed on the
endpoints by number and percentage. Possible statuses are:
RunningThe agent is running.
StoppedThe agent service has been stopped.
DisconnectedThe server hasn't received a heartbeat message from
the agent for a preconfigured amount of time.
ShutdownThe endpoint has been shut down.
COMPUTER Displays the version of the Traps agent instances installed on the
DISTRIBUTION AND endpoints by number and percentage.
VERSION
LICENSE CAPACITY Displays the Traps license utilization for the server and client by number
of used and available licenses.
MOST TARGETED Displays applications that have the highest distribution of preventions.
APPLICATIONS
MOST TARGETED Displays endpoints that have the highest distribution of preventions.
COMPUTERS
MOST TARGETED Displays preventions that have the highest distribution per end user.
USERS
Use the Security Events dashboard (Security Events > Summary) to monitor high-level information about
security events that occur on the endpoints in your organization. From this view, you can see the number
of events that have occurred in the last day, week, or month. The Security Events Dashboard displays both
events where exploit attempts were blocked and events that triggered only notifications.
The following table describes the different areas of the dashboard in more detail.
THREATS Displays all the threats to protected processes and executable files that have
occurred in your network. For convenience, you can click any rule type to
view additional details about events of that type. You can also click on the
number of events that have occurred to view only those events. For more
information, see Manage Security Events.
SECURITY ERROR LOG Displays all of the errors and recent issues that Traps reports about the
endpoints in your organization. Click any error type or on the number of
security errors to view a filtered list of errors from the Monitor > Security
Errors Log page. For more information, see View Security Error Log Details.
The standard details view of the Threats page displays a table of security events with fields displayed along
the top. Selecting an event in the Threats table expands the row to reveal additional details about the
security event. In addition to viewing details about threat events, you can create and view notes about the
event, retrieve log data about the event from the endpoint, or create an exclusion rule to allow the process
to run on a particular endpoint.
For details on the fields in the security events table, refer to the online help.
Delete events.
1. Select the checkbox for each event that you want to export.
2. Click the action menu , and select Delete Selected. The ESM Console removes the records from all
Security Events pages.
(WildFire events only) View the WildFire Report for an executable file
From the expanded view of a security event, click WildFire Report.
(Exploit events only) Create a rule to exclude an endpoint from exploit protection.
From the expanded view of a security event, click Create Rule to create an exploit protection rule that
excludes the endpoint from the exploit protection rule that prevented the process from running. The
rule uses the details from the security event to populate a rule with settings that allow a process to run
on a specific endpoint.
For details on the fields in the Security Error Log table, refer to the online help.
The standard details view of the Health page displays a table of endpoints with fields displayed along
the top. Selecting an endpoint in the Health table expands the row to reveal additional details about the
endpoint and actions that you can perform. You can also export the logs to a CSV file by clicking the menu
icon , and selecting Export Logs.
For details on the fields in the Agent > Health table, refer to the online help.
STEP 1 | From the ESM Console, select Monitor > Agent > Logs.
STEP 2 | To view the table entries, use the paging controls on the top right of each page to view
different portions of the table.
STEP 3 | (Optional) To sort the table entries, select the column heading to sort by ascending order. Select
the column heading again to sort by descending order.
STEP 4 | (Optional) To filter the table entries, click the filter icon to the right of the column to specify
up to two sets of criteria by which to filter the results.
STEP 5 | (Optional) To export the logs to a CSV file, click the menu icon , and then select Export Logs.
Anti-Exploit Protection Indicates whether or not exploit prevention rules are active in the endpoint
security policy.
Anti-Malware Indicates whether or not restriction and/or malware protection modules are
Protection enabled in the endpoint security policy.
Status tab Displays the Connection status and level of protection on the endpoint. The
Traps console opens to the Status tab by default.
Events tab Displays security events that have occurred on the endpoint.
Protection tab Displays the processes that the Traps agent protects that are currently
running on the endpoint.
Policy tab Displays changes to the endpoint security policy including the date and time
of the update.
Verdict Updates tab Displays changes in verdict for executables that have been opened on the
endpoint.
Settings Displays language options that you can use to change the language of the
Traps Console.
Connection Displays the status of the connection between Traps and ESM Server.
Last Check-In Displays the date and time that Traps last received a heartbeat message.
Open Log File... Opens the most recent trace file on the endpoint.
Send Support File Creates a zipped file of traces and sends it to the forensic folder.
STEP 1 | Open the Endpoint Security Manager and select Monitor > Agent > Health.
STEP 2 | Select the row of the endpoint for which you want to view the rule history. The row expands
to display further details and actions you can perform.
STEP 3 | Select Agent Policy from the drop-down on the right. The recent status information appears in
the Agent Policy and Logs section of the page.
STEP 4 | Click Details to view the full rule history log. The status indicates one of the following:
ActiveThe rule is active in the endpoint security policy.
HistoricThe rule is an older version of a rule that is active in the endpoint security policy.
DisabledThe rule was deactivated in the security policy.
Each rule type has a dedicated management page that you can use to view and manage
the rules for your organization. To create a text file containing the active security policy
on an endpoint, run the following from a command prompt: cyveraconsole.exe
export(641980)
CyveraConsole.exe creates an XML file in \programdata\cyvera
\logs\ containing the active policy. The filename uses the format
ClientPolicy_<date>_<time>.xml to indicate the date at which the policy was active,
for example: CyveraPolicy_20160831_113415.xml
STEP 1 | Do one of the following to launch the Traps Console on the endpoint:
From the Windows tray, right-click the Traps icon and select Console, or double-click the icon.
Run CyveraConsole.exe from the installation folder of the Traps Console.
STEP 1 | From the ESM Console select Monitor > Agent > Health.
STEP 2 | Select the row of the endpoint for which you want to view the rule history. The row expands
to display further details and actions you can perform.
STEP 3 | Select Service Status from the drop-down on the right. The recent status information appears
in the Agent Policy and Logs section of the page.
STEP 4 | Click Details to view the full service status history log.
STEP 1 | From the ESM Console select Monitor > Agent > Health.
To quickly locate an endpoint, use the filter controls at the top of the columns.
STEP 3 | Select Delete Selected from the action menu at the top of the Health table. Click OK to
confirm the deletion.
The ESM Console changes the status of the endpoint to Historic and hides the endpoint from the
default display of endpoints on the Health page (to view the deleted endpoints, filter the status column
by Historic).
STEP 1 | From the ESM Console, select Monitor > ESM > Health.
STEP 2 | To view the table entries, use the paging controls on the top right of each page to view
different portions of the table.
STEP 3 | (Optional) To sort the table entries, select the column heading to sort by ascending order. Select
the column heading again to sort by descending order.
STEP 4 | (Optional) To filter the table entries, click the filter icon to the right of the column to specify
up to two sets of criteria by which to filter the results.
STEP 5 | (Optional) To export the logs to a CSV file, click the menu icon , and then select Export Logs.
STEP 6 | (Optional) To view a list of agents that are connected to the ESM Server, expand the row for the
server, and then click Agent List next to the connected or disconnected field. If there are no
agents, this option is grayed out.
STEP 1 | From the ESM Console, select Monitor > ESM > Logs.
STEP 2 | To view the table entries, use the paging controls on the top right of each page to view
different portions of the table.
STEP 3 | (Optional) To sort the table entries, select the column heading to sort by ascending order. Select
the column heading again to sort by descending order.
STEP 4 | (Optional) To filter the table entries, click the filter icon to the right of the column to specify
up to two sets of criteria by which to filter the results.
STEP 5 | (Optional) To export the logs to a CSV file, click the menu icon , and then select Export Logs.
STEP 1 | From the ESM Console, select the rule management page for that rule type, for example
Policies > Exploit > Protection Modules.
STEP 2 | To view the table entries, use the paging controls on the top right of each page to view
different portions of the table.
STEP 3 | (Optional) To sort the table entries, select the column heading to sort by ascending order. Select
the column heading again to sort by descending order.
STEP 4 | (Optional) To filter the table entries, click the filter icon to the right of the column to specify
up to two sets of criteria by which to filter the results.
STEP 5 | (Optional) To expand a rule entry, click the expansion arrow on the right side of the rule. From
the expanded view, you can view further rule details or take any of the actions to manage a
rule. See Save Rules on page 129.
119
120 TRAPS ADMINISTRATOR'S GUIDE | Getting Started with Rules
Endpoint Policy Rule Concepts
Policy Rule Types
Policy Enforcement
Default Protection Policy
Policy Description
Malware protection Malware protection rules use protection modules to block common behavior
initiated by malicious executable files. Each rule in the malware protection
policy specifies the type of protection module used to block suspicious actions.
The rule can also include a whitelist that specifies exceptions to the rule. For
more information, see Malware Protection Rules.
Exploit protection Exploit protection rules determine the method of protection for processes that
run on your endpoints. Each rule in the exploit prevention policy specifies the
type of protection modules used to protect processes. For more information,
see Exploit Protection Rules.
Restrictions Restriction rules limit the scope of an attack by specifying where and how
executable files can run that are launched on Windows endpoints. For more
information, see Restriction Rules.
WildFire WildFire rules enable pre- and post-prevention analyses of executable files and
macros by sending unknown files to the public or private WildFire cloud. For
more information, see Configure a WildFire Rule.
Forensics Forensics rules enable you to set preferences about memory dump and
forensic file collection. For more information, see Forensics Rules.
Agent settings Agent settings rules enable you to change the values of Traps agent settings
related to logging, heartbeat frequency, and console accessibility. For more
information, see Traps Agent Settings Rules.
Modification dateWhen rules have the same level of specificity, where the core configuration is
the same across two or more rules, Traps determines which rule takes precedence to avoid rule
conflicts. For example, consider two exploit protection rules which use the same module to protect
the same process but have conflicting settings: One rule enables the module and the other disables
the module. In this case, the rule that was created or edited more recently takes precedence over an
older rule. An easy way to identify which rule is more recent is to look at the ID number assigned to
the rule. The ESM Console assigns an ID to each rule sequentially as you modify or add rules to the
security policy so a higher ID number indicates the rule was created more recently.
Target ObjectsA target object can be any user, group, organizational unit, or computer that appears in
Active Directory or any endpoint on which Traps is installed. For a rule to apply, the rule must specify
the endpoint as a target object or specify no target objects (meaning the rule applies to all objects). In
addition, the rule must not specify the endpoint as a target object from which to exclude the rule.
ConditionsA condition is an identifying characteristic on the endpoint which can be used to apply or
exclude a rule on an endpoint. For a rule to apply, the endpoint must match any conditions specified
in the rule. For example, rules with conditions for Windows 7 endpoints will apply only to Windows 7
endpoints. Similarly, the rule must not specify a condition which matches the endpoint in an exclude
condition.
Define the settings and actions that are specific to the For more details on the specific settings
rule type. required for each rule type, see:
Manage Malware Protection Rules
Create an Exploit Protection Rule
WildFire Integration
Manage Restrictions on Executable Files
Manage Traps Action Rules
Manage Agent Settings Rules
Manage Forensics Rules and Settings
View the default policy rules. Show or Hide the Default Policy Rules
Disable or enable all protection rules. Disable or Enable All Protection Rules
Conditions
A condition is an identifying characteristic on the endpoint which you can define to apply or exclude a rule
on an endpoint.
For Windows endpoints, you can define a condition to match a filename, a filename and file version, or a
registry path. You can also define a condition for a specific version of an executable file defined in the file
path. You can then use the condition to apply or exclude a rule on a Windows endpoint.
For Mac endpoints, you can configure a condition to match the bundle path or bundle ID and then use the
condition to apply or exclude a rule on a Mac endpoint.
Define Activation Conditions for a Rule on Windows Endpoints
STEP 1 | Select Settings > Conditions > Windows. The Conditions page displays the unique ID number,
Name, Description, and Path (if applicable) for each condition.
STEP 2 | Click the action menu and then Add a new condition.
STEP 4 | Select the type of condition, either Path to match on the path of a specific executable file
and optionally on a specific version or range of versions for the executable file, or Registry to
match a specific registry key:
To match a specific executable file (or to match a specific version of an executable file), specify the
full Path of an executable file that exists on the endpoint. Optionally, you can use system variables in
the path. For example, specify %windir%\system32\calc.exe to apply the rule if the calculator
executable file is run from this location.
If you specified an executable file in the Path field, you can also set a match condition for a file
Version (as displayed in the file properties) or range of versions of that executable file. If you specify
a Version value, Traps will only apply the rule if the executable is run from the location specified in
the Path field and also matches the Version value. By default, the condition matches any version of
the file. To narrow the number of versions, select one of the following Version Comparison options
and then enter a Version number.
When you configure a condition to match a Version, Traps evaluates the version
value stored in the file properties. Because this number may be different than the
published version number, we recommend that you verify the version number in the
file properties before creating your condition.
The Version must follow the standard Windows version convention and be no longer
than four segments long (for example, 4.30.200.100). To match versions longer than
four segments long, use Regex.
You cannot specify CurrentUser registry paths because Traps runs as the local
system.
Traps will only apply the rule if the endpoint contains the specified path in its registry. You can also
configure a specific registry Key or Data value (String and DWord only) as a match condition.
For example, to apply a rule on endpoints that have IPv6 enabled, configure a condition that matches
the following registry settings:
Registry Path: LocalMachine\SYSTEM\CurrentControlSet\services
\TCPIP6\Parameters\EnableICSIPv6
Key: DisabledComponents
Data: 0
STEP 1 | Select Settings > Conditions > macOS. The Conditions page displays the unique ID number,
Name, Description, and if applicable, Path or Bundle ID for each condition.
STEP 2 | Click the action menu and then Add a new condition.
STEP 3 | Select the type of condition from the drop down, either Path or Bundle ID.
Bundle IDSpecify the numeric bundle ID. To specify a bundle ID as an include or exclude condition,
enter the unique ID number. You can optionally specify match conditions for the bundle version.
STEP 1 | From the rule configuration page, select the Conditions tab.
STEP 2 | Select a condition and Add it to the include or exclude list. To select multiple conditions, press
and hold the Ctrl key while selecting.
STEP 3 | Configure the rule settings and then Save or Apply the rule (see Save Rules on page 129).
STEP 1 | Select Settings > Conditions. The Conditions page displays the unique ID number, Name, and
Description for each condition.
Target Objects
Target objects define the scope of a rule and the endpoints to which a rule applies. An object can be one of
the following:
Organizational Unit A subdivision within Active Directory into which you can place users,
groups, computers, and other organizational units.
Existing Endpoints A computer or mobile device on which the Traps agent is installed.
The Endpoint Security Manager identifies existing endpoints by
communication messages it receives from Traps agents.
For objects defined in Active Directory, the ESM Console provides autocompletion as you type.
You can apply rules to all objects, to selected objects, or to all objects except those in the Exclude list.
Rules that you define for users and groups will apply to those users and groups, regardless of the endpoint
on which they log in.
The rule that is modified or edited most recently takes precedence over older rules of the
same type. As a result, changing the name of a rule changes the modification date for the
rule and can cause the edited rule to override older rules.
The rule description is a good place to record the business reasons for the creation of a rule.
For example, you might include an incident identification number or a link to a help desk
ticket.
Save Rules
To save a rule, you must complete all required fields for that rule type. Tabs with required fields are
indicated by a red tab background.
Action Description
Save Save the rule without activating it. The status of the rule is shown as Inactive,
and you can activate it later. This option is only available for inactive, new, or
cloned default rules.
Apply Save the rule and activate it immediately. The ESM Server sends the updated
rule at the next heartbeat communication with the Traps agent. However, you
can trigger a policy update by clicking Check In Now in the Traps console on
an endpoint.
Duplicate (Action rules only) Create a new rule from an existing rule.
Delete Discard the rule; the rule is removed from the system.
To delete multiple rules at the same time, select the rules and then select
Delete Selected (non-Default) from the action menu at the top of the
table.
Activate/Deactivate If the rule was previously saved but not applied, you can Activate the rule to
add it to the current security policy. If the rule is active, you can Deactivate it
to remove the rule from the current security policy but not from the system.
To activate or deactivate multiple rules at the same time, select the rules and
then select Activate Selected or Deactivate Selected from the menu at the
top of the table. To disable or enable all exploit, malware, or forensics rules,
see Disable or Enable All Protection Rules.
Edit Edit the rule definition. Selecting this option opens the rule configuration
dialog and allows you to change the rule definition. For more information, see
Create an Exploit Protection Rule.
Import Rules/Export From the action menu at the top of the table, you can import rules or
Selected export selected rules. Exporting rules saves the selected rules to an XML file.
For more information, see Export and Import Policy Files.
Show Default From the action menu at the top of the table, you can expand the default
Rules/Hide Default rules or hide default rules. Select the rule to view additional information about
Rules the rule. For more information, see Show or Hide the Default Policy Rules.
Clone When you show default rules and then select a rule, the ESM Console
displays additional details about the rule settings and an option to Clone the
rule. Cloning enables you to create a new rule that overwrites the default
policy settings. For more information, see Show or Hide the Default Policy
Rules.
Filter Rules
Each rule summary and management page in the ESM Console displays details about the rules that define
your organizations security policy. To narrow the number of rules that the ESM Console displays, you can
filter the rules using the filter control at the top of each column. Use the filter control to define either one
or two values to filter on rule status, rule name, rule description, or modification date.
The operators that are available for each column depend on the column type. For example, you can filter
columns that display text using any of the following operators to search for a string value: Is equal to, Is not
equal to, Starts with, Contains, Does not contain, or Ends with. For columns that display a date, you can
filter for a specific date or a date range using any of the following operators: Is equal to, Is not equal to, Is
after or equal to, Is after, Is before or equal to, or Is before.
The ESM Console identifies columns that have active filters with an applied filter icon and a blue
background. To remove the filter, click the icon and then select Clear.
The following table shows the columns, operators, and values that you can use to filter the rules.
STEP 1 | From the ESM Console, select any rule management page, such as Policies > Malware >
Restrictions.
Value Purpose
%ALLUSERSPROFILE% C:\ProgramData
%ProgramData% C:\ProgramData
%SystemDrive% C:
%SystemRoot% C:\Windows
%USERPROFILE% C:\Users\<username>
%windir% C:\Windows
%COMPUTERNAME% <computername>
%ComSpec% %SystemRoot%\system32\cmd.exe
%FP_NO_HOST_NAME% NO
%NUMBER_OF_PROCESSORS% 1
%OS% Windows_NT
%PATH% %SystemRoot%\system32;%SystemRoot%...
%PATHEXT% .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
%PROCESSSOR_ARCHITECTURE AMD64
%
%PROCESSOR_LEVEL% 6
%PROCESSOR_REVISION% 4501
%SystemDrive% C:
%SystemRoot% C:\Windows
%windir% C:\Windows
%COMPUTERNAME% <computername>
%ComSpec% %SystemRoot%\system32\cmd.exe
%FP_NO_HOST_NAME% NO
%NUMBER_OF_PROCESSORS% 1
%OS% Windows_NT
%PATH% %SystemRoot%\system32;%SystemRoot%
%PATHEXT% .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
%PROCESSSOR_ARCHITECTURE x86
%
%PROCESSOR_LEVEL% 6
%PROCESSOR_REVISION% 3a09
Example Result
C:\temp\a.exe Matches only the a.exe file and only if launched from the C:\temp folder
%TEMP%\a.exe Matches only the a.exe file and only if launched from the C:\Users
\<username>\AppData\Local\Temp folder on Windows Vista and
later machines or C:\Documents and Settings\<username>\Local
Settings\Temp on Windows XP machines
C:\temp* Matches any file launched from the C:\temp folder or from any folder or
subfolder in a filepath that begins with C:\temp (for example, C:\temp
\folder\a.exe, C:\temp1\a.scr, and C:\temporary\folder
\b.exe)
C:\temp\* Matches any file launched from the C:\temp\ folder or subfolder (for
example: C:\temp\a.scr and C:\temp\temp2\b.exe)
C:\temp\a?.exe Matches any file beginning with a and followed by a second character
launched from the C:\temp\ folder (for example: C:\temp\a1.exe and
C:\temp\az.exe)
C:\temp*.exe Matches any executable file with an .exe file extension, a filename that
begins with temp, and that is launched from the C:\ drive (for example,
C:\temp1.exe and C:\temporary.exe) and matches any executable
file with an .exe file extension that is launched from any folder or subfolder
in a filepath that begins with C:\temp (for example, C:\temp\folder
\a.exe, C:\temp1\b.exe, and C:\temporary\folder\c.exe)
C:\temp\*.exe Matches any executable file with an .exe file extension that is launched
from the C:\temp\ (or equivalent %SystemDrive%\temp\ folder) or
%SystemDrive%\temp
from any folder or subfolder in a filepath that begins with C:\temp\
\*.exe
*\a.exe Matches only the a.exe file regardless from which location it is launched
a.exe (Java restriction rules only) Matches only the a.exe file regardless from
which location it is launched
C:\temp Does not match any executable files because the path is not a full path
(partial paths must contain at least one wildcard to be useful)
C:\temp\
The process type, as shown on the Process Management page, does not indicate whether
a process is used in the default security policy. Instead, the process type only indicates
whether the process can be used in an exploit protection rule. For more information, see
Process Protection Types.
To ensure process protection continues, we recommend that you do not change the names
of commonly used processes on the system. If a process name change is required, ensure
that you add the renamed process as a protected process and mirror the protection rules for
the old process name. As needed, you can also configure additional exploit protection rules
to protect the process.
By extending protection to the applications that are important to your organization, you can provide
maximum protection with minimal disruption of day-to-day activities. Add processes as either protected,
provisional, or unprotected and configure them using the Process Management page.
You can configure only exploit protection rules on Protected or Provisional processes.
You cannot change the default Protected processes that are included in the initial setup.
Consult the Palo Alto Networks support team for questions.
STEP 5 | For each new protected process, configure an exploit protection rule to activate the ROP
Mitigation EPM in the process and another exploit protection rule to activate the JIT
Mitigation EPM in the process. These exploit protection rules provide the best protection
with the lowest false-positive rate.
1. For each EPM, Create an Exploit Protection Rule with the following settings:
EPM:
ActivationOn
STEP 2 | Select the type of operating system for which you want to manage processes, either Windows
or macOS.
You can not unlink processes from default rules and, as a result, you cannot remove any
processes specified in default rules.
After the process is unlinked, you can select the name of the process and do any of the following:
Delete the process.
Change the Process Name and then Save your changes.
Change the Protection Type and then Save your changes. For more information, see Process
Protection Types.
On Windows endpoints, Traps displays the name, description, unique process ID number, time the process
was initiated, and memory allocation register.
On Mac endpoints, Traps displays the name and unique process ID number.
STEP 1 | Launch the Traps Console:
From the Windows tray, double-click the Traps icon or right-click the icon and select Console.
Run CyveraConsole.exe from the Traps installation folder.
The Traps Console launches.
STEP 2 | Select the Advanced > Protection tab to view the protected processes.
143
144 TRAPS ADMINISTRATOR'S GUIDE | Malware Protection
Malware Protection Policy Best Practices
The key principle when defining a malware protection policy is to minimize the chance of infection from
known and unknown malware. To achieve this goal, the best practice malware protection policy uses
WildFire rules that enable Traps to identify and block all known threats and send unknown files for analysis
and identification by WildFire. In addition, the best practice malware protection policy enables Traps to
take advantage of built-in mechanisms to analyze unknown executable files and determine the likelihood of
malware. Consider the following recommendations when creating a malware protection policy:
Enable WildFire integration to allow Traps to evaluate executable files based on their WildFire verdicts.
WildFire integration is automatically enabled in the default policy. Therefore, if you need to create new
WildFire rules, ensure that WildFire Activation is On. See Configure a WildFire Rule.
Block the execution of malware. The easiest way to prevent malware from causing harm to your
endpoints is to block its execution. To do this, the Action in the WildFire policy for executable and
Microsoft Office files (containing macros) must be set to Prevention. Because the default policy
configures this setting, we recommend that you leave the default setting, or if you need to create new
rules, inherit the action from the default policy. See Configure a WildFire Rule.
Enable Traps to submit unknown executable files to the ESM Server and enable the ESM Server to send
those samples to WildFire for analysis. By submitting the samples, you take advantage of advanced
WildFire threat intelligence which enables analysis and identification of zero-day malware. WildFire
also makes information about newly-discovered executable files available globally to other ESMs (upon
query) and to Palo Alto Networks firewalls (within minutes). This enables you and other Palo Alto
Networks customers to transform unknown samples to known samples thus reducing the time spent
determining the nature of the unknown executable file. Because the default policy configures this
setting, no additional action is required to enable this functionality. However, if you need to create new
rules, ensure that you configure the Unknown Verdict Configuration to block unknown executables and
enable Traps agents to Upload Files for WildFire Analysis. See Set Up the ESM to Communicate with
WildFire.
Enable Traps to perform local analysis on unknown executable files to determine if they are likely to be
malware. Local analysis uses a statistical model that was developed using machine learning on WildFire
threat intelligence. When enabled, local analysis uses the model to issue a local verdict for the file. Traps
simultaneously queries the ESM Server for a verdict for the unknown executable but can use the local
analysis verdict until the ESM Server responds with either an official WildFire verdict or administrative
hash control policy. Because the default policy configures this setting, no additional action is required
to enable this functionality. However, if you need to create new rules, ensure that you enable Local
Analysis. See Local Static Analysis.
Install the latest content update. Each content update packages the latest Palo Alto Networks threat
intelligence into a default security policy file. The content update can include changes to the list of
trusted signers, local analysis model, compatibility rules, and default rule configuration settings. By
installing the latest content update, you can ensure that your endpoints take advantage of this threat
intelligence. See Content Updates.
Trusted Signers
Legitimate software is often signed by a trusted signer to signify that the software has not been altered
or tampered with. Palo Alto Networks regularly reviews and makes changes to the list of trusted signers
and makes the list available with the default security policy. Any updates to the list of trusted signers are
made available with content updates that you can obtain from the Support portal (for more information, see
Content Updates on page 101).
When a user attempts to open an unknown executable file for which a hash control policy does not exist,
the WildFire module begins the verdict evaluation process by verifying whether an executable file is signed
by a trusted signer.
If the executable file is signed by a trusted signer, the file is considered benign and is locally exempt from
additional WildFire verification and local analysis. As long as execution restrictions and malware protection
rules do not apply to the executable file, Traps permits it to open. If Traps blocks a file that is signed by a
trusted signer (for example, if the file was signed by a trusted signer but violated a restriction rule), the ESM
Console displays the signer information in the new Source Signers field in the security event details.
If the executable file is not signed by a trusted signer, Traps next evaluates the official WildFire Verdict on
page 148.
WildFire Verdict
If an executable file is not signed by any Trusted Signers, the Traps agent performs a hash verdict lookup to
determine if a verdict already exists in its local cache.
If the executable file has a malware verdict, Traps reports the security event to the Endpoint Security
Manager and, depending on the configured behavior for malicious files, Traps then does one of the
following:
Blocks the malicious executable file
Notifies the user about the file but still allows the file to execute
Logs the issue without notifying the user and allows the file to execute.
If the verdict for a hash indicates that the associated file is benign, Traps moves on to the next stage of
evaluation (see Phase 2: Evaluation of the Restriction Policy).
If the hash does not exist in the local cache or has an unknown verdict, Traps performs Local Static Analysis.
For additional questions about configuring malware protection rules, contact Support team or
your Sales Engineer.
Child Process (Windows only) The Child Process Protection MPM prevents script-based
Protection attacks used to deliver malware such as ransomware by blocking known
targeted processes from launching child processes commonly used to bypass
traditional security approaches. For more information, see Configure Child
Process Protection.
The Child Process Protection MPM for Windows endpoints prevents script-based attacks used to deliver
malware such as ransomware. To prevent these attacks, the MPM is enabled by default and blocks
known targeted processes from launching child processes commonly used to bypass traditional security
approaches.
For increased flexibility, you can configure the module to operate in one of two ways:
Use a whitelist to block all child processes initiated by a process except for those specified in the
whitelist.
Use a blacklist to allow a process to run all child processes except for those specified in the blacklist.
To control how new rules inter-operate with existing rules, you can also choose to merge or override
settings in rules that apply to the same parent process.
Use the following workflow to configure enhanced child process protection:
STEP 2 | Select Windows as the operating system (child process protection is not supported on Mac
endpoints).
STEP 4 | Select Child Process Protection and configure the rule settings:
ActivationSelect On to enable child process protection or Off to disable child process protection.
ActionSelect the action to take when a process attempts to call a child process: Block the child
process from running (Prevention), or permit the child process to run and log the issue (Notification).
If you choose to Inherit the behavior, Traps defers to the default policy for the action.
To view additional details about the default policy, select Policies > Malware >
Protection Modules, and then select Show Default Rules from the action menu.
User AlertSpecify the notification behavior when a process attempts to call a child process, either
On to notify the user, or Off to suppress notifications. If you choose to Inherit the behavior, Traps
defers to the default policy for the notification behavior.
If multiple rules exist for the same parent process that specify List Action: Merge,
Traps consolidates the Child Process List (either the whitelist or blacklist). If multiple
rules exist for the same parent process that specify List Action: Override, only the
most recent rule (with the highest ID number) takes precedence.
If multiple rules exist for the same parent process but use different list behaviors (for example, one
as a whitelist and one as a blacklist), only the most recent rule (with the highest ID number) takes
precedence.
STEP 6 | Select the Processes tab and Add one or more source (parent) processes to which Traps will
apply child process protection. As you type, the ESM Console provides auto-completion based
the list of processes defined in the ESM Console.
STEP 7 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat this step to add more conditions, as needed. To add a
condition to the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints.
STEP 8 | (Optional) Define the Target Objects to which to apply the restriction rule.
To define a smaller subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 9 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 2 | Select macOS as the operating system (the Gatekeeper Enhancement MPM is not supported
on Windows endpoints).
To view additional details about the default policy, select Policies > Malware >
Protection Modules, and then select Show Default Rules from the action menu.
User AlertSpecify the notification behavior when Traps detects a child process which does not
match or exceed the configured signature level, either On to notify the user, or Off to suppress
notifications. If you choose to Inherit the behavior, Traps defers to the default policy for the
notification behavior.
/Applications/myapp1.app/Contents
3. Repeat the process to add any additional child processes, if desired.
4. Select the Whitelist Action to Merge or Override the child process list with lists defined in other
user-defined or default policy rules for the parent process.
If multiple rules exist for the same parent process that specify Whitelist Action:
Merge, Traps consolidates the Whitelist. If multiple rules exist for the same parent
process that specify Whitelist Action: Override, only the most recent rule (with the
highest ID number) takes precedence.
STEP 7 | Select the Processes tab and Add one or more source (parent) processes to which Traps will
apply the Gatekeeper Enhancement MPM. As you type, the ESM Console provides auto-
completion based on the list of processes defined in the ESM Console.
STEP 8 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat this step to add more conditions, as needed. To add a
condition to the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints.
STEP 9 | (Optional) Define the Target Objects to which to apply the restriction rule.
To define a smaller subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 10 | (Optional) Review the rule name and description. The ESM Console automatically generates
the rule name and description based on the rule details but permits you to change these
fields, if needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
Restriction Rules
A restriction rule limits the surface of an attack on a Windows endpoint by defining where and how your
users can run executable files. The following table displays the different types of restrictions you can
configure:
Running executable Many attack scenarios are based on writing malicious executable files to
files from certain certain folders and then running them. For example the local temp and
folders download folders are commonly used to store and later run malicious
executable files. To make an exception to this general restriction, you can
add specific folders to a whitelist. For more information, see Manage Global
Whitelists, Block Execution from Local and Network Folders, and Whitelist a
Network Folder.
Running executable Malicious code can gain access to endpoints via external media such as
files from external removable drives and optical drives. To protect against this, you can define
media restrictions that control the executable files, if any, that users can launch
from external drives attached to the endpoints in your network. For more
information, see Define External Media Restrictions.
Processes spawning (Traps 3.4 and earlier releases) Malicious code can activate by causing
child processes a legitimate process to spawn malicious child processes. You can block
the malicious code by defining an appropriate restriction rule. For more
information, see Define Child Process Restrictions.
Java processes run (Traps 3.4 and earlier releases) A common entry point for malicious code is
from browsers through Java processes that are imported from a remote host and launched
through Internet browsers. To protect against these exploits, you need
to prevent untrusted Java applets from executing objects using browsers
while whitelisting specific trusted processes so they can run on endpoints as
needed. You can selectively choose which actions are permitted (read, write,
or execute) based on process file types, locations, and registry paths. For
more information, see Define Java Restrictions and Exemptions.
STEP 4 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat this step to add more conditions, as needed. To add a
condition to the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints.
STEP 5 | (Optional) Define the Target Objects to which to apply the restriction rule. By default, a new
rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 6 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 2 | To specify whether Traps blocks an executable file that it is opened from a location not
included in the whitelist or that is younger than the block period, configure the Action as one
of the following:
NotificationDo not block access to executable files and processes but log when files that are
opened from locations not included in the whitelist and report those events to the ESM.
or
PreventionBlock executable files and processes.
STEP 3 | To specify whether Traps should notify the user when an executable file is opened from a
location not included in the whitelist, configure the User Alert as one of the following:
OnNotify the user.
or
OffDo not notify the user.
STEP 4 | Click the add folder icon next to the whitelist area for Local Folder, Child Process, or Media
Control and enter the full path or partial path. For example, C:\Windows\filename.exe.
Whitelists also support wildcards and environmental variables, such as %windir% (for
more details, see Wildcards and Variables in Policy Rules).
%MySystemDrive%\myfolder\temp\malware.exe
Any executable run from a specific local folder or subfolders, for example:
C:\temp\*
Specific executable files run from a remote location, for example:
\\remoteserver\folder\malware.exe
Specific remote locations, for example:
\\remoteserver\*
When you enable this restriction rule, all executable files are permitted to run unless they match the folders
or files specified in the rule. If a user tries to open an executable file from a blocked location, Traps blocks
the attempt and reports the security event to the ESM Server.
For a more stringent security policy, consider configuring a network folder behavior rule which blocks
all executables run from remote network folders except for those expressly whitelisted (see Whitelist a
Network Folder).
You can also configure an exception for a local folder by adding the folder to the a whitelist (see Manage
Global Whitelists). The whitelists take precedence over the blacklist and enables executable files in specific
locations to always run.
To blacklist a folder, you must terminate the path with a wildcard. For example, C:
\temp\* matches any file launched from the C:\temp\ folder or subfolder).
For additional syntax examples, see Wildcards and Variables in Policy Rules.
4. Repeat the previous step to add multiple paths as needed.
STEP 3 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
STEP 4 | (Optional) Define the Target Objects to which to apply the restriction rule. By default, a new
rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 2 | Select the option to Restrict file execution from all network folders except the locations listed
below.
STEP 3 | Click the add folder icon , to Add the file or folder path in uniform naming convention (UNC)
format.
For additional syntax examples, see Wildcards and Variables in Policy Rules.
STEP 5 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat this step to add more conditions, as needed. To add a
condition to the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints.
STEP 6 | (Optional) Define the Target Objects to which to apply the restriction rule. By default, a new
rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 7 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 3 | (Optional) Add Conditions to the Rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat this step to add more conditions, as needed. To add a
condition to the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints.
STEP 4 | (Optional) Define the Target Objects to which to apply the restriction rule. By default, a new
rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 7 | (Optional) To whitelist specific external media locations from your external media restriction
rule, add one or more folders to the External Media Whitelist. For more information, see
Manage Global Whitelists.
In an attempt to control an endpoint, an attacker can cause a legitimate process to spawn malicious child
processes. Define a restriction rule to prevent child processes from launching from one or more processes.
STEP 2 | Define the behavior for child processes. By default, child processes spawned from a process
are allowed.
STEP 3 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat this step to add more conditions, as needed. To add a
condition to the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints.
STEP 4 | (Optional) Define the Target Objects to which to apply the restriction rule. By default, a new
rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
A common entry point for malicious code is through Java processes that are imported from a remote host
and run in Internet browsers. To protect against these exploits, you can configure Traps to prevent a Java
applet from executing objects from within web browsers and whitelist only trusted processes so they can
execute as needed. Use the whitelist option to selectively choose which processes Java is permitted to run.
2. Configure the Action to take when a Java process attempts to run and the process is not whitelisted:
InheritInherit the behavior from the default policy.
PreventionTerminate all Java processes except for those specified in the whitelist.
NotificationLog the issue and allow the Java process to continue.
3. Configure the User Alert behavior when a Java process attempts run from a web browser.
InheritInherit the behavior from the default policy.
OnNotify the user.
OffDo not notify the user.
4. In the Java Whitelisted Processes section, click the add processes button to specify the Java
processes that will be allowed to run from web browsers (for example AcroRd32.exe). Repeat this
step to add additional processes.
5. From the Browsers list, select the web browsers on which to enforce Java protection.
STEP 3 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat this step to add more conditions, as needed. To add a
condition to the Conditions list, see DefineActivation Conditions for a Rule on Windows Endpoints.
STEP 4 | (Optional) Define the TargetObjects to which to apply the restriction rule. By default, a new rule
applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
ESM Forwarding
The Endpoint Security Manager (ESM) forwards unknown samples for in-depth analysis to the WildFire.
You can integrate your ESM environment with either the WildFire public cloud or a local WF-500 that acts
as a local sandbox. The type of samples the ESM submits and frequency at which the ESM communicates
with WildFire is determined by the WildFire settings and rules that you configure (see Set Up the ESM to
Communicate with WildFire and Configure a WildFire Rule).
For samples that Traps reports, the agent first checks its local cache of hashes to determine if it has an
existing verdict for that sample. If Traps does not have a local verdict, Traps queries the ESM to determine
if WildFire has previously analyzed the sample. If the sample is identified as malware, it is blocked. If the
sample remains unknown after comparing it against existing WildFire signatures, the ESM forwards the
sample for WildFire analysis. For more information, see Malware Protection Flow.
Verdicts
WildFire delivers verdicts to identify samples it analyzes as safe, malicious, or unwanted (grayware is
considered obtrusive but not malicious):
BenignThe sample is safe and does not exhibit malicious behavior.
MalwareThe sample is malware and poses a security threat. Malware can include viruses, worms,
Trojans, Remote Access Tools (RATs), rootkits, botnets, and malicious macros. For files identified as
malware, WildFire generates and distributes a signature to prevent against future exposure to the threat.
GraywareThe sample does not pose a direct security threat, but might display otherwise obtrusive
behavior. Grayware typically includes adware, spyware, and Browser Helper Objects (BHOs).
When WildFire is not available or integration is disabled, Traps can also assign a local verdict for the sample
using additional methods of evaluation: When Traps performs Local Static Analysis on a file, it uses machine
learning to determine the verdict. Traps can also compare the signer of a file with a local list of Trusted
Signers to determine whether a file is malicious:
Verdict Caches
Traps stores hashes and the corresponding Verdicts for all executable files that open on the endpoint in
its local cache. The local cache is stored in the C:\ProgramData\Cyvera\LocalSystem folder on the
endpoint and scales in size to accommodate the number of unique executable files opened on the endpoint.
When service protection is enabled (see Manage Service Protection), the local cache is accessible only by
the Traps agent and cannot be changed.
Each time an executable file attempts to run, the Traps agent performs a lookup in its local cache to
determine if a verdict already exists. If known, the verdict is either the official WildFire verdict or manually
set as an administrative hash control policy. Verdicts with an administrative hash control policy take
precedence over any additional verdict analysis.
If the executable file is unknown in the local cache, the Traps agent then queries the ESM Server for the
verdict. The Endpoint Security Manager stores verdicts for all executable files that have been opened on
the endpoints across your organization in its server cache which is stored in the ESM database. When the
ESM Server receives a verdict request it performs a lookup in its server cache to determine the verdict.
The ESM Server responds with the verdict at the next heartbeat communication with the Traps agent that
requested the verdict.
If the executable file is unknown in the server cache, the ESM Server then queries WildFire and optionally
submits the file for analysis.
STEP 1 | From the ESM Console, select Settings > ESM > WildFire.
STEP 3 | In the Unknown Verdicts Recheck Interval (Minutes) field, enter the frequency (in minutes)
at which the ESM Server resubmits hashes to WildFire for unknown files. A file can have an
unknown verdict if it is the first time an endpoint submits the hash to the server or if WildFire
has not, yet, analyzed or finished analyzing the file (range is 1 to 20,160; default is 30).
STEP 4 | In the Known Verdicts Recheck Interval (Minutes) field, enter the frequency (in minutes) at
which the ESM Server rechecks with WildFire for the value of known benign or malicious
hashes (range is 1 to 20,160; default is 1,440).
STEP 5 | In the Upload Retry Interval (Minutes) field, enter the frequency (in minutes) at which the ESM
Server attempts to re-upload any files that did not upload to WildFire successfully (range is 1
to 20,160; default is 1,440).
STEP 6 | Enter the WildFire web address (for example, https://wildfire.paloaltonetworks.com) that
the ESM will use to check hashes and submit samples. To forward samples to a local WF-500
appliance, see Set Up a Private WildFire Cloud.
The WildFire API Key is required only for a private WildFire cloud.
When an unknown file attempts to run on your endpoints, the WF-500 appliance queries the WildFire
public cloud to obtain the verdict and analyzes the executable file in the local private sandbox. By default,
the WF-500 appliance does not send discovered malware outside your network, however, you can choose
to automatically forward malware to the WildFire public cloud to generate and distribute signatures to
all Palo Alto Networks firewalls with Threat Prevention and WildFire licenses. Otherwise, the WF-500
appliance only forwards the malware report (and not the sample itself) to the WildFire public cloud.
To enable the ESM Server to verify and trust the identity of the WF-500 appliance, you obtain the WF-500
Root CA certificate from Support and import it on each ESM Server.
To integrate a WF-500 application in with your ESM deployment, use the following workflow:
STEP 1 | On each ESM Server, import the WF-500 Root CA certificate (Palo Alto Networks Root CA 1)
into the Trusted Root Certification Authorities.
1. Contact Support to obtain the WF-500 Root CA certificate and save it to a location you can access
from the ESM Server.
2. On the ESM Server, open the Microsoft Management Console (MMC.exe).
3. Select File > Add/Remove Snap-In > Certificates and add the Certificates snap-in for the Computer
account.
4. Select Local Computer > Finish, and then click OK.
5. Expand the Certificates (Local Computer) folder.
6. Right-click Trusted Root Certification Authorities and then select All Tasks > Import > Next.
7. Browse to the certificate you saved in the previous step and then click Next. The certificate import
wizard displays details about the Trusted Root CA certificate.
8. Click Finish.
STEP 3 | To verify connectivity between the ESM Server and the local WF-500 appliance, recheck a
hash verdict with WildFire.
1. Select Policies > Hash Control.
2. Select a record in the hash control table.
3. Select Recheck Verdict. If the connection is successful, the WF-500 appliance returns a verdict. If the
connection is not successful, the verdict is No Connection.
STEP 1 | Verify that the ESM components are configured to communicate with WildFire.
See Set Up the ESM to Communicate with WildFire.
STEP 3 | To activate the WildFire module to enable Traps to calculate and check hash verdicts against
its local cache of hashes, set WildFire Activation to On.
STEP 5 | Specify whether Traps will notify the user about the malicious file.
From the User Alert drop-down, select On to notify the user or Off to silently log the event.
STEP 6 | (ESM 4.0.1 and later) To exempt a file from WildFire examination, add the file to the whitelist.
Whitelisting files can be useful if the associated hash value changes but the filename stays the same.
For example, consider an application such as GoToMeeting which creates a new executable file with
the same filename and a unique hash value each time you launch the application. In this case, to exempt
GoToMeeting from WildFire examination, you can add the full path for GoToMeeting.exe to the
whitelist.
If you do not expect the hash value associated with a file to change and want to whitelist
the file, we recommend that you configure an administrative hash override for the verdict.
The whitelist also supports the same environment variables and wildcards that
you can use in restriction rules. For example, to allow a file at path C:\temp
\myfilename.exe to run, add the path to the whitelist. Or to allow myfilename.exe to
run regardless of where myfilename.exe is stored, you can use wildcards to define
the full path as *\myfilename.exe.
3. Repeat this process to specify additional files.
4. Select the Whitelist Action to Merge or Override the whitelist with lists defined in other user-
defined or default policy rules.
If multiple rules specify List Action: Merge, Traps consolidates the Whitelist.
STEP 7 | Configure the WildFire integration behavior for the type of file:
To get the most out of WildFire integration, we recommend that you turn on all WildFire
functionality.
Executable Files:
Upload Files for WildFire AnalysisSet this value to On to enable Traps to send unknown executable
files to the ESM Console, which sends the files to WildFire for analysis.
Apply Malware Verdict on GraywareSet this option to On to treat all grayware as malware.
Otherwise, if this option is Off, grayware is considered benign and is not blocked.
Enable Local Analysis on Unknown FilesSet this option to On to enable Traps to use embedded
machine learning to determine the likelihood that an unknown executable file is malware and issue a
local verdict for the file. When this option is Off and is configured to block unknown files, users will
not be permitted to open unknown executable files. As a result, the unknown file remains blocked
until Traps receives an official WildFire verdict.
Quarantine Prevented FilesSet this option to On to enable Traps to quarantine malware on the
endpoint. A file is considered malware if one of the following sources issued a malware verdict for
the file: WildFire, administrative policy override, or local analysis. Set this option to Off to allow
malware to remain on the endpoint in its original location. The quarantine feature is not available for
malware identified in network drives.
WildFire Verdict is UnavailableSet this option to Block Unknowns or Allow Unknowns when the
file is unknown in the local and server cache.
By default Traps permits unknown executable files to open; however, if local analysis
is enabled, Traps always returns a verdict for an unknown executable file. Therefore,
enabling these options files only applies to agents for which local analysis is not
enabled or for agents running Traps 3.3.
ESM UnreachableSet this option to Block Unknowns or Allow Unknowns when Traps cannot reach
the ESM Server to query for a verdict or submit the file for analysis.
Office Files:
Upload Files with Macros for WildFire AnalysisSet this value to On to enable the ESM Server to
send the files it received from Traps agents which contain unknown macros to WildFire for analysis.
STEP 8 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat this step to add more conditions, as needed. To add a
condition to the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints.
STEP 9 | (Optional) Define the Target Objects to which to apply the WildFire rule. By default, a new rule
applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 10 | (Optional) Review the rule name and description. The ESM Console automatically generates
the rule name and description based on the rule details but permits you to change these
fields, if needed.
STEP 2 | Filter the results displayed on the Hash Control page using any of the following methods:
Import and run a previously-saved search query
1. Click the button to expand the list of available actions and search queries.
2. Select Import Search.
3. Browse to and Upload an XML file containing a previously saved search query. The Hash Control
page automatically applies the imported search query.
Use a predefined search query
1. Click the button to expand the list of available actions and search queries.
2. Select from one of the following predefined search queries:
1. Specify whether to match Any of the conditions you specify (similar to an OR operation) or to match
All of the conditions (similar to an AND operation).
2. To clear all existing search conditions, click . Or, to remove a single search term, click next to
the condition you want to remove.
3. Select your search condition, operator, and value. For options, see File Hash Search Conditions.
4. To enter additional search conditions, click next to the condition. The Hash Control page adds an
additional search condition for you to configure.
5. When you are done adding conditions, click Search. The Hash Control page displays up to 1000
records which match your search conditions.
STEP 3 | (Optional) To run you search query at a later time, export it to a file.
1. Click the button to expand the list of available actions and search queries.
2. Select Export Search. The ESM Console saves your search parameters to an XML file.
If you attempt to edit the XML file in Excel, Excel automatically adds quotes around some
values in the file. These quotes do not adhere to the input format expected by the ESM
Console. Therefore, if you need to modify the XML file, you must use a text editor to remove
the quotes before attempting to import the file.
STEP 1 | From the ESM Console, select Policies > Malware > Hash Control.
STEP 1 | From the ESM Console, select Policies > Malware > Hash Control.
STEP 2 | Search for and then select the hash for which you would like to see the report.
STEP 3 | Click WildFire Report. The ESM Console displays the cached report.
STEP 1 | From the ESM Console, select Policies > Malware > Hash Control.
STEP 2 | Select the record for a hash. If necessary, Filter Hash Control Records to reduce the number of
records the ESM Console displays.
STEP 3 | In the Previously Reported Verdicts section, review up to five of the most recent verdicts that
were applied on an agent.
STEP 4 | To view details about the endpoints which have opened the file associated with the hash,
select Agent List.
STEP 1 | From the ESM Console, select Policies > Malware > Hash Control.
STEP 2 | To view the WildFire verdict for a specific hash, do either of the following:
Use the search at the top of the page to search for a hash value or process name.
Use the paging controls on the top right of each page to view different portions of the table.
STEP 3 | To review the endpoints on which a user has tried to open the executable file, select Agent List
(available only when there are five or more instances of a process hash).
STEP 5 | Select the hash record and then click Treat as Benign to allow the executable file to run or
click Treat as Malware to block execution of the file. This override does not affect the official
WildFire verdict but it does change the verdict in the local security policy for your organization.
If you suspect a WildFire verdict is incorrect, please consider reporting the issue to Palo Alto
Networks. See Report an Incorrect Verdict.
STEP 6 | On a regular basis, review any mismatches between the official WildFire verdict and your local
policy action.
STEP 7 | When the override is no longer needed, remove it. From the action menu , select Revert to
WildFire Verdict. The ESM Console reverts to the verdict last known by the ESM Server.
STEP 1 | From the ESM Console, select Policies > Malware > Hash Control.
STEP 2 | To view the WildFire verdict for a specific hash, do either of the following:
Use the search at the top of the page to search for a hash value or process name.
Use the paging controls on the top right of each page to view different portions of the table.
STEP 3 | Select the hash record to view additional details about the process hash and then click
Recheck. To recheck multiple records at the same time, select the check box for each hash
record, and then select Recheck with WildFire from the action menu . These actions initiate
an immediate query to WildFire.
STEP 2 | Fill out the report with details that indicate why the verdict is incorrect.
1. Review the sample information and verify the verdict that you are reporting.
STEP 1 | From the ESM Console, select Policies > Malware > Hash Control.
STEP 2 | To view the WildFire verdict for a specific hash, do one of the following:
Use the search at the top of the page to search for a hash value or process name.
Use the paging controls on the top right of each page to view different portions of the table.
Filter the table entries by clicking the filter icon to the right of a column to specify up to two sets
of criteria by which to filter the results. For example, filter the Verdict column for unknown files.
STEP 3 | Select the row to view additional details about the process hash and then Upload the file to
WildFire.
When the same malware file (same filename and hash) runs from multiple locations, the
Hash Control page only displays information about the last instance. As a result, if you
choose to restore a file, you can only restore the last instance.
Each time you restore an executable file, the ESM Console sends a one-time action rule to the agent to
restore the file. You can also use Cytool to view and restore quarantined files (see Restorea Quarantined
File Using Cytool). To view the quarantine and restoration status, view the logs or configure the ESM to
send logs to an external logging server.
STEP 2 | Configure an administrative hash control policy for the executable file. Each time a user
attempts to run an executable file, Traps evaluates whether the file is malware and whether
to quarantine the file. If you choose to restore an executable file but do not change the Hash
Control policy, the next time a user attempts to run the file, Traps blocks and then quarantines
the file again. Therefore, to prevent Traps from continuing to block and quarantine a file, you
must configure an administrative hash control policy to Treat as Benign.
In the additional details view of the hash record, select Treat as Benign. You can also select the
checkbox next to the row or rows and select Treat as Benign from the action menu . This changes the
verdict in the server cache from Malware to Benign.
The Restore button is disabled (grayed out) if the file is not quarantined.
You can also forward reports for these events to an external logging server or to an email
address. See Reportsand Logging.
Select Monitor > Agent > Logs, Filter the Report Type by any of the following events:
File Restore SucceededTraps successfully restored an executable file to its original location on an
endpoint.
File Restore FailedTraps failed to restore an executable file to its original location on an endpoint.
185
186 TRAPS ADMINISTRATOR'S GUIDE | Exploit Protection
Exploit Protection Rules
An exploit protection rule uses exploit protection modules (EPMs) to protect processes in your organization
from specific exploitation techniques. An EPM is a code module that you activate for one or more processes
to prevent attacks on program vulnerabilities related to memory corruption or logic flaws.
The default security policy contains a preconfigured set of exploit protection rules that are activated for
commonly used protected processes. To protect processes and additional applications that are important
to your organization, you can add these to the list of protected or provisional processes and then configure
additional exploit protection rules. For example, to protect two processes that your organization uses (for
example, ProcessA.exe and ProcessB.exe) from a specific type of memory corruption attack called return
oriented programming (ROP), you can add the processes to the protected processes list and then create
an exploit protection rule that activates the ROP Mitigation EPM. When a user opens a file or URL, the
Traps agent injects code into the protected process or processes involved in opening the file and activates
the EPM. If the file contains code designed to exploit APIs used in ROP chains, Traps blocks the memory
corruption attack. When a security event triggers a prevention, the Traps agent also takes a snapshot of the
memory for subsequent forensic investigation.
On a regular basis, the Traps agent retrieves the latest security policy from the ESM Server. The security
policy determines which processes Traps protects and the type of EPM that Traps activates to protect the
process.
View a summary of exploit protection rules on the Policies > Exploit > Protection Modules page. Selecting a
rule on the page displays further information about the rule and other actions that you can take on the rule
(Delete, Activate/Deactivate, or Edit).
Consult with Palo Alto Networks Support before making any changes to the EPMs in security
policy rules.
CPL Protection Application Protects against vulnerabilities related to the display routine for
Protection Windows Control Panel shortcut images, which can be used as a
malware infection vector.
DLL Security Application Prevents access to crucial DLL metadata from untrusted code
Protection locations.
DLL-Hijacking Application Prevents DLL-hijacking attacks where the attacker attempts to load
Protection Protection DLLs from unsecured locations to gain control of a process.
Exception Heap Application Detects instances of heap sprays upon occurrence of suspicious
Spray Check Protection process crashes (indicative of exploitation attempts).
Exploit Kit Application Protects against the fingerprinting technique used by browser exploit
Fingerprinting Protection kits to identify informationsuch as the OS or applications which
Protection run on an endpointwhich attackers can use to leverage an attack or
evade protection capabilities.
Font Protection Application Prevents improper font handling, a common target of exploits.
Protection
Hot Patch Application Prevents the use of system functions to bypass DEP and address
Protection Protection space layout randomization (ASLR).
JIT Mitigation Application Prevents an attacker from bypassing the operating system's memory
Protection mitigations using just-in-time (JIT) compilation engines. In ninja-
mode, you can also configure advanced hooks and whitelists for this
module.
Kernel Privilege Kernel Prevents an attacker from using the privilege information of another
Escalation Protection process with greater privileges to run a process with system
Protection permissions.
Memory Limit Application Detects instances of heap sprays using the Palo Alto Networks
Heap Spray Protection proprietary algorithm, which is triggered by a sudden increase in
Check memory consumption (indicative of ongoing exploitation).
Null Application Prevents malicious code from mapping to address zero in the
Dereference Protection memory space, making null dereference vulnerabilities unexploitable.
Protection
ROP Mitigation Application Protects against the use of return oriented programming (ROP) by
Protection protecting APIs used in ROP chains.
SEH Protection Application Prevents hijacking of the Structured Exception Handler (SEH), a
Protection commonly exploited control structure called Linked List, which
contains a sequence of function records.
Shellcode Application Reserves and protects certain areas of memory commonly used to
Preallocation Protection house payloads using heap spray techniques.
SysExit Application Protects against the use of return oriented programming (ROP) by
Protection protecting APIs used in ROP chains.
JIT Mitigation Application Prevents an attacker from bypassing the operating system's memory
Protection mitigations using just-in-time (JIT) compilation engines. In ninja-
mode, you can also configure advanced hooks and whitelists for this
module.
Kernel Privilege Kernel Prevents an attacker from using the privilege information of another
Escalation Protection process with greater privileges to run a process with system
Protection permissions.
ROP Mitigation Application Protects against the use of return oriented programming (ROP) by
Protection protecting APIs used in ROP chains.
As with other types of rules, you can reduce the scope of an exploit protection rule by specifying Target
Objects and Conditions that must be satisfied for the rule to apply. A target object can be any user, group,
organizational unit, or computer that appears in Active Directory or any existing endpoint on which the
Traps agent is installed. A condition can refer to a specific file, the specific version or range of versions for a
file, or a registry path that must exist on the endpoint.
Additional EPMs and fine-grained settings are hidden and are accessible only in ninja mode . To configure
these EPMs and settings, you must enter an administrative password.
STEP 3 | From the action menu , select Add to add a new rule that applies to the operating system
you previously selected.
Changing EPM definitions changes the order in which rules are evaluated and can
affect your protection level (see Policy Enforcement). To avoid compromising your
organizational security, consult with Palo Alto Networks Support.
STEP 6 | Select the processes for which you want to apply the rule.
Before configuring an exploit protection rule on a new process, you must define the process and the
protection type on the Policies > Exploit > Process Management page. To add a new process, see Add
a New Protected Process. To change the protection type of a process, for example from Unknown to
Protected, see View, Modify, or Delete a Process.
1. Select the Processes tab.
2. Narrow the list of processes by selecting the process type from the drop-down, either Protected or
Provisional. Provisional processes are processes that are undergoing a test run and are monitored
separately from protected processes. For a list of processes that are protected by the default security
policy, see the release notes for your associated content update version.
3. Select one or more processes to which to apply the rule, and then click Add. Or, to apply the rule to
all protected or provisional processes, select All Processes.
STEP 7 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat this step to add more conditions, as needed. To add a
condition to the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints.
STEP 8 | (Optional) Define the Target Objects to which to apply the restriction rule.
To define a smaller subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 9 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
To avoid unnecessarily exposing your organization to attacks, create exclusion rules only
when necessary.
You can also create exclusion rules from scratch by adding Objects to the Exclude section of the rule (see
Create an Exploit Protection Rule).
STEP 3 | Click Create Rule to populate the rule with details about the specific EPM and endpoint. This
function is available only for exploit protection rules.
1. Review the details on the Processes, Conditions, Objects, and Name tabs.
2. By default the exclusion rule applies only to the endpoint on which the security event occurred. If
you want to exclude multiple objects or endpoints from the rule, add them to the Exclude section on
the Objects tab.
3. Apply the rule immediately or Save the rule to activate it later.
STEP 4 | Verify that the exclusion rule allows the process to run on the endpoint.
1. Open the Traps Console.
2. Select Check In Now to obtain the latest security policy.
3. Select Advanced > Policy and verify that the rule appears.
4. Launch the application on the endpoint to verify that the user can successfully run the process.
195
196 TRAPS ADMINISTRATOR'S GUIDE | Manage the Endpoints
Manage Traps Action Rules
Use action rules to perform one-time actions on the Traps agent that runs on each endpoint.
Traps Action Rules
Add a New Action Rule
Manage Data Collected by Traps
Uninstall or Upgrade Traps on the Endpoint
Manage data files that Each endpoint stores prevention and security information that includes
the Traps agent creates historical data, memory dumps, and quarantined files. Using this type of
action rule, you can erase or retrieve data files that the Traps agent creates on
the endpoint. For more information, see ManageData Collected by Traps.
Uninstall or upgrade Create an action rule to uninstall or upgrade Traps from the Endpoint Security
the Traps software Manager. To upgrade the Traps software on an endpoint, upload the software
zip file to the ESM (ESM) Server and specify the path when configuring the
action rule. For more information, see Uninstallor Upgrade Traps on the
Endpoint.
Traps does not apply action rules until the Traps agent receives the updated security policy,
typically with the next heartbeat communication with the server. To manually retrieve the
latest security policy from the ESM Server, select Check In Now on the Traps Console.
You can create or edit action rules on the Actions summary and management page (Settings > Agent >
Actions). Select a rule to display additional information about that rule and other actions that you can take
on the rule (Duplicate, Delete, or Activate/Deactivate). For more information, see ManageTraps Action
Rules.
STEP 2 | Select the type of operating system (Windows or macOS) and then Add a new rule.
STEP 4 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat this step to add more conditions, as needed. To add a
condition to the Conditions list, see Define Activation Conditions for a Rule.
STEP 5 | (Optional) Define the Target Objects to which to apply the action rule. By default, a new rule
applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 6 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 2 | Configure the tasks you want to perform on the Traps data stored on the endpoints.
Select Agent Data and then select any of the following options to manage Traps agent data.
Clear historyEach endpoint stores a history of security prevention events. Select this option to clear
historical data files from the Traps Console.
Erase memory dumpsMemory dumps are records of the contents of system memory when a
prevention event occurs. Select this option to erase the system memory records from target objects.
Erase quarantined filesWhen a security event occurs on an endpoint, Traps captures memory
dumps and recent files associated with the event and stores (quarantines) them in the forensic folder
STEP 3 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule.
STEP 4 | (Optional) Define the Target Objects to which to apply the action rule. By default, a new rule
applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 2 | Define the tasks you want to perform on the Traps agent on the endpoints.
1. Select Agent Installation and then select Uninstall to uninstall the Traps software or Upgrade from
path to browse to and then select the installation file to use for upgrading the Traps software.
2. Enter the Uninstall Password.
STEP 3 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 4 | (Optional) Define the Target Objects on page 128 to which to apply the action rule. By default,
a new rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
Event logging Configure a size quota for endpoint logs. For more information, see Define
Event Logging Preferences.
Heartbeat frequency Determine the frequency at which the Traps agent sends a heartbeat message
to the ESM Server. The optimal frequency is determined according to the
number of endpoints in the organization and the typical network load. For
more information, see Define Heartbeat Settings Between the Agent and the
ESM Server.
New process Configure Traps agents to collect new processes from endpoints. When this
information collection option is enabled, Traps reports every new process that runs on an endpoint
to the ESM Server. You can view the processes in the Process Management
view of the ESM Console and choose whether to create security rules related
to the processes. For more information, see Collect New Process Information.
Service protection (Windows only) Prevent attempts to disable or make changes to the Traps
registry values and files. When this option is enabled, users cannot shut down
or modify the Traps agent service. For more information, see Manage Service
Protection.
Agent security (Windows only) By default, users and administrators must enter a password
to uninstall the Traps application. Use this option to change the password. For
more information, see Change the Uninstall Password.
Communication Configure the amount of time, known as the timeout value, after which Traps
stops initiating attempts to reconnect to the ESM Server when the server
becomes unreachable. Configure the grace period to specify when Traps
should attempt to reestablish communication. For more information, see
Define Communication Settings Between the Agent and the ESM Server.
User visibility and Determine whether and how end users can access the Traps Console
access application. Optionally, you can configure the console so that only
administrators can access it. For more information, see Hide or Restrict
Access to the Traps Console.
User alerts Customize the general settings for all user alerts, including the display image
and footer. You can also configure the title that appears on user alerts related
to protection modules, restrictions, and unknown files. For more information,
see Create a Custom User Alert Message.
Traps does not apply agent setting rules until the Traps agent receives the updated security
policy, typically with the next heartbeat communication with the server. To manually retrieve
the latest security policy from the ESM Server, select Check-in now on the Traps Console.
Select a rule on the Settings page to display additional information about that rule and other actions that
you can perform to manage the rule (Delete, Activate/Deactivate, or Edit). For more information, see
Manage Agent Settings Rules.
STEP 2 | Select the type of operating system (Windows or macOS) and then Add a new rule.
STEP 3 | Select the type of setting that you want to change and configure your preferences.
Select one of the following, and then configure the settings according to the type of preference:
Event LoggingFor more information, see Define Event Logging Preferences.
Heartbeat SettingsFor more information, see Define Heartbeat Settings Between the Agent and
the ESM Server.
Communication SettingsFor more information, see Define Communication Settings Between the
Agent and the ESM Server.
Process ManagementFor more information, see Collect New Process Information.
(Windows only) Service ProtectionFor more information, see Manage Service Protection.
(Windows only) Agent SecurityFor more information, see Change the Uninstall Password.
User Visibility & AccessFor more information, see Hide or Restrict Access to the Traps Console.
User AlertsFor more information, see Create a Custom User Alert Message.
STEP 4 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule.
STEP 5 | (Optional) Define the Target Objects to which to apply the agent settings rule. By default, a new
rule applies to all objects in your organization.
STEP 6 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 3 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 4 | (Optional) Define the Target Objects on page 128 to which to apply the agent settings rule. By
default, a new rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
You can create an agent settings rule to change the accessibility of the console and specify whether to hide
notifications from users.
STEP 3 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
Define Heartbeat Settings Between the Agent and the ESM Server
During the heartbeat communication, the Traps agent requests the current security policy and sends a
response to the Endpoint Security Manager to report the status of the endpoint. The frequency at which
the Traps agent sends heartbeat messages to the ESM Server is called the heartbeat cycle. The optimal
frequency is determined according to the number of endpoints in the organization and the typical network
load.
Traps also reports changes in service, including start, stop, and crash events and new processes discovered
on the endpoint. The frequency at which the Traps agent sends report notifications is called the reports
interval.
STEP 3 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 4 | (Optional) Define the Target Objects on page 128 to which to apply the agent settings rule. By
default, a new rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 2 | Define the communication settings between the Traps agent and the ESM Server.
Select Communication Settings and then select one or more of the following options:
Set Agent-WildFire Process Verdict TimeoutSpecify the amount of time (in seconds) that Traps
will wait for the ESM Server to respond to a verdict request (default is 10). After the timeout
period expires, Traps assigns the process a No Connection verdict. Traps will attempt to reestablish
communication only if a user clicks Check-In Now on the Traps Console, or if Traps needs to query
the ESM Server for unknown hash verdicts.
If your endpoints frequently lose their connection with the server, consider increasing the
timeout value.
Set No Connection Refresh IntervalSpecify the frequency (in minutes) at which the Traps agent
checks for available ESM Servers after entering a No Connection state (default is 1).
Set ESM Server Validation IntervalSpecify the frequency (in hours) at which the agent will verify
the integrity of the ESM Server list (default is 1).
STEP 3 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 4 | (Optional) Define the Target Objects on page 128 to which to apply the agent settings rule. By
default, a new rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 3 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 4 | (Optional) Define the Target Objects on page 128 to which to apply the agent settings rule. By
default, a new rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 7 | On a regular basis, review the list of unprotected processes and evaluate whether add them to
existing security rules or create new rules to protect them.
1. Select Policies > Exploit > Process Management.
2. Filter or sort the table by the Unprotected protection type.
3. Review each process and decide whether to change the protection type:
Change the protection type to Provisional, if you want to use the process in a security rule run as
a test.
Change the protection type to Protected to take advantage of existing rules that apply to all
processes. See View, Modify, or Delete a Process on page 140. You can also add the process to
rules that apply to specific processes, as needed.
STEP 3 | (Optional) Add Conditions to the rule. By default, a new rule does not contain any conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule.
STEP 4 | (Optional) Define the Target Objects to which to apply the agent settings rule. By default, a new
rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 3 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 4 | (Optional) Define the Target Objects on page 128 to which to apply the agent settings rule. By
default, a new rule applies to all objects in your organization.
To define a subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Units, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
Traps displays prevention and notification messages when a file or process violates a security policy and
the termination behavior is configured to block the file and notify the user or to log the issue and notify the
user. Use an agent settings rule to customize the general settings for all user alerts, including the display
image and footer. You can also configure the title that appears on user alerts related to protection modules,
restrictions, or unknown files.
STEP 2 | (Optional) Customize the icon and footer used for all user alert messages.
1. Select User Alerts and then select General Settings (icon and footer).
2. Customize either or both of the following options:
IconTo select an image that will appear in place of the Traps icon in user alert messages, Browse
to and then Upload a new image. The preview on the right allows you to view an example of how
the user alert message will look with the new icon.
Action/FooterTo provide contact or other information along the bottom of the message, enter
up to 250 characters. The preview on the right shows your changes as you make them. To specify
an email address, use standard HTML format, for example:
<a href="mailto://[email protected]"> Help Desk</a>
3. Select the Triggering Action: Prevention Mode or Notification Mode.
STEP 4 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 6 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 1 | From the ESM Console select Monitor > Agent > Health.
STEP 2 | In the agent health table, select the checkbox for one or more endpoints you want to delete.
To quickly locate an endpoint, use the filter controls at the top of the columns.
STEP 3 | Select Delete Selected from the action menu at the top of the Health table. Click OK to
confirm the deletion.
The ESM Console changes the status of the endpoint to Historic and hides the endpoint from the
default display of endpoints on the Health page (to view the deleted endpoints, filter the status column
by Historic).
215
216 TRAPS ADMINISTRATOR'S GUIDE | Forensics
Forensics Overview
Forensics Flow on page 217
Forensic Data Types on page 218
Forensics Flow
Accessed Files Files that are loaded in memory under the attacked process for in-depth event
inspection including:
Relevant DLL retrieval including their path
Relevant files from Temporary Internet Files folder
Open files (executables and non-executables)
Loaded Modules PE image files that are loaded on the system at the time of a security event.
Accessed URI Network resources that were accessed at the time of the security event and
uniform resource identifier (URI) information.
The Traps agent can collect accessed URI from Internet Explorer and Firefox
browsers only. When an event occurs that is related to other browsers (for
example, Microsoft Edge), you will not be able to access URI data for further
analysis.
Collected information includes:
URIs including hidden links and frames of the relevant attacked threads.
Java applet source URIs, filenames and paths, including parents,
grandparents, and child processes
Collection of URI calls from browser plug-ins, media players, and mail-
client software
To customize which types of files are collected, Create a Forensics Rule on page 223.
Forensics Rules
Forensics management rules enable you collect forensics data captured by Traps from a central location.
From the Policies > Forensics > Management page, you can create rules to manage the following forensics
settings:
Memory dump Specify files settings including a size for the memory dump and enable
settings Traps to send the memory dump to the server automatically. This
setting only applies to data collected from prevention events related to
protected processes. For more information, see Define Memory Dump
Preferences on page 224.
Forensics collection Enable Traps to collect forensic data for each security event including
which files were accessed, modules that were loaded into memory, URIs
that were accessed, and ancestor processes of the process that triggered
the security event. For more information, see Define Forensics Collection
Preferences on page 225.
To encrypt forensic data, we strongly recommend that you use SSL to communicate
with the forensic folder. To use SSL, include the fully qualified domain name (FQDN)
and specify port 443, for example HTTPS://ESMserver.Domain.local:443/
BitsUploads. If you are not using SSL, specify port 80, for example http://
ESMSERVER:80/BitsUploads.
All commands run using the DB Configuration Tool are case sensitive.
C:\Users\Administrator> cd
C:\Program Files\Palo Alto Networks\Endpoint Security Manager\Server
To encrypt forensic data, we strongly recommend that you use SSL to communicate
with the forensic folder. To use SSL, include the fully qualified domain name (FQDN)
and specify port 443, for example HTTPS://ESMserver.Domain.local:443/
BitsUploads. If you are not using SSL, specify port 80, for example http://
ESMSERVER:80/BitsUploads.
STEP 5 | (Optional) To verify the path of the forensic folder, run the dbconfig server show command:
STEP 3 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions, as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 4 | (Optional) Define the Target Objects on page 128 to which to apply the restriction rule.
To define a smaller subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 2 | Define memory dump preferences when a prevention event occurs on the endpoint.
1. Select Memory Dump and then select either of the following preferences:
Automatically send the memory dumps to the server by selecting Send the memory dumps
automatically.
Specify the size of the memory dump file by selecting the Memory dump size option and then
selecting Small, Medium, or Full from the drop-down.
2. Select the source processes from with Traps will collect memory dumps, either one or more Specific
processes or All processes.
STEP 3 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions, as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 4 | (Optional) Define the Target Objects on page 128 to which to apply the restriction rule.
To define a smaller subset of target objects, select the Objects tab, and then enter one or more Users,
Computers, Groups, Organizational Unit, or Existing Endpoints in the Include or Exclude areas.
The Endpoint Security Manager queries Active Directory to verify the users, computers, groups, or
organizational units or identifies existing endpoints from previous communication messages.
STEP 3 | (Optional) Add Conditions on page 125 to the rule. By default, a new rule does not contain any
conditions.
To specify a condition, select the Conditions tab, select the condition in the Conditions list, and then
Add it to the Selected Conditions list. Repeat to add more conditions, as needed. To add a condition to
the Conditions list, see Define Activation Conditions for a Rule on Windows Endpoints on page 126.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
To create a general rule to retrieve data from one or more endpoints, see Manage Data Collected by Traps
on page 198.
STEP 1 | From the ESM Console, select Security Events > Threats to view security events related
to protected processes, or Monitor > Provisional Mode to view security events related to
provisional processes.
STEP 3 | Click Retrieve Data. The ESM Console populates the settings for an agent settings rule.
STEP 4 | Review the rule details, and then click Apply to activate the rule immediately or Save to
activate the rule at a later date. At the next heartbeat communication with the ESM Server, the
Traps agent receives the new rule and sends the prevention data to the forensics folder.
STEP 5 | To view the status of the forensic upload select Monitor > Data Retrieval.
STEP 6 | After the upload is complete, click Download to save the prevention data locally or navigate to
the forensic folder. If you are no longer require the prevention data, you can, optionally, Delete
it from the Data Retrieval table.
STEP 2 | Configure one or more search parameters for the query. When multiple search parameters are
specified, Traps will return a result if the search matches any of the parameters.
1. Select the search parameters, either a File name, Folder name, or Registry Key name.
2. Enter the matching search value, and then click Add.
Optionally, you can use wildcards in the last portion of the file or folder name path, for
example: C:\Temp\*.txt
3. Repeat as needed to enter multiple search criteria.
STEP 5 | (Optional) Review the rule name and description. The ESM Console automatically generates the
rule name and description based on the rule details but permits you to change these fields, if
needed.
To override the autogenerated name, select the Name tab, clear the Activate automatic description
option, and then enter a rule name and description of your choice.
STEP 1 | From the Policies > Forensics > Agent Query page, select the row for the applied query. The
row expands to display additional information about the query and includes any matches for
the query in the Agent Query, Found matches section.
For each applied query, the ESM Console displays the number of endpoints that received the query
(Applied On), the number of endpoints which successfully executed the search (Succeeded), and the
number of endpoints which failed to run the query or did not receive the query (Failed).
STEP 2 | (Optional) To view detailed information about the match, click Details.
STEP 3 | (Optional) To view the full text, hover over cell of the Result or Metadata field.
STEP 4 | (Optional) To save the results to a comma-separated (CSV) file that you can parse, click the
action menu at the top of the page and select Export Logs.
231
232 TRAPS ADMINISTRATOR'S GUIDE | Reports and Logging
Event Log Types
The ESM Console displays information about events that occur on your Traps components on the Logs
and Security Events pages. The events can include security events, policy changes, agent and ESM Server
status changes, and changes to settings. When you enable log forwarding to a SIEM or syslog device, or to
an email, you can customize the type of events that the ESM Console sends. The events are grouped into
the following categories based on the type of event:
Security Events on page 233
Policies - General on page 234
Policies - Rules on page 234
Policies - Process Management on page 235
Policies - Restriction Settings on page 235
Policies - Hash Control on page 236
Monitor - Agent on page 237
Monitor ESM on page 241
Settings - Administration on page 242
Settings - Agent on page 243
Settings - ESM on page 244
Settings - Conditions on page 245
Settings - Licenses on page 245
Security Events
The following table displays the security event logs you can forward to an external logging platform or
email.
Post Detection Event An executable file that was previously allowed to run on an endpoint was
determined to be malware. Post detection events provide notifications for
each endpoint on which the file executed.
CEFPostDetectionEvent
LEEFPostDetectionEvent
SyslogPostDetectionEvent
EmailPostDetectionEvent
Protection Disabled An administrator disabled protection of all security rules on the ESM Console.
CEFDisabledProtection
LEEFDisabledProtection
SyslogDisabledProtection
EmailDisabledProtection
Protection Enabled An administrator re-enabled protection by all security rules on the ESM
Console.
CEFEnabledProtection
LEEFEnabledProtection
SyslogEnabledProtection
EmailEnabledProtection
Server Content Revert A content update was rolled back to an older version.
Success
CEFServerContentRevertSuccess
LEEFServerContentRevertSuccess
SyslogServerContentRevertSuccess
EmailServerContentRevertSuccess
Server Content Revert A content update failed to roll back to an older version.
Failure
CEFServerContentRevertFailure
LEEFServerContentRevertFailure
SyslogServerContentRevertFailure
EmailServerContentRevertFailure
Policies - Rules
The following table displays the policy rule logs you can forward to an external logging platform or email.
Verdict Changed - The verdict of a hash has changed from malicious to a new verdict.
Malware to Any
CEFVerdictChangeMalwareToAny
LEEFVerdictChangeMalwareToAny
SyslogVerdictChangeMalwareToAny
EmailVerdictChangeMalwareToAny
Verdict Changed - No The verdict of a hash has changed from no connection to a new verdict.
Connection to Any
CEFVerdictChangeNoConnectionToAny
LEEFVerdictChangeNoConnectionToAny
SyslogVerdictChangeNoConnectionToAny
EmailVerdictChangeNoConnectionToAny
Verdict Changed - The verdict of a hash has changed from unknown to a new verdict.
Unknown to Any
CEFVerdictChangeUnknownToAny
LEEFVerdictChangeUnknownToAny
SyslogVerdictChangeUnknownToAny
EmailVerdictChangeUnknownToAny
Hashes Imported An administrator has imported one or more hashes into the server cache.
CEFHashesImport
LEEFHashesImport
SyslogHashesImport
EmailHashesImport
Monitor - Agent
The following table displays the agent logs you can forward to an external logging platform or email.
Agent Service Start The agent service was started on the endpoint.
CEFServiceAlive
LEEFServiceAlive
SyslogServiceAlive
EmailServiceAlive
Agent Service Stopped The agent service was stopped on the endpoint.
CEFServiceStopped
LEEFServiceStopped
SyslogServiceStopped
EmailServiceStopped
Agent Service Start The agent service failed to start on the endpoint.
Failed
CEFServiceStartFailed
LEEFServiceStartFailed
SyslogServiceStartFailed
EmailServiceStartFailed
Agent Process Injection The agent exceeded the permissible amount of time to inject into a process.
Timeout
CEFProcessInjectionTimedOut
LEEFProcessInjectionTimedOut
SyslogProcessInjectionTimedOut
EmailProcessInjectionTimedOut
Local Analysis Feature The file that local analysis tried to examine was corrupt and could not be
Extraction Failed examined using local analysis. When this occurs, Traps identifies the file as
malware until it receives a verdict (either from WildFire or the administrative
hash control policy).
CEFLocalAnalysisFeatureExtractionFailed
LEEFLocalAnalysisFeatureExtractionFailed
SyslogLocalAnalysisFeatureExtractionFailed
EmailLocalAnalysisFeatureExtractionFailed
Local Analysis Model The local analysis model was missing on the endpoint and was therefore
Unavailable disabled.
CEFLocalAnalysisModelUnavailable
LEEFLocalAnalysisModelUnavailable
SyslogLocalAnalysisModelUnavailable
EmailLocalAnalysisModelUnavailable
Local Analysis Module The local analysis model successfully analyzed an unknown executable file
Succeeded and issued a verdict.
CEFLocalAnalysisModuleSucceeded
LEEFLocalAnalysisModuleSucceeded
SyslogLocalAnalysisModuleSucceeded
EmailLocalAnalysisModuleSucceeded
Local Analysis Module The local analysis model failed to analyze an unknown executable file and
Failed issue a verdict.
CEFLocalAnalysisModuleFailed
LEEFLocalAnalysisModuleFailed
SyslogLocalAnalysisModuleFailed
EmailLocalAnalysisModuleFailed
Trusted Signer Changed The local decision of a trusted signer on the agent has changed. This can
be due a change in the local certificate store on the endpoint, a content
update containing changes to the trusted signer list, or a manual update to the
trusted signers list.
CEFPublisherChanged
LEEFPublisherChanged
SyslogPublisherChanged
EmailPublisherChanged
Agent Content Update The agent received a new content update version.
CEFAgentContentUpdate
LEEFAgentContentUpdate
SyslogAgentContentUpdate
EmailAgentContentUpdate
Quarantine Quota The storage quota for quarantined files on the endpoint has been exceeded.
Exceeded
CEFQuarantineQuotaExceeded
LEEFQuarantineQuotaExceeded
SyslogQuarantineQuotaExceeded
EmailQuarantineQuotaExceeded
Agent Registration An agent that has already registered with the ESM Server has tried to re-
Conflict register but lacks valid authentication identification. This could indicate:
A duplicate machine name exists on the network (for Traps agents running
pre-4.0.2 versions). When this occurs, ensure the machine name is unique
or upgrade the agent to Traps 4.0.2 or a later release to ensure the agent
receives a unique ID.
A malicious component is attempting to manipulate the endpoint
protection policy. When this occurs, verify the validity of the agent and, if
needed, remediate the component.
Formats:
CEFRegistrationConflict
LEEFRegistrationConflict
SyslogRegistrationConflict
EmailRegistrationConflict
Monitor ESM
The following table displays the ESM logs you can forward to an external logging platform or email.
ESM Status Changed The status of the ESM Server has changed.
CEFEsmStatusChange
LEEFEsmStatusChange
SyslogEsmStatusChange
EmailEsmStatusChange
Tech Support File The status of the ESM tech support file has changed.
Status
CEFTechSupportFileStatus
LEEFTechSupportFileStatus
SyslogTechSupportFileStatus
EmailTechSupportFileStatus
Communication Check A proxy communication event occurred between the ESM components and
with Proxy the proxy server. Proxy communication events can disrupt communication
with WildFire.
CEFCommunicationsCheckWithProxy
LEEFCommunicationsCheckWithProxy
SyslogCommunicationsCheckWithProxy
EmailCommunicationsCheckWithProxy
WildFire The communication status between the ESM Server and WildFire has
Communication Status changed from reachable to unreachable or from unreachable to reachable.
Changed
CEFWfCommunicationsStatusChanged
LEEFWfCommunicationsStatusChanged
SyslogWfCommunicationsStatusChanged
EmailWfCommunicationsStatusChanged
Settings - Administration
The following table displays the administrative logs you can forward to an external logging platform or
email.
Settings - Agent
The following table displays the agent settings logs you can forward to an external logging platform or
email.
Agent One Time Action An agent has finished running an action rule on an endpoint.
Completed
CEFOneTimeActionComplete
LEEFOneTimeActionComplete
SyslogOneTimeActionComplete
EmailOneTimeActionComplete
Agent One Time Action An agent failed to run an action rule on an endpoint.
Failed
CEFOneTimeActionFailed
LEEFOneTimeActionFailed
SyslogOneTimeActionFailed
EmailOneTimeActionFailed
File Restore Failed An agent failed to restore a file to its original location on the endpoint or
attached removable media.
CEFRestoreFailed
LEEFRestoreFailed
SyslogRestoreFailed
EmailRestoreFailed
File Quarantine Failed An agent failed to quarantine a file on the endpoint or its attached removable
media.
CEFQuarantineFailed
LEEFQuarantineFailed
SyslogQuarantineFailed
EmailQuarantineFailed
File Restore Succeeded An agent successfully restored a file to its original location on the endpoint or
attached removable media.
CEFRestoreSucceeded
LEEFRestoreSucceeded
SyslogRestoreSucceeded
EmailRestoreSucceeded
File Quarantine An agent successfully quarantined a file on the endpoint or its attached
Succeeded removable media.
CEFQuarantineSucceeded
LEEFQuarantineSucceeded
SyslogQuarantineSucceeded
EmailQuarantineSucceeded
Settings - ESM
The following table displays the ESM settings logs you can forward to an external logging platform or email.
ESM Items Deleted A security event was removed from the ESM Console.
CEFArchivedPreventions
LEEFArchivedPreventions
SyslogArchivedPreventions
EmailArchivedPreventions
ESM Items Deleted The ESM Console failed to remove a security event.
Failed
CEFArchivedPreventionsFailure
LEEFArchivedPreventionsFailure
SyslogArchivedPreventionsFailure
EmailArchivedPreventionsFailure
Settings - Licenses
The following table displays the license management logs you can forward to an external logging platform
or email.
License Quantity The license utilization has reached 80%. Consider purchasing additional
licenses.
CEFLicenseQuantity
LEEFLicenseQuantity
SyslogLicenseQuantity
EmailLicenseQuantity
License Pool Added A new pool of licenses was added to the ESM Console.
CEFLicensePoolAdded
LEEFLicensePoolAdded
SyslogLicensePoolAdded
EmailLicensePoolAdded
Name Meaning
For example, consider the output for an Agent Service Start event in CEF format:
Notice that this event uses several common variables, namely: dhost, duser, and msg.
Name Meaning
For example, consider the output for a Role Added/Edited event in CEF format:
Notice that this event uses several common variables, namely: shost, suser, and msg.
Name Meaning
For example, consider the output of a Hash Added event in CEF format:
Notice that this event uses several common variables, namely: shost, suser, fileHash, and msg.
Name Meaning
For example, consider the following output for a Communication Check With Proxy event in CEF format:
Notice that this event uses several common variables, namely: shost, dhost, and msg.
Notice that this event uses several common variables, namely: dhost, duser, deviceProcessName,
fileHash, dvc, and msg.
STEP 2 | Configure the settings to send logs from ESM components to an external logging platform. To
send logs to an email, see Forward Logs to Email on page 299.
Configure the following settings:
Syslog ServerHostname or IP address of the external logging platform.
Syslog PortCommunication port of the external logging platform, such as 514.
Syslog ProtocolThe format the ESM uses to send reports: CEF, LEEF, or Syslog.
Keep-alive TimeoutPeriod (in minutes) in which Traps sends a keep-alive message to the external
logging platform (default is 0; range is 0 to 2,147,483,647). A value of 0 specifies that you do not
want to send a keep-alive message to the external logging platform.
Communication ProtocolTransport layer protocol that the ESM uses to send syslog reports: TCP,
TCP with SSL, or UDP.
STEP 3 | Select the events that you want to send to the external logging platform.
In the Logging Events area, select one or more of the events. Scroll through the list to see additional
types of events you can send.
All commands run using the DB Configuration Tool are case sensitive.
C:\Users\Administrator> cd
C:\Program Files\Palo Alto Networks\Endpoint Security Manager\Server
STEP 4 | Enable log forwarding to an external logging platform such as a syslog server:
STEP 5 | Specify the IP address (or hostname) of the external logging platform:
STEP 6 | Specify the communication port for the external logging platform, a value between 1 and
65535 (default is 514):
STEP 7 | Specify the protocol that the ESM Console will use to send reports, either Cef, Leef, or
Rfc5424 (syslog).
STEP 8 | (Optional) Specify a timespan (in minutes) where the endpoint sends a keep alive message to
the log or report, a value of 0 or greater (default is 0):
STEP 9 | (Optional) Specify the maximum number of report notifications to store in the database, a value
of 0 or greater (default is 4000):
For example, specifying a maximum report count of 5000 notifications means the Endpoint Security
Manager will discard older notifications higher than 5000.
STEP 10 | (Optional) Specify the minimum number of report notifications to store in the database, a value
of 0 or greater (default is 5000):
CEF Format
The following table lists the events in CEF format.
LocalAnalysisFeatureExtractionFailed
@Model["Time"] @Model["EsmIp"] CEF:0|
Palo Alto Networks|Traps Agent|
@Model["ProductVersion"]|Local Analysis
Extraction Failed|Agent|@Model.ExternalSeverity|
rt=@Model["Time"] dhost=@Model["host"]
duser=@Model["user"] cs3Label=ContentVersion
cs3=@Model["ContentVersion"] msg=Local Analysis
Feature Extraction Failed
VerdictChangeNoConnectionToAny
@Model["Time"] @Model["EsmIp"] CEF:0|Palo Alto
Networks|Traps ESM|@Model["ProductVersion"]|
Verdict Change No Connection To Any|Policy|
@Model.ExternalSeverity|rt=@Model["Time"]
shost=@Model["esmHost"] suser=@Model["user"]
fileHash=@Model["Hash"] cs5Label=NewVerdict
cs5=@Model["NewVerdict"] msg=Hash verdict changed
from No Connection. @Model["OldVerdict"] ->
@Model["NewVerdict"]
LEEF Format
The following table lists the events in LEEF format.
LocalAnalysisFeatureExtractionFailed
LEEF:1.0|Palo Alto Networks|Traps Agent|
@Model["ProductVersion"]|Local Analysis Extraction
Failed|cat=Agent subtype=Local Analysis Extraction
Failed devTime=@Model["Time"] src=@Model["EsmIp"]
dhost=@Model["host"] duser=@Model["user"]
ContentVersion=@Model["ContentVersion"]
msg=Local Analysis Feature Extraction Failed
[email protected]
VerdictChangeNoConnectionToAny
LEEF:1.0|Palo Alto Networks|Traps ESM|
@Model["ProductVersion"]|Verdict Change No
Connection To Any|cat=Policy subtype=Verdict
Change No Connection To Any devTime=@Model["Time"]
src=@Model["EsmIp"] shost=@Model["esmHost"]
suser=@Model["user"] fileHash=@Model["Hash"]
NewVerdict=@Model["NewVerdict"] msg=Hash verdict
changed from No Connection. @Model["OldVerdict"] ->
@Model["NewVerdict"] [email protected]
LocalAnalysisFeatureExtractionFailed
<134>1 @Model["Rfc5424Time"]
@Model["EsmIp"] - - - @Model["Time"],Traps
ESM,@Model["ProductVersion"],Config,License
Revoked,@Model["esmHost"],@Model["user"] ,@Model["host"],Licens
revoked,@Model.ExternalSeverity,,,,
VerdictChangeNoConnectionToAny
<134>1 @Model["Rfc5424Time"]
@Model["EsmIp"] - - - @Model["Time"],Traps
ESM,@Model["ProductVersion"],Policy,Verdict Change
Malware To
Any,@Model["esmHost"],@Model["user"],Hash verdict
changed from Malware. Awaiting to restore:
@Model["QuarantineStatus"]. @Model["OldVerdict"] ->
@Model["NewVerdict"],@Model.ExternalSeverity,@Model["Hash"],,,@
WfCommunicationsStatusChanged<134>1 @Model["Rfc5424Time"]
@Model["EsmIp"] - - - @Model["Time"],Traps
ESM,@Model["ProductVersion"],Policy,Verdict
Reverted To
Wildfire,@Model["esmHost"],@Model["user"],Hash
verdict reverted to WildFire.
@Model["OldVerdict"] ->
@Model["NewVerdict"],@Model.ExternalSeverity,@Model["Hash"],,,@
Because a Panorama virtual appliance in legacy mode cannot ingest Traps logs, you must
use a Panorama virtual appliance in Panorama mode.
STEP 1 | On your enterprise domain controller, create a DNS A record that points to the IP address of
the Panorama log collector (for example, you can use the DNS snap-in available in Windows
Administrative Tools to create the DNS record).
STEP 2 | Create the server certificate for the ESM components to use to trust and verify the identity of
Panorama. The certificate must be generated from a certificate authority (CA) that is trusted
by the ESM. The Common Name of the certificate must also identify Panorama using the name
you specified in the DNS record.
There are multiple methods for creating the server certificate:
Obtain a certificate from an external CA (see Steps 1 and 2 in the procedure and then follow the
instructions below to import the certificate)
Obtain a certificate from your Active Directory CA.
The following procedure describes how to create a certificate from your Active Directory CA:
1. Open IIS Manager and navigate to the level you want to manage.
2. Double-click Server Certificates.
3. In the Actions pane, click Create Domain Certificate.
4. On the Distinguished Name Properties page of the Create Certificate Wizard, enter the information
for your certificate. In the Common name field, make sure to specify Panorama using the name you
used to identify the server in the DNS record.
STEP 4 | Click the certificate Name and enable the Certificate for Secure Syslog, then click OK.
STEP 5 | On Panorama, associate the certificate that you configured for secure communication with the
managed collector:
1. Select Panorama > Managed Collectors > <collector> > General.
2. Select the Inbound Certificate for Secure Syslog. This is the certificate you created and imported
earlier in the workflow.
3. Click OK and then Commit your changes.
STEP 6 | Enable communication between the ESM Server and Panorama to use TLS 1.1 and higher
protocols.
1. On the ESM Server, open regedit.exe: Click Start, and type regedit in the Run or Search field and
press Enter.
2. Browse to the following path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
\v4.0.30319\
3. Select Edit > New > DWORD (32-bit) Value.
4. Name the value SchUseStrongCrypto.
5. Double-click the new value and enter 1 as the value data in Hexadecimal format, then click OK.
6. Reboot the ESM Server.
STEP 7 | Configure the ESM to forward logs to Panorama as described in Enable Log Forwarding to
Panorama and then verify your connectivity.
STEP 2 | To Configure a Panorama log collector to receiveESMandTraps logs, first define the log
ingestion profile on Panorama:
1. Select Panorama > Log Ingestion Profile, and click Add.
2. Enter a Name for the profile.
3. Add a new profile and enter the details for the ESM Server. You can add up to four ESM Servers to a
profile.
4. Enter a Source Name.
5. Specify the Port on which Panorama will be listening for syslog messages. The range is 23000 to
23999.
6. Select the Transport layer protocolTCP, UDP, or SSL.
7. Select Traps_ESM for External Log type and 3.4.1+ from the Version drop-down.
As Traps log formats are updated, the updated log definitions will be available through content updates
on Panorama.
STEP 2 | Select Monitor > External Logs > Traps ESM to view the logs ingested in to Panorama.
The date/time of the each logged event is in Universal Time Coordinated (UTC).
Use the following workflow to configure the ESM Console to send logs and events to an email account.
STEP 1 | Enable email reporting.
From the ESM Console, select Settings > ESM > Email, and then select Enable Mail Reporting.
STEP 3 | Select the events that you want to send to an external email address.
In the Logging Events area, select one or more of the events. Scroll through the list to see additional
types of events you can send.
LocalAnalysisFeatureExtractionFailed<html><body><p><div>Log Event:<strong>
Local Analysis Feature Extraction Failed</
strong></div><p></p><div>Description:<strong>
Local Analysis Feature Extraction
Failed</strong></div><div>Content
Version:<strong>@Model["ContentVersion"]</
strong></div><div>Hash:<strong>@Model["Hash"]</
strong></div><div>Model
Version:<strong>@Model["ContentVersion"]</
strong></div><div>Server
Name:<strong>@Model["esmHost"],
@Model["EsmIp"]</strong></div><div>By
User:<strong>@Model["user"]</strong></
div><div>Product Version:<strong>
@Model["ProductVersion"]</strong></div></p></
body></html>
317
318 TRAPS ADMINISTRATOR'S GUIDE | Troubleshooting
Traps Troubleshooting Resources
To troubleshoot Traps and the Endpoint Security Manager (comprising an ESM Server, the ESM Console,
and a database), use the following resources:
Resource Description
ESM Resources
ESM Console Web interface, which provides reports and logs. The information is useful
for monitoring and filtering the logs to interpret unusual behavior on your
network. After analyzing a security event, you can choose to create a custom
rule for the endpoint or process.
ESM Server DebugWeb Indicates information, warnings, and errors related to the Endpoint Security
log Manager. The DebugWeb log is located in the %ProgramData%\Cyvera
\Logs folder of the ESM Server.
ESM Server log Indicates information, warnings, and errors related to the Endpoint Database
and ESM Server. The Server log is located in the %ProgramData%\Cyvera
\Logs folder of the ESM Server.
ESM Tech Support file On-demand aggregation of active ESM Console and ESM Server logs and
settings to aid Technical Support in troubleshooting and diagnosing issues.
For more information, see ESM Tech Support File.
Database (DB) Command-line interface that provides an alternative to managing basic server
Configuration Tool settings using the ESM Console. You can access the DB Configuration Tool
(dbconfig.exe) using a Microsoft MS-DOS command prompt run as an administrator. For
more information, see Database (DB) Configuration Tool.
Traps Resources
Traps installation log Specifies any errors encountered during installation of Traps or ESM
components. Use this log file when you need to troubleshoot installation
issues. On Windows endpoints, the installer stores the log files in the %temp%
or C:\Users\<user_name>\AppData\Local\Temp folder.
Traps Service log Indicates information, warnings, and errors related to the Traps service. The
Service log is located in the following folder on the endpoint:
Windows Vista and later: %ProgramData%\Cyvera\Logs
Windows XP: C:\Document and Settings\All Users
\Application Data\Cyvera\Logs
Mac OS X 10.10 and OSX 10.11/var/log/traps/
macOS 10.12View logs from the Console application
Traps Console log Indicates information, warnings, and errors related to the Traps console.
The Console log is located in the following folder on the endpoint:
Windows Vista and later: C:\Users\<username>\AppData\Roaming
\Cyvera
Windows XP: C:\Document and Settings\<username>
\Application Data\Cyvera\Logs
Mac OS X 10.10 and OSX 10.11/var/log/traps/agent/
macOS 10.12View logs from the Console application
Traps and ESM initiated See Traps and Endpoint Security Manager Processes.
processes
Supervisor Command Allows you to enumerate protected processes, enable or disable protection
Line Tool (cytool.exe) features, and enable or disable Traps management actions from a command
line interface. For more information, see Cytool.
ESM
ESM CyveraServer.exe ESM Server core service, which communicates with the agents and
Server with WildFire.
Traps authorized Traps process which communicates with WildFire to obtain the latest
agent verdicts.
Traps pmd Traps process which communicates with the ESM Server to obtain the
agent latest security policies.
Traps kproc_ctrl Kernel extension which enforces the policy and prevent security
agent attacks, when needed.
Traps CyveraConsole.exe User interface for the Traps console. Runs only after the user launches
agent the console from the notification area (system tray).
Traps CyveraService.exe Traps agent core service, which works with Cyserver.exe to enforce
agent the policy, communicate with the server, and prevent security attacks,
when needed.
Traps Cyserver.exe Traps agent core service, which works with CyveraService.exe to
agent enforce the policy, communicate with the server, and prevent security
attacks, when needed.
Traps Cytray.exe Traps Tray process, allows the user to click on the tray icon and run
agent the console. Runs constantly in the background.
Traps Tda.exe Traps dump analyzer, which analyzes the contents of memory
agent locations and other data when a prevention event occurs on the
endpoint.
Traps Tdawork.exe Traps dump analyzer worker processes, one per processor. These
agent processes run in the background and should run constantly.
STEP 2 | Select Generate to start the collection process. The ESM Console deactivates (grays out) the
Generate button during generation process.
STEP 3 | Refresh the page to view the status of the file. When the file is available, the ESM Console
displays the time the file was created and updates the file size in the download link. The ESM
Console reports a failure if it fails to generate the file within the preconfigured timeout period
(25 minutes).
You can also monitor logs related to ESM tech support file generation on the Monitor > ESM > Logs
page. From there, you can filter the Report Type by Tech Support File Status, or filter the Message by a
specific job ID.
STEP 4 | Click Download to save the file and then send it to Technical Support, as needed. To view the
history of all available ESM tech support file requests, select Monitor > Data Retrieval page.
From there, you can download previous files or delete them as needed. If the tech support file
failed to generate, the Download button is hidden and you can only Delete the request.
All commands run using the DB Configuration Tool are case sensitive.
To enforce role-based access control, use the ESM Console to make changes to
administrative access, when possible.
You can access the DB Configuration Tool using a Microsoft MS-DOS command prompt that you run as an
administrator. The DB Configuration Tool is located in the Server folder on the ESM Server.
All commands you run using the DB Configuration Tool are case sensitive.
Repeat this step to add additional administrative users. The DB Configuration Tool appends the
usernames to the existing list of administrative users.
All commands you run using the DB Configuration Tool are case sensitive.
STEP 4 | (Optional) Configure or change any of the ESM Server settings, as needed. For usage guidelines
and default values, see Customizable ESM Server Settings. For example, to specify the
allowable grace period, in seconds, for an endpoint that is not responding (range is 300 to
86,400; default is 4200):
For example, a value of 300 means that if the ESM Server does not receive any communication from the
endpoint within five minutes (300 seconds), the Endpoint Security Manager reports the endpoint status
as disconnected.
Access Cytool
To view syntax and usage examples for Cytool commands, use the /? option after any command.
STEP 1 | Open a command prompt (on Windows) or Terminal (on Mac) as an administrator:
Windows:
Select Start > All Programs > Accessories. Right-click Command prompt, and then select Run as
administrator.
Select Start. In the Start Search box, type cmd. Then, to open the command prompt as an
administrator, press CTRL+SHIFT+ENTER.
Mac:
From Finder, select Applications > Utilities. Double-click Terminal.
Mac:
On Mac endpoints, you must run the command as a superuser (sudo) and supply the
administrator password.
Options:
-h --help Display help
information.
enum List processes protected
by Traps.
rpc <enable | disable> <process_name | all> Enable/Disable RPC
services for daemon(s) and agent(s).
esm <connect | disconnect> [address=hostname:port] Connect/Disconnect Traps
to/from ESM.
startup query List startup status for
traps endpoint agent(s) and daemon(s).
startup <enable | disable> <process_name | all> Enable/Disable agent(s)
and daemon(s) after reboot.
runtime query List runtime status for
agent(s), daemon(s) and kernel extensions.
runtime <start | stop> <process_name | all> Start/Stop agent(s),
daemon(s) and kernel extensions immediately.
persist list Display list of
persistent databases.
persist export <db_name | all> Export database(s) to
the file(s) in JSON format.
persist import <db_name> <file_name> Import data into the
database from the given file.
persist print <db_name | all> [csv] Print database to the
command prompt.
log <log_level> <process_name | all> Set log level for the
desired process.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 3 | For more detailed information on the Traps version and status of the agent, use the cytool
info query command.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | View processes initiated by the current user by entering the cytool enum command. To view
processes for all users including those initiated by the operating system, specify the /a option,
and enter the supervisor password when prompted.
Mac:
You must enable remote process calls (RPCs) before you can run this command. See
Enable or Disable RPC Services.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
The following example displays output for enabling protection of core processes. The Mode column
displays the revised protection status, either Enabled or Disabled, or Policy when using the
settings in the local security policy to protect core processes.
To use the default policy rule settings to protect core processes on the endpoint, see Use the Security
Policy to Manage Service Protection.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | To manage the protection settings of registry keys on the endpoint, use the following
command:
The following example displays output for enabling protection of registry keys. The Mode column
displays the revised protection status, either Enabled or Disabled, or Policy when using the
settings in the local security policy to protect registry keys.
To use the settings in the local security policy to protect registry keys on the endpoint, see Use the
Security Policy to Manage Service Protection.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | To manage the protection settings of Traps files on the endpoint, use the following command:
The following example displays output for enabling protection of files. The Mode column displays the
revised protection status, either Enabled or Disabled, or Policy when using the settings in the local
security policy to protect Traps files.
To use the default policy rule settings to protect Traps files on the endpoint, see Use the Security Policy
to Manage Service Protection.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | To manage the protection settings of Traps services on the endpoint, use the following
command:
The following example displays output for enabling protection of services. The Mode column displays the
revised protection status, either Enabled or Disabled, or Policy when Traps uses the settings in the
local security policy to protect Traps services.
To use the default policy rule settings to protect Traps services on the endpoint, see Use the Security
Policy to Manage Service Protection.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | To use the rules in the security policy to manage service protection, use the following
command:
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | To view the current startup behavior of Traps drivers and services, use the following command:
Windows:
Mac:
Changes to Traps drivers and services do not take effect until the system restarts.
To make changes to Traps drivers and services that take effect immediately, see
StartorStopTrapsRuntime Components on the Endpoint.
STEP 1 | Open a command prompt or terminal as an administrator and navigate to the Traps folder (see
Access Cytool).
STEP 2 | To change the startup behavior for a specific driver or service, use the cytool startup
command:
Windows:
Mac:
Where <component> is a process on the Mac endpoint. Alternatively, you can specify all to change
the startup behavior for all startup processes.
The following example displays output for disabling the startup behavior of the trapsd process. The
Startup status column displays the revised behavior as Disabled.
STEP 1 | Open a command prompt (as an administrator) or terminal and navigate to the Traps folder (see
AccessCytool).
STEP 2 | To view the current runtime state of Traps drivers and services, run the cytool runtime
query command:
Windows:
Mac:
Changes to the runtime behavior of Traps drivers and services reset when the system
restarts. To make changes to the startup behavior of Traps drivers and services, see Enable
or Disable the Startup of Traps Components on the Endpoint.
Making changes to the runtime behavior requires you to enter the supervisor (uninstall) password when
prompted.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | To start or stop a driver or service, use the cytool runtime start <component> command:
Windows:
STEP 1 | Open a terminal as an administrator and navigate to the Traps folder (see Access Cytool).
STEP 2 | To enable RPC services for all daemons and the Traps agent, use the cytool rpc enable all
command:
STEP 3 | To enable RPC services for a specific service, use the cytool rpc enable <process_name>
command, for example:
STEP 4 | To disable RPC services for all daemons and the Traps agent, use the cytool rpc disable
all command:
STEP 5 | To disable RPC services for a specific service, use the cytool rpc disable <process_name>
command, for example:
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | To view the active policy for a process, use the following command:
where <process> is either the process name or PID. For example, to view details about a policy for
notepad, enter cytool policy query notepad. The following example displays policy details for a
process with PID 1234.
Compare Policies
At regular intervals, Traps requests an updated security policy from the ESM Server and stores it in the
system registry on Windows endpoints. When a user starts a process, Traps determines whether or not to
protect the process based on the settings in the security policy.
In troubleshooting scenarios where Traps does not behave as expected, use the cytool policy
compare command to view differences in policies that are applied to processes running on the endpoint.
Using the command, you can compare a policy for a process to the default security policy or compare a
policy for a process to a policy for another process. In both cases, you can specify either the name of the
process or the process ID (PID). Specifying the process name simulates the application of the policy to the
process. Specifying the PID queries the effective policy for the running process. Cytool displays the policy
settings side-by-side and indicates any differences between policies in red.
To compare policies, you must enter the supervisor password when prompted.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
where <process1> and <process2> are either the process name or process ID (PID). For example,
to compare the policy applied to iexplorer to the policy applied to chrome, enter cytool policy
compare iexplorer chrome. You can also compare the policies for two PIDs or compare the
policy of a process to a policy of a PID.
The following example displays output for comparing the policies applied to two PIDs, 1592 and
1000. Differences between the two policies are shown in red.
STEP 1 | Open a command prompt or terminal as an administrator and navigate to the Traps folder (see
Access Cytool).
STEP 2 | To start logging a Traps component, use the cytool log start command:
Windows:
where <components> is either an * to start logging on all Traps services, or one or more Traps services
encased in quotes and separated by spaces, for example "cyverak cyvrfsfd".
The following example displays output for using cytool to log Errors on the cyverak and cyvrmtgn files to
a log file with a maximum file size of 20 MB.
Mac:
Using Cytool, you can restore a file to any non-network writable file system including NTFS,
ExFAT, FAT32, FAT16, ReFS.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | To view all files that Traps has quarantined on the endpoint, use the following command:
The following example displays output for using cytool to query for all quarantined files.
where <guid> is the unique identifier of the file. If you want to restore the executable file to its original
location leave the <filepath> blank. Otherwise, enter the locationincluding the filenameto which
you want to restore the executable file
The following example displays output for using cytool to restore the malware1.exe file to an alternate
location.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | Identify the process identifier (PID) of the running process for which you want statistics. To
determine which processes are being actively protected, see the Protection tab on the Traps
console.
View Details About the Traps Local Analysis Module Using Cytool
Using Cytool, you can determine the current version of the Traps local analysis module.
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | To view the local analysis version and associated release date, use the following command:
STEP 1 | Open a command prompt as an administrator and navigate to the Traps folder (see Access
Cytool).
STEP 2 | To view hash details about a file, use the cytool image <filepath>\<filename>
command. For example, the following output displays information about iexplorer.exe.
Possible Causes
You do not have administrative privileges to start services on the endpoint.
Solution
After each step in the following procedure, verify if you can install Traps. If Traps still reports an error,
proceed to each subsequent step until the issue is resolved.
STEP 2 | The service log file contains information, warnings, and errors related to the Traps service. To
further troubleshoot an issue related to the Traps service, open the C:\ProgramData\Cyvera
\Logs\Service.log file in a text editor and review any errors in the log file that occurred at the
time of the event.
By default, the ProgramData folder may be hidden. To view the folder in Windows
Explorer, select Organize > Folder and Search Options > View > Show hidden files
and folders.
Possible Causes
In earlier versions of Traps, the service protection feature prevents you from modifying or tampering with
Traps system files.
Solution
STEP 1 | Create an action rule to disable service protection (see Manage Service Protection on page
209).
STEP 3 | Delete the action rule (see Save Rules on page 129).
STEP 4 | Try to upgrade Traps. To further troubleshoot an issue related to the Traps service, view the
logs to see if Traps reports a specific error:
From the Traps Console, select Open Log File.
From the Traps Console, select Send Support File to send the logs to the ESM Server.
Create an action rule to retrieve the logs from the endpoint (see Manage Data Collected by Traps on
page 198).
STEP 1 | Verify that the server and endpoint both meet the prerequisites.
STEP 3 | Verify that the Endpoint Security Manager core service is running on the ESM Server.
1. Open the Services Manager:
Windows Server 2008: From the Start Menu, select Control Panel > Administrative Tools >
Services.
Windows Server 2012: From the Start Menu, select Control Panel > System and Security >
Administrative Tools > Services.
2. Locate the Endpoint Security Manager core service (called CyveraServer in older versions of the
Endpoint Security Manager) and verify that the service status is Started (Windows Server 2008) or
Running (Windows Server 2012).
3. If the service status is Stopped or Paused, double-click the service, then select Start. Click Close.
STEP 4 | Verify that you can reach the ESM Server from the endpoint.
From the endpoint, open a command prompt and ping the IP address or hostname of the ESM Server. If
the ESM Server is unreachable, examine the network connectivity settings between the devices.
STEP 5 | Verify that you can reach the endpoint from the ESM Server.
From the ESM Server, open a command prompt and ping the IP address or hostname of the endpoint. If
the endpoint is unreachable, examine the network connectivity settings between the devices.
STEP 6 | Verify that the port for the ESM Server is open on the Windows Firewall (default is 2125).
1. To check port access from the endpoint:
1. Open a command prompt as an administrator.
2. Enter the following command to telnet to port 2125 on the ESM Server:
STEP 8 | Verify that connectivity is restored between Traps and the ESM Server.
From the Traps Console, click Check In Now. If the connectivity is established, the connection status
appears as Successful.
Possible Causes
The username or password was not entered correctly.
The user specified during the initial installation does not have DB Owner privileges.
The user was not added as an administrator.
The user who installed the server was not a local administrator on the server.
Solution
STEP 1 | Verify that you entered the correct username and password.
STEP 2 | Verify that the user has DB Owner privileges (see Configure the MS-SQL Server Database on
page 45).
STEP 3 | Log in as an administrator and verify that the authentication mode is correct and that the user
account appears on the User Management page. To add an administrative user, see Configure
the Authentication Mode on page 98. Alternatively, you can add the administrator using the
Database Configuration Tool (see Configure Administrative Access to the ESM Console Using
the DB Configuration Tool on page 324).
STEP 4 | If you cannot log in as an administrator, reinstall the Endpoint Security Manager as a local
administrator.
STEP 5 | Restart IIS: Click Start > Run, type IISReset, and then click OK.
Possible Causes
The server does not meet the prerequisite for .NET Framework 4.0 patched with the KB2468871 update.
Solution
Install .NET Framework 4.0 and the KB2468871 patch.
STEP 3 | Verify that the Endpoint Security Manager core service is running on the ESM Server.
1. Open the Services Manager:
Windows Server 2008: From the Start Menu, select Control Panel > Administrative Tools >
Services.
Windows Server 2012: From the Start Menu, select Control Panel > System and Security >
Administrative Tools > Services.
2. Locate the Endpoint Security Manager core service (called CyveraServer in older versions of the
Endpoint Security Manager) and verify that the service status is Started (Windows Server 2008) or
Running (Windows Server 2012).
3. If the service status is Stopped or Paused, double-click the service, then select Start. Click Close.
STEP 4 | Verify that the port for the ESM Server is open on the Windows Firewall (default is 2125).
1. To check port access from the endpoint:
1. Open a command prompt as an administrator.
2. Enter the following command to telnet to port 2125 on the ESM Server: