Configuring Advanced Threat Prevention Settings

In This Section: Threat Prevention Engine Settings SNORT Signature Support Optimizing IPS Using the Whitelist Threat Indicator Settings Using Anti-Bot and Anti-Virus with VSX Using Threat Extraction with VSX Threat Prevention CLI Commands

Threat Prevention Engine Settings

This section explains how to configure advanced Threat Prevention settings that are in the Engine Settings window, including: inspection engines, the Check Point Online Web Service (ThreatCloud repository), internal email whitelist, file type support for Threat Extraction and Threat Emulation and more.

To get to the Engine Settings window, go to Manage & Settings > Blades > Threat Prevention > Advanced Settings.

The Threat Prevention Engine Settings window opens.

Fail Mode

Select the behavior of the ThreatSpect engine if it is overloaded or fails during inspection. For example, if the Anti-Bot inspection is terminated in the middle because of an internal failure. By default, in such a situation all traffic is allowed.

• Allow all connections (Fail-open) - All connections are allowed in a situation of engine overload or failure (default).
• Block all connections (Fail-close) - All connections are blocked in a situation of engine overload or failure.

Check Point Online Web Service

The Check Point Online Web Service is used by the ThreatSpect engine for updated resource categorization. The responses the Security Gateway gets are cached locally to optimize performance.

• Block connections when the web service is unavailable
  • When selected, connections are blocked when there is no connectivity to the Check Point Online Web Service.
  • When cleared, connections are allowed when there is no connectivity (default).
• Resource categorization mode - You can select the mode that is used for resource categorization:
  • Background - connections are allowed until categorization is complete - When a connection cannot be categorized with a cached response, an uncategorized response is received. The connection is allowed. In the background, the Check Point Online Web Service continues the categorization procedure. The response is cached locally for future requests (default).
    This option reduces latency in the categorization process.
  • Hold - connections are blocked until categorization is complete - When a connection cannot be categorized with the cached responses, it remains blocked until the Check Point Online Web Service completes categorization.
  • Custom - configure different settings depending on the service - Lets you set different modes for Anti-Bot and Anti-Virus. For example, click Customize to set Anti-Bot to Hold mode and Anti-Virus to Background mode.

Connection Unification

Gateway traffic generates a large amount of activity. To make sure that the amount of logs is manageable, by default, logs are consolidated by session. A session is a period that starts when a user first accesses an application or a site. During a session, the gateway records one log for each application or site that a user accesses. All activity that the user does within the session is included in the log. For connections that are allowed or blocked in the Anti-Bot, Threat Emulation, and Anti-Virus Rule Base, the default session is 10 hours (600 minutes).

To adjust the length of a session:

1. Go to Manage & Settings > Blades > Threat Prevention > Advanced Settings > General > Connection Unification > Session unification timeout (minutes).
2. Enter the required value.
3. Click OK.

Configuring Anti-Bot Whitelist

The Suspicious Mail engine scans outgoing emails. You can create a list of email addresses or domains whose internal emails are not inspected by Anti-Bot.

To add an email address or domain whose internal emails are not scanned by Anti-Bot:

1. Go to the Manage & Settings > Blades > Threat Prevention > Advanced Settings > Anti-Bot.
2. Click the + sign.

In this window, you can also edit or remove the entries in the list.

Selecting Emulation File Types

You can select the file types that are sent for emulation for all the Threat Prevention profiles. Each profile defines an Inspect or Bypass action for the file types.

To select Threat Emulation file types that are supported in Threat Prevention profiles:

1. In SmartConsole, select Manage & Settings > Blades.
2. From the Threat Prevention section, click Advanced Settings.

   The Threat Prevention Engine Settings window opens.

3. From the Threat Emulation Settings section, click Configure file type support.

   The File Types Support window opens.

4. Select the file types that are sent for emulation. By default all file types are sent for emulation.

   The Emulation supported on column shows the emulation environments that support the file type.

5. Click OK and close the Threat Prevention Engine Settings window.
6. Install the Threat Prevention policy.

Configuring Advanced Engine Settings for Threat Extraction

Advanced Threat Extraction engine settings let you configure file type support and mail signatures for the Threat Extraction.

Configuring File Type Support

To configure file type support:

1. In the Threat Prevention Engine Settings window Threat Extraction, click Configure File Type Support.

   The Threat Extraction Supported File Types window opens.

2. From the list select the file types which the Threat Extraction blade supports.
3. Click OK.

Configuring Mail Signatures

To configure mail signatures:

1. In the Threat Prevention Engine Settings window > Threat Extraction, click Configure Mail Signatures.

   The Threat Extraction Mail Signatures window opens.

   Use this window to configure text for:

   • Mail signatures for attachments with potential threats extracted

     The first signature is always attached to an email that had threats extracted.

     The second signature is added to the first if the email recipient has access to the original file.

   • Mail signatures for unmodified attachments

     You can insert predefined field codes into the signature text, such as:

     • A link to the file before it was modified by the blade.

     The link opens the UserCheck Portal. The portal shows a list of attachments the recipient can download.

     • Reference ID.

     Use this ID to send the file to the recipient. You can also find the ID in the logs.

     On the gateway, run the command: scrub send_orig_email.

2. Click OK.

SNORT Signature Support

SNORT is a popular, open source, Network Intrusion Detection System (NIDS). For more information about SNORT see snort.org.

Check Point supports the use of SNORT rules as both the GUI and the SmartDomain Manager API’s options.

When you import a SNORT rule, it becomes a part of the IPS database.

You can perform these actions on a Check Point Management Server:

• Import existing SNORT rules from a file
• After import and conversion:

