www.tufin.club

In a workflow the field „Manager“ can be used. This might be useful if the manager has to approve a ticket requested by a member of his team.

The requester provides the E-Mail address of his manager so this person can approve the request in the next step.It's mandatory to have in the next step a "Manager Assignment" so the decision who has to work on the ticket is flexible. Besides this, if the mail address provided by the requester isn's valid for Manager function, the E-Mail will be sent to a "Default Manager" provided in the following step. This person (named Default_Manager below) is able to approve/reject the ticket as well to reassign it.

 

If the manager gets the E-Mail from SecureChange, logging in to SecureChange is necessary. After this, working on the ticket is possible.

Having local users configured, the validity of the mail address is checked. Examples:

  • If the assigned manager has the appropriate right, approval is possible.
  • If there is no right for approval, but a link sent by E-Mail, the approval is possible for this case.
  • If the mail address isn't known in SC, Default Manager is taken.

So as a result, when this option is used with local users, everything works as designed in SecureChange.The Manager is able to approve a step even if he doesn't have "global rights by role" to do so. Having a LDAP Server connected to SecureChange, this is the result:

  • If the assigned manager has the appropriate right, approval is possible.
  • If there is no right for approval, but a link, then the approval is possible for this ticket.
  • If the mail address isn't known in SC but in LDAP, the ticket is assigned and even without being defined in SecureChange, the manager can follow the link and to approve the step.
  • If the mail address is "external", the Default Manager is taken.

Please be aware, that the MANAGER as well as the DEFAULT-MANAGER need to be known in SecureChange or LDAP Server. The MANAGER doesn't need appropriate rights in every case.

 

 

Sometimes it's necessary to have a documentation about changes at the system itself or about changes in Workflows defined in SecureChange. System changes can be documented in SecureTrack easily, but what about changes in Workflows that are defined and used in SecureChange?
Currently there is no option in the WebUI to get a report about these changes, but they are recorded in the system, i.e. in the database table change_audit.

To view the table content, a SQL query is used at the CLI of the SecureChange Server:

# psql -Upostgres securechangeworkflow -x -c " select * from change_audit"

This delivers all changes to the CLI, including the name of the user as well as a XML output of the workflow before and after. If necessary, the output can be redirected to a file, e.g. for further inspection.

 

 

 

 

On March 31, 2017, TufinOS 1.x will reach its End of Live (EOL) as CentOS 5 does. This correlation is there since TufinOS is based on CentOS. After this date, no more patches or even security related patches will be published for TufinOS 1.x. The last versions that will run on TufinOS 1.x are 16-3 and 16-4, respectively.

So it's recommended to upgrade to TufinOS 2.x before EOL of TufinOS 1.x. Tufin describes how to upgrade in their Knowledge Center. Main information given here:

  • Upgrade should be possible from TufinOS 1.22 / TOS R13-3 or above
  • If the TOS Database is smaller than 20 GB a simple backup from the old system should be made
  • There is no way to upgrade from TufinOS 1.x to TufinOS 2.x without a new installation of the system, so a new install of TufinOS 2.x is necessary
  • After having the OS installed, the same TOS version as running on the old system needs to be installed (pls. remember, the restore of a backup works only for the same build-number)
  • Then, a simple restore of the data is possible
  • After having checked that everything works, TOS should be upgraded to the latest version, too

How to find out what is running?

TufinOS: # cat /etc/redhat-release

TOS:      # tos version

 

 

 

 

The latest version of Tufin Orchestration Suite (TOS) is now 16-3. This GA Version delivers some improvements for its software parts, e.g.

Cloud:

  • AWS Security Groups are automatically recommended per required access
  • Changes are automatically verified per required access

Security Change Automation:

  • New Role in SecureChange allowing "Assign tickets to any handler"
  • "Modify Group" allows adding/removing IP ranges now
  • Designer suggestion is shown in Policy Context, i.e. suggested changes are shown in existing policy
  • Palo Alto Networks Panorama Device Group Policy Automation
    • Automatic selection of Device Group per required access
    • Automatic risk/compliance Analysis
    • Automatic Change Design and Provisioning incl. AppID
    • Automatic verification after changes
  • REST API allows now to export Designer results
  • Designer CLI

Security and Compliance:

  • Rule Documentation (Policy Browser) now allows to search for disabled rules
  • Palo Alto Networks Panorama Device Group integraion
    • Changes are tracked and monitored
    • Full visibility into Panorama Device Group hierarchy
    • Full intetration into Policy Browser (including rule usage information)
    • Cleanup support
    • Integration into SecureTrack Unified Security Policies
    • Reports are possible
    • Support of Tufin SeureTrack Topology
    • SecureApp connection status monitoring (currently not for AppID)

Application Management:

  • Introduction of application-centric User Permissions

Devices and Platforms:

  • Juniper: Topology Support for Virtual Routers in SRX Routes
  • Fortinet: Support of FortiManager 5.4.1
  • VMware: Support of NSX 6.2.4
  • F5: F5 12-1 is supported by TOS, but no iApps
  • Cisco: Support of ASA

 

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

 

 

Tufin has released a Security Announcement regarding "Dirty COW" (CVE-2016-5195)

Background:

A race condition has been found in the way the Linux kernel's memory subsystem handles the copy-on-write (COW) breakage of private read-only memory mappings.
An unprivileged, local user could use this flaw to gain write access to otherwise read-only memory mappings, and thus increase their privileges on the system.

Vulnerable Systems:

All versions of TufinOS are affected: TufinOS 1.8 - 1.22 as well as 2.00 - 2.12
Installations using Red Hat Enterprise Linux and CentOS are affected also. Please find a patch on the website of the Linux distribution itself.

Remediation:

Tufin will publish a fix for TufinOS 2.12 on November, 2nd. A fix for TufinOS 1.22 will be published after Red Hat has published a fix for RHEL 5.
If you are not running the latest version of TufinOS, you should upgrade to be able to install the fix.

 

Update (20161102):

The fix for TufinOS 2.x is included in TufinOS 2.13 which is available since November, 1st.
A patch for TufinOS 2.12 will be released on November, 6th. This is relevant if an update to TufinOS 2.13 isn't possilble.

Update (20161104):

The fix for TufinOS 1.x is included in TufinOS 1.23 which is available since November, 4th. An upgrade to this version is recommended if still TufinOS 1.x is used.
Please be aware that TufinOS 1.x reaches its End of Live (EOL) on March 31st, 2017 - as CentOS 5 does. After this date, no updates or security patches will be created for TufinOS 1.x, so upgrading to TufinOS 2.x before this date is recommended.

 

 

 

Bug in TOS if SecureChange is run in HA mode

Tufin points out a potential vulnerability in Tufin Orchestration Suite (TOS) if SecureChange is run as a cluster. It might happen that MongoDB provides a simple HTTP interface that might be accessable from external sources. This could deliver information to external persons.

 

Affected are only HA deployments running SecureChange R15-3 or higher. Clusters running SecureTrack only aren't affected as standalone installations of SecureChange are. A fix will be included in R16-2 HF4, R16-3 GA and R16-4 RC1 and above. If you run an elder version not being able to upgrade, you will need to check the configuration of your HA installation of SecureChange.

 

To address this issue, just edit the configuration of MongoDB on the systems:

  1. Backup the original file /etc/mongod.conf
  2. Edit the file /etc/mongod.conf and add this option at the end of the file:
       nohttpinterface = true
  3. Save the file with your changes
  4. Restart the MongoDB service using
       # service mongod restart

Tufin states that this change won't interfere with the performance, stability, or functionality of TOS.