Push to SIEM

Check Point Portal can forward logs to SIEM destinations. Supported destinations include traditional Syslog-based SIEM integrations and Microsoft Sentinel.

Supported Check Point Portal Services

Event Forwarding can send data from these Check Point Portal services:

• Check Point Portal Audit logs

• Browse Security

• Connect

• Email Security

• Endpoint Security

• Mobile Security

• Management & Smart-1 Cloud

• Check Point SASE

• Spark Management

• WAF Application Security - Application Security

• Workforce AI Security

Destination Types

You can select these destinations:

• Syslog-based SIEM

• Microsoft Sentinel (Azure Monitor Logs Ingestion API)

Syslog-based SIEM

Prerequisites

• The SIEM server must support TLS 1.2.

• The OpenSSL CLI must be installed on your computer.

Network Access Requirements

To receive events from Check Point Portal, the SIEM must accept inbound connections on a dedicated listener port.

Configure your network and firewall policy to allow inbound traffic from Check Point Portal regional endpoints, using FQDN-based filtering.

Use the regional Fully Qualified Domain Name (FQDN) that corresponds to your Check Point Portal location:

Region	FQDN	Ports
Europe (EU)	whitelist-cidr.eu.datatube.checkpoint.com/	514, 6514
United States (US)	whitelist-cidr.us.datatube.checkpoint.com/	514, 6514
Asia-Pacific (AP, Australia)	whitelist-cidr.ap.datatube.checkpoint.com/	514, 6514
India (IN)	whitelist-cidr.in.datatube.checkpoint.com/	514, 6514
United Arab Emirates (AE)	whitelist-cidr.ae.datatube.checkpoint.com/	514, 6514

Important - Customers must configure the FQDN. New customers must use the FQDN, and existing customers must replace any static IP addresses with the FQDN listed above.

Note - During onboarding, new customers can use all ports between 5514-5517 and 7514-7517.

If FQDN-based filtering is not supported

Use IP-based filtering only if your firewall platform does not support FQDN-based rules.

If FQDN-based rules are not supported, configure your firewall to allow inbound traffic from the IP address returned by a DNS lookup of the required regional domain.

Important - The resolved IP address is not static and may change over time. When using IP-based rules, review and update the configured IP address periodically to maintain connectivity.

Reference IP addresses (IP-based filtering only)

Data Region	Example IP Address	Source Ports
Australia	20.53.179.128/29	514, 6514
Canada	20.116.186.248/29	514, 6514
India	20.207.91.248/29	514, 6514
UAE	20.233.160.96/29	514, 6514
US	20.22.10.32/29	514, 6514
Europe	20.23.152.176/29	514, 6514

Note - These IP addresses are provided for convenience, but they are not guaranteed to remain static. Always prefer FQDN-based rules when possible.

Prepare your organization's domain certificate

If you already have a <CA>.key file and a <CA>.pem file, then skip this step.

Skip this step if any of these is correct:

• You use TLS, not mutual TLS encryption.

• You already have a <CA>.key file and a <CA>.pem file.

If you do not have a <CA>.key file and a <CA>.pem file, follow one of these procedures to prepare your organization's domain certificate:

Open a port on the SIEM server

On your SIEM server, open a dedicated port to receive logs from Check Point Portal.

Configure regional network access

Configure the SIEM server to listen to a specific FQDN address for its region.

Region	FQDN	Ports
Europe (EU)	whitelist-cidr.eu.datatube.checkpoint.com/	514, 6514
United States (US)	whitelist-cidr.us.datatube.checkpoint.com/	514, 6514
Asia-Pacific (AP, Australia)	whitelist-cidr.ap.datatube.checkpoint.com/	514, 6514
India (IN)	whitelist-cidr.in.datatube.checkpoint.com/	514, 6514
United Arab Emirates (AE)	whitelist-cidr.ae.datatube.checkpoint.com/	514, 6514

Create a SIEM destination

A destination in the Check Point Portal defines a connection between the Check Point Portal and a SIEM server.

After you configure a destination for your SIEM server, you can review, edit, search, and delete the destination(s) in the Manage Destinations window. For more information, see Managing Destinations.

1. In the Check Point Portal, click > Event Forwarding.

2. Click Create Destination or Manage Destinations.

3. From the Forwarding method list, select Push to SIEM.

4. Click Next.

5. Enter a destination name.

6. From the SIEM server list, select the SIEM server type.

7. In the Host field, enter the SIEM server FQDN.

8. In the Port field, enter the SIEM server port.

   Note - Below the Port field, default configurations appear. You cannot change these configurations: Protocol - The communication protocol. Currently, only TCP is supported. Encryption - The encryption protocol. You can select TLS or mutual TLS.

9. Click Next.

   The Certificates tab opens.

Establish secure communication

For this step, keep the Certificates tab of the Check Point Portal open and the SIEM server active. Then, follow the workflow:

• For mutual TLS encryption, follow the numbered workflow in the Certificates tab.

• For TLS encryption, skip to Step 3 to upload your CA certificate.