1. Snort Protection names are Snort imported: <value of the ‘msg’ field in the original SNORT rule>. See Creating SNORT Rule Files.
2. Snort Protections get these attributes automatically:
   • Performance Impact - High
   • Severity - High
   • Confidence Level - Low or Medium

• Delete the existing SNORT rules

Importing SNORT Protection Rules to the Security Management Server

Make sure you have the SNORT rule file. It holds SNORT rules and usually has the extension: .rules.

In a Multi-Domain Security Management environment, import SNORT rules to the Security Management Server. Then assign Global policy to the Domain Management Servers. This downloads the new SNORT protections to the Domain Management Servers.

To import SNORT Protection rules to the Security Management Server:

1. Connect with SmartConsole to the Security Management Server that manages the applicable Security Gateway or Security Cluster.
2. Open the applicable policy.
3. From the left navigation panel, click Security Policies.
4. In the top section of Threat Prevention, click Policy.
5. In the bottom section Threat Tools, click IPS Protections.
6. From the top toolbar, click Actions > Snort Protections > Import Snort rules.
7. Select the file with the SNORT rules and click Open.

   The tool converts the rules to Check Point syntax and updates the protections database.

   Important - SmartConsole shows the converted SNORT rules as IPS protections whose names start with Snort imported.

   

8. Publish the session.
9. Install the Threat Prevention Policy on the applicable Security Gateway or Security Cluster.

To override the profile settings for a specific SNORT protection, see Action on SNORT Protection Rules.

Deleting SNORT Protection Rules from the Security Management Server

To delete SNORT protection rules from the Security Management Server:

1. Connect with SmartConsole to the Security Management Server that manages the applicable Security Gateway or Security Cluster.
2. Open the applicable Policy.
3. From the left navigation panel, click Security Policies.
4. In the top section Threat Prevention, click Policy.
5. In the bottom section Threat Tools, click IPS Protections.
6. From the top toolbar, click Actions > Snort protections > Delete all snort protections.

   

7. Publish the session.
8. Install the Threat Prevention Policy on the applicable Security Gateway or Security Cluster.

Importing SNORT Protection Rules to the Multi-Domain Server

Make sure you have the SNORT rule file. It holds SNORT rules and usually has the extension: .rules.

In a Multi-Domain Security Management environment, import SNORT rules to the Multi-Domain Server. Then assign Global policy to the Domain Management Servers. This downloads the new SNORT protections to the Domain Management Servers.

To import SNORT rules to the Multi-Domain Server:

1. Connect with SmartConsole to the Multi-Domain Server to the MDS context.
2. From the left navigation panel, click Multi Domain > Domains.
3. Right-click on the Global Domainand select Collect to domain.
4. From the left navigation panel, click Security Policies.
5. Open the applicable global policy.
6. In the top section Threat Prevention, click Policy.
7. In the bottom section Threat Tools, click IPS Protections.

   

8. From the top toolbar, click Actions > Snort Protections > Import Snort rules.
9. Select the required file with the SNORT rules and click Open.

   The tool converts the rules to Check Point syntax and updates the protections database.

   Important - SmartConsole shows the converted SNORT rules as IPS protections whose names start with Snort imported.

10. Publish the session.
11. Close the SmartConsole connected to the Global Domain.
12. From the left navigation panel, click Multi Domain > Global Assignments.
13. Reassign the Global Policy to the Local Domains.
14. Connect with SmartConsole to the applicable Domain Management Server that manages the applicable Security Gateway or Security Cluster.
15. Install the Threat Prevention Policy on the applicable Security Gateway or Security Cluster.

To override the profile settings for a specific SNORT protection, see Action on SNORT Protection Rules.

Deleting SNORT Protection Rules from the Multi-Domain Server

To delete SNORT protection rules from the Multi-Domain Server:

1. Connect with SmartConsole to the Multi-Domain Server to the mds context.
2. From the left navigation panel, click Multi Domain > Domains.
3. Right-click on the Global Domain and select Collect to domain.
4. From the left navigation panel, click Security Policies.
5. Open the applicable global policy.
6. In the top section Threat Prevention, click Policy.
7. In the bottom section Threat Tools, click IPS Protections.
8. From the top toolbar, click Actions > Snort Protections > Delete all Snort protections.

   

9. Publish the session.
10. Close the SmartConsole connected to the Global Domain.
11. From the left navigation panel, click Multi Domain > Global Assignments.
12. Reassign the Global Policy to the Local Domains.
13. Connect with SmartConsole to the applicable Multi-Domain Server that manages the applicable Security Gateway or Security Cluster.
14. Install the Threat Prevention Policy on the applicable Security Gateway or Security Cluster.

Action on SNORT Protection Rules

The Security Gateway enforces SNORT protection rules based on the profile which is installed on the Security Gateway. For example, if the profile installed on the Security Gateway is Optimized, by default the Security Gateway does not enforce SNORT protection rules, because their performance impact is High and the allowed performance impact defined in the Optimized profile is Medium or lower.

To override the profile settings for a specific SNORT protection:

1. In IPS Protections, right-click a SNORT protection and select Edit.

   Note - The SNORT protection names start with Snort imported.

   

2. Right-click the profile and select Edit.

   

3. In the Main Action area, select Override with.

   

4. From the drop-down menu, select the required action.

   

5. Click OK.
6. Click Close.
7. Publish the session.
8. Install the Threat Prevention Policy.

Note - The images here follow the example described above. If you are on a different profile, or want a different action, change steps 2 or 4 accordingly.

Alternative Methods to add and delete SNORT Protection Rules

These alternative methods on the Management Server let you can add and delete SNORT protection rules:

• mgmt_cli tool
• SmartConsole CLI
• Gaia Clish
• POST Requests

Adding SNORT Rules

The applicable command accepts two arguments:

• package-format" which always takes the string value "snort"
• "package-path" which is the path to the protections' package

