www.tufin.club

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...

AERAsec is proud to announce that we are the first Tufin Service Delivery Partner + (SDP+) in Germany

Tufin has announced that its Service Delivery Partner Plus (SDP+) training program has introduced a new developer course to its 2020 portfolio. Designed to fill industry gaps, the course delivers training and development opportunities in key areas such as Tufin APIs, integrations, customizations, and development techniques.

AERAsec is proud to be the first SDP+ partner in Germany (press release in German language) after being one of the first SDP partners worldwide. So we can deliver now even more value to our customers due to the ability to officially deliver customizations of the Tufin Orchestration Suite. So customers will have additional value not only from AERAsec's experience but also from very intense cooperation between AERAsec and Tufin.

Customers purchasing Tufin products from AERAsec will have an additional advantage because of special conditions regarding these services. Please This email address is being protected from spambots. You need JavaScript enabled to view it. if you want to know more about AERAsec delivering Tufin Products and Services.

In many situations, Firewalls not have their "productive" interfaces only, but also others like e.g. Management Interfaces. If this is the case and many Firewalls are connected not only via "productive" interfaces but also via Management Interfaces, some problems might arise. One could occur when SecureTrack Topology is used to check the path a packet takes. Even if it's not the case in real life, Topology could consider the shortest way using the Management Network... As a consequence, the Designer of SecureChange could also assume this path - and the result isn't as expected.

So in many cases, it seems to be useful to ignore single interfaces in SecureTrack Topology. This can be done quite easily, but it needs to be done very carefully and well documented (!).

Please don't continue before you have made a backup of your data!

To find out the relevant device, you first need its Management ID in Tufin SecureTrack. If it's a directly monitored Firewall (e.g. Cisco ASA, FortiGate without FortiManager or directly monitored Check Point Firewall Module) the Management ID can be found in Menu > Compare. Go to the left pane called "Monitored Devices" and press "t". The Management ID shows up beside the name of the device. In the screenshot shown below, Firewall modules have the Management ID 290 and 294, respectively.

If only the Management is listed here, another step is necessary because here only the ID of the Management is shown.

In this case, you need to go to Menu > Settings > Administration > Licenses. Here you scroll down to the section called "Devices", click into it, and press "t". The Management IDs of all Devices will be shown here.

Next is to find which interface shal be ignored by Tufin Topology. You can obtain this information from SecureTrack or directly from the device. 
To have an example, we will ignore the Interface "Mgmt" of the device with ID 290 and IP address 192.168.1.1 from Topology.

This information needs to be stored in the database. You can do this using the REST API or directly via CLI. In this example, we use CLI for modification of the table "ignored_interfaces".
To get a list of all currently "ignored_interfaces" this command should be used:

[root@TufinOS ~]# psql -Upostgres securetrack -xc "select * from topology_ignored_interfaces"
-[ RECORD 1 ]--+-----------------
interface_name | ethernet1/1
mgmt_id        | 2
ip             | 0.0.0.0
[root@TufinOS ~]#

To add an interface to this list, be sure to have the Management ID of the device as well as the name of the interface and its IP address. Then it can be added to this table using

[root@TufinOS ~]# psql -Upostgres securetrack -xc "insert into topology_ignored_interfaces (interface_name, mgmt_id, ip) values ('Mgmt','290','192.168.1.1')"

After having done so, this interface is listed in the table and therefore ignored by SecureTrack Topology - after a Sync of the Topology (!).
(The IP address can also be left out, then it later shows "0.0.0.0")

[root@TufinOS ~]# psql -Upostgres securetrack -xc "select * from topology_ignored_interfaces"
-[ RECORD 1 ]--+-----------------
interface_name | ethernet1/1
mgmt_id        | 2
ip             | 0.0.0.0
-[ RECORD 2 ]--+-----------------
interface_name | Mgmt
mgmt_id        | 290
ip             | 192.168.1.1
[root@TufinOS ~]#

If you look at the device in the Topology, this interface isn't listed here any more.
To remove an interface from this list and to get it back into Topology, just take the command

[root@TufinOS ~]# psql -Upostgres securetrack -xc "delete from topology_ignored_interfaces where interface_name='Mgmt' and mgmt_id='290'"

To make this change effective, don't forget to Synchronize the Topology again.