www.tufin.club

Tufin has officially released TOS R25-2. It's the second and final version of the Tufin Orchestration Suite of 2025. 
TOS R25-2 is available as GA and can be downloaded from the Tufin Portal (authentication required).
Some improvements of TOS R25-2:

Change Monitoring, Automation, and Orchestration

• SecureTrack
  Legacy reports in SecureTrack now use a 64-bit process, delivering better performance esp. for devices with a large number of rules and objects
  
  
• SecureTrack
  A Rule Optimizer allows to deliver hints how to tighten the rule base, based on real-time traffic logs, for AWS, Azure NSGs and Zscaler ZIA
  
  
• SecureTrack
  The Topology Map now supports generic policy-based routing (PBR) in the Path Analysis. PBR rules of monitored devices can be defined, edited, monitored and mapped. 
  
  
• SecureChange
  The Rule Recertification Workflow has got some improvements, including a better UI and certification history
  
  
• SecureChange
  The Designer now has a new interface for Access Requests involving changes on OPM devices, Azure NSGs, Azure firewalls, Zscaler ZIA, Huawei, Versa and others
  
  

Devices and Platforms

• TufinOS
  TufinOS is now available as an Amazon Machine Image (AMI) in the AWS Marketplace
  
  
• Azure
  Starting with R25-2 PHF1, Microsoft Azure Subscriptions for a given Tenant can be onboarded very simple, allowing Azure Subscriptions to be managed and monitored in an easy way
  
  
• Azure
  Starting with R25-2 PHF2, Azure VNET is going to be imported automatically, enabled for individual subscriptions
  
  
• Azure and OPM devices
  Change automation is possible for access requests involving Azure NSGs and OPM devices
  
  
• AWS
  Management of AWS accounts at organizational level is possible now, also automatically
  
  
• Cisco
  Cisco ACI endpoint security groups (ESGs) are supported now in object and contract comparisons, change tracking, and ESG-based path analysis in the Topology Map
  
  
• Cisco
  For Cisco FMC Tos now takes AppID and URL category into account, improving also path analysis
  
  
• Cloud
  Checking compliance with USPs is now also possible for AWS, GCP and Azure network security groups installed on a NIC
  
  
• Palo Alto
  Palo Alto Networks external dynamic lists (PAN EDLs) are supported now, alloing e.g. filtering by IP in the Rule Viewer
  
  
• Zscaler
  Zscaler ZIA is now integrated into SecureChange, allowing automatic Target selection in Access Requests as well as Risk Analysis and the use of Designer and Verifier
  
  

Administration

• Installation 
  When installing TufinOS on VMware ESXi, the disk setup considers the separation of ETCD as part of the configuration workflow
  
  
• Updates
  When installing a patch, from now on it isn't necessarily the complete package that is installed. Tufin has optimized TOS for being able to receive (smaller) hotfixes also
  
  
• Remote Collector
  From now on, Remote Collectors automatically recover after disaster recovery switchover and restore of the central cluster
  
  

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

Running the Tufin Orchestration Suite (TOS) not only means to have a system running Linux, but also a Kubernetes Cluster is running on the system. If a system restart is necessary, it's not sufficient to simply enter the "reboot" command at the command line. Even if a snapshot needs to be created from a virtual machine, measures must be taken beforehand—otherwise, a snapshot might be available, but it will not be suitable for restoring the system. 

To shut down the system running TOS these steps should be taken: 

• Stop TOS and wait for the message that TOS has been stopped
  # tos stop -d 
  
  
• The Pods are still terminating, wait until all Pods have been stopped successfully, then resume the command using Ctrl-C
  # watch kubectl get pods
  
  
• The Kubernetes Cluster should also be stopped and disabled
  # systemctl stop k3s.service
  # systemctl disable k3s.service
  
  
• The result should be checked using the commands
  # systemctl is-active k3s
  # systemctl is-enabled k3s

Now it's safe to shutdown or restart the system. Creating a snapshot is now also possible safely.
After a restart or restore of the system, neither k3s nor tos will start automatically.
This might be uncomfortable, but it should be done this way. If not, problems migth arise due to open data bases, open files, etc. 

To start the system, these steps should be carried out: 

• Start, enable and check k3s Service. This needs to be done first since TOS requires a running Kubernetes Cluster
  # systemctl start k3s.service
  # systemctl enable k3s.service
  # systemctl is-enabled k3s.service
  # systemctl status k3s.service
  
  
•  Start TOS and wait for the message that TOS has been started successfully
  # tos start -d 
  
  
• The Pods are still starting even if the command states that the start has been successully done.
  Check that all Pods have been started, leave the command afterwards using CTRL-C
  # watch kubectl get pods

