SecureChange

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

 

 

 

When having SecureChange upgraded to TOS 20-2 and TufinOS 3.x, scripts need a unique path. If the location of a script is "somewhere" on the machine (as before), an error might be shown.

ERROR 2021-02-27 15:00:56,073
[asyncTaskExecuter-19::c.t.s.s.i.ScriptServiceImpl.runScriptAndGetResult] [user:system] Failed to run script java.lang.Exception: Path location is not valid.

To have scripts working in SecureChange, be sure that they are located only here:

/opt/tufin/data/securechange/scripts/
 
 
 
 
 

When configuring Tufin SecureChange, the corresponding SecureTrack server needs to be connected to the SecureChange server.
So in a first step an administrative user is configured in SecureTrack. This user is for a later authentication of SecureChange at SecureTrack.

  • Hint:
    Don't use reserved words like "Securechange" as username. This user won't be able to authenticate.

So if the user for SecureChange is configured, test it by logging in using the WebUI. If this works, SecureChange also will be able to authenticate.

  • Hint:
    The Authentication of SecureChange at SecureTrack is machine based. Using a certificate is currently not possible.
    So use a very strong password not known to any person for this purpose.

The next step is to log in at SecureChange with permission to configure "Settings". In the menu select "SecureTrack".

This information needs to be provided if SecureTrack isn't configured to run on the same system as SecureChange:

  1. Select "Remote host" and provide the IP address of SecureTrack, SecureChange will connect to.
  2. Provide user name and password as configured in SecureTrack.
  3. optional: "Show link to SecureTrack" - sometimes useful for admins, but maybe confusing end users working with SecureChange. It selected, the IP address configured in (1) will be linked here.
  4. Provide "Internal IP of SecureChange server" means to fill in the IP address SecureTrack uses for connections to SecureChange. This IP address will also be in the link to SecureChange shown in the login screen of SecureTrack.

For (1) as (4) a host name can be configured also, but this name needs to be resolved using DNS.

If the configuration is ready, try the button "Test connection" on the right bottom of the page. This will test the connection and deliver a result. This result can be, that an authentication error has occurred, the connection couldn't be established - or that the connection is ok. If this is the case, press "Save" and the task is finished.

  • Hint:
    The test done checks not only the connection from SecureChange to SecureTrack, but also from SecureTrack to SecureChange. So it might happen that you can connect from SecureChange to SecureTrack using 443/tcp - and the WebUI delivers a connection error. This is because maybe the back connection from SecureTrack to SecureChange isn't possible. In this case, error message might point to other reasons. So it's useful to check the back connection.

Connecting SecureChange to SecureTrack is essential, since the license is held in SecureTrack. Besides this, SecureChange uses features of SecureTrack like e.g. Zones and USP as well as the Topology.

 

 

 

Sometimes the question arises if Access Requests can consider NAT Rules also

Option 1:
End users opening an Access Request ticket are mostly not interested if NAT is necessary for ther request or not. In most cases they even won't know if NAT is neccessary. So in this case the question if NAT should be considered in the ticket is not that important.

Option 2:
An administrator knows that NAT is needed and tries to configure it in the ticket. This is possible:

Opening the object browser allows to provide IP addresses and NAT addresses

This results in a specific entry for Destination:

So everything seems ok, BUT this needs to be considered:

  • Risk Analysis doesn't use NAT information
  • Designer doesn't use NAT information
  • Verifier doesn't use NAT information

Due to these facts, it's not really recommended to use NAT in Access Request tickets.

 

 

 

 

 

 

 

The Interactive Map of Tufin SecureTrack allows to find a Path from A to B combined with a service / protocol / application.
This has the advantage that matching rules of firewalls involved are shown also.

Using earlier versions, it was very easy to select a specific service, e.g. tcp:8080
This is still stated in the (i), but when a newer version is used, the Button "Find Path" is still greyed out when some information is provided in the "Service" field.

So it seems that a search isn't possible...
Tufin has changed the use of this field, so please be sure to type "protocol:port" as needed and press <return> afterwards.
Only then the configured Service is taken by the system - and therefore only then a search in the Interactive Map is possible.

 

 

 

 

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
  • Generic
    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.

 

 

 

 

Page 2 of 4