www.tufin.club

When configuring Tufin SecureChange, the corresponding SecureTrack server needs to be connected to the SecureChange server.
So in a first step an administrative user is configured in SecureTrack. This user is for a later authentication of SecureChange at SecureTrack.

  • Hint:
    Don't use reserved words like "Securechange" as username. This user won't be able to authenticate.

So if the user for SecureChange is configured, test it by logging in using the WebUI. If this works, SecureChange also will be able to authenticate.

  • Hint:
    The Authentication of SecureChange at SecureTrack is machine based. Using a certificate is currently not possible.
    So use a very strong password not known to any person for this purpose.

The next step is to log in at SecureChange with permission to configure "Settings". In the menu select "SecureTrack".

This information needs to be provided if SecureTrack isn't configured to run on the same system as SecureChange:

  1. Select "Remote host" and provide the IP address of SecureTrack, SecureChange will connect to.
  2. Provide user name and password as configured in SecureTrack.
  3. optional: "Show link to SecureTrack" - sometimes useful for admins, but maybe confusing end users working with SecureChange. It selected, the IP address configured in (1) will be linked here.
  4. Provide "Internal IP of SecureChange server" means to fill in the IP address SecureTrack uses for connections to SecureChange. This IP address will also be in the link to SecureChange shown in the login screen of SecureTrack.

For (1) as (4) a host name can be configured also, but this name needs to be resolved using DNS.

If the configuration is ready, try the button "Test connection" on the right bottom of the page. This will test the connection and deliver a result. This result can be, that an authentication error has occurred, the connection couldn't be established - or that the connection is ok. If this is the case, press "Save" and the task is finished.

  • Hint:
    The test done checks not only the connection from SecureChange to SecureTrack, but also from SecureTrack to SecureChange. So it might happen that you can connect from SecureChange to SecureTrack using 443/tcp - and the WebUI delivers a connection error. This is because maybe the back connection from SecureTrack to SecureChange isn't possible. In this case, error message might point to other reasons. So it's useful to check the back connection.

Connecting SecureChange to SecureTrack is essential, since the license is held in SecureTrack. Besides this, SecureChange uses features of SecureTrack like e.g. Zones and USP as well as the Topology.

 

 

 

Tufin has released R19-1, the first version of the Tufin Orchestration Suite in 2019. TOS 19-1 is available as GA now, delivering some improvements, e.g.

  • Interactive Map of SecureTrack allows to save queries now. This allows administrators to save the most important path queries and to re-use them again
  • SecureApp has been optimized for color-blind access. It's compatible with corresponding industry standards now.

Change Automation and Orchestration

  • SecureChange
    Clone Server Policy Workflow allows easy duplication of access permissions when new servers are introduced. This might also help when a server is moved from one address to another.
    Supported platforms are Cisco ASA, Cisco Firepower, Check Point R80 (CMA, SmartCenter, MDS), Fortinet FortiManager advanced and Palo Alto Panorama advanced
  • SecureChange
    Enhanced sorting of selections when adding or removing components. This might help e.g. when an assingment to some users / groups is done. The box for selecting / deselecting them can be sorted not only by name but also by "add" or "clear". This is relevant for "Access Request" and "Clone Server Policy" workflows.