The command returns:

Upon success:	0
Upon failure:	1 along with several parameters describing the error upon failure

Examples:

• From the mgmt_cli tool, run this command:

  mgmt_cli add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json

• From the SmartConsole CLI, run this command:

  add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json

• From the Gaia Clish, run this command:

  mgmt add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json

  Note - The --format json part is optional. By default, the output is presented in plain text.

• POST Request Method

  A post request must:

  • Be sent to the following URL: https://<ip-address-of mgmt-server>:<port>/web_api/v1.2/add-threat-protections
  • Have the request headers Content-Type set to application/json and X-chkp-sid set to the unique session identifier returned by the login request.
  • Have the Content-Type arguments package-format and package-path in the request body.

The server returns:

Upon success:	Status code 200
Upon failure:	The appropriate status code

Example:

POST {{server}}/v1.2/add-threat-protections Content-Type: application/json X-chkp-sid: {{session}} { "package-path" : "/path/to/community.rules", "package-format" : "snort" }

Deleting SNORT Protections

The applicable command accepts one argument "package-format", which always takes the string value "snort".

The command returns:

Upon success:	0
Upon failure:	1 along with several parameters describing the error upon failure

Examples:

• From the mgmt_cli tool, run this command:

  mgmt_cli delete threat-protections package-format "snort" --version 1.2

• From the SmartConsole CLI, run this command:

  delete threat-protections package-format "snort" --version 1.2

• From the Gaia Clish, run this command:

  mgmt delete threat-protections package-format "snort" --version 1.2

• POST Request method

  A POST Request must be send to this URL:

  https://<IP-address-of-mgmt-server>:<port>/web_api/v1.2/delete-threat-protections

With the request headers Content-Type set to application/json and X-chkp-sid set to the unique session identifier returned by the login request. The argument package-format must be sent in the request body.

The server returns:

Upon success:	Status code 200
Upon failure:	The appropriate status code

Example:

POST {{server}}/v1.2/delete-threat-protections Content-Type: application/json X-chkp-sid: {{session}} { "package-format" : "snort" }

Creating SNORT Rule Files

You can write your own SNORT rules and then import them to a Check Point Management Server to become IPS protections . For more information about SNORT, see snort.org.

Check Point supports SNORT 2.9 version and lower.

SNORT rules use signatures to define attacks. A SNORT rule has a rule header and rule options.

The name of the imported SNORT protection is the value of the msg field in the original SNORT rule.

• If one SNORT rule has multiple msg strings with the same value, Management Server aggregates these values in one IPS SNORT protection.
• If you import a SNORT rule at different times, and it has the same msg string, the latest import overrides the existing IPS SNORT protection.

SNORT Rule Syntax:

<Action> <Protocol> <Source IP Address> <Source Port> <Direction> <Destination IP Address> <Destination Port> (msg:"<Text>"; <Keyword>:"<Option>";)

SNORT rules have two logical parts: Rule Header and Rule Options.

• SNORT Rule Header:

<Action> <Protocol> <Address> <Port> <Direction> <Address> <Port>

• SNORT Rule Options:

<keyword>:"<option>"

Example:

alert tcp any any -> any 1:65535 (msg:"Possible exploit"; content:"|90|";)

Where:

• Action = alert
• Protocol = TCP
• Source IP Address = any
• Source Port = any
• Direction = ->
• Destination IP Address = any
• Destination Port (Range) = 1:65535
• Name of protection rule in IPS = Possible exploit
• Keyword = content
• Option = |90|

Supported Snort syntax:

These are the generally supported syntax components. There are some limitations.

Keyword	Description
length	Specifies the original length of the content that is specified in a protected_content rule digest
pcre	Lets you write rules with Perl-compatible regular expressions. Example: alert tcp any any -> any 80 (content:"/foo.php?id="; pcre:"/\/foo.php?id=[0-9]{1,10}/iU";)
flowbits	Lets rules track states during a transport protocol session. Used in conjunction with conversation tracking from the Session preprocessor. Example: alert tcp $HTTP_SERVERS any -> $EXTERNAL_NET 21 (msg: "Does not match state in FTP path"; flow: established, to_server; content: "targetfile"; nocase; fast_pattern; flow bits: isset,INFTPPATH;no_match;)
byte_test	Tests a byte field for a specific value (with operator). Example: alert udp $EXTERNAL_NET any -> $HOME_NET 123 (msg: "Header length longer than maximum"; content: "length|3d|"; byte_test: 4, >, 1024, 1, relative;)
byte_jump	Lets you write rules that skip over specific portions of the length-encoded protocols and perform detection in very specific locations. Example: alert udp any any -> any 123 (msg: "Check for 0001 after 0123"; content: "|30 31 32 33|"; byte_jump: 4,4, relative; content: "|30 30 30 31|"; distance: 1; relative;)
isdataat	Verifies that the payload has data at a specified location. Example: alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg: "\r\n\r\nHas 300 byte after"; flow: established, to_server; content: "|0a 0d 0a 0d|"; isdataat: 300,relative; sid:11111111;)
no_match	Does not block traffic even if the rule matches. Used with the “flow bits” key word to set a flag without performing a block. Example: alert tcp $HTTP_SERVERS any -> $EXTERNAL_NET 21 (msg: "Does not match state in FTP path"; flow: established, to_server; content: "targetfile"; nocase; fast_pattern; flow bits: isset,INFTPPATH;no_match; sid: 55555555;)

• Supported Content Keyword Modifiers: "nocase", "rawbytes", "depth", "offset:", "distance:", "within", "urilen"
• Supported Threshold Rule Types - Threshold, Both (Limit is not supported.)
• Supported Macros - HTTP_PORTS (Interpreted as 80 and 8080 ports.)

  Note - Make sure that SNORT Rules with the same flowbits flag have the same content in the msg field. Otherwise, they will not be under the same protection.

