McAfee Threat Intelligence Exchange Server
This runs a PostgreSQL database that stores information about file and certificate reputations that it receives from the available reputation providers within the environment and cloud-based sources such as McAfee Global Threat Intelligence. Multiple server appliances can be deployed in different operation modes to offer scale and fail-over capabilities.
McAfee Threat Intelligence Exchange Client
The client allows you to determine what happens when a file with a malicious or unknown reputation is detected in your environment. You can also view threat history information and the actions taken. The client uses rules for determining actions based on multiple data points such as reputations, local intelligence, and contextual information. The clients are available as add-on modules for either McAfee VirusScan Enterprise or McAfee Endpoint Security (Adaptive Threat Prevention). The client module allows you to configure client policies that determine what actions are taken once a final reputation has been determined. For example, the Adaptive Threat Protection client can be configured to take one of the following actions:
- Allow the file to be opened
- Allow the file to run within a container
- Block the file
- Prompt the user to choose an action
Data Exchange Layer (DXL) Fabric
DXL includes clients and servers, referred to as DXL brokers. The DXL layer allows for bidirectional communication between endpoints on a network. DXL works in the background, communicating with services, databases, endpoints, and applications. Each McAfee Threat Intelligence Exchange server contains an embedded DXL client to connect to the DXL layer to be a reputation service for any clients that request reputation information.
The DXL client should be installed on each managed endpoint so threat information from security products that use DXL can be shared immediately with all other services and devices. DXL clients maintain a persistent connection to their brokers regardless of their location. Even if a managed endpoint running the client is behind a NAT (network address translation) boundary, it can receive updated threat information from its broker located outside the NAT.
Multiple McAfee Threat Intelligence Exchange server appliances can be deployed into different operation modes to offer scaling and fail-over capabilities. The first two servers installed will automatically have an operation mode assigned, namely, primary and secondary instances. For each additional server instance, you will need to manually configure the operation mode after completing the installation.
- Primary: Holds and writes the McAfee Threat Intelligence Exchange server database and replicates the updates to all the secondary instances. There can be only one primary server at a time. A primary server provides queries at the same time it aggregates updates from replicas and pushes out database changes.
- Write-Only Primary: Only serves to aggregate changes and push out updates. It includes file metadata and reputation update requests. This mode does not process endpoint requests, therefore if primary write-only servers are present, there must be at least one secondary instance. In a large network, it is recommended to have a McAfee Threat Intelligence Exchange write-only primary server dedicated to processing updates and settings.
- Secondary: Processes DXL requests exactly like a primary instance using a database that is replicated from the primary server.
- Reporting Secondary: Improves the McAfee ePO reporting services. It does not process reputation requests. If a reporting secondary is deployed, this system should be defined as the Registered McAfee Threat Intelligence Exchange database server within the McAfee ePO Registered Server section.
- Reputation Cache: In-memory cache synchronized through DXL minimizes network requirements and provides endpoint operational reputation services. The reputation cache rebuilds after rebooting because it resides in memory. The reputation cache mode server role requires a specific DXL topology configuration. Review KB 89775 for steps on how to properly deploy a reputation cache server.
In a multi-McAfee ePO environment with a DXL bridge, only McAfee Threat Intelligence Exchange servers managed by a local McAfee ePO server are editable. For an environment with a single McAfee ePO server, managed McAfee Threat Intelligence Exchange servers are displayed in a tree structure, where the root is the instance operating in primary mode.
Brokers can be arranged into a hierarchy to provide failover protection. This is configured within McAfee ePO server settings DXL Topology. When supporting multiple regions or data centers, additional brokers can be added to service those areas. The goal is to minimize WAN communication and network latency. When multiple brokers are present within the DXL topology, all brokers must be defined in a Parent-Child relationship.
Any two DXL brokers can be combined to create what is known as a DXL hub. Hubs supply load balancing and high availability in an Active-Active configuration. When clients connect to a hub, the client will randomly choose a specific DXL broker and switch-on failure. The general rule is that any broker that has children should be configured as a hub to prevent a single point of failure.
DXL clients maintain a persistent connection to their brokers. When a client receives the DXL client policy from McAfee ePO, it includes a certificate and key for authentication to the DXL fabric along with a list of brokers. The closest broker is then determined via ICMP hop counts.
If ICMP is disabled in the environment, the client will simply round-robin the brokers. The settings with the DXL client policy can be modified to restrict clients to connect only to a specific broker, hub, or branch of the fabric.
Service zones are groups of brokers that allow you to control how requests are routed on the fabric. For example, if you have multiple McAfee Threat Intelligence Exchange servers and brokers across geographical locations, you can create service zones that contain brokers and services.
McAfee Threat Intelligence Exchange is one of the services that uses the DXL fabric. Clients connected to a broker in a service zone access services in that zone first. If those services are not available, the broker routes the request to services in other zones. Services like McAfee Threat Intelligence Exchange must have a policy that restricts them to one specific hub to enforce the distribution of services across the fabric.
Bridging DXL fabrics allows DXL brokers that are managed by different McAfee ePO servers to communicate with each other to share clients and services. McAfee Threat Intelligence Exchange file and certificate reputation data will be shared across the DXL bridge. For more information, refer to the DXL Product Guide.
Installation & Upgrade
First-Time Installation Planning
- Sizing and Performance Guide
- DXL Architecture Guide
- Default ports required for each component (KB 66797)
Server Deployment Recommendations
- Plan to deploy at least two McAfee Threat Intelligence Exchange server instances, one primary and one secondary, for fault tolerance.
- Place additional collocated secondary servers to increase capacity as required, ensuring multiplied replication bandwidth requirements are met by the network infrastructure. Consider latency impact on throughput when adding remote secondary servers.
- As the environment expands, switch the original primary to a write-only primary server to maximize replication potential for deploying multiple secondary servers.
- Add a report-only secondary server to concentrate load from McAfee ePO reporting.
- Rely on reputation cache servers when remote bandwidth is not enough to replicate the full reputations database or to increase reputation throughput of reused files and certificates.
DXL Broker Deployment Recommendations
The number of brokers needed is determined by the geographic and network configuration of the customer.
- Establish a total node count and validate that you have enough brokers for performance. The guideline is a maximum of 50,000 clients per broker. Consider broker loss. Will you still have enough brokers if one goes down? Often, regional failover is acceptable.
- Add at least one or more brokers for each McAfee ePO server in your enterprise.
- Implement a pair of brokers in a hub to create a Root Hub. The Root Hub should typically not have services directly connected. It should provide connectivity services across the fabric.
- Add additional brokers to span across network security zones. For example, place one or more brokers in the DMZ.
- Consider adding one or more brokers for each major site, such as a major data center.
- Install the McAfee ePO management extensions for McAfee Threat Intelligence Exchange server and DXL.
- Install a DXL Broker and McAfee Threat Intelligence Exchange server using the OVA (or ISO) file.
- Configure the McAfee Threat Intelligence Exchange server extension, topology, and policies.
- Deploy the McAfee Threat Intelligence Exchange client and DXL client to managed endpoints (DXL Client 5.0 is now included with McAfee Agent 5.6).
- Verify the installation.
The McAfee Threat Intelligence Exchange server is distributed as an OVA appliance optimized for VMware or as an ISO image used with compatible hardware or other virtualization technologies. For details on the supported virtualization methods for the server, refer to KB 83368.
The first two McAfee Threat Intelligence Exchange servers installed will automatically have an operation mode assigned, namely, primary and secondary instances. For each additional server instance, you need to manually configure the operation mode after completing the installation. All server appliances can also be configured to include the DXL broker. This is done during the initial configuration wizard.
For the new deployment, it is advisable to configure the McAfee Threat Intelligence Exchange server to also include a DXL broker, unless there are firewalls or other limitations. Having a DXL broker on the same machine as the McAfee Threat Intelligence Exchange server should not affect performance for either service up to the McAfee Threat Intelligence Exchange maximums.
The currently available OVA and ISO also include the option to enable the Active Response Server service. This setting is optional.
File and certificate reputations are determined at the time a file is executed on a managed system. The reputation and file metadata are provided to the McAfee Threat Intelligence Exchange server via one of the available reputation provider sources. These sources can be any of the currently available DXL-enabled products including:
- McAfee Threat Intelligence Exchange Module for McAfee VirusScan Enterprise
- McAfee Endpoint Security Adaptive Threat Protection
- McAfee Advanced Threat Defense
- McAfee Web Gateway
- McAfee Application Control
- McAfee GTI and Cloud Threat Detection
The McAfee Threat Intelligence Exchange database can store reputation data for any file type, however the file types analyzed and submitted depend on the file types supported by the installed point products. The specific workflow used to determine a file or certificate reputation also depends on the available reputation providers within the environment.
McAfee Threat Intelligence Exchange stores reputation results as a value between 0 and 99. Each numerical score maps to a reputation result as follows:
|85||Most Likely Trusted|
|70||Might Be Trusted|
|30||Might Be Malicious|
|15||Most Likely Malicious|
Reputation Workflow Examples
McAfee Endpoint Security Adaptive Threat Protection (ATP)
- A user or system tries to run a file.
- McAfee Endpoint Security inspects the file and is unable to determine its validity and reputation.
- The ATP client inspects the file and gathers file and local system properties of interest.
- The module checks the local reputation cache for the file hash.
- If the file hash is found, the module uses the reputation data from the local cache. This ends the workflow.
- If the file hash is not found, the module queries the McAfee Threat Intelligence Exchange server via the DXL layer. If the hash is found on the database, the McAfee Threat Intelligence Exchange server returns the file hash's reputations, enterprise age, prevalence data, and other data points to the client. The server could set a flag so that the ATP client will submit metadata about the file back to the McAfee Threat Intelligence Exchange server.
- If the file hash is not found in the McAfee Threat Intelligence Exchange server database, the server creates an entry in the database and queries McAfee GTI for the file hash reputation. McAfee GTI replies with the available information, for example "unknown" or "malicious," and the server stores that information. The server sends the GTI reputation back to the McAfee Threat Intelligence Exchange client along with a flag so that the ATP client will submit metadata about the file back to the server.
McAfee Endpoint Security Adaptive Threat Protection (ATP) with McAfee Advanced Threat Defense (Sandboxing)
When McAfee Advanced Threat Defense or McAfee Cloud Threat Detection are enabled within the McAfee Threat Intelligence Exchange server policy, the response to a reputation request includes a flag requesting the ATP client to upload the binary.
- If server reputation response includes a flag with a sandboxing candidate tag, the endpoint uploads the file to be analyzed by McAfee Advanced Threat Defense to the McAfee Threat Intelligence Exchange server.
- The server sends the file over HTTPS (not DXL) to McAfee Advanced Threat Defense or McAfee Cloud Threat Detection for scanning.
- The server polls the McAfee Advanced Threat Defense server for the final analysis report until they are available.
- McAfee Advanced Threat Defense scans the file and sends the file reputation results to the McAfee Threat Intelligence Exchange server through the DXL fabric.
- The McAfee Threat Intelligence Exchange server updates the McAfee Threat Intelligence Exchange database with the McAfee Advanced Threat Defense results and sends the updated reputation information to all McAfee Threat Intelligence Exchange server-enabled systems.
How ATP determines reputation:
- A portable executable (PE) file is loaded for execution in a process.
- McAfee Endpoint Security checks the exclusions to determine whether to inspect the file.
- ATP inspects the file and gathers file and local system properties.
- ATP checks the local reputation cache for the file hash.
- If the file hash is in the local reputation cache, ATP gets the reputation data from the cache and takes the associated action.
- If the file hash isn't in the cache, ATP gets the reputation data from the McAfee Threat Intelligence Exchange server.
- When the ATP rules determine the final reputation, ATP updates the McAfee Threat Intelligence Exchange server with the latest local reputation information and ATP takes the associated action.
- If ATP does not have the final reputation, the Real Protect client-based scanner scans the file.
- If Real Protect determines the final reputation, ATP updates the server with the latest reputation and takes the associated action.
- If Real Protect does not determine the final reputation, the file reputation is set as “Unknown.”
- The ATP client responds according to the ATP policy enforced on the system that is running the file and blocks or allows executing the file.
Enterprise, Composite, and Unknown Reputations
This is the reputation that can be manually set within McAfee ePO and is used to mark files or certificates with a specific user-defined reputation. It can be used to override an existing local or GTI-based reputation. For example, a known safe, custom in-house developed application that has an “Unknown” reputation in GTI can be marked with an enterprise reputation of “Known Trusted.” Marking the application with a “Known Trusted” enterprise reputation will prevent ATP from blocking execution of the file.
The composite reputation is the potential effective reputation score based on all available definitive reputations.
- If the file has an enterprise reputation, the composite reputation is the enterprise score.
- If the file does not have an enterprise reputation, but has an associated certificate enterprise reputation, the composite has the same value.
- If the file does not have either of the previous reputations, but its latest local reputation is the most recent reputation the file has had, the composite reputation is the latest local reputation.
If none of the above apply, the composite reputation reflects the associated GTI certificate reputation. In the event there is not an associated GTI certificate reputation available, the composite reputation reflects the definitive reputation using the following order:
- Definitive GTI
- Definitive McAfee Advanced Threat Defense
- Definitive McAfee Cloud Threat Detection
- Definitive McAfee Web Gateway
See KB 90345 for additional details and examples.
An unknown reputation is displayed when the reputation score is determined to be 50, falling into the middle of the scale. These are files where there is not enough data to set a confirmed trusted or confirmed malicious reputation. It is expected that all McAfee Threat Intelligence Exchange environments mark some files with the unknown reputation score.
Follow KB 90344 for guidance on managing unknown reputations.
The McAfee Threat Intelligence Exchange Server Topology Management page shows an overview of your McAfee Threat Intelligence Exchange health status. If there is an error on a specific primary or secondary server instance, it is highlighted in red.
This check tests the connection between the McAfee Threat Intelligence Exchange server instance that you selected and the McAfee ePO server through DXL. This check is valid for all operation modes of the McAfee Threat Intelligence Exchange servers.
- The tieserver service on the server must be running for McAfee Threat Intelligence Exchange to have an active DXL connection. To start the service, run the following terminal command: bash# service tieserver start.
- The replication on any secondary or reporting secondary servers must be in sync.
- From the terminal session, use the curl command to ensure that the server can reach one or more of the available DXL brokers. Example: bash# curl -kv
Database and Storage
Verifies database size, local connections, and maintenance executions. Errors will be displayed if:
- The available space in the data directory or root directory is reaching a critical level and could cause operations to fail.
- The latest execution of vacuum full is older than the defined threshold. Check the McAfee Threat Intelligence Exchange server database maintenance scheduling from the McAfee ePO Server Tasks and Server Task Log. The Server Task is called McAfee Threat Intelligence Exchange Server Database Maintenance, is enabled by default, and runs every Sunday at 2 a.m. Information about vacuum execution is stored in /var/log/tieserver-vacuumdb.log.
- Run the tie-info.sh command to show general information about the server, including the dates of the latest vacuum and vacuum full completions.
- The number of opened database connections exceeds the maximum configured. PostgreSQL database is limited to 1,024 concurrent connections for writing. It is expected that the primary server will consume 160 connections and each secondary server will use about 100 connections. To avoid exhausting the connection pool, consider changing some secondary servers to reputation cache mode.
This verifies if the replication of the database is running. This is applicable only to secondary and secondary-reporting server instances. The replication of the database between the primary and each secondary can fall out of sync under conditions where there is high network latency between the primary and the secondary. In these scenarios, the replication can be reset by running the following command on each secondary: bash# replication-monitoring –c reset.
This verifies if the connection to McAfee GTI is enabled and properly configured. This check is applicable to all server instances, except secondary-reporting server instances. If the server requires using a proxy for the internet connection, check that it is properly configured through the assigned McAfee Threat Intelligence Exchange server policy.
See KB 84157 for troubleshooting GTI connections.
- The stored certificate is valid for the current IP address.
- The certificate is valid against the CA.
- The keystore used for sample submission from the endpoints can be opened using the stored password.
- The McAfee Advanced Threat Defense keystore can be opened if the Advanced Threat Defense certificate validation is enforced.
This check verifies that the version of the McAfee Threat Intelligence Exchange Server management extension matches the version of each McAfee Threat Intelligence Exchange server.
Click [+] to see details about CPU Usage, Throughput, and General Write Buffer Usage.
Cache Topology Configuration
This verifies that the topology configuration of the cache mode is correct.
Internal Cache Status
This returns the status of the cache mode regarding initialization, the percentage of usage, and the number of objects saved.
McAfee Advanced Threat Defense Connection
This verifies if the connection to McAfee Advanced Threat Defense is enabled and properly configured.
McAfee Cloud Threat Detection Connection
This verifies if the connection to McAfee Cloud Threat Detection is enabled and properly configured.
Database and Storage
This verifies database size, local connections, and maintenance executions.
Reputation Search Service
This verifies that the search service works correctly.
FAQ & Documentation
I have installed McAfee Threat Intelligence Exchange for the first time. How do I manage the information it is collecting?
See the recommended workflow in KB 86307.
Do I need to upgrade the DXL Client version on the on McAfee Threat Intelligence Exchange servers?
No. The DXL client upgrades are managed by the platform package installed as part of upgrading the server version. Before upgrading servers or DXL broker appliances, validate the embedded DXL client version being installed and confirm that the DXL extensions are the same versions or newer.
Should I upgrade the McAfee Agent on McAfee Threat Intelligence Exchange servers?
No. The McAfee Agent upgrades are managed by the platform package installed as part of upgrading the McAfee Threat Intelligence Exchange server version.
What McAfee Threat Intelligence Exchange server should I upgrade first?
The primary server should be upgraded first, followed by secondary server roles.
Root Certificate Expiration
The McAfee product line uses TLS for secure communication. Two certificates validate McAfee TLS chains, including a primary expiring in 2038 and a secondary expiring on May 30, 2020. If either certificate, or both, are present in your environment, TLS will function correctly prior to May 30, 2020. After May 30, 2020, only the primary certificate will be valid. Out of an abundance of caution McAfee is informing customers of this impending event.
Generally, certificates are auto-updated through operation systems and customers will not be impacted. However, in environments where automatic management of root certificates is disabled and the primary certificate has not been manually deployed, customers will potentially be impacted. KB92937 provides information on how to verify and install the primary certificate.
Failure to have a valid certificate will cause product issues including reduced detection efficacy.
The primary certificate that needs to be validated is in a customer's environment as below:
Subject : CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, S=New Jersey, C=US
Thumbprint : 2B8F1B57330DBBA2D07A6C51F70EE90DDAB9AD8E
Expiration : 2038-01-18
Subscribe to KB92937 to receive updates.