www.tufin.club

Tufin has released TOS R21-1, the first version of the Tufin Orchestration Suite of 2021.

Please be aware that TOS 21-1 requires TufinOS 3.x, CentOS 7, or RHEL 7.

TOS 21-1 is available as GA and can be downloaded from the Tufin Portal (login required). It delivers improvements, e.g.

Change Automation and Orchestration

  • SecureChange can be integrated with SecureCloud now. Automated workflows that include Azure devices can be configured. Importing Azure ASG (Application Security Groups) is possible and therefore using automation tools of SecureChange (e.g. Auto-suggest target, Provisioning) is possible. Designer and Verifier can be used for on-prem devices.
  • When provisioning changes, the Designer of SecureChange used in an Access Request workflow can consider related tickets that might have an impact on the update. Related tickets can be considered when a redesign is done. 
  • The Interactive Map of SecureTrack now allows to add/modify generic devices such as L2 firewalls, generic interfaces, and generic VPN by right-clicking on the mouse.
  • The Interactive Map also supports IPv6 path analysis for generic devices now.
  • SecureTrack Interactive Map supports using LDAP groups in Source and Destination.
  • The Interactive Map allows viewing device data and calculation of paths having Amazon AWS devices included.

Devices and Platforms

  • Amazon AWS
    For Amazon AWS devices the Interactive Map can be used to view device data and paths included in these devices.
  • Check Point
    When using Inline Layers rules configured here, can now be viewed in Policy Browser. From here, SecureChange tickets for rule modification, rule recertification, and rule decommission can be opened.
    Check Point Cloud devices in NSX-T, ACI and AWS can be included in SecureTrack.
  • Cisco
    Support for Cisco IOS-XE routers and L3 devices
  • Juniper
    Juniper SRX is now supported to have IPv6 configuration in SecureTrack Topology.
  • Fortinet
    For Fortinet FortiManager SecureTrack now offers visibility for user IDs and rules on the devices' security rules, the global level, and Adom level.
  • Palo Alto
    Using Panorama allows the use of Shared Objects now in SecureChange. The Designer can be configured to use or create shared objects as part of the automation process.

REST API

  • Error handling
    • Code for unauthorized users has been set to 403 for SecureTrack and SecureChange
    • SecureTrack returns 503 if during synchronization another graph builder is running
  • Improvements for SecureTrack
    • Check Point R80 rule numbering has been improved
    • Getting IPv6 bindings is possible now
    • Mapping zones to device interfaces can be retrieved
    • Rule recertification can now be done via API
  • Improvements for SecureChange
    • Get Security Zone for Access Requests
    • Modify Expiration Date and Reference Ticket ID
    • API returns an error if a device contains multiple objects or services with the same name
    • Import validations added for Rule Modification
    • Support of Panorama tags for Designer

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

 

 

 

 

 

When having SecureChange upgraded to TOS 20-2 and TufinOS 3.x, scripts need a unique path. If the location of a script is "somewhere" on the machine (as before), an error might be shown.

ERROR 2021-02-27 15:00:56,073
[asyncTaskExecuter-19::c.t.s.s.i.ScriptServiceImpl.runScriptAndGetResult] [user:system] Failed to run script java.lang.Exception: Path location is not valid.

To have scripts working in SecureChange, be sure that they are located only here:

/opt/tufin/data/securechange/scripts/
 
 
 
 
 

If you don't have upgraded now, you should consider not to wait too long. Reasons for upgrade are - new version with new features (ok, that's as always if a new version is released), but above all - upgrade of TufinOS to version 3.x based on CentOS 7. This is necessary because TufinOS 2.x is based on CentOS 6 which isn't supported any more since end of November 2020. Additionally, some security issues have been found in CentOS that are fixed inTufinOS 3.x, but will not be fixed for TufinOS 2.x due to EOL. So also this is a reason for upgrading soon.

All information about the upgrade can be found in the Tufin Portal.

 

