Using Designer

SecureChange Requester This topic is intended for SecureChange handlers who are responsible for processing change requests.

Overview

Designer is an automatic tool which recommends changes that are needed to process the ticket. After running Designer, many workflows allow you to use Provisioning to implement the changes, and then use Verifier to confirm that changes were implemented successfully.

Designer makes recommendations based on the workflow type:

  • Access Request Workflow: Designer recommends objects, rules, and other changes that would be need to implement the Access Request. If the request workflow does not use topology, then the Designer only runs on the access requests that have a target defined (the target cannot be Any).

    When a request includes the Internet object, Designer uses the internet object for the target device to represent the all IPv4 addresses in the Internet in TOS features (Configurable in SecureTrack for Check Point and Stonesoft; ANY for other devices).

    When a request includes application identities, the Designer considers the service that the application identity uses. When designing new groups in a rule, the Designer creates them according to how they have been defined in SecureApp. Then you provision the changes directly from the ticket.

  • Decommission Network Object Workflow: Designer suggests how specific rules should be modified to remove the server from them. The recommendations may be to remove the server from specific rules, remove a server from a group, or to remove a rule completely if it will no longer be relevant once the server has been decommissioned.

  • Server Clone Workflow: Designer lists the objects that need to be added to rules, for example, if the server being cloned is referenced in a rule, the cloned server will also need to be added to the rule.

  • Modify Group: Designer lists objects which should be added or removed from the group, or new groups that should be created.

  • Rule Modification: Designer: Designer gives recommendations how to change the rule base

  • Rule Decommission Workflow: Designer recommends how to change the rule base to decommission a rule.

Device Types

To see which Designer recommendations are supported on each device type, and which devices support Provisioning, see SecureChange Features by Vendor.

You can use the GET Designer results API to see which devices are supported for Designer but not for Provisioning.

If a device is not listed as supporting Provisioning, suggestions from Designer have to be imported manually.

Related or Conflicting Tickets

Sometimes, Designer will be run on multiple related tickets. When you accept Designer's suggestions and implement the suggested changes on the device for the first ticket, you might render the suggestions for the other tickets obsolete. This is because the original revision - upon which Designer based its suggestions - has changed.

A revision is considered obsolete when a newer revision was received, or about to be received on the device (when provisioned from another ticket), causing a policy change which might intersect with the Designer’s results.

To avoid conflicting or inaccurate provisioning in case Designer results are based on an obsolete revision, every time you open an existing Designer suggestion or run new Provisioning to update a device, TOS checks if those suggestions are still valid. If the revision has become obsolete, a warning notification appears.

Once the revision has been accepted, you can select one of the options:

  • Update devices - implement original changes regardless of the conflict

  • Redesign - rerun Designer and receive new suggestions for the affected devices, while keeping Designer results for devices with no detected dependencies.

If the obsolete revision for Designer results was detected during provisioning on auto-step, the automatic step will stop and default handler assigned for the step would see these notifications when opening Designer results. Since they will be able to run Redesign, the SecureChange workflow admin should ensure that this default handler is qualified to run Designer.

The feature is only supported on the following devices:

  • Check Point CMA/SMC

  • Cisco ASA/IOS

  • Cisco Firepower Management Center (FMC)

  • Fortinet FortiManager

  • Juniper SRX

  • Palo Alto Panorama

  • VMware NSX

When working with unsupported devices, manual changes, or multiple handlers assigned on the same device in dynamic assignment, SecureChange is not able to identify related tickets. Instead every new revision includes an indication that you should manually run Designer. In these cases, automatic steps will not fail.

If multiple objects have the same IP Address value in different tickets, they are not considered dependent and they will not trigger a recalculation warning.

Remove Access Requests

A Remove or Decommission Access Request removes network access. For example, you may need to remove network access that is no longer required, or for an access request ticket that has reached its expiration date and its network access should be removed from the system.

Designer determines whether removing access requires rules to be removed or modified, or network groups need to be modified for each Access Request in a ticket. If a ticket includes multiple Access Requests, each Access Request is listed separately in Designer. A single ticket can include requests to add access, as well as requests to remove access.

If the Access Decommission contains user identities or application identities in the access request, Designer will only provide suggestions to remove access on the following supported devices:

  • Panorama (user identities and application identities)
  • Check Point R80 and above (user identities)

