How to connect a Check Point Security Management Server (SMS, aka SmartCenter) R77.x to SecureTrack:


Prepare the Check Point SMS

It's recommended to define a Permission Profile for Tufin's access to the SMS and the logs. If there is only SecureTrack and no provisioning by SecureChange is wanted, a Read-Only Profile is sufficient. To define it, go in the SmartDashboard Menu to Manage > Permission Profiles and define a Read-Only profile.

Next, an object of the type Host Node is needed representing the System Tufin SecureTrack is running on. This is necessary because the IP address is needed later when the OPSEC Application is defined. To define it, go to Manage > Network Objects > New > Host Node.

 

To initiate the Secure Internal Communication (SIC), defining an OPSEC Application is necessary. To do so, open Manage > Servers and OPSEC Applications and define a new one. Necessary protocols are LEA (Log Export API) to have access to logs as well as CPMI (Check Point Management Interface) to have access to the objects and rules.

It's necessary to configure the permissions of Tufin SecureTrack within Check Point. For CPMI as well as for LEA the Permission Profile defined earlier should be selected. You are free to allow further access, but it's not necessary if the use of only SecureTrack is planned.

 

After these steps, the SIC should be initiated by setting an Activation Key. This is a One-Time Password for authenticating Tufin SecureTrack at the SMS. When this authentication is successful, a newly generated certificate is transferred to SecureTrack. From then on, authentication is based on this certificate. The communication is encrypted as it is between the Check Point components like e.g. SMS and Firewall Module.

When the password is typed twice, the button Initialize finishes this part of the configuration.

Please don't forget to make this newly generated certificate available by installing the Database. This is done by Menu > Policy > Install Database. If you forget to install the database on the SMS, the connection to SecureTrack won't work.

 


Prepare the Check Point Rulebase

If there is a Firewall between Tufin SecureTrack and Check Point SMS, a rule must allow the necessary access. Besides the access using LEA and CPMI furhter connections are needed, e.g. for Certificate Management:

  • 18210/tcp
    Connection to SMS for authenticating using the one-time password and for retrieving the certificate
  • 18264/tcp
    Connnection needed to access the CRL running on the SMS to check if the certificate presented by SMS is valid
  • 18184/tcp
    Connection from SecureTrack to SMS / Logserver to retrieve log data (statistics) and Audit log data (recognition of actions done by administrators)
  • 18190/tcp
    Connection from SecureTrack to SMS with a CPMI client to retrieve the latest revision

So a rule needs to be configured. This is necessary if any firewall is between SecureTrack and SMS. When a Check Point Firewall is in between, the rule could look like this:

 


Configure Check Point SMS in Tufin SecureTrack

The Check Point SMS needs to be defined in SecureTrack so the configuration can be monitored. To do so, some steps are necessary. First of all, connect with administrative rights to Tufin SecureTrack using a web browser using HTTPS (443/tcp). In the default configuration doesn't redirect a HTTP request from port 80/tcp to the correct port.

 In the Menu go to Settings > Monitoring > Manage Devices. On the left pane all monitored devices are listed. On the right side a new device can be definded. Here, select Check Point SmartCenter.

After this selection a wizard starts, asking for several configuration options in five steps.

The Device Type can't be changed here since this option has been selected before. The other options are:

  • Name for Display
    Name shown in SecureTrack for this device
  • Domain
    If SecureTrack is configured to use Domains, the corresponding Domain can be selected there. Please be aware that using this option clearly separates all data.
  • Get revisions from <IP> or <Offline File>
    If the SMS is monitored live, the IP Address of the SMS is provided here. If there is no direct access, configuration data can be imported. Please be aware that this option requires a license also - even if there is no monitoring of the changes.
  • Usage Analysis
    Here it's selected which data are collected. Esp. when "Rule and Object Usage" reports are required, the first two options need to be selected. Besides this, it's recommended to select the enablement of the Topology. In this case, all information that require Topology is available (e.g. Policy Analysis, Zones, Compliance Rules...).

The next step is to authenticate using the One-Time Password and to retrieve the certificate used from then on to authenticate.

It's necessary to provide the name of the OPSEC Application configured in Check Point SmartDashboard. The Activation Key is the One-Time Password provided during configuration in Check Point SMS.

In many cases the next windows can be kept using "default" for the OPSEC settings.

If there were changes configured in $CPDIR/conf/sic_policy.conf they can be considered here. It's all about authentication used for LEA and CPMI. All relevant Check Point options can be selected, so a successful authenticated connection from Tufin SecureTrack to Check Point SMS is possible.