Requirements for upgrading to TOS 20-2 and TufinOS 3.x are

  • TufinOS 2.21 or higher, or RHEL/CentOS 6
  • TOS R20-1 or R19-3 (any specific HF)
  • Postgres 11 (and not PostgreSQL 9.0 or 9.4)
    This upgrade is mostly done when upgrading to TufinOS 2.21

Be sure that the new server you will install the latest version of TufinOS has at least 500 GB Hard Disk and 16 GB RAM (even for lab installations). Both parameters are checked during the installation of TufinOS. Installation will stop when these requirements are not fulfilled. Anyway, you shold consider the hardware requirements published by Tufin when setting up a new server.

Before beginning the upgrade you need a new machine besides the existing machine. TufinOS as well as TOS will be installed on this new machine. Your configuration as well as data need to be copied to this machine also. Later on you can turn off the old server and change the IP addresses of the new server to the addresses of the old one.
If you don't have a new machine, you need a new hard disk that is going to be mounted to the existing server. All data are saved to this mount point, so they are available afterwards.

 

It's recommended that you follow the "Upgrade Assistance" published by Tufin. It's recommended to download an Upgrade Planner Application that needs to be exectured on each server any component of TOS is running on. Resullt of the execution is a JSON file with all relevant information about this specific installation. Throwing this file into the field of the page mentioned before will guide you to the correct and recommended upgrade procedure.

It's also possible to get upgrade information directly without running the Planner Application or other scripts. It's important to distinguish between the different installation types, e.g. "standalone", "with Distributed Archtecture" or "with High Availability Cluster". The recommended way is to use the Upgrade Assistant since in this case all information is transferred. It's the most safe way to upgrade. If you don't like it, you can also upgrade manually.

 

 

 

Tufin has released TOS R20-2, the second version of the Tufin Orchestration Suite of 2020.

Please be aware that TOS 20-2 requires TufinOS 3.x, CentOS 7, or RHEL 7. This has been pointed out before. More information about this process to be published here.

So a direct upgrade isn't possible. It's necessary to upgrade/reinstall the Operating System itself. This isn't the move to TOS 2.0, the new version Tufin is talking about a lot. TOS 2.0 is currently available for SecureTrack only. Upgrade tools point customers using SecureTrack only to this new version. If you upgrade, please consider the hardware requirements Tufin has published for the "old" TOS as well as for the "new" TOS.

TOS 20-2 is available as GA, delivering some improvements, e.g.

Change Automation and Orchestration

  • SecureChange offers "ticket references". So tickets can be combined and/or referenced. This might be useful if e.g. a rule is decertified and in the next step a Rule Decommissioning should start. Here, a link can be placed, showing to the first ticket.
  • When in a SecureChange Access Request "Risk Analysis" is done, only USPs in SecureTrack could be considered. Now, also results of an External Risk Analysis can be considered and shown to the corresponding user.

Security, Risk, and Compliance

  • The integration of Transparent Firewalls (working on layer 2 in bridge mode) needed extra tools. Now, they can be added using the WebUI of SecureTrack.
  • If a path is found in SecureTrack Interactive Map, the result can now be exported in a PDF file. This file includes all relevant information about devices involved, including corresponding rules. So here is more information as it is shown via a REST API call.
  • Searches in SecureTrack Interactive Map allow more than eight results now.

Devices and Platforms

  • Check Point - improvement of Rule Numbering when monitoring a CMA with Global Policies.
  • Cisco ACI - SecureTrack Path Analysis for simulation of paths to external IP addresses traveling via specific EPGs is possible now.
  • Fortinet - Support of IPv6 Path Analysis in SecureTrack Interactive Map, FQDN Object Automation in SecureChange and possibility for Global Level configuration. The last two points require a FortiManager.
  • Microsoft Azure - Support of SecureTrack Interactive Map
  • Palo Alto Networks Panorama - Besides predefined applications now also custom applications can be used in SecureChange Automation. Improvements for Device Monitoring are included as well as the possibility to add Panorama tags to new rules.
  • Support of additional devices and versions:
    • Check Point R80.40 (Check Point Management API v1.5 and v1.6)
    • Cisco ACI 4.2
    • Juniper SRX 19.4
    • Palo Alto PanOS 9.1
    • VMware NSX-T 2.5 and 3.0

