SecureChange

Details

Category: SecureChange

Last Updated: 23 September 2023

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

Last Updated: 04 August 2023

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

Last Updated: 26 April 2023

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

Last Updated: 11 July 2023

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.