SecureChange

Details
Category: SecureChange

Tufin SecureChange offers results of the Designer for Access Request (AR) Workflows e.g. where to put a new rule, including definition of objects, comments, etc. The Designer can run in one of two modes.

As shown, the base configuration is done via SecureChange > Workflows > [workflow name] > Workflow properties. Please find some remarks about these two options below.

  • Optimize policy for rule reuse
    Having this option active (default), the Designer tries to implement the changes in an existing rule, e.g. if SRC and DST are the same, but only the (new) service is not implemented yet, a change of the rule is assumed - "add Service xxx to rule yyy". This leads to a slimmer rule base, but changes cannot be found easily. So this option is useful for permanent changes and not for test situations. 

  • Create new policy rule for each access request
    This option instructs the Designer to create new rules for each access request, i.e. even if there is a rule with same SRC and DST, a new rule will be proposed. It is the exact Access Request in the ticket. An advantage of this behavior is a good overview "rules per AR", so e.g. rules for testing can easily be removed. Some characteristics need to be considered when using this mode:
    • Even if a rule allows the required access completely, the Designer recommends to create a new rule for the exact Access Request. This might lead to shadowed and / or redundant rules. When using Check Point, the policy cannot be installed any more because of the verifier results.
    • When using SecureApp, a workflow having this option enabled, cannot be selected. In this case, Application Owners need to open the AR directly in SecureChange, without any help by SecureApp.

More information about the Designer can be found in the Tufin Portal (Authentication required).

 

 

 

Details
Category: SecureChange

After upgrading to R23-1 it might happen that configured workflows have "less steps" as expected (e.g. 7 steps instead of 21). While the WebUI shows the first steps only, the XML output via API is fine and every step is still configured.

Tufin support has confirmed this behavior as a bug that will be corrected in R23-2 PGA2.00 which will be published on December, 20th. Until then, it's recommended to use the zoom function of the browser.

 

 

 

Details
Category: SecureChange

It is possible to set an Expiration Date within e.g. an Access Request Ticket in Tufin SecureChange. This Expiration Date has a default value of 180 days, i.e. half a year. To increase this time limit, access to the pod and database is necessary. The Expiration Date can be set up to a limit of 10 years. This is useful for rules that shall be valid "forever".

Please be aware that users might not be able to work with SecureChange due to a (necessary) restart of the pod

To change the maximum Expiration Date, these steps are recommended:

  • Check the currently configured time for the Expiration Date:
    # sudo kubectl exec -it stolon-keeper-0 -- psql  -h stolon-sc-svc securechangeworkflow -xc "select * from general_configuration"
    A list of value is shown. Look for an entry like this:

    -[ RECORD 1 ]-+------------------------------------

    id            | 10

    key           | expirationField.maxExpirationPeriod

    value         | 180

    default_value | 180

    If this key doesn't show up, it's useful to filter for the key using the command
    # sudo kubectl exec -it stolon-keeper-0 -- psql  -h stolon-sc-svc securechangeworkflow -xc "select * from general_configuration where key='expirationField.maxExpirationPeriod'"
    At least then the record shown above will be displayed, the relevant ID can be found out this way.

  • If the record has been found, the value for the maximal Expiration Date can be set with the command
    # sudo kubectl exec -it stolon-keeper-0 -- psql  -h stolon-sc-svc securechangeworkflow -xc "update general_configuration set value='36000' where id='10'"
    The ID needs to be adapted to the result of the step before. In this example, the time is set to approximately 10 years which is the maximum time supported by Tufin

  • After having set the time it's useful to check the entry in the database again
    # sudo kubectl exec -it stolon-keeper-0 -- psql  -h stolon-sc-svc securechangeworkflow -xc "select * from general_configuration where id='10'"
    Again, the ID is 10, as shown in the example above.

    -[ RECORD 1 ]-+------------------------------------

    id            | 10

    key           | expirationField.maxExpirationPeriod

    value         | 3600

    default_value | 180

  • In TOS Classic it was necessary to restart the Tomcat Server. In TOS Aurora, the pod needs to be deleted. Once done this, the pod will start again - using the newly set value.
    First, the exact name of the pod needs to be found using the command
    # sudo kubectl get pods | grep sc-server

    sc-server-a76994ab9-98236 3/3 Running 0 19m

    (the number shown with the pod varies, so here it's an example only). Once found, this pod should be deleted using
    # sudo kubectl delete pod sc-server-a76994ab9-98236

  • It's useful to check the restart and watch the pod coming up again
    # sudo kubectl get pods | grep sc-server
    After the successful restart of the pod, It's possible to take the new (maximum) value within tickets.

 

 

 

Details
Category: SecureChange

Sometimes it might happen that the Risk for a ticket in SecureChange cannot be calculated. The message is:
SecureTrack is not responding because of either an internal error it had or broken connectivity. Check your SecureTrack settings, and if the problem persists contact Tufin support.

It's obvious that SecureChange cannot contact SecureTrack for Risk Analysis, even if the connection via
   Menu > Settings > General > SecureTrack
is working fine and delivering "success".

In TOS Classic, German Umlauts were no problem, neither in First Name nor in the Last Name of any user.
It's the same for TOS Aurora, BUT a small change has been done.

The user SecureChange uses to connect to SecureTrack must not contain any German Umlaut. If it does,

everything works - except the Risk Check in SecureChange.
Replacing the "für" with "fuer" does solve this problem and the Risk Check works as expected.

 

 

 

 

Details
Category: SecureChange

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.

 

 

 

 

 

Details
Category: 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

 

 

 

  • You are here:  
  • Home
  • SecureChange