Security, Risk and Compliance

  • SecureTrack, SecureChange
    Map Ticket to Rule is a new feature that maps a fully or paritally implemented ticket to rules. This mapping is based on results of the Verifier.
  • SecureChange
    Enhancements for "Legacy Rules". The Designer now places changes above a legacy rule now only if the legacy rule traffic intersects the Access Request traffic. Until now, this was done always.
  • SecureTrack
    Enhanced USP allows to automatically trigger a violation for IP addresses that are not explicitely included in any USP. They can easily be added to relevant zones.
  • SecureTrack
    A new network zone called "Unassociated Networks" is predefined. It includes all private IP addresses that are not defined in any other zone. This is the "private equivalent" to the predefined zone "Internet". It's used in SecureTrack as well as SecureChange and SecureApp.

 Devices and Platforms

  • SecureTrack
    NAT support for Palo Alto Panorama advanced to track changes on NAT rules
  • SecureTrack
    URL Filtering Support for Palo Alto Panorama advanced to track changes in URL Category
  • SecureTrack
    Cisco Nexus VXLAN Routing Support is implemented now and shown in the Interactive Map
  • SecureTrack
    Routes configured in Juniper MX Router Devices can be selected now, i.e. if there are many dynamic routes specific networks and routes can be added / deleted which might increase router performance
  • SecureChange
    "Server Decommission" is supported now for Global Objects defined in Check Point MDS
  • Support of new devices:
    • Check Point R80.20 (Check Point API version 1.1)
    • Forcepoint SMC 6.5 (SMC API version 6.4)
    • Fortinet FortiManager 6.0.2

REST API

  • Improvements for SecureTrack
    • Unified Returned JSON Array Format is completed now
    • Panorama Firewall Name to Rule- and Policy-related API (PolicyTargetDTO)
    • Adding Devices via API is possible now (for Check Point R77, Cisco ASA without Virtual Contexts, more to follow)
    • Get Panorama URL Categories
    • Compare Traffice Between Devices
    • Service Object Search
    • Modify Unified Security Policy via API is possible now
  • Improvements for SecureChange
    • Clone Server Policy Request DTO
    • Reject Ticket via API
    • Map Rules to Ticket

 

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

 

 

 

Starting with April 2019, Tufin has published TufinOS 2.18. This version is available for download now in the Tufin Portal.
If you start a new installation, you don't need to install and upgrade TufinOS 2.15 anymore, since TufinOS 2.18 is available for clean installation (ISO or Appliance) also.

New features and updates of TufinOS 2.18 are:

  • 28 RPMs are updated to version CentOS 6.10, which is the latest version
  • Microsemi Adaptec ARCCONF Command Line Utility version 3.01.23531
  • PostgreSQL version 9.4.21-1PGDG.rhel6
  • sTunnel version 5.50
  • PAM Radius version 4.0

An updated description how to upgrade TufinOS in HA environments is available in the Tufin Portal.

 

 

 

Many installations use Tufin Appliances to run SecureTrack and/or SecureChange with SecureApp. In some situations it feels as if with each new version of TOS the performance becomes slower and slower while in parallel the load of the machine becomes higher - even if there is no change in the number of monitored devices, log volume or number of concurrent users.

Looking at older versions like e.g. 17-1, the requirements for SecureTrack and SecureChange on a machine were 4 processor cores and 4 GB RAM. Recommendation for productive environments were at least 4 processor cores and 8 to 12 GB RAM.

Since then many features have been added to Tufin Orchestration Suite, so the software package has become much bigger, e.g. 16-1 was about 750 MB, 17-1 was about 810 MB while 18-1 has grown up to approximately 1.4 GB. A possible reason are many new features that are added to the code. The size of the code has nearly doubled which in consequence leads to an increase of hardware requirements. These are today:

  • CPU: 24 Cores
  • RAM: 32 GB
  • HD: 1 TB usable space in RAID

For a production environment recommended hardware is

  • CPU: 32 Cores
  • RAM: 64 GB
  • HD: 2 TB usable space in RAID

Following these recommendations, a Tufin T-510 fulfills minimum requirements only. Even if this machine has been suitable for some environments about two or three years ago, it's currently recommended to use in productive environments the appliances T-1100 or T-1100XL only.
The load on a machine can be reduced using Tufin Distributed Architecture. In this configuration, Remote Collectors and Distribution Servers take load from the Central Server. Additional licenses are not required, only additional hardware.

The "real requirements" depend not only on the number of monitored devices, but also on the size and complexity of rule bases as well as the number of logs, concurrent users etc. Please consult your Tufin SE to get more detailed information about your individual hardware requirements.

 

 

 

 

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