This method appears to be complex, but it's recommended regarding data security and keep the system running without issues. 

For administration of Tufin SecureTrack and Tufin SecureChange you need at least one administrative account. This account must not be lost and the password must not be forgotten. If it is forgotten, there is a way to reset the admin account if CLI access is possible as root.

SecureChange / SecureApp

It's not possible to create a new user, so a reset of the user "admin" is done. Resetting the admin account requires access to the correct pod in the Kubernetes Cluster. You need to enter the pod, then use a command and leave the pod afterwards: 

# kubectl exec -it deploy/sc-server -- bash
pod$> scw reset-admin
pod$> exit
# 

This procedure resets the admin account to the password "admin", so access with admin/admin ist possible. For sure, the password admin needs to be changed at the next login.

SecureTrack

The procedure shown for SecureChange doesn't work for SecureTrack. But there is a command that will allow you to define a new local (administrative) user. As before, you need to configure it via the correct pod. After calling the command, the needed information is requested by the system. 

# kubectl exec -it deploy/keycloak-service -c keycloak-service -- manage_keycloak -r add_st_admin_user
Username: <user>
Password: <pass>
Confirm Password: <pass>
Admin user <user> is added.
#

After having finished the command, a new user with permissions "administrator" is known in SecureTrack. As usual, the system requires a password change at the first login. 
It's not reasonable to add a person with the permissions of "user" to the system, because it's possible with the newly created admin user after login. 

Usually, the Tufin Orchestration Suite (TOS) is going to be installed on TufinOS. In virtualized environments, TufinOS requires VMware ESXi as basis. 
Some companies don't continue using VMware, they are switching to Proxmox. This environment is not supported by TufinOS, so the installation of Rocky Linux is necessary to have an OS for TOS. This combination is supported by Tufin.

In Rocky Linux, the sudo environment is not enforced as it is when installing TufinOS. This is a problem if a Tufin Extension like e.g. Rule Lifecycle Mangement (RLM) is going to be installed. 
The routine installing the Extension states errors like e.g. "kubectl - command not found" or "tos - command not found" - even if TOS is installed and working correctly, i.e. these commands work when using them at the command line as root. 

The reason for this behavior: using "sudo" is hardcoded in the code of the Extensions. If it's not configured, the script doesn't work.

If the installation is done at the console with the permissions of root, editing the Extension might help. 
Open the Extension using e.g. vi / vim and remove all "sudo" references in commands. So if there is the command
   "sudo kubectl" 
replace it with a simple "kubectl". Doing the same procedure for "sudo tos" and saving the file allows an installation without this kind of error. 

The Tufin Orchestration Suite (TOS) provides the option to use a multi-domain management in SecureTrack as well as in SecureChange. This is useful e.g. when there are several companies or parts of a big enterprise using the same TOS instance. Some hints about it below. 

SecureTrack

Introducing Domains in SecureTrack is quite easy. In SecureTrack you go in the menu to "Monitoring - Domains" to define one or more domains. After this, managed devices can be assigned to different domains. Users as well as administators can be restricted to see only domains they are allowed to. 

Hints: 

• Domains can be changed later, as well as the membership of a device. 
• Users / Administrators might get their permissions per domain. 
• Users cannot see the Map / Topology in multi-domain mode, even if they have the permission to view all devices in all domains (!)
  If this is needed, the multi-domain mode needs to be switched back to single-domain mode
  • Remove all devices from any domain, except default domain
  • Go to https://<securetrackVIP>/stcgitest.htm
  • Fetch the configuration using the link "Configuration - EditStConf - Fetch Current Conf"
  • Change the parameter <is_mssp>1</is_mssp> to <is_mssp>0</is_mssp>
  • Save the change by pressing "Submit New Conf" at the bottom of the page

SecureChange

If you have configured domains in SecureTrack, there is an option to use them in SecureChange, too. There are two options for domains in SecureChange that can be configured via the menu "Settings - Multi Domains". Please read the text below before clicking an option (!)

• Segregated domains
  Users are restricted to see only devices ot the domain(s) as configured in SecureTrack. In SecureChange there are additional restrictions: Ticket Handlers have to be in the same domain as the Requester who created the ticket - also only targets and objects of this domain can be seen. Addtionally, Target Suggestion, Designer, and Verifier can analyze access requests only within this domain. 
• Interconnected domains
  The restrictions shown above are not present, so Target Suggestion, Designer, and Verifier to analyze access requests across domains (same as the default "none"). In this configuration, the "Clone Network Object Policy Workflow" is not supported. 

When considering to configure domains in SecureChange, lease beware of the fact that a change of this selection is not possible (!)