Secure Internal Communication (SIC)

Check Point platforms and products authenticate each other through one of these Secure Internal Communication (SIC Secure Internal Communication. The Check Point proprietary mechanism with which Check Point computers that run Check Point software authenticate each other over SSL, for secure communication. This authentication is based on the certificates issued by the ICA on a Check Point Management Server.) methods:

• Certificates.

• Standards-based TLS for the creation of secure channels.

• 3DES or AES128 for encryption.

  Security Gateways R71 and higher use AES128 for SIC. If one of the Security Gateways is below R71, the Security Gateways use 3DES.

SIC creates trusted connections between Security Gateways, management servers and other Check Point components. Trust is required to install polices on Security Gateways and to send logs between Security Gateways and management servers.

Note - From R81 Jumbo Hotfix Accumulator Take 34, to see SIC errors, examine the $CPDIR/log/sic_info.elg file on the Security Management Server Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server. and on the Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources..

Initializing Trust

To establish the initial trust, a Security Gateway and a Security Management Server Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server. use a one-time password. After the initial trust is established, further communication is based on security certificates.

Note - Make sure the clocks of the Security Gateway and Security Management Server are synchronized, before you initialize trust between them. This is necessary for SIC to succeed. To set the time settings of the Security Gateway and Security Management Server, go to the Gaia Portal > System Management > Time.

SIC Status

After the Security Gateway receives the certificate issued by the ICA, the SIC status shows if the Security Management Server can communicate securely with this Security Gateway:

• Communicating - The secure communication is established.

• Unknown - There is no connection between the Security Gateway and Security Management Server.

• Not Communicating - The Security Management Server can contact the Security Gateway, but cannot establish SIC. A message shows more information.

Trust State

If the Trust State is compromised (keys were leaked, certificates were lost) or objects changed (user leaves, open server upgraded to appliance), reset the Trust State. When you reset Trust, the SIC certificate is revoked.

The Certificate Revocation List (CRL) is updated for the serial number of the revoked certificate. The ICA signs the updated CRL and issues it to all Security Gateways during the next SIC connection. If two Security Gateways have different CRLs, they cannot authenticate.

1. In SmartConsole, from the Gateways & Servers view, double-click the Security Gateway object.

2. Click Communication.

3. In the Trusted Communication window that opens, click Reset.

4. Install Policy on the Security Gateways.

   This deploys the updated CRL to all Security Gateways. If you do not have a Rule Base All rules configured in a given Security Policy. Synonym: Rulebase. (and therefore cannot install a policy), you can reset Trust on the Security Gateways.

   Important - Before a new trust can be established in SmartConsole, make sure the same one-time activation password is configured on the Security Gateway.

Troubleshooting SIC

If SIC fails to Initialize:

1. Make sure there is connectivity between the Security Gateway and Security Management Server.

2. Make sure that the Security Management Server and the Security Gateway use the same SIC activation key (one-time password).

3. If the Security Management Server is behind a gateway, make sure there are rules that allow connections between the Security Management Server and the remote Security Gateway. Make sure Anti-spoofing settings are correct.

4. Make sure the name and the IP address of the Security Management Server are in the /etc/hosts file on the Security Gateway.

   If the IP address of the Security Management Server mapped through static NAT by its local Security Gateway, add the public IP address of the Security Management Server to the /etc/hosts file on the remote Security Gateway. Make sure the IP address resolves to the server's hostname.

5. Make sure the date and the time settings of the operating systems are correct. If the Security Management Server and remote the Security Gateway reside in different time zones, the remote Security Gateway may have to wait for the certificate to become valid.

6. Remove the Security Policy Collection of rules that control network traffic and enforce organization guidelines for data protection and access to resources with packet inspection. on the Security Gateway to let all the traffic through:

   1. Connect to the command line on the Security Gateway

   2. Log in to the Expert mode.

   3. Run:

      fw unloadlocal

      Important - See the R81 CLI Reference Guide > Chapter Security Gateway Commands > Section fw > Section fw unloadlocal.

7. Try to establish SIC again.

Remote User access to resources and Mobile Access

If you install a certificate on a Security Gateway that has the Mobile Access Check Point Software Blade on a Security Gateway that provides a Remote Access VPN access for managed and unmanaged clients. Acronym: MAB. Software Blade Specific security solution (module): (1) On a Security Gateway, each Software Blade inspects specific characteristics of the traffic (2) On a Management Server, each Software Blade enables different management capabilities. already enabled, you must install the policy again. Otherwise, remote users will not be able to reach network resources.

Understanding the Check Point Internal Certificate Authority (ICA)

The ICA (Internal Certificate Authority) is created on the Security Management Server when you configure it for the first time. The ICA issues certificates for authentication:

• Secure Internal Communication (SIC) - Authenticates communication between Security Management Servers, and between Security Gateways and Security Management Servers.

• VPN certificates for gateways - Authentication between members of the VPN community, to create the VPN tunnel.

• Users - For strong methods to authenticate user access according to authorization and permissions.

ICA Clients

In most cases, certificates are handled as part of the object configuration. To control the ICA and certificates in a more granular manner, you can use one of these ICA clients:

• The Check Point Configuration Tool - This is the cpconfig CLI utility. One of the options creates the ICA, which issues a SIC certificate for the Security Management Server.

• SmartConsole - SIC certificates for Security Gateways and administrators, VPN certificates, and user certificates.

• The ICA Management Tool - VPN certificates for users and advanced ICA operations.

See audit logs of the ICA in SmartConsole Logs & Monitor > New Tab > Open Audit Logs View.

SIC Certificate Management

Manage SIC certificates in the

• Communication tab of the Security Gateway properties window.

• The ICA Management Tool.

Certificates have these configurable attributes:

Attributes	Default	Comments
validity	5 years
key size	2048 bits
KeyUsage	5	Digital Signature and Key encipherment
ExtendedKeyUsage	0 (no KeyUsage)	VPN certificates only

To learn more about key size values, see RSA key lengths.