In some cases the configuration for the timing of monitoring needs to be adjusted.

As in many cases, the default setting is useful when the global configured timing is sufficient.

Finally, the configured connection should be tested. If this is ok, the button Save finalizes the configuration.

 


Monitoring the Check Point SMS

The status of monitoring the SMS can be checked using Menu > Settings > Administration > Status. Depending on the connection and the load on the Check Point SMS the status will remain some time in "Starting" and "Yellow". When it has changed to "Green" the SMS is shown under Menu > Compare also in green and after a short time the first revision will show up.

 

 

 

 

 

Let's imgine following situation:

Tufin SecureTrack is licensed for 2 Firewall Clusters which are centrally managed by one Check Point Security Management Server (resulting in a single SecureTrack ID).
Reports for e.g. Rule and Object Usage deliver results for one Firewall Cluster only. Reports on the second Cluster don't contain any data.

This behavior isn't as expected since it cannot be the connectivity between the Log Server and SecureTrack. Besides this, logs for this cluster are there and shown in the tools by Check Point. So Log data are there but SecureTrack doesn't deliver any report.

 

This behaviour can be reasoned by a missing license! In our case only one FW-license was attached to the Firewall Cluster, but not the second one. So the Firewall Cluster not delivering reports wasn't licensed full and therefore no reports were generated. After (re-)attaching the license reports deliver results for both Firewall Clusters - as expected.

 

 

When connecting a Check Point Security Management Server to SecureTrack, there are two possibilities to gather the topology:

Check Point Security Management Server only

In this case, Secure Internal Communication is set up to have a secure connection between the SecureTrack Server and the Check Point Management.
The Topology for SecureTrack is read from the Interface information defined in the Check Point Firewall and Cluster, respectively. Anti-Spoofing information is also read to get as much information as possible about the Topology.

Check Point OS Monitoring

In this case, the Topology is read from the monitored devices directly using SNMP. Other information isn't gathered - information from the object defined in the Security Mangagement Server is ignored.

 

Lesson learned:

If Check Point OS monitoring is activated and the SecureTrack Server has no possibility to read information using SNMP (161/udp), no information about the Topology is imported and therefore this device isn't shown in the SecureTrack Topology. Allowing SNMPv3 between the SecureTrack Server and the firewall device helps to avoit this potential problem.

 

Tufin SecureTrack offers some possibilities if a device can't be monitored directly. One of them is to define a Generic Device. Just a short explanation of this kind device and how to configure it.


Generic Device

This kind of device is defined for SecureTrack Topology only. No Monitoring, no security configuration and no logs are imported into SecureTrack. Such a device is necessary if a non monitored device is needed to correct / enhance the Network Topolgy SecureTrack is working with. As you know, that's the base for enhanced features of SecureChange and SecureApp. So it's important to let the Topology of SecureTrack show the reality regarding Networks and Routing.

Since no data is used for reports, analysis of rule bases etc. no license for such a device is necessary.

Why and how to define it? Let's assume you have a topology which isn't according with the reality. Mostly the reason is a missing device, connecting two or more networks. The topology shows like e.g.

So defining a Generic Device might help to improve the topology to show the reality.

Just create a plain ASCII file with all relevant data. Referring to the User Guide might be useful...  ;)
If you want to define a Generic Device to connect the device "firstvs" managed by "SMC-Rio" with the net 198.18.50.0/24 the plain ASCII file might look like this example:

Name, Ip, Mask, Vrf
interface1, 192.168.50.254, 255.255.255.0
interface2, 172.16.41.254, 255.255.255.0

Destination, Mask, Interface, Next-Hop, Vrf
0.0.0.0, 0.0.0.0, interface1, 198.18.50.1

Now it's time to import the file to SecureTrack. This is done in the menu option "Network > Topology > Add Generic Device".

The next step is to save the file and to wait for a moment. SecureTrack is calculating the new Topology. After finishing it, the Generic Device is shown in the SecureTrack Topology. For sure, this change will also be known in SecureChange.

So from now on, this device is known in Tufin SecureTrack Topology and also considered by the other components of the Tufin Orchestration Suite.
If there is a "big Core Device" by Cisco, no definition of all Interfaces and routes is necessary. Just an import of exported configuration data does the job. Redirect the output of

# show ip route
# show ip interface

to a file and import it as shown above. We have proved this also for very big configuration files - and it works if it's a Cisco device...