In the Designer Recommendations screen, Access Requests to add access are colored green, Requests to remove access are colored orange.

To view the rules which will be affected by Designer's suggestions, see View Access Request and Related Rules.

Troubleshoot Designer Issues

You can use the Designer Debug tool to help the Tufin development team debug and fix escalations relevant to Designer and Verifier in access requests.

Special Cases Handled by the Manage Related Rules Feature

The following cases are set to Ignore by default:

  • If NAT is found on the path of an Access Request
  • If you are using SecureApp and there are other SecureApp connections that are mapped to a related rule

For Designer to include these rules in its suggestions, in the Related Rules window, clear the Ignore checkbox next to these rules, click OK, and then Redesign.

What Can I Do Here?

Using Designer for an Access Request

  1. Open or create an Access Request and click Designer.

    If there is no Designer button, check if Designer was enabled in this step of the workflow configuration.

  2. If your access request contains an AWS instance, you must Select Security Groups for the VPC.

  3. Look through the Designer recommendations, organized by vendor > device > policy > access request.

    If a later access request requires changes that are also required in an earlier access request, Designer notes that no changes will be implemented for the later access request.

  4. In the recommendations, the Designer assigns names to the new servers/services/rule names using these guidelines:

    • Creates a name using the format:

      host_<ip> / subnet_<ip>

    • If the request came from SecureApp, then it uses the name given in SecureApp

      If an "i" icon appears next to the recommendation, then Designer has modified the name assigned in SecureApp to meet the vendor's requirements. For example if you created a new connection with the name “Connection 1” the Designer changes it to “Connection1” if spaces are not allowed.

      Click to view the original name.

  5. In the recommendations, you can click on the following fields to change the values given by the Designer:

    These values cannot be changed if a new revision was received from the device.

    • Object names

    • Rule names

    • Rule location (before or after specific rule number, or as last rule)

    • Logging levels

  6. For new or existing rules, you can add or edit comments on the following devices:

    • Check Point R80 and above (Can also edit comments of existing rules)

    • Juniper SRX (Can also edit comments of existing rules; Rule IDs are not sequential)

    • Fortimanager (Can add rule name)

    • Cisco (Cannot change the name of a new rule)

    • ASA

    • NSX

    • Panorama

  7. For NSX devices, when adding new rules, if the Access Requests has a Security Group as a Source or Destination, Designer can provide more specific suggestions based on the relevant security groups, instead of using DFW. Click the Applied to field to select the relevant security groups.

  8. For Decommission Access Requests, if there are related rules, click Manage Related Rules, to review a list of related rules, and if required, select Ignore next to rules that should not receive suggestions by Designer, and click Redesign.

  9. Click View rule to see the results as a firewall rule for the specified vendor.

    Click on Customize rule to see the objects that have alternative objects that match the access request. For example, when the access request specifies IP address 1.1.1.1 and the device has more than one object with that IP address, you can change the object that is used in the Designer results:

    1. Click View rule.

    2. Click Customize rule.

    3. Click to change the editable object.

    4. Select a different object to use in the rule.

    5. Click Update.

  10. Click to save the change or to cancel the change that you entered.

  11. If you have permissions, to implement the changes:

    • Check Point:

      1. Click Update Policy or to update all policies at one time click Update All Policies. The updated policies are saved in CMA/SmartCenter.

        To have the Update Policy option, enabling the Designer to apply changes directly to Check Point policies, you need to configure SecureTrack to use an OPSEC object that has Read/Write permissions.

      2. Use Check Point SmartDashboard to install the policies.

    • Cisco ASA, Cisco IOS, and Juniper SRX:

      • Click Commands > Update Device.

        To have the Update Device option, enabling the Designer to apply changes directly to Cisco devices, you need to configure SecureTrack to monitor the devices via SSHv2.

    • Juniper NetScreen:

      1. Click Commands > Copy Commands.

      2. Paste the commands on to the device's CLI.

    • Palo Alto/Panorama:

      • Click Update devices.

  12. Click Close to return to the ticket.

    If you click Close and save the progress on the task, the designer results are saved.

    You can click next to the access request to see the results, and other handlers can click in this step to see the results.

  13. Once you have implemented the changes recommended by Designer, you can run Verifier to confirm that the changes were implemented, see Verifying Access Requests.

How Do I Get Here?

SecureChange > My Requests > Open or create Request > Designer