It's quite a good feature that reports in SecureTrack can be generated automatically and sent by E-Mail to recipients.
Sometimes the time mentioned in the reports seems to be wrong, even if following time settings are correct and all the same:

  • PC of the user  
  • SecureTrack Server
  • Monitored Device reported on

Even if all these time settings are ok, it might happen that e.g. the report is sent at 16:40 while the time in the report itself shows 17:40.

The reason for this behaviour is that PostgreSQL has another time zone configured. By default the time zone in TufinOS is "Israel".
This can be changed using these steps: 

Stop services

  • # service crond stop
  • # service tufin-jobs stop
  • # service jms stop
  • # service postgresql-9.4 stop

Edit configuration file

  • Backup and edit the file /var/lib/pgsql/9.4/data/postgresql.conf
    find the settings for
         log_timezone ='Israel'    
         timezone
    = 'Israel'
    and change them to your time zone, e.g. 'UTC' or 'Europe/Berlin' (the timezone needs to be listed in /usr/share/zoneinfo)

Start services

  • # service postgresql-9.4 start
  • # service jms start
  • # service tufin-jobs start
  • # service crond start
  • # service tomcat restart

After the services are started again in the correct order, the time used in reports should be correct. Restarting tomcat is necessary because otherwise the time of ticket creation in SecureChange isn't correct.

Hint: If the postresql service doesn't start, check the correct spelling of the time zone configured.

 

 

 

 

 

Working with SecureTrack mainly means to work with a Browser connected to the SecureTrack Server. If nothing is done, an automatic logout is initiated by the system. The time untli this logout happens, can be configured.

Sometimes a logout from the WebUI happens while the administrator works. This should not happen and seems to be a "feature" of versions up to and including 17-2.
With 17-3 and subsequent versions Tufin has changed the authentication method to Keycloak. These versions don't show this effect any more.

If there is a problem with automatic logout while working with the WebUI, an upgrade to 17-3 or newer is recommended.

 

 

 

When using Check Point Management R80.x besides the "normal" OPSEC connections a connect to the Check Point Management API is necessary.

How to connect Tufin SecureTrack with Check Point Management R80 is described here.

Even if the connection to the Check Point Management is ok, an error might be displayed: 
Checkpoint API client error

Testing the connection from SecureTrack using
Menu > Settings > Monitoring > Check Point Management R80 > Test Connectivity

seems successful, but the status icon of the device is yellow in SecureTrack. In Menu > Settings > Administration > Status > Check Point Management R80 > Status the error is shown and no new revisions are imported to SecureTrack.

Background information: "Test Connectivity" checks currently the OPSEC channel (used in R77.x) only. The second channel is the Management API which is necessary when monitoring R80.x.

Some troubleshooting might solve this issue. You can try one or more of the following things before restart monitoring the device:

  • Check that the Check Point Management monitored is really Version R80.x and not still Check Point R77.30. If that's the case, the device needs to be deleted and new defined as Check Point Management R77.30. There is no way to change the Check Point Version from R80.x back to the old one.
  • Check that Tufin SecureTrack is able to connect to Check Point management Server using port 443/tcp. Maybe a Firewall is blocking this traffic.
  • Check the credentials configured for the Tufin user at the Check Point Management Server.


  • Check the permissions of the Tufin user at the Check Point Management Server. This user needs rw even if there is no provisioning configured or planned.


  • Check the Expiration Date of the account, sometimes it's not the default value ending in 2030.
  • If all these measures don't help, try to restart the Management API at the Check Point Management Server. This can be done as "expert" using the command api restart.

 

If you have further ideas or if these items didn't help, please don't hesitate to contact us.

 

 

 

Using the latest versions of SecureTrack, the "good old" Topology isn't available any more.
The new Interactive Map offers more possibilities and doesn't need Flash.

Searching a path from A to B is possible inside this map.

The result is shown inline. Especially in komplex environments, the result is shown very small and many administrators have difficulties to have a "good graph for documentation". In this case, it's useful to take the REST API for the request.
The URL https://forum.tufin.com/support/kc/R16-3/securetrack/apidoc/#!/Network_Topology/getPathCalcImage shows the syntax how to request the path which is shown in the browser afterwards.