Debugging:

The $FWDIR/log/SnortConvertor.elg file on the Management Server contains is updated with the debug messages from the last SnortConvertor run import of SNORT rules.

To find failed rule debugs in this file, search for: Failed to convert rule

Unsupported SNORT Syntax

This syntax is not supported and will not convert:

• pcre modifiers: ‘G’, ‘O’, ‘A’
• pcre regular expression with lookahead assertion: ?!
• Using byte_test keyword with operator not in: <,>,=,&,^
• http_method is not supported if it is the only http modifier type in the Snort Rule
• Protocols: icmp, ip. (all is interpreted as UDP and TCP protocols)
• Snort Rule without content keyword
• All PORT macros, except HTTP_PORTS
• Specification of source port (only any is supported)
• Specification of destination port "any" (you must specify an exact destination port number, or range of destination port numbers).

The conversion will change the behavior of these macros and syntax.

• Specification of IP Addresses – Enforced on all IP Addresses.
• HOME_NET macro - Interpreted as any IP Addresses.
• EXTERNAL_NET macro - Interpreted as any IP Addresses.
• HTTP_SERVERS macro - Interpreted as any IP Addresses.

These combinations of keywords and modifiers are implemented differently in the IPS blade as Snort protection rules than in SNORT Rules. Best Practice - Test them before activating them in a production environment.

• rawbytes content, or B pcre modifiers with http_uri content or U pcre modifiers
• With http content or pcre modifiers:
  • http_raw_uri content or I pcre modifiers
  • http_stat_msg content or Y pcre modifiers
  • http_stat_code content or S pcre modifiers
• Without http content or pcre modifiers:
  • Two or more uses of http_header content or H pcre modifiers
  • Two or more uses of http_raw_header content or D pcre modifiers
• With depth or offset content and http content that is one of these on the same content keyword, or ^ (carrot) in pcre with one of these http pcre modifiers on the same pcre keyword:
  • http_header content or H pcre modifiers
  • http_raw_header content or D pcre modifiers
  • http_stat_msg content or Y pcre modifiers
  • http_stat_code content or S pcre modifiers
  • http_uri content or U pcre modifiers
• Use of depth or offset content, or ^ (carrot) in pcre, without any http content, and with destination ports that are not HTTP_PORTS macro
• http_client_body content or P pcre modifier
• A pcre keyword with {} (curly braces) quantifier
• Use of both content and byte_test keywords
• http_header content modifiers or H pcre modifiers enforced only on raw http data (not decoded and normalized header data)
• Use of the urilen keyword, except in a SNORT Rule that has only http_uri and U pcre modifiers, or http_raw_uri content modifier and I pcre modifiers.
  • If the SNORT Rule has only http_uri content or U pcre modifiers, the size will be of the decoded and normalized buffer.
  • If the SNORT Rule has only http_raw_uri content or I pcre modifiers, the size will be of the raw uri buffer.

Optimizing IPS

IPS is a robust solution which protects your network from threats. Implementation of the recommendations in this chapter will help maintain optimal security and performance.

During the tuning process, keep in mind that Check Point bases its assessment of performance impact and severity on an industry standard blend of traffic, which places greater weight on protocols such as HTTP, DNS, and SMTP. If your network traffic has high levels of other network protocols, you need to take that into consideration when you assess the inspection impact on the gateway or severity of risk to an attack.

Managing Performance Impact

A Check Point Security Gateway performs many functions in order to secure your network. At times of high network traffic load, these security functions may weigh on the gateway's ability to quickly pass traffic. IPS includes features which balance security needs with the need to maintain high network performance.

Bypass Under Load

To help you integrate IPS into your environment, enable Bypass Under Load on the Gateway to disengage IPS activities during times of heavy network usage. IPS inspection can make a difference in connectivity and performance. Usually, the time it takes to inspect packets is not noticeable, but under heavy loads it may be a critical issue. IPS allows traffic to pass through the gateway without inspection, and IPS then resumes inspection after gateway's resources return to acceptable levels.

Best Practice - Because IPS protections are temporarily disabled, apply Bypass Under Load only during the initial deployment of Threat Prevention. After you optimize the protections and performance of your Gateway, disable this feature to make sure that your network is protected against attacks.

To bypass IPS inspection under heavy load:

1. In SmartConsole, click Gateways & Servers and double-click the Security Gateway.

   The gateway window opens and shows the General Properties page.

2. From the navigation tree, click IPS.
3. Select Bypass IPS inspection when gateway is under heavy load.
4. To set logs for activity while IPS is off, in the Track drop-down list, select a tracking method.
5. To configure the definition of heavy load, click Advanced.
6. In the High fields, provide the percentage of CPU Usage and Memory Usage that defines Heavy Load, at which point IPS inspection will be bypassed.
7. In the Low fields, provide the percentage of CPU Usage and Memory Usage that defines a return from Heavy Load to normal load.
8. Click OK to close the Gateway Load Thresholds window.
9. Click OK.
10. Install Policy.

Tuning Protections

This section shows you how to tune protections to suit your needs.

IPS Policy Settings

The IPS Policy settings allow you to control the entire body of protections by making a few basic decisions. Activating a large number of protections, including those with low severity or a low confidence level, protects against a wide range of attacks, but it can also create a volume of logs and alerts that is difficult to manage. That level of security may be necessary for highly sensitive data and resources; however it may create unintended system resource and log management challenges when applied to data and resources that do not require high security.

Best Practice - adjust the IPS Policy settings to focus the inspection effort in the most efficient manner. Once system performance and log generation reaches a comfortable level, the IPS Policy settings can be changed to include more protections and increase the level of security. Individual protections can be set to override the IPS Policy settings.