REST API

  • Error Code For Unauthorized Users Changed to 403
  • Rule Numbering Enhancement for Check Point R80 Devices
  • Get IPV6 Binding
  • Get zone to interface mapping
  • Synchronize Topology Model API Enhancement
  • Rule Recertification - Update the Certification Status of SecureTrack Rules
  • Network Object and Service Name Verification
  • GET Security Zone for Access Requests
  • Panorama supported for Designer APIs
  • Expiration Date and Reference Ticket ID Can Be Modified
  • Input Validations Added to Rule Modification Fields

 

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

 

 

 

 

 

TufinOS 2.x is based on CentOS 6.x. For this version support has reached its EOL (End of Life), so no more support for CentOS 6.10 and below is provided, not even security patches. Therefore Tufin has published TufinOS 3.x, based on CentOS 7 that will be supported until June 30th, 2024.

Besides this, if you want to upgrade to TOS 20-2 you need to upgrade TufinOS also.

So please prepare this upgrade carefully. Some information about it can be found on Tufin's web site, later on we will also provide some information.

 

 

 

In SecureTrack it's possible to mark rules as "legacy" or "stealth" in the Rule Metadata shown in the Policy Browser. Marking a rule is also relevant for decisions and/or results of the Designer and Verifier in SecureChange.
To mark a rule, SecureTrack needs to be opened. Then go to Menu > Home > Policy Browser and select a device. After this, mark the rule that shall become a "legacy rule" or a "stealth rule".

The selected rule is shown with a yellow background afterwards. At the top right, a pen is shown. A click on this pen opens a window that allows to edit the metadata of this rule.

In this window, under "advanced options" the rule can be marked as "legacy" (rule action: accept) or "stealth" rule (rule action: drop/deny). To put this information into the rule metadata, "save" needs to be clicked at the bottom of the window.
These are the consequences:

Legacy Rule

In most cases, a rule accepting traffic is marked as "legacy" when it's too open, e.g. allowing every service. In a SecureChange Access Request, the Designer finds usually out that the traffic using even an exotic protocol is allowed due to this rule. If it's marked as "legacy" rule, it's treated as shadowed rule and the Designer puts a new rule above the marked rule. The Verifier of SecureChange also ignores the rule marked as "legacy" rule, i.e. even if every service is allowed it will state that it's not because this rule is ignored from the Verifier. 

Stealth Rule

A rule denying traffic marked as stealth rule is usually protecting a firewall gateway because every access from anywhere to this gateway is forbidden by this rule. Each allowed traffic destined to the gateway itself needs to be placed above the stealth rule. The stealth rule usually is located in the top part of a rule base.

 

Consequences for SecureChange Designer

The Designer considers this kind of rating a rule. If a rule marked as "legacy" would match the traffic, the Designer must not consider this rule for traffic, so above the "legacy" rule a new rule is suggested. This behavior is correct, even if the requested traffic is allowed by the other rule.

If a rule is marked as "stealth" rule, all suggested new rules for accepting traffic are located below it.

 

Possible problem

If rules marked as "legacy" and "stealth" in a rule base, a problem might occur if a rule marked as "stealth" is below a rule marked as "legacy". An example would be rule 6 as a "legacy" rule and rule 25 as a "stealth" rule. In this case the Designer of SecureChange states

"No suggestion available: Cannot determine correct location for a new rule when the requested traffic intersects a legacy rule which is included in the stealth section"

 If you get this error message, keep an extra eye on "legacy" and "stealth" rules...