Just an easy example: We want to know the way from 10.100.1.1/32 to 40.50.60.1/32 using SSH. In the Interactive Map the request is configured and the result is shown. This example delivers a simple output:

 

The result could be much more detailed, so it might happen that the output is too small. In this case, or if a graphic file is wanted directly, the same request can be done by using this URL:

https://<IP_SecureTrack>/securetrack/api/topology/path_image?src=10.100.1.1:32&dst=40.50.60.1:32&service=ssh%20protocol

The result is a png graphic file which can be saved and easily put into a documentation.

 

 

 

 

Some administrators of Tufin SecureTrack are used to the old Topology Map, which has been removed in TOS 16-4. Instead of the Topology Map the new Interactive Map has been integrated. It shows some advantages and doesn't require the Adobe Flash. But still some administrators want the "good old Topology Map".

This is the view administrators have today - only the Interactive Map is shown in the Menu. It's possible to enable the Topology Map using this command at the CLI of the server:

[root@TufinOS]# /usr/local/st/manage_old_topology_tab.sh enable
Restarting httpd service to apply changes
[root@TufinOS]#

The change becomes visible when the page is reloaded or the user has logged off and logged on again.

As you see, even in the latest versions the Topology Map can be used. Due to improved options, the Interactive Map should be the preferred way to work with  the Topology in SecureTrack.

 

PS: To disable the Topology Map, this command can be used:

[root@TufinOS]# /usr/local/st/manage_old_topology_tab.sh disable
Restarting httpd service to apply changes
[root@TufinOS]#

 

 

 

 

Sometimes it's necessary to have zones defined that include "new" or "unknown" networks.


Traditional Approach

The traditional approach in Tufin SecureTrack is to have devices monitored. These devices deliver information about Networks and Routes to SecureTrack. This information is used to build the Topology.
The next step would be to define Zones manually. These zones include networks included in the Topology. So finally, only "known networks" are defined in zones which can be used to define the Unified Security Policy (USP).


Another Approach

Some administrators have a tool for IPAM (IP Address Management) that includes all IP-Adresses and Networks, even if they are not registered in SecureTrack Topology. This information at all shall be used for compliance rules ini the USP. Since an import of zones is possible and no check is done if the networks exist in SecureTrack, exporting these data from IPAM helps, e.g.

Known: Zone a (Network 10.1.1.0/24), Zone b (Network 10.1.2.0/24)

in IPAM: Network 10.1.3.0/24 which should be imported into a new zone

File for import into SecureTrack Zones:

"#Zone Properties"
"zone name","description"
"Internet","Internet zone is all public addresses, excluding the addresses defined in all other zones"
"Users Networks","Users Networks zone should include the address space from which users can come within your organization"
"a",""
"b",""
"c","new zone"

"#Zone Hierarchy"
"parent","child"

"#Zone Subnets"
"zone name","subnet","description"
"a","10.1.1.0/24",
"b","10.1.2.0/24",
"c","10.1.3.0/24","new"

"#Zone Security Groups"
"zone name","security group name","description"

Even if the new zone isn't known in SecureTrack before and the network isn't in the Topology the import works.
After having imported the zones including the new zone c, the USP can be adapted and imported, too. Even if the following example isn't really a USP, it can be shown that it works.

"from zone","to zone","severity","access type","services","rule properties","flows"

"a","a","high","allow all","","",""
"a","b","critical","allow all","","",""
"b","a","low","allow all","","",""
"b","b","high","allow all","","",""
"c","c","high","allow all","","",""
"a","c","critical","allow all","","",""
"c","a","low","allow all","","",""
"b","c","critical","allow all","","",""
"c","b","low","allow all","","",""

After import, the new zone c is shown in the USP, even if the network isn't included in the SecureTrack Topology.

 

Lesson learnt: If an IPAM hosts all information about the networks, exporting relevant information in the correct format allows to define a USP with networks not even included in the Topology.