www.tufin.club

Many thanks to Tufin for awarding AERAsec at the Annual Partner Summit as

Tufin 2022 Best SDP+ Partner of the Year for the EMEA region

After more than 15 years of successful cooperation with Tufin, the AERAsec team is proud to receive this award.

When working with Workflows in Tufin SecureChange, it's sometimes useful to skip a specific step. To configure this for a step in the Workflow, go to "Assignments" and select the option "Skip this step if:" Several conditions can be added and combined with AND or OR. A mixture is not possible (e.g. (a AND b) or c).

The example above has a Skip Condition with combined parameters. The step will be skipped if

• the Check Box "Important access for me" is checked (e.g. in step 1)
  AND
• the service is NOT http (tcp 80)
  AND
• the Risk Status of all access requests is "No risk"

This condition works perfectly for a single Access Request.

BUT

If there is more than one Access Request in a ticket, the Skip Condition is evaluated for each Access Request. The suggested behavior has been that if each Access Request fulfills the Skip Condition, the step is skipped - and vice versa: If any Access Request does not fulfill the condition, the skip will not be skipped. This is wrong (!)

Lesson Learned

Tufin Support has clarified the behavior: "For tickets containing multiple access requests, the step will be skipped if the condition is met in any one of them unless the condition selected specifically states that it applies to all access requests."

So if only one Access Request within the ticket fulfills the Skip Condition, the step will be skipped - regardless of all other Access Requests.

The condition applies to all Access Requests only for "Risk Status", "Target", "Destination", "Verification Status". So only for these four conditions the behavior is as expected above.

SecureTrack has two kinds of users: "Administrator" and "User".
An "Administrator" has access to every part of SecureTrack, also to SecureTrack Topology. The permissions of this user cannot be restricted.

In TOS Classic a "User" had the possibility to access SecureTrack Topology. The requirement was that this user has permission to view "all devices". In this case, Topolgy has been shown and could be used. For sure, when a new device has been added, the permission of the user needed to be updated (because otherwise the requirement for accessing the Topology was not fulfilled).

The access to the Topology for users has been classified by Tufin as a "security flaw". Therefore, in TOS Aurora there is no possibility for a "User" to access the Topology. If this access is needed, the permissions need to be extended to "Administrator" (with all consequences). If only some information is needed, a user is able to use the API for calling specific information from the Topology. Examples of this API access are shown here:
https://forum.tufin.com/support/kc/rest-api/R22-2P/securetrack/apidoc/#!/Network_Topology/getPathCalc
https://forum.tufin.com/support/kc/rest-api/R22-2P/securetrack/apidoc/#!/Network_Topology/getPathCalcImage

A very useful feature of Tufin SecureChange is the possibility to have an automatic target selection in Access Request workflows. Quite often, the first step of an Access Request ticket doesn't require the requester to fill in the necessary targets. Just Source and Destination as well as Service are needed for opening a ticket. In the next step, the corresponding targets are often calculated automatically for further use, e.g. by the Designer or Verifier. These tools rely on the results of the values configured in "Targets" - independently if they are filled in manually or by Automatic Target selection.
The automatic selection works perfectly for Access Requests with one Source and one Destination.

AR with one Source and one Destination - working path

For the first request below a target can be found because the path can be found in the SecureTrack Topology. This behavior is as expected.

AR with one Source and one Destination - not working path

The second request is not in SecureTrack Topology, therefore neither a path nor a target can be found. This behavior is also as expected.

AR with a "mixed condition" for Source and Destination

If now both cases are mixed within one Access Request, Tufin only finds the targets of the first example, not pointing out that for the second option, no Targets have been found. Only the found Targets are filled into the field - without any hint that not all connections have been found within SecureTrack Topology.

Conclusion

Following Tufin Support, this behavior is "as designed" - "an "Access Request that has partial targets, i.e. some targets are found, but not all” is expected by the product design to only show what is possible and not indicate what paths failed"
There are (manual) workarounds possible, but currently, no out-of-the-box solution for Automatic Target Selection is available.
Esp. if there are complex Access Requests (as they occur in real life), this fact needs to be considered.
If you need further information, please contact us by E-Mail: tufin-support at aerasec dot de.

Update 2023-07-04

This issue is resolved in R23-1 GA. A new flag can be enabled via configuration. It generates a notification in the "target suggestion phase".
The flag is called "TOPOLOGY_SHALL_CALCULATE_UNROUTED_TRAFFIC" and it has three levels:
- 'enabled' - calculate and display unrouted elements in path API and path finder(Map)
- 'enabled_restrict' - calculate and display unrouted elements in path API, path finder(Map) and suggest target failure
- 'disabled' - don't calculate unrouted elements in any tool

Since TOS Aurora 22-1, there is an option to use a Single Sign On (SSO) for SecureTrack and SecureChange / SecureApp. In new installations, this feature is enabled by default, but in upgraded installations, this feature needs to be enabled manually. This is quite easy, following Tufin Knowledge Base. If SSO is turned on, there is no additional authentication required if a user changes from e.g. SecureTrack to SecureChange.

Enable SSO

To activate SSO access to the command line is necessary. Additionally, administrative permissions are needed (e.g. root or the use of sudo). This command enables SSO:

[Tufin]$ sudo tos config set -p tos.sso.enabled=true

After this action, SSO is active and the login screen shows "Tufin Orchestration Suite".

Sometimes it's useful, to disable SSO (see below).

Disable SSO

Disabling the optional SSO is done using this command with administrative permissions at the CLI (e.g. root or the use of sudo):

[Tufin]$ sudo tos config set -p tos.sso.enabled=false

After this command, a separate login screen is shown for SecureTrack and/or SecureChange - as it has been before for many years.

Items to consider when using SSO for SecureTrack and SecureChange

• The login using the portal shown above requires the user to be configured in SecureTrack.
  If a user is configured in SecureChange only (e.g. Approver, Auditor), a successful login is not possible.
  So these users need to be configured in SecureTrack also (but don't need any permission to view any device).
  
  
• If a disclaimer is required, there is only one possibility to configure it (see also here).
  
  
• If external Servers for authentication are used, please be aware of which server is needed and where users need to be configured. (Special AD branches for user/admin used in SecureTrack vs. separate LDAP authentication in SecureChange).
  
  
• The "old" SSO option for SecureChange is no more supported if SSO for SecureTrack/SecureChange is configured.
  So if a portal is used for SecureChange authentication, this needs to be migrated to use SAML-based authentication.
  
  > added May, 30th, 2023:
  If you want to use SAML, please consider that there is no support for integration with SAML IDP IBM.