www.tufin.club

What happens with USP if a Network is not member of a SecureTrack Zone?

Having a Unified Security Policy (USP) matrix defined requires zones configured in SecureTrack Network Topology. Networks are assigned to these zones, which are referenced in a USP. In this matrix, traffic can be allowed or forbidden explicitely. The compliance of a connection with USP is tested in SecureTrack Violations as well as SecureChange Risk checks and SecureApp Compliance checks.

Besides individually configured zones a zone called Internet is available by default. This zone includes all networks that are not configured to be in other zones and that are not defined as Private Networks (RFC 1918). So in many cases this Internet Zone can be used to forbid "all other traffic" in the USP. So all official networks which aren't assigned to an individually configured zone will result in "RISK".

What happens if a private network like e.g. 192.168.1.0/24 isn't assigned to a zone, but used as SRC or DST?

 

Behaviour before R18-2 HF1

Private networks not assigned to a zone referenced in the USP are not mentioned here, so they are not tested - and therefore such a network in SRC or DST will not lead to "RISK". Result of USP check is "no risk". 

 

Behaviour since R18-2 HF1

Tufin has introduced a new row to configure this behaviour. This can be done quite easily: 

  • Navigate to https://<SecureTrackHost>/stcgitest.htm
    to be redirected to https://<SecureTrackHost>/securetrack/admin/stcgitest.htm
  • Find Edit StConf and follow the link to Edit StConf

  • Press the button to Fetch Current Conf

  • Now search for this entry and modify the severity as needed

<unmatched_internal_address_risk_severity>0</unmatched_internal_address_risk_severity>

  • When ready, safe the configuration using the button Submit New Conf

You can select the Severity by changing the number in the middle of the expression. Possible options are

0 - No Risk (Default, same behaviour as before R18-2 HF1)
1 - Severity low
2 - Severity medium
3 - Severity high
4 - Severity critical

Based on this information a USP can be configured in a way that also "unknown" private networks lead to "RISK"

 

 

SecureTrack as well as SecureChange are using a WebUI to interact with Administrators and Users. Here a timeout of about half an hour is configured by default, i.e. after 30 minutes of inactivity users are logged out automatically.
Not for every case this time is fine, e.g. for some customers this time might be too long due to security reasons. Other complain that this time is too short and they can't work with the tool. Both can be helped by changing the time for auto-logout within the configuration of SecureTrack and SecureChange. Parameters used for SecureChange are also valid for SecureApp.

 

Changing auto-logout time for SecureTrack WebUI

This change is done by changing the Apache configuration.
These steps will help to adjust the time between 600 and 86.400 seconds:

  • Backup the file /etc/httpd/conf/httpd.conf
  • Edit the file /etc/httpd/conf/httpd.conf and find this parameter: OIDCSessionInactivityTimeout
  • Replace the number following this parameter and select your own number of seconds here,
    e.g. if you want to have the timeout after 10 Minutes:
    OIDCSessionInactivityTimeout 60 (space between variable and number)
  • Save the file with the change
  • Restart the webserver using # service httpd restart
  • Restart the Tomcat Server using # service tomcat restart

 

Changing auto-logout time for SecureChange WebUI

This change is done by changing the TOS configuration.
These steps will help to adjust the time in minutes:

  • Backup the file /opt/tufin/securitysuite/conf/tufin_settings.properties
  • Edit the file /opt/tufin/securitysuite/conf/tufin_settings.properties and find the parameter SC_SESSION_TIMEOUT
  • Replace the number following this parameter and select your own number of minutes here,
    e.g. if you want to have the timeout after 10 Minutes:
    SC_SESSION_TIMEOUT=10 (equal sign between variable and number)
  • Save the file with the change
  • Restart the Tomcat Server using # service tomcat restart

 

 

 

 

Tufin has released R18-3, the third version of the Tufin Orchestration Suite in 2018. TOS 18-3 is available as GA now, delivering some improvements, e.g.

Change Automation and Orchestration

  • SecuerChange
    Remove Access for VMware NSX. This kind of Workflow is available for NSX now.
  • Secure Change
    Modify Group Automation for Palo Alto Panorama Shared Objects
  • SecureChange
    Server Decommission Automation, now supported for Palo Alto Panorama Shared Objects and Cisco Firepower Management Console (FMC)
  • SecureChange
    Change Automation Enhancements for Cisco Firepower, now supporting workflows "Allow Access", "Modify Group", "Server Decommission", "Rule Decommission", and "Rule Recertification"
  • SecureChange
    Action "Commit Now" is possible in an automatic step in workflows "Access Request", "Modify Group", "Access Request and Modify Group", and "Rule Decommision" for these Devices: Palo Alto Panorama Advanced Management Mode, Fortinet FortiManager Advanced Management Mode, Check Point CMA R80. Check Point MDS R80 is only supported for "Modify Group"