For more information on IPS Policy, see Automatically Activating Protections.

Note - A careful risk assessment should be performed before disabling any IPS protections.

Focus on High Severity Protections

IPS protections are categorized according to severity. An administrator may decide that certain attacks present minimal risk to a network environment, also known as low severity attacks. Consider turning on only protections with a higher severity to focus the system resources and logging on defending against attacks that pose greater risk.

Focus on High Confidence Level Protections

Although the IPS protections are designed with advanced methods of detecting attacks, broad protection definitions are required to detect certain attacks that are more elusive. These low confidence protections may inspect and generate logs in response to traffic that are system anomalies or homegrown applications, but not an actual attack. Consider turning on only protections with higher confidence levels to focus on protections that detect attacks with certainty.

IPS Network Exceptions can also be helpful to avoid logging non-threatening traffic.

Focus on Low Performance Impact Protections

IPS is designed to provide analysis of traffic while maintaining multi-gigabit throughput. Some protections may require more system resources to inspect traffic for attacks. Consider turning on only protections with lower impact to reduce the amount system resources used by the gateway.

Enhancing System Performance

SecureXL

Check Point SecureXL improves gateway performance. For more information on how to optimize network performance, see the R80.20 Performance Tuning Administration Guide.

CoreXL

For Security Gateways running on multi-core hardware, CoreXL lets the gateway to leverage the multiple cores to more efficiently handle network traffic. For more information on CoreXL and optimizing the CoreXL configuration, see the R80.20 Performance Tuning Administration Guide.

Using the Whitelist

Whitelist is a list of files that are trusted. Check Point Threat Prevention engine does not inspect trusted files for malware, viruses, and bots, which helps decrease resource utilization on the gateway.

Adding a File to the Whitelist

To configure files on the Threat Prevention Whitelist:

1. In SmartConsole, click Security Policies > Threat Prevention > Policy > Threat Tools > Whitelist Files.
2. Click New.

   The Whitelist File window opens.

3. Enter the Object Name and MD5 signature for the new file exception.

   Note - To edit or remove Whitelist files, right-click the file and select the applicable option.

4. Click OK.
5. Install the Threat Prevention policy.

Threat Indicator Settings

Threat Indicators lets you upload Indicator files that contain sets of observables. These observables are added to the Threat Prevention policy.

Indicator – Set of observables which represent a malicious activity in an operational cyber domain, with relevant information on how to interpret it and how to handle it.

Observable – An event or a stateful property that can be observed in an operational cyber domain. For example: IP address, MD5 file signature, URL, Mail sender address.

Indicators of Compromise convey an attack campaign by:

• Specific observable patterns
• Additional information intended to represent artifacts & behaviors of interest within a cyber-security context

Indicators are derived from intelligence, self-analysis and/or governments, partners etc.

To use Threat Indicators:

Indicator files must be in CSV or STIX XML format, and contain records of equal size. If an Indicator file has records which do not have the same number of fields, it will not load.

Each record in the Indicator file has these fields:

Field		Description	Valid Values	Value Criteria	Optional
UNIQ-NAME		Name of the observable	Free text	Must be unique	No
VALUE		A value that is valid for the type of the observable	See the table below	See the table below	No
TYPE		Type of the observable	URL Domain IP IP Range MD5 Mail-subject Mail-from Mail-to Mail-cc Mail-reply-to	Not case sensitive	No
CONFIDENCE		Degree of confidence the observable presents	low medium high critical	Default - high	Yes
SEVERITY		Degree of threat the observable presents	low medium high critical	Default - high	Yes
PRODUCT		Check Point Software Blade that processes the observable	AV AB	AV - Check Point Anti-Virus Software Blade (default) AB - Check Point Anti-Bot Software Blade Note - only the Anti-Virus Software Blade can process MD5 observables.	Yes
COMMENT			Free text		Yes
	Notes - If an optional field is empty, the default value is used. If a mandatory field is empty, the Indicator file will not load.

These are the values that are valid for each observable type:

Observable Type	Validation Criteria
URL	Any valid URL
Domain	Any URL domain
IP	Standard IPv4 address
IP Range	A range of valid IPv4 addresses, separated by a hyphen: <IP>-<IP>
MD5	Any valid MD5
Mail-subject	Any non-empty text string
Mail-to Mail-from Mail-cc Mail-reply-to	Can be one of these: A single email address (Example: abc@domain.com) An email domain (Examples: @domain.com or domain.com)

Requirements for validation of CSV Indicator files:

• Use commas to separate the fields in a record
• Enter one record per line, or use '\n' to separate the records
• If free text contains quotation marks, commas, or line breaks, it must be enclosed in quotation marks
• To enclose part of free text in quotations, use double quotation marks: ""<text>""

Notes -

• As of this release, STIX 2.0 (JSON file) is not supported.
• Custom Indicators CLI (load_indicators) are not supported.
• SHA1/SHA256 is not supported as a valid MD5 value.
• The supported STIX elements are: stix:STIX_Package, stix:STIX_Header, stix:Title, stix:Description, stix:Indicators, stix:Indicator, indicator:Title, indicator:Type, indicator:Description, indicator:Observable. cybox:Object, cybox:Properties, FileObj:Hashes, cyboxCommon:Hash, cyboxCommon:Type, cyboxCommon:Simple_Hash_Value, stix:Observables, cybox:Observable, URIObj:Value, URIObject:Value, AddressObject:Address_Value, AddressObj:Address_Value, AddressObj:AddressObjectType, AddressObjet:AddressObjectType, cybox:Title
• Condition Type Enum and Condition Application Enum support Equals and Any.

  <cyboxCommon:Simple_Hash_Value condition="Equals" apply_condition="ANY">

