The Threat Emulation Solution

In This Section: ThreatCloud Emulation Selecting the Threat Emulation Deployment

ThreatCloud Emulation

You can securely send files to the Check Point ThreatCloud for emulation. The ThreatCloud is always up-to-date with the latest Threat Emulation releases.

Sample ThreatCloud Emulation Workflow

1. The Security Gateway gets a file from the Internet or an external network.
2. The Security Gateway compares the cryptographic hash of the file with the database.
   • If the file is already in the database, no additional emulation is necessary
   • If the file is not in the database, it is necessary to run full emulation on the file
3. The file is sent over an SSL connection to the ThreatCloud.
4. The virtual computers in the ThreatCloud run emulation on the file.
5. The emulation results are sent securely to the Security Gateway for the applicable action.

Sample ThreatCloud Deployment

Item	Description
1	Internet and external networks
2	Perimeter Security Gateway
3	Check Point ThreatCloud servers
4	Computers and servers in the internal network

Threat Emulation Analysis Locations

You can choose a location for the emulation analysis that best meets the requirements of your company.

• ThreatCloud - You can send all files to the Check Point ThreatCloud for emulation. Network bandwidth is used to send the files and there is a minimal performance impact on the Security Gateway.
• Threat Emulation Private Cloud Appliance (Emulation appliance) in the Internal network - You can use an Emulation appliance to run emulation on the files.

Local or Remote Emulation

You can install an Emulation appliance in the internal network.

Sample Workflow for Emulation Appliance in a Local Deployment

1. The Emulation appliance receives the traffic, and aggregates the files.
2. The Emulation appliance compares the cryptographic hash of the file with the database.
   • The file is already in the database, no more emulation is necessary.
   • If the file is not in the database, the virtual computers in the Emulation appliance run full emulation on the file.

Item	Description
1	Internet and external networks
2	Perimeter Security Gateway
3	Threat Emulation Private Cloud Appliance
4	Computers and servers in the internal network

Sample Workflow for Emulation Appliance in a Remote Deployment

1. The Security Gateway aggregates the files, and the files are sent to the Emulation appliance.
2. The Emulation appliance compares the cryptographic hash of the file with the database.
   • The file is already in the database, no more emulation is necessary.
   • If the file is not in the database, the virtual computers in the Emulation appliance run full emulation on the file.

Item	Description
1	Internet and external networks
2	Perimeter Security Gateway
3	Threat Emulation Private Cloud Appliance
4	Computers and servers in the internal network

Optimizing File Emulation

Files have unique cryptographic hashes, these file hashes are stored in a database after emulation is complete. Before emulation is run on a file, the appliance compares the file hash to the database:

• If the hash is not in the database, the file is sent for full emulation
• If the hash is in the database, then it is not necessary to run additional emulation on the file

This database helps to optimize emulation and give better network performance.

Selecting the Threat Emulation Deployment

What are my options to send traffic for emulation?

• Inline - Traffic is sent for emulation before it is allowed to enter the internal network. You can use the Threat Prevention policy to block malware.
• SPAN/TAP - You can use a mirror or TAP port to duplicate network traffic. Files are sent to the computer in the internal network. If Threat Emulation discovers that a file contains malware, the appropriate log action is done.
• MTA (Mail Transfer Agent) - SMTP traffic goes to the Security Gateway, and is sent for emulation. The MTA acts as a mail proxy, and manages the SMTP connection with the source. The MTA sends email files to emulation after it closes the SMTP connection. When the file emulation is completed, the emails are sent to the mail server in the internal network. Best Practice - enable the MTA on the Security Gateway for Threat Emulation profiles that use the Prevent action for SMTP traffic.
• A Threat Emulation deployment that uses an MTA optimizes emulation for profiles that use the Prevent action.

I want to use the Prevent action and be able to block malicious files, what are my deployment options?

• ThreatCloud - Files are sent to the ThreatCloud for emulation. When the emulation is complete, ThreatCloud sends a notification to the Security Gateway that the files are safe. Then they go to computers in the internal network.
• Threat Emulation Private Cloud Appliance with inline deployment - The files are kept in the Emulation appliance and after emulation, safe files go to the computer in the internal network.

This table summarizes how Threat Emulation sends traffic for emulation:

	Block Malware
Inline	Yes
SPAN/TAP	No
MTA	Recommended with Prevent action for emails

Inline Deployments (Prevent and Ask)

Use the Prevent or Ask UserCheck action to quarantine a malicious file.

Sample Inline Emulation Workflow (Prevent Action)

1. The ThreatCloud or Emulation appliance gets a file from the Security Gateway.
2. Emulation is run on the file.
   • The file is safe, and it is sent to the computer in the internal network.
   • If the file contains malware, it is quarantined and logged.

Monitor Deployments

Sample Monitor Emulation Workflow

1. The ThreatCloud or Emulation appliance gets a copy of a file from the Security Gateway. The original file goes to the computer in the internal network.
2. Emulation is run on the file.
   • The file is safe, no other action is done
   • If the file is identified as malware, it is logged according to the Track action of the Threat Prevention rule

Threat Emulation Deployments with a Mail Transfer Agent

Best Practice - If you use the Prevent action to block SMTP traffic, we recommend that you enable the Security Gateway as an MTA (Mail Transfer Agent). You can use the MTA to help manage the emulation of emails and attachments.

SMTP traffic goes to the Security Gateway, and is sent for emulation. The MTA acts as a mail proxy, and manages the SMTP connection with the source. The MTA sends email files to emulation after it closes the SMTP connection. When the file emulation is completed, the emails are sent to the mail server in the internal network.