1. Client Certification Sign Request (.csr file)

   1. In the Check Point Portal, click Certificate sign request.

      Your web browser downloads the Check Point Portal's .csr file to your computer.

   2. On your computer, use the OpenSSL command line to open the .csr file.

   3. On your computer, use the openssl x509 command to sign the downloaded Client Certificate. To do this, it is necessary to enter your private and public keys.

      Note - Make sure you are in the same working folder as the <CA>.key and <CA>.pem files.

      openssl x509 -req -in <CERTIFICATE>.csr -CA <CA>.pem -CAkey <CA>.key -CAcreateserial -out <YOUR-CERTIFICATE>.crt -days 825 -sha256

2. Client Certificate (.crt file) - In the Check Point Portal, click Browse and upload the signed Client Certificate (.crt file).

   Best Practice - For a more secure connection, also upload the signed client certificate (.crt file) to your SIEM server.

3. Certificate Authority (CA) certificate (.pem file) - Click Browse and upload the CA certificate (<CA>.pem).

4. Click Test Connectivity. The connectivity test verifies that Check Point Portal can reach the destination and establish the configured secure connection.

   Important - In a first-time configuration, you must do a successful test before you can continue configuring Event Forwarding.

If the connection is successful, the status changes to Connected successfully.

If the connection is not successful, refer to sk182879 - Check Point Portal Event Forwarding - Troubleshooting.

5. Click Finish.

Microsoft Sentinel

Use these steps to forward Check Point Portal events to Microsoft Sentinel through the Azure Monitor Logs Ingestion API.

Prerequisites

Before you start, make sure that:

• You have a Check Point Export to SIEM contract.

• The relevant Check Point Portal services support Event Forwarding.

• You have permission to create or edit Event Forwarding destinations.

• You have permission in Microsoft Azure Collection of integrated cloud services that developers and IT professionals use to build, deploy, and manage applications through a global network of data centers managed by Microsoft. to create or configure the required Microsoft Sentinel resources.

  Important: Allow up to 30 minutes for the Azure role assignment to propagate. Copy the client secret Value when you create it. Microsoft Azure displays the secret value only once. Never share client secrets, private keys, or other sensitive credentials.

Prepare Microsoft Sentinel resources

Before you configure the destination in Check Point Portal, set up the required Azure Monitor Logs Ingestion API resources in Microsoft Sentinel and Log Analytics. For instructions, see:

• Microsoft Learn: Logs Ingestion API in Azure Monitor

• Microsoft Learn: Set up resources required to send data to Azure Monitor Logs using the Logs Ingestion API

To prepare these resources:

1. In Microsoft Azure, create a Log Analytics workspace.

2. Create a Microsoft Sentinel instance and attach the Log Analytics workspace to it.

3. Create a custom Log Analytics table for Check Point events. For more details, see Log Analytics table schema.

4. During table creation, create a Data Collection Rule (DCR) that is configured for the Azure Monitor Logs Ingestion API and the target Log Analytics table.

5. In the DCR JSON view, copy the DCR immutable ID.

6. Copy the Logs Ingestion endpoint used by the DCR.

7. Copy the stream name defined in the DCR.

8. Create a Microsoft Entra ID app registration.

9. Copy these values:

   • Directory (tenant) ID

   • Application (client) ID

   • Client secret value

   • Client secret expiration date

10. Assign the Monitoring Metrics Publisher role to the app registration on the DCR:

    1. In Microsoft Azure, go to Monitor > Data Collection Rules.

    2. Select the DCR used for Check Point Event Forwarding.

    3. Select Access control (IAM).

    4. Select Add role assignment.

    5. Select Monitoring Metrics Publisher.

    6. Select the app registration.

    7. Select Review + assign.

    Wait about 30 minutes for the role assignment to propagate.

Create a Check Point Portal Destination

1. In the Check Point Portal, click > Event Forwarding.

2. Click Create Destination or Manage Destinations.

3. From the Forwarding method list, select Push to SIEM.

4. Click Next.

5. Enter a destination name.

6. From the SIEM server list, select Microsoft Sentinel.

7. Enter the Microsoft Azure values in the corresponding Check Point Portal fields:

   • Azure Tenant ID - Enter the Microsoft Entra Directory (tenant) ID that you copied when you created the app registration.

   • Application (Client) ID - Enter the Microsoft Entra Application (client) ID that you copied when you created the app registration.

   • Client Secret - Enter the Client secret value from the app registration.

   • Client Secret Expiration Date - Enter the client secret expiration date.

   • Data Collection Endpoint - Enter the DCR Logs Ingestion endpoint or the DCE Logs Ingestion URI.

   • DCR Immutable ID - Enter the DCR immutable ID from the DCR JSON view.

   • Stream Name - Enter the DCR stream name for incoming Check Point event data.

8. Click Next.

9. Click Test Connectivity. The connectivity test verifies that Check Point Portal can reach the destination and establish the configured secure connection.

   Important - In a first-time configuration, you must do a successful test before you can continue configuring Event Forwarding.

   If the connection is successful, the status changes to Connected successfully.

   If the connection is not successful, see Troubleshooting Microsoft Sentinel Event Forwarding.

