- Category: Version update
Tufin has released the latest version of the Tufin Orchestration Suite. So TOS 17-3 is available in its GA version, delivering some improvements, e.g.
- SecureChange with end-to-end Automation Support for VMware NSX
- SecureTrack with Enhanced Cisco ACI Support
- License visibility is given now
Security Policy Change Automation and Orchestration
- Integration of Check Point Identity Awareness Blade Support for Policy Change Automation
- Enhancements for "Modify Group" workflow, e.g. support of creating new groups and not modify existing only
- Rule Decommission Automation for Juniper SRX
Security, Risk, and Compliance
- Policy Browser Search Enhancements
- Interactive Map Enhancements
Devices and Platforms
- FortiManager Support Enhancements
- Cisco Firepower Enhancements
- Support of new devices / versions:
- BlueCoat - SGOS 220.127.116.11
- Cisco - ASA 9.7
- Cisco - CSM 4.12
- Forcepoint - SMC 6.3
- Fortinet - FortiGate 5.6
- Fortinet - FortiManager 5.6
- Juniper - M/MX 13.3 R10.2, 16.1 R4
- VMware - NSX 6.3.3
- VMware - vCenter 6.5
- API Support for Check Point R80 Identity Awareness
- New Network Topology APIs
- New Cloud Topology APIs
- Enhanced Rule Search
- Authentication using TACACS via REST API
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: SecureTrack
When using Check Point Management R80.x besides the "normal" OPSEC connections a connect to the Check Point Management API is necessary.
How to connect Tufin SecureTrack with Check Point Management R80 is described here.
Even if the connection to the Check Point Management is ok, an error might be displayed:
Checkpoint API client error
Testing the connection from SecureTrack using
Menu > Settings > Monitoring > Check Point Management R80 > Test Connectivity
seems successful, but the status icon of the device is yellow in SecureTrack. In Menu > Settings > Administration > Status > Check Point Management R80 > Status the error is shown and no new revisions are imported to SecureTrack.
Background information: "Test Connectivity" checks currently the OPSEC channel (used in R77.x) only. The second channel is the Management API which is necessary when monitoring R80.x.
Some troubleshooting might solve this issue. You can try one or more of the following things before restart monitoring the device:
- Check that the Check Point Management monitored is really Version R80.x and not still Check Point R77.30. If that's the case, the device needs to be deleted and new defined as Check Point Management R77.30. There is no way to change the Check Point Version from R80.x back to the old one.
- Check that Tufin SecureTrack is able to connect to Check Point management Server using port 443/tcp. Maybe a Firewall is blocking this traffic.
- Check the credentials configured for the Tufin user at the Check Point Management Server.
- Check the permissions of the Tufin user at the Check Point Management Server. This user needs rw even if there is no provisioning configured or planned.
- Check the Expiration Date of the account, sometimes it's not the default value ending in 2030.
- If all these measures don't help, try to restart the Management API at the Check Point Management Server. This can be done as "expert" using the command api restart.
If you have further ideas or if these items didn't help, please don't hesitate to contact us.
- Category: TufinOS
Since some time many news have been published about Meltdown and Spectre. Exploiting these vulnerabilities might allow an unprivileged attacker to bypass conventional memory security restrictions in order to gain read access to privileged memory that would otherwise be inaccessible. Further information about these vulnerabilities can be found e.g. here:
Tufin has published a Security Advisory regarding this topic.
These versions TufinOS is affected by these vulnerabilities: TufinOS 1.8 - 1.23 as well as TufinOS 2.0 - 2.14.
Tufin has released TufinOS 2.15 which includes the corresponding patch. It's strongly recommended to update to this version.
Information about possible performance impacts can be found here.
Since TufinOS 1.x is based on CentOS 5 it's no more supported. So no patch will be provided. Upgrading from TufinOS 1.x to TufinOS 2.15 is possible and strongly recommended.
PS: Please check Release Notes which versions of TOS are compatible with TufinOS 2.15!
- Category: SecureChange
Sometimes it seems as if not all needed options are available when defining a Workflow in Tufin SecureChange.
Since many versions of SecureChange, some templates are available that might help administrators to create Workflows:
- Access Request Template
- Group Change Template
- Generic Template
- Remove Access Template
If the requirement allows to use such a Template as basis for a new, own Workflow it's ok to use them.
If there are further requirements like e.g. Removal of a rule, a "new" Workflow should be defined.
This is done by clicking on the corresponding button (required: Correct right from Role in SecureChange, otherwise this option might not be available).
After clicking on New Workflow some basic things like Name of the Workflow needs to be configured. Besides this, the Type of Workflow is required. Please be aware that this type can’t be changed later on.
Available options are:
- Access Request
Users need this type of Workflow to request access to some hosts or networks using “Source-Destination-Service”
- Access Request & Modify Group
Besides requesting access this type allows to request a change of a group of firewall objects, e.g. a group of Hosts or Networks
A very flexible Workflow allowing e.g. the management of holidays (which isn’t the real purpose of SecureChange…)
- Modify Group
This Workflow allows to change Groups of e.g. hosts or networks defined in Firewall configuration. It’s mostly used by people having access to Firewall configuration files. Please be aware that since R17-3 also new Groups can be defined here.
- Rule Decommission
If a rule needs to be removed, this type of Workflow should be used. It’s triggered from SecureTrack > Menu > Policy Browser. Please find further information about this topic here.
- Server Decommission
For removing Servers this is the Type of Workflow that should be selected.
Be sure that you select the correct type for the Workflow you need. Please consider the fact that changing the type isn’t possible when copying a Workflow as a base for a new Workflow.
- Category: SecureChange
Decommissioning Rules is possible if Tufin SecureTrack and SecureChange are licensed and connected to a Device for which this feature is supported.
This article is about decommissioning Rules on a Check Point Management Server.
Some requirements need to be fulfilled for this task:
- Tufin TOS 17-1 or above with correct licenses
- A user in SecureTrack and SecureChange with identical login name
- A workflow for Rule Decommission
- Check Point Management Server R80 or above since this feature isn't supported for R77.x
Requirements for Check Point Management Server
Above all, the Check Point Management Server needs to be a "new one", i.e. R80 or above. This server needs to be connected to SecureTrack correctly. This means, that the Management API is working and new revisions are shown in SecureTrack. Additionally, write access to Check Point Management is necessary if provisioning is desired.
We want to remove Rule 3 from the Rule Base of the Check Point Maangement Server as shown below.
Users in SecureTrack and SecureChange
A user in SecureTrack needs to be defined having access to the data of the Check Point Management Server within SecureTrack.
In SecureChange a user with identical login credentials needs to be configured. It's required that this user has the right to "Create Change Requests" by the role assigned to him.
Workflow in SecureChange
A workflow is needed to carry out a Rule decommission. After opening a new workflow, SecureChange requires to define the purpose of it. Here, "Rule decommission" should be selected.
The workflow itself can be kept quite simple with e.g. three steps. We will not discuss "basic things" like Properties of the step or its Assignment but concentrate on the section Fields.
Now let's have a look at the steps:
1 - Rules to Remove/Disable
Insert a field of the type "Rule decommision". Besides the basic option no others are required in this step. If wanted, further fields like e.g. Business Justification might be added.
2 - Business approval
The second step should show the field "Rule decommission" and allow the Approver to see what he or she is approving... So a field "Approve/Reject" should be added, too.
3 - Technical Design and Implementation
This step also shows the field "Rule Decommision". Having provisioning licensed, the full feature can be used now. So the Designer as well as the Verifyer should be activated.
After having completed all steps, the workflow needs to be activated and saved. The part of Workflow definition is done now.
Search for rule in SecureTrack
Using the Option Menu > Home > Policy Browser allows to find the rule that shall be deleted. It can be searched by this (new) tool, also.
Clicking on the very left field of the rule (eye) opens a window showing all details, including meta data like e.g. Permissiveness, Last Hit etc.
Adding a rule to a new Ticket
If the rule is selected, it's shown with a yellow background. The option "Add to ticket" should be active as shown below.
Having clicked this button, the eye besides it shows a number - if one rule is selected only, this number is "1".
Clicking on the eye opens a window that allows to open a Change Request. The rule is shown to the user. Additionally, on the right side of the window the action needs to be proviced (Disable or Remove). A name for the Ticket is required as well as the selection of the workflow that will be used for this Ticket.
To continue select the button "Continue" at the right bottom of this page.
Now, a Ticket is opened in SecureChange which needs to be submitted for further action.
Steps in the Ticket and Provisioning of the change
After having completed the first step and having submitted the Ticket, it will be approved in the second step. The request itself is shown in this step, so the Approver knows what he or she approves.
The third step allows the Designer and Verifyer to be run.
The designer finds the rule and shows it. If Provisioning is licensed, the field "Update Policy" can be used to provision the change directly. If the change is finished, the Verifier can prove if this change has been done correctly.
Hint: Please wait using the Verifier until SecureChange has downloaded the new Revision, otherwise the Verifyer will show the message that the change hasn't been implemented.
After a successful verification, the Verifier should give a green field also.
Finally, the Check Point Management Server should be checked regarding this change. Don't forget to install the policy so the change becomes active on the Gateway.