Example of a CSV Indicator File

#! DESCRIPTION = indi file,,,,,,

"#! REFERENCE = Indicator Bulletin; Feb 20, 2014",,,,,,

# FILE FORMAT:,,,,,,

"# All lines beginning ""#"" are comments",,,,,,

"# All lines beginning ""#!"" are metadata read by the SW",,,,,,

"# UNIQ-NAME,VALUE,TYPE,CONFIDENCE,SEVERITY,PRODUCT,COMMENT",,,,,,

observ1,8d9b6b8912a2ed175b77acd40cbe9a73,MD5,medium,medium,AV,FILENAME:WUC
Invitation Letter Guests.doc

observ2,76700f862a0c241b8f4b754f76957bda,MD5,high,high,AV,FILENAME:essais~.swf|
NOTE:FWS type Flash file

observ7,http://somemaliciousdomain.com/uploadfiles/upload/exp.swf?info=
789c333432d333b4d4b330d133b7b230b03000001b39033b&infosize=00840000
,URL,high,high,AV,IPV4ADDR:196.168.25.25

observ8,svr01.passport.ServeUser.com,Domain,low,high,AB,TCP:80|
IPV4ADDR:172.18.18.25|NOTE:Embedded EXE Remote C&C and Encoded Data

observ9,somemaliciousdomain2.com,Domain,,low,AV,TCP:8080|IPV4ADDR:172.22.14.10

observ10,http://www.bogusdomain.com/search?q=%24%2B%25&form=MOZSBR&pc=
MOZI,URL,low,low,AB,IPV4ADDR:172.25.1.5

observ11,http://somebogussolution.com/register/card/log.asp?isnew=-1&LocalInfo=
Microsoft%20Windows%20XP%20Service%20Pack%202&szHostName=
ADAM-E512679EFD&tmp3=tmp3,URL,medium,,AB,

observ14,172.16.47.44,IP,high,medium,AB,TCP:8080

observ15,172.16.73.69,IP,medium,medium,AV,TCP:443|NOTE:Related to Flash
exploitation

observ16,abc@def.com,mail-to,,high,AV,"NOTE:truncated; samples have appended to
the subject the string ""PH000000NNNNNNN"" where NNNNNNN is a varying number"

observ34,stamdomain.com,domain,,,AB,

observ35,stamdomain.com,mail-from,high,medium,AV,

observ37,xyz.com,mail-from,medium,medium,AB,

observ38,@xyz.com,mail-from,medium,medium,AB,

observ39,a@xyz.com,mail-from,medium,medium,AB,

Example of a STIX 1.0 XML Indicator File

<stix:STIX_Package

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:stix="http://stix.mitre.org/stix-1"

xmlns:indicator="http://stix.mitre.org/Indicator-2"

xmlns:stixVocabs="http://stix.mitre.org/default_vocabularies-1"

xmlns:FileObj="http://cybox.mitre.org/objects#FileObject-2"

xmlns:cybox="http://cybox.mitre.org/cybox-2"

xmlns:cyboxCommon="http://cybox.mitre.org/common-2"

xmlns:cyboxVocabs="http://cybox.mitre.org/default_vocabularies-2"

xmlns:example="http://example.com/"

xsi:schemaLocation="

http://stix.mitre.org/stix-1 ../stix_core.xsd

http://stix.mitre.org/Indicator-2 ../indicator.xsd

http://stix.mitre.org/default_vocabularies-1 ../stix_default_vocabularies.xsd

http://cybox.mitre.org/objects#FileObject-2 ../cybox/objects/File_Object.xsd

http://cybox.mitre.org/default_vocabularies-2 ../cybox/cybox_default_vocabularies.xsd"

id="example:STIXPackage-ac823873-4c51-4dd1-936e-a39d40151cc3"

version="1.0.1">

<stix:STIX_Header>

<stix:Title>Example file watchlist</stix:Title>

<stix:Package_Intent xsi:type="stixVocabs:PackageIntentVocab-1.0">Indicators - Watchlist</stix:Package_Intent>

</stix:STIX_Header>

<stix:Indicators>

<stix:Indicator xsi:type="indicator:IndicatorType" id="example:Indicator-611935aa-4db5-4b63-88ac-ac651634f09b">

<indicator:Type xsi:type="stixVocabs:IndicatorTypeVocab-1.0">File Hash Watchlist</indicator:Type>

<indicator:Description>Indicator that contains malicious file hashes.</indicator:Description>

<indicator:Observable id="example:Observable-c9ca84dc-4542-4292-af54-3c5c914ccbbc">

<cybox:Object id="example:Object-c670b175-bfa3-48e9-a218-aa7c55f1f884">

<cybox:Properties xsi:type="FileObj:FileObjectType">

<FileObj:Hashes>

<cyboxCommon:Hash>

<cyboxCommon:Type xsi:type="cyboxVocabs:HashNameVocab-1.0" condition="Equals">MD5</cyboxCommon:Type>

<cyboxCommon:Simple_Hash_Value condition="Equals" apply_condition="ANY">0522e955aaee70b102e843f14c13a92c##comma##0522e955aaee70b102e843f14c13a92d##comma##0522e955aaee70b102e843f14c13a92e</cyboxCommon:Simple_Hash_Value>

</cyboxCommon:Hash>

</FileObj:Hashes>

</cybox:Properties>

</cybox:Object>

</indicator:Observable>

</stix:Indicator>

</stix:Indicators>

</stix:STIX_Package>

Configuring Indicators in SmartConsole

Define network objects to hold the Indicator files.

To load Indicators:

1. Go to Security Policies > Threat Prevention > Policy >Threat Tools > Indicators.

   The Indicators page opens.

