- Category: Version update
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.
- Category: Version update
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
- 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
- Category: TufinOS
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.
- Category: Basics
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:
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.
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.
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...
Page 2 of 17