www.tufin.club

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: Version update

Tufin has released TOS R23-1, the first version of the Tufin Orchestration Suite of 2023.
TOS R23-1 is available as GA and can be downloaded from the Tufin Portal (login required).
This version is available for TOS Aurora only. Some improvements of TOS Aurora R23-1:

Change Automation and Orchestration

  • SecureChange (Azure)
    Azure Firewalls can be included in Access Request tickets in topology mode, i.e. they can be used as targets in such a ticket.

  • SecureChange (Check Point)
    Support of FQDN configured in Check Point has been integrated into SecureChange automation tools.

  • SecureChange (Cisco)
    Access Requests now can be provisioned to Cisco Nexus devices

  • SecureChange
    A redesign by the Designer can be triggered by API.

  • SecureChange
    Using API POST allows the creation of tickets with rules from multiple devices for workflows focused on rules (modification, decommission, recertification).

  • SecureChange API
    The API now allows to trigger "commit now", automatic retries are possible also.

  • SecureChange API
    Automation of the provisioning can be scheduled, triggered, or retried using the API

Cloud

  • SecureTrack (AWS)
    Importing multiple AWS accounts and additional entries like VPCs or transit gateways is possible using the bulk API feature.

Deployment and Monitoring

  • TOS Aurora deployment in AWS is now supported for large customers
  • Solarwinds can be used to monitor the health of the Kubernetes cluster
  • Backups can be stored externally using NAS (NFS) storage.
  • Remote Collectors are now supported for Cloud Deployments (AWS, Azure, GCP)
  • From now on, the Microsoft Authentication Library (MSAL) can be used for authentication, since the Active Directory Authentication Library (ADAL) will no more be supported after June 2023

Devices and Platforms

  • Amazon AWS
    AWS Gateway Load Balancers can be imported from the AWS account and be integrated into SecureTrack Topology. This also means that change automation also can be used for these devices.

  • Check Point / Palo Alto Networks
    Syslog is now supported not only using TCP instead of UDP but also using encryption. So for these two devices, Syslog can be transferred securely to SecureTrack.

  • Check Point
    SecureTrack as well as SecureChange support Check Point FQDN objects. They are visible in security rules and change tracking, assessment, path analysis, and matching rules. In SecureChange they can be used in Target Selection, Designer, and Verifier.

  • Cisco
    SecureTrack Rule Viewer, Topology, and USP now support Cisco Meraki Firewalls

  • Microsoft Azure
    Azure Virtual Hubs from Azure subscriptions can be imported to SecureTrack Topology. So they can not only be used for Path Analysis, but also by SecureChange Automation Tools.

  • Microsoft Azure
    The import of Azure Virtual Hubs from Azure subscriptions is possible to show in SecureTrack Topology. This can be used for Path Analysis as well as in SecureChange.

  • Microsoft Azure
    Azure Shared Express Routes are now modeled in the Topology map to be used here as well as in SecureChange

  • Microsoft Azure
    Azure Application Security Groups (ASGs) that are part of Network Security Group (NSG) rules can be used in SeureTrack Rule Viewer, Object Lookup, Compare Revisions, and Topology Path Analysis.

  • Palo Alto Networks
    In SecureTrack Rule Viewer a search for PAN Rule UUID is possible. This information also appears in the ID of the Device column when exporting Rule Viewer information.

  • API
    The Devices Bulk API has been provided with a delete function. So it's possible to remove a Management Device and all of its managed devices with an API call.

  • API
    Rule-based tickets containing multiple devices or policies per ticket can be submitted by API now.

GraphQL API

  • USP exceptions
    Exceptions can be defined with network objects (e.g. network groups, IP addresses) via GraphQL. This isn't possible using the WebUI

REST API

  • Enhancements for SecureTrack
    • Bulk Device Deletion API allows to delete e.g. a management server and all firewalls managed by it from SecureTrack
    • Multiple AWS Accounts Management API allows using of this bulk API feature to onboard multiple AWS accounts and edit them by importing VPCs and transit gateways also.
    • Exceptions can be defined with network objects (e.g. network groups, IP addresses) via REST API and GraphQL API, respectively. This isn't possible using the WebUI

  • Enhancements for SecureChange
    • Designer Redesign is possible now using the API. This is useful if e.g. a new revision has been retrieved between design and provisioning.
    • Selective Device Update is useful for the automation of provisioning changes.
    • Ticket Creation is possible using API POST for rules of multiple devices. This is used for Rule Modification, Rule Decommission, or Rule Recertification.
    • Trigger Commit Now for a specific device is possible. Automatic Retries can be automated.
    • Submit (Rule-Based) Tickets can be used now for multiple devices.

Security, Risk, and Compliance

  • USP Exceptions contain Object IDs now, so within these exceptions, network objects can be used.

Topology Map

  • Device Grouping in the Topology Map delivers more visualization. This is done by grouping network and security devices by domain or other custom requirements.

User Experience

  • Accessibility for color-blind users can be improved by configurable high-contrast color schemes.
  • The Look and Feel of the Tickets page is updated, delivering a more user-friendly experience.

 

Further improvements, as well as corrections, are included in R23-1.
The latest version of the Tufin Orchestration Suite can be found at the Tufin Portal: https://portal.tufin.com

Update July 2023: R23-1 PGA.0.0 and R23-1 PHF1.0.0 were recalled.
R23-1 PHF1.1.0 should be considered the earliest available R23-1 release.

Update August 2023: R23-1 PGA1.2.0 is available now for download.

 

 

 

Details
Category: SecureTrack

Sometimes there are requirements regarding redundancy and high availability. In most cases, firewalls are configured to act as a cluster. So if one cluster member fails, packets are still possible to pass the firewall. In this case, the firewall cluster has a virtual IP address that is addressed by the packets.

Check Point Management HA

Check Point offers not only firewall clusters but also redundant management. In this case, there are two management servers running as active and standby, respectively. The administrator connects to the active management server and makes changes to the firewall configuration. These changes are synchronized to the standby management server. If the active management server fails, the administrator can connect to the other management server to continue the work and install the policy on the firewalls. Regarding this situation, there are two different IP addresses the administrator connects to; no virtual cluster IP address is in use.

Management HA and SecureTrack

Tufin supports Check Point Management HA for many years. After the first server is defined in Tufin SecureTrack, the second server is imported using the WebUI via "/tools". This is described in the Tufin Portal. Everything works as expected if only rule changes are tracked.

Restrictions of SecureTrack regarding rule metadata

Today's SecureTrack works with metadata for each rule. These metadata include further information about the rule, e.g. "last hit", "last modification date", "rule owner", etc. Many companies need information stored in the metadata, e.g. reference to a "ticket number" in SecureChange that is related to this rule or a "rule recertification date". This date can be set with e.g. the Rule Lifecycle Management (RLM) tool. Recertification is often required esp. for companies working in the finance sector.

When metadata are created or modified, they are written to the corresponding rule on the active Check Point Management server - and these data are not synchronized (by design). So if e.g. rule 2 has been certified until 2024, this information is stored on the active server only. After a failover the other management server becomes active - and rule 2 is not certified here. The same situation occurs if a rule is modified: Ticket information is stored on the active server only, and is not synchronized to the standby server.

Lesson Learned

Tufin SecureTrack doesn't support "modern features" like rule recertification or ticket information per rule if Check Point Management HA is deployed.

 

 

 

 

Details
Category: Basics

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.