www.tufin.club

"Redo Step" not working?

Details

Category: SecureChange

Last Updated: 28 September 2016

When a ticket is worked on, the ticket goes step for step through the workflow.
There is an option called "Redo Step" to jump back to an earlier step which will be redone then. To do so, just select the earlier step and press the "Redo Step" button.

In this example we are currently at step 5 while step 3 shall be repeated (and therefore step 4 and 5 also becuse in the repeated step a change could have be configured).
Here, in step 5 the step 3 is selected and shown (read only).

After having selected the step, press the "Redo Step"button.

So the ticket goes back in the workflow to the step selected (in this case back from step 5 to step 3).

BUT - this sometimes doesn't seem to work

In the upper example, step 2 is shown with a "skip" sign. This sign is shown if the step of the workflow has been skipped in this ticket. Due to this, a "Redo Step" can't be assigned. At the first glance, it seems to be strange that this step can't be selected, but with a second look it's quite logical. Btw - if a ticket using other conditions is going through the step, a "Redo Step" for this step can be configured later on. In this case, the "skip" sign doesn't show up in the ticket.

Lesson learned:

The option "Redo Step" can be used to go back to any step the ticket has passed before.
If a step has been skipped, going back to this step using "Redo Step" isn't possible.

Manager Approvals in SecureChange

Details

Category: SecureChange

Last Updated: 23 September 2016

How to work with the field "Manager" in Tufin SecureChange

To use this feature, first of all it needs to be defined in the workflow. To do so, in the definition of a step of the workflow select the option Add Field to let a menu open.

In the Drop Down Menu select the option Manager.

If done so, the field is shown to the user. Since it's marked as Mandatory, it will show up with a red dot. Therefore the user is required to fill this field in the step.

To have this option work, in the NEXT STEP the Assignment needs to be defined correctly. For this following step, the selection of Manager Assignment is mandatory. Since the user might provide an incorrect E-Mail Address, a "Default Manager" needs to be defined. This is a user of Tufin SecureChange. So if the E-Mail to the Manager can't be delivered, this user will get an E-Mail to work on the ticket.

Hints:

• This option can be used in multiple steps, i.e. the Manager Field can be used for the step when opening a ticket and also at a later step (additionally)
• Using the Manager Field requires the next step to be configured with "Manager Assignment"
• Even in a step that is "Manager Assigned", a (new) Manager Field can be defined and used
• If the step has "Dynamic Assignment" configured (e.g. to have different Approvers for different destination networks) the Manager Field is not supported and can't be used!

Generic Device

Details

Category: SecureTrack

Last Updated: 12 September 2016

Tufin SecureTrack offers some possibilities if a device can't be monitored directly. One of them is to define a Generic Device. Just a short explanation of this kind device and how to configure it.

Generic Device

This kind of device is defined for SecureTrack Topology only. No Monitoring, no security configuration and no logs are imported into SecureTrack. Such a device is necessary if a non monitored device is needed to correct / enhance the Network Topolgy SecureTrack is working with. As you know, that's the base for enhanced features of SecureChange and SecureApp. So it's important to let the Topology of SecureTrack show the reality regarding Networks and Routing.

Since no data is used for reports, analysis of rule bases etc. no license for such a device is necessary.

Why and how to define it? Let's assume you have a topology which isn't according with the reality. Mostly the reason is a missing device, connecting two or more networks. The topology shows like e.g.

So defining a Generic Device might help to improve the topology to show the reality.

Just create a plain ASCII file with all relevant data. Referring to the User Guide might be useful...  ;)
If you want to define a Generic Device to connect the device "firstvs" managed by "SMC-Rio" with the net 198.18.50.0/24 the plain ASCII file might look like this example:

Name, Ip, Mask, Vrf
interface1, 192.168.50.254, 255.255.255.0
interface2, 172.16.41.254, 255.255.255.0

Destination, Mask, Interface, Next-Hop, Vrf
0.0.0.0, 0.0.0.0, interface1, 198.18.50.1

Now it's time to import the file to SecureTrack. This is done in the menu option "Network > Topology > Add Generic Device".

The next step is to save the file and to wait for a moment. SecureTrack is calculating the new Topology. After finishing it, the Generic Device is shown in the SecureTrack Topology. For sure, this change will also be known in SecureChange.

So from now on, this device is known in Tufin SecureTrack Topology and also considered by the other components of the Tufin Orchestration Suite.
If there is a "big Core Device" by Cisco, no definition of all Interfaces and routes is necessary. Just an import of exported configuration data does the job. Redirect the output of