Security, Risk and Compliance

  • SecureTrack
    Rule Change and Object Change Reports for Palo Alto Panorama Device Groups for Advanced Management Mode and FortiManager ADOM Policies when configured for Advanced Management Mode.
  • SecureTrack
    Enhanced Unified Security Policy (USP) Risk Analysis, e.g. configuration of Default Behavior when an IP address is not covered in the USP

Devices and Platforms

  • SecureTrack
    Fortinet FortiManager Rule Name support for FMG version 5.4 and above
  • SecureTrack
    Syslog support for Check Point R77, so traffic and audit logs can be received using LEA or syslog
  • SecureTrack
    External syslog support for VMware NSX, support of vRealize Log Insight
  • SecureTrack
    Cisco Firepower revision changes support
  • SecureTrack
    Policy-based routing (PBR) and related ACL rules support for Cisco IOS routers in the Interactive Map
  • Support of new devices
    • Cisco ASA 9.9
    • Check Point R80.20 (EA)
    • Palo Alto PanOS 8.1

REST API

  • Improvements for SecureTrack
    • Unified Returned JSON Array Format - continued
    • New Change Windows APIs
    • Get General SecureTrack Properties
    • Enhanced API for retrieving subnet information
    • Restricted pagination for Rule Search API
    • Enhanced API for Monitored Devices
    • Service Search
    • Retrieve suggested targets for an access request
  • Improvements for SecureChange
    • Commit Results
    • Modify Designer suggestion

Further improvements as well as corrections are included.
The latest version of the Tufin Orchestration Suite can be found at the Tufin Portal: https://portal.tufin.com

 

 

 

 

Tufin SecureTrack supports Check Point R80.x since a longer time now. Using a Check Point Management R80.20 may result in a problem.

A Check Point Management R80.20 can be connected to SecureTrack without a problem - at the first glance. All checks regarding OPSEC and Management API are ok, the device is shown in green pointing out that everything is ok.

But getting a revision seems not possible. Everything is green, but no revision shows up. In the corresponding log the statement "Checkpoint error code: http_forbidden" can be found.

This problem can be solved by using the correct version of Tufin SecureTrack.
Check Point R80.20 is supported from TOS R18-2 HF 1.2 and TOS R18-3 GA on (not by RC).
Upgrading to one of these versions solve the problem.

 

 

 

 

Some months ago, an article about potential problems connecting SecureTrack to a Check Point R80 Management Server has been published here. Most of the points are still true - except the option
   Menu > Settings > Monitoring > Check Point Management R80 > Test Connectivity
is now also testing the API connect to the Check Point Management Server (e.g. in R18-3).

As pointed out in Tufin Knowledge Center #10413, one reason for an API client error is the API itself. At the CLI of this machine an "expert" user can (and should) check the status of the api to be sure it's up and running. Tufin points out the resolution to allow access to the API from "All IP addresses", which is correct.

It might happen that access isn't possible even if the change has been configured, published via SmartConsole and the API has been restarted using CLI. Assuming that access to port 443/tcp is granted, another reason might be possible. In our lab this problem has been found using Check Point R80.20 with SecureTrack R18-3. It might happen in your environment also, but not necessarily.

Even if the change of allowed IP addresses has been published and the API has been restarted, it might not be active for the API. This can be checked by an "expert" user

[Expert@SMS]# api status
API Settings:
---------------------
Accessibility:                      Require ip 127.0.0.1
Automatic Start:                  Enabled

So in this case, the change hasn't become active and the API allows access from 127.0.0.1 only. This might also not change when the API is restarted again. In this case, try the command

[Expert@SMS]# api reconf
API reconfigured successfully
[Expert@SMS]# api status
API Settings:
---------------------
Accessibility:                      Require all granted
Automatic Start:                  Enabled

After the completion of the first command, the change is active and SecureTrack can access the API.

 

 

 

 

If Tufin SecureTrack is monitoring Cisco Firewalls and Routers, credentials to authenticate SecureTrack here need to be provided. Now it has been found, that the Enable Password may be exposed in a log file. This has been rated as "High Severity Vulnerability".

Please note that the password is shown in a log file of SecureTrack only, so only administrators with CLI access might get this information, but no unauthenticated attackers.

Affected versions of SecureTrack are R17-1, R17-2, R17-3, R18-1, R18-2 and R18-3, respectively.
A vulnerability fix will be included in HFs for supported versions:

  • TOS 18-1: Fix is included in R18-1 HF3.1 which will be published November 4th, 2018
  • TOS 18-2: Fix is included in R18-2 HF1 which will be published Novermber 7th, 2018
  • TOS 18-3: Fix is included in R18-3 RC1.1 which will be published November 4th, 2018

If you use an older version please plan an update to a version supported by Tufin.
Newer versions of Tufin Orchestration Suite will have the Fix included.