2. Click New.

   The Indicators configuration window opens.

3. Enter a Name.

   Each Indicator must have a unique name.

4. Enter Object Comment (optional).
5. Click Import to browse to the Indicator file.

   The content of each file must be unique. You cannot load duplicate files.

6. Select an action for this Indicator:
   • Ask - Threat Prevention Software Blade asks what to do with the detected observable
   • Prevent - Threat Prevention Software Blade blocks the detected observable
   • Detect - Threat Prevention Software Blade creates a log entry, and lets the detected observable go through
   • Inactive - Threat Prevention Software Blade does nothing
7. Add Tag.
8. Click OK.

   If you leave an optional field empty, a warning notifies you that the default values will be used in the empty fields. Click OK. The Indicator file will load.

To delete Indicators:

1. Select an Indicator.
2. Click Delete.
3. In the window that opens, click Yes to confirm.

You can edit properties of an Indicator object, except for the file it uses. If you want an Indicator to use a different file, you must delete it and create a new one.

Using Anti-Bot and Anti-Virus with VSX

When you configure Virtual Systems to use the Anti-Bot and Anti-Virus Software Blades, make sure the Software Blade:

• Is enabled and configured on the relevant Virtual Systems and enabled and configured on the VSX Gateway (VS0)

  VSO handles contract validation for all Virtual Systems.

• Can connect to the internet

  A Virtual System gets updates through the VSX Gateway (VS0). If the VSX Gateway fails, each Virtual System uses its proxy settings to get the update from the internet.

Note - Where applicable, make sure the routing, DNS, and proxy settings for the VSX Gateway (VSO) are configured correctly.

To enable Anti-Bot and Anti-Virus on Virtual Systems:

1. If applicable, configure proxy settings for the VSX Gateway (VSO) or the Virtual Systems or both:
   1. From the Network Object tree, double-click the VSX Gateway (VSO).
   2. From the navigation tree, select Topology > Proxy.
   3. Configure the proxy settings, and click OK.
2. Enable Anti-Bot and Anti-Virus on the VSX Gateway (VSO) for all Virtual Systems that use Anti-Bot and Anti-Virus:
   1. From the Network Object tree, double-click the Virtual System.
   2. In the Network Security section, select Anti-Bot and Anti-Virus.
   3. Click OK.
3. Select the Threat Prevention and configure the policies.
4. Install the Threat Prevention policy (and access policy if needed) on the VSX Gateway (VSO) and the relevant Virtual Systems.

Using Threat Extraction with VSX

When you configure Virtual Systems to use the Threat Extraction Software Blade, make sure that the Software Blade:

• Is enabled and configured on the relevant Virtual Systems and enabled and configured on the VSX Gateway (VS0).
• The Virtual Systems are configured with a Mail Transfer Agent (MTA).

Note - Where applicable, make sure that the routing, DNS, and proxy settings for the VSX Gateway (VS0) are configured correctly.

To enable Threat Extraction on Virtual Systems:

1. In the Gateways & Servers view, right-click the Virtual System object and select Edit.

   The Virtual System Properties window opens.

2. On the General Properties > Network Security tab, select Threat Extraction.

   The Threat Extraction First Time Activation Wizard opens.

3. In the Next Hop Configuration window, select Skip this configuration now, and click Next.
4. In the Summary window, click Finish.
5. In the VS Properties window, go to Mail Transfer Agent in the navigation tree, and select Enable as Mail Transfer Agent (MTA).
6. Add the MTA definitions to Mail Forwarding.
7. Click OK.
8. Install the Standard policy on the Virtual Systems (including VS0).

Threat Prevention CLI Commands

You can run commands from the CLI (Command Line Interface) to install Threat Prevention policy and for IPS and advanced Threat Emulation management.

In any case of conflict between the CLI commands and the SmartConsole configuration, the CLI commands will be enforced.

mgmt_cli install-policy

Description: Run this command on the Security Management Server to install the Threat Prevention policy on the specified Security Gateways.

Syntax: mgmt_cli install-policy <options>

Note: For more information, see Management API Reference.

te_add_file

Description: Use this command to manually send files for threat emulation. The command has to be run from expert mode. For a complete explanation of all the available parameters, run te_add_file.

Syntax: te_add_file -f=<file path> -d=<directory path>

Parameter	Description
-f=	Specifies the path to the file. You must include the file name at the end of the path.
-d=	Specifies the path to a directory. The command takes all the files in the directory and sends them for emulation.

Example: te_add_file -f=/home/admin/test.pdf

[Expert@gaia]# te_add_file -f=/home/admin/test.pdf

# Sending files... Wait for response: True

# Trying to connect to ted...

# Connected to ted...Ready to send...

# File path: /home/admin/test.pdf

# File type: pdf

# Got response from ted...

(

:event_id ("{000000A5-006D-0045-9D15-D6896862D148}")

:action (drop)

:confidence (high)

:done (0)

:file_path ("/home/admin/test.pdf")

:md5_string (61baabd6fc12e01ff73ceacc07c84f9a)

)

# Got response from ted...

(

:event_id ("{000000A5-006D-0045-9D15-D6896862D148}")

:action (drop)

:confidence (high)

:done (1)

:file_path ("/home/admin/test.pdf")

:md5_string (61baabd6fc12e01ff73ceacc07c84f9a)

)

/home/admin/test.pdf

Verdict: drop Time: 1 *

Total Files: 1

Verdicts distribution:

drop: 1

# Done 1 files in 1 seconds...Bye Bye...

Comments: ted is the Threat Emulation daemon.

tecli

Use the tecli commands to:

• Control local cache
• Show information about the Threat Emulation system
• Run advanced options
• Show status of emulation downloads, statistics and processes
• Configure affinity for TED (Threat Emulation Daemon)