# show ip route
# show ip interface

to a file and import it as shown above. We have proved this also for very big configuration files - and it works if it's a Cisco device...  

HTTP redirect to SecureTrack using HTTPS

Details

Category: SecureTrack

Last Updated: 18 August 2016

By default, Tufin TOS runs with Apache configured to listen on port 443/tcp to accept HTTPS only. In some installations users are used to type http:// only - so a redirect might be useful. Since on machines running Tufin TOS (mostly) only this applilcation is active, the change of the apache configuration can be done globally and doesn't require things like VirtualHosts etc.

To make Tufin listen on Port 80/tcp for HTTP in cleartext and to redirect this request to Port 443/tcp to use HTTPS these steps are necessary:

- Backup your original configuration file /etc/httpd/conf/httpd.conf and keep in a safe place

- Edit the file /etc/httpd/conf/httpd.conf :

• After the line
      Listen 127.0.0.1:80
  add a new line with
     Listen <IP Address of the Tufin Server>:80
  to make the system listening on the network IP address and not on the internal IP address only
• Add the line
       RewriteEngine On
  to enable rewriting (somewhere at the end of the file)
• Add the line
       RewriteCond %{HTTPS} off
  to check if HTTPS is turned on (it should be). If so, the next line will be executed (Add this line below the rewrite line)
• Add the line
       RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
  to redirect to HTTPS on Port 443/tcp, and give a 301 Message to the browser (permanent redirect)
  (Add this line below the other two)
• Save the file

- Now it's time to restart the web server running on the system. You can do it by executing
     service httpd restart
  or by executing the command
     /etc/init.d/httpd restart

- You will need to check if there are any error messages, for sure. And - please test the configuration to be sure it works as you want

Tufin Orchestration Suite 16-2

Details

Category: Version update

Last Updated: 03 August 2016

Today, Tufin has published the second Major Release of TOS in 2016. Therefore it's called 16-2. Please find some information about changes in this version below.
This version includes some improvements, e.g.:

• Optional configuration of the user interface without Adobe Flash components
• Enhanced syslog support, up to 150k syslogs per second
• Improvements regarding Distributed Architecture

Cloud:

• Provisioning of AWS Security Groups, policy changes to AWS and built-in risk analysis checks
• Unified Security Policy for AWS

Automation:

• End-to-End Automation support for FortiManager ADOM Policies in SecureChangen, incl. Risk Analysis, Designer, Provisioning, Server Decomissioning
• Configurable Designer Suggestions regarding objects selected
• REST API allows the change of ownership of a Closed Ticket is possible now

Security and Compliance:

• Find permissive Rules using the Rule Documentation feature to optimize policies
• Rest API allows to configure Flow Exceptions in a Unified Security Policy

Devices and Platforms:

• Fortinet:
  Full support of FortiManager 5.4 using ADOM Policies
• Palo Alto:
  Support of Panorama 7.1 regarding Devices using Device Groups
• Cisco:
  Cisco CSM 4.8 and 4.9 are now certified to work with TOS
• Cisco:
  Cisco ASA 9.5 is now certified to work with TOS
• Forcepoint:
  Stonesoft 5.10 is certified to work with TOS

Changes regarding SecureTrack:

• Unitied Security Policy for AWS
• Analyzing and Optimization of Policies using Rule Permissiveness Level
• IPv6 Support for Stonesoft Devices, Definition of IPv6 Zones in Zone Manager is possible now
• Filtering of Cisco ASA passwords is possible (optional)
• Support of FortiManager 5.4 managing Devices using ADOM Policies
• Managing Devices using Device Groups in Palo Alto Panorama 7.1 is possible
• Using REST API allows to get matching rules for Unified Security Policy exceptions as well as to configure flow exceptions is the Unified Security Policy

Changes regarding SecureChange:

• Provisioning of AWS groups
• End-to-End Automation for FortiManager
• Configurable Designer Suggestions - Object Selection
• View of additional Palo Alto Network Fields
• IPv6 Support for Stonesoft Policies and for Risk Analysis in Unified Security Policies

Changes regarding SecureApp:

• View of additional Palo Alto Network Fields
• Support of FortiManager ADOMs
• IPv6 support allowing security compliance checks for violations to IPv6 Zones

Further improvements and corrections are included.

 The latest version of the Tufin Orchestration Suite can be found at the Tufin Portal: https://portal.tufin.com