Verify events in Microsoft Sentinel

After the connection test succeeds, verify that the test event arrived in the Log Analytics table.

1. In Microsoft Sentinel or Log Analytics, run this query:

   CheckPointEventForwarding_CL | where TimeGenerated > ago(5m) | take 10

2. Replace CheckPointEventForwarding_CL with the table name configured for the destination.

If the target table uses a different schema, update the query to use the columns in your target table.

Configure Network Access

The Azure Monitor Logs Ingestion endpoint must be reachable from Check Point Portal over HTTPS.

Public Access

Use a publicly reachable DCR logs ingestion endpoint or use a DCE with public network access enabled.

Note - Public network access does not allow anonymous ingestion. Azure Monitor Logs Ingestion API still requires Microsoft Entra authentication, and the app registration must have the required role on the DCR.

Restricted Access with Azure Network Security Perimeter

If your organization does not want to allow general public network access to the ingestion endpoint, use Azure Network Security Perimeter (NSP) with a DCE and allow the Check Point Portal source ranges for your tenant region.

Note - If you want to use Azure Network Security Perimeter (NSP), use a Data Collection Endpoint (DCE) for Logs Ingestion API traffic. Do not use a DCR endpoint for this option. Microsoft lists DCE as a supported Azure Monitor resource for NSP. For more information, see Microsoft Learn: Configure Azure Monitor with Network Security Perimeter.

To restrict access with NSP:

1. Create or select a DCE in Microsoft Azure for the Logs Ingestion API.

2. Configure the DCR to use that DCE for ingestion.

3. In Azure Network Security Perimeter, associate the DCE resource with the NSP profile.

4. Add an inbound access rule to the NSP profile.

5. In the inbound rule, allow the Check Point Portal source IP ranges that match your tenant region.

6. In Check Point Portal, enter the DCE logs ingestion URI in the Data Collection Endpoint field.

7. Run Test Connectivity in Check Point Portal.

Use the regional FQDN below to identify the Check Point Portal source range for your tenant region:

Check Point Portal Region	Source FQDN	IP Address Range
Europe (EU)	whitelist-cidr.eu.datatube.checkpoint.com/	20.23.152.176/29
United States (US)	whitelist-cidr.us.datatube.checkpoint.com/	20.22.10.32/29
Asia-Pacific (AP, Australia)	whitelist-cidr.ap.datatube.checkpoint.com/	20.53.179.128/29
India (IN)	whitelist-cidr.in.datatube.checkpoint.com/	20.207.91.248/29
United Arab Emirates (AE)	whitelist-cidr.ae.datatube.checkpoint.com/	20.233.160.96/29

Important - Network Security Perimeter inbound access rules use IPx address ranges in CIDR format or subscriptions. They do not use FQDNs as source values. Resolve the relevant regional FQDN to the current source IP range and configure that range in the NSP inbound access rule.

Create a Forwarding Rule

After configuring the destination, add a forwarding rule with this destination. For more information, see Managing Forwarding Rules.

References

File extensions for certificates

File	Description
<CA>.key	Private key
<CA>.pem	Public key
.csr	Certificate Signing Request
.crt	File you create when you sign the .csr file with the <CA>.key file and the <CA>.pem file.
.pfx	If you use an existing domain certificate, this file contains the [CA].key file and <CA>.pem file.

Log Analytics table schema

When you create a custom table in the Azure portal, Azure automatically adds the _CL suffix .

Azure portal table name	Log Analytics table name
CheckPointEventForwarding	CheckPointEventForwarding_CL

Use the table name with the _CL suffix when you query the table in Microsoft Sentinel or enter the table name in Check Point Portal.

Check Point Event Forwarding sends events to Microsoft Sentinel with this schema:

Column	Type	Description
TimeGenerated	datetime	Timestamp used by Log Analytics. Depending on your DCR transformation, this can be the ingestion time or a timestamp parsed from the event payload.
RawData	string	Raw Check Point event payload. The value can contain JSON, Syslog, CEF, or LEEF, according to the Event Forwarding format selected in Check Point Portal.

Note - If you need to store the events in a different table schema, configure a DCR transformation that converts the incoming Check Point Event Forwarding data to the required schema. The target table schema does not need to match the internal fields inside the RawData value.

For more information, see Microsoft Learn: Transformations in Azure Monitor.

Logs Ingestion endpoint

The Logs Ingestion endpoint format is

https://<endpoint-name>.<region>.ingest.monitor.azure.com

The endpoint can be one of these values:

• The DCR logs ingestion endpoint.

• The Data Collection Endpoint (DCE) Logs Ingestion URI.

The DCR, DCE, and Log Analytics workspace must be configured according to Microsoft Azure Monitor Logs Ingestion API requirements.

DCR Stream Name

Stream Name Example:

Custom-CheckPointEventForwarding_CL

Important: The stream name must match the DCR configuration exactly. Use the same capitalization and spelling as in the DCR. Do not use the table name unless the DCR stream is configured with the same value.