tecli advanced clear

Description: Resets the emulation statistics for the Security Gateway or appliance.

Syntax: tecli advanced clear

tecli cache clean

Description: Deletes all the records in the local cache.

Syntax: tecli cache clean

tecli control sizing

Description: Controls the sizing mode tool that lets you estimate the resources that Threat Emulation will use in your network.

Syntax: tecli control sizing {enable|disable|status}

Note: For more about using sizing mode, go to sk93598.

tecli debug

Description: Enable and disable debug mode for Threat Emulation.

Syntax: tecli debug {on|off|scan local {enable|disable}}

Parameter	Description
on	Enables debug mode
off	Disables debug mode
scan local enable	Enables the appliance or Security Gateway to scan local connection
scan local disable	Disables the appliance or Security Gateway to scan local connection

Example:

tecli d o or tecli debug on

tecli d s l e or tecli debug scan local enable

tecli show

tecli show commands show data and statistics about the Threat Emulation Software Blade. You can also use abbreviated parameters to run tecli show commands. These are some useful command combinations:

Command	Description
tecli s s	Shows emulation statistics
tecli s c i	Shows information about ThreatCloud emulation
tecli s c q	Shows the quota for ThreatCloud emulation
tecli s e e	Shows the current status of the emulation queue
tecli s u a	Shows all the parts of file emulation

tecli show cloud

Description: Shows data and statistics about your ThreatCloud account.

Syntax: tecli show cloud {identity|info|quota}

Parameter	Description
identity	Shows data about how the Security Gateway or Emulation appliance connects to the ThreatCloud
info	Shows data about your file emulation in the ThreatCloud
quota	Shows data about your ThreatCloud monthly emulation quota

Example:

tecli s c id or tecli show cloud identity

tecli s c in or tecli show cloud info

tecli show emulator

Description: Shows data about Threat Emulation queue and VMs (Virtual Machines).

Syntax: tecli show emulator {emulations|vm {synopsis|detailed|id <ID>}}

Parameter	Description
emulations	Shows the current status of the emulation queue
synopsis	Shows a summary of the VMs
detailed	Shows data and details of the VMs
id <ID>	Shows data for the VM with this ID

Example:

tecli s e e or tecli show emulator emulations

tecli s e v s or tecli show emulator vm synopsis

tecli show downloads

Description: Shows data and statistics about files and rules that Threat Emulation is downloading.

Syntax: tecli show downloads {all|images|dr|sa|raw|types}

Parameter	Description
all	Shows the status of all downloads
images	Shows download status of operating system images
dr	Shows download status of malware detection rules
sa	Shows download status of static analysis rules
raw	Shows download status of general Threat Emulation files
types	Shows the file extensions that are being sent for emulation

Example:

tecli s d a or tecli show downloads all

tecli s d i or tecli show downloads images

tecli show remote

Description Shows data and statistics about the Emulation appliance

Syntax tecli s r i or tecli show remote information

tecli show statistics

Description: Shows statistics to the Emulation appliance or Security Gateway.

Syntax: tecli s s or tecli show statistics

Results:

tecli show throughput

Description: Shows data about file emulation for each time interval.

Syntax: tecli show throughput {minute|hour|day|month}

Parameter	Description
minute	Shows how many files completed emulation for each minute
hour	Shows how many files completed emulation for each hour
day	Shows how many files completed emulation for each day
month	Shows how many files completed emulation for each month

Example:

tecli s t mi or tecli show throughput minute

tecli s t mo or tecli show throughput month

tecli show unit

Description: Shows all the parts of file emulation:

• Prepare
• Processing
• Finalizing

The output shows the number of files for each task in the emulation part.

Syntax: tecli u a or tecli show unit all

Results:

# tecli s u a [prepare] - system state (15) - policy (15) - file (1) - contract (1) - cache inquirer (1) [processing] - duplicate (1) - static analysis (1) - emulator (1) - cloud emulation (1) - remote emulation (1) [finalizing] - forensics (15) - cache updater (15) - threat cloud sharing (15) - threat cloud statistics (15) - file saver (15) - logger (15) - local filter counter (15)

Managing IPS gateways - CLI

You can use these CLI commands to manage IPS on your Security Gateways. You must be in expert mode to use the commands.

To see all available commands:

1. On the gateway, go to the expert mode.
2. Type ips and press Enter.

   Command	Description
   ips on|off [-n]	Enable or disable IPS on the Security Gateway.
   	-n	Empty templates table (applies fwaccel off; fwaccel on immediately). Otherwise, this command takes effect in a few minutes.
   ips stat	Show the IPS status of the Security Gateway.
   ips bypass stat	Show the Bypass Under Load status.
   ips bypass on|off	Enable or disable Bypass Under Load.
   ips bypass set cpu|mem low|high <threshold>	Set the Bypass Under Load threshold.
   	threshold	Valid range is 1 to 99. Unit is percent.
   ips debug [-e filter] -o <output_file>	Create an IPS debug file. Filter valid values are the same as for fw ctl debug. Consult with Check Point Technical Support.
   ips refreshcap	Refresh the sample capture repository.
   ips stats [<ip_address> -m] [-g <seconds>] [<ip_address> <seconds>]	Print IPS and Pattern Matcher performance statistics. Without arguments, runs on current Security Gateway for 20 seconds. This is a resource intensive command. Do not run it on a system with a high load.
   	-m	Analyzes input statistics file from Security Gateway. Give IP address of the Security Gateway. Run from the management server.
   	-g	Collect statistics for current Security Gateway.
   	seconds	period in which statistics are gathered
   ips pmstats reset	Reset pattern matcher statistics.
   ips pmstats -o <output_file>	Print pattern matcher statistics.