About Workflows

Overview

A workflow is a set of steps to complete a change request. For example, you could create a workflow to process an access request which includes the following steps:

Submit Access Request
Business Approval for the request
Technical Design
Security Review and Approval
Implement the change request

Each of these steps includes fields with required information. For example the first step, Submit Access Request, may contain information such as the target, source, and destination, and business justification of the request. Each step also needs to define who the step will be assigned to, for example, the Approval step may be automatically assigned to a manager.

The first step in a workflow is always Submit Request. The final steps are normally to implement and verify the change.

SecureChange Requester Workflows are created and maintained by Workflow Owners in the Workflows page, see Workflows Page.

SecureChange Requester Existing workflows are used by Requesters to create change requests, see Creating a Change Request.

SecureChange Requester Change requests are then processed Handlers, see Assigning Change Requests.

Tufin provides an extension - Rule Lifecycle Management App (RLM) - that simplifies and manages the rule recertification process. For more information, see Rule Lifecycle Management App.

Workflow Types

SecureChange includes the following workflow types:

Access Request: A request to grant access between a designated Target and Source, and if required for a Destination. For further information, see Managing Access Requests.
Decommission Network Object: Removes an IP address from anywhere that it appears in the system, including firewalls, groups, and rules. For further information, see Decommission Network Object Field.
Clone Network Object Policy: Creates a duplicate of the access permissions of an existing server in your security policy for new servers. The Clone Network Object Policy workflow supports only single domain mode and Segregated Domains mode. For further information, see Clone Network Object Policy Field.

Cloning a Network Object Policy
Rule Decommission: This workflow is typically run before a rule is deleted. By decommissioning a rule, the rule will not be used to assess whether the rule is needed before it is deleted. For further information, see Rule Decommission Field.

Decommissioning a Rule

Decommission policy rules and save changes using the Rule Modification workflow.
Modify Group: Adds or removes objects from a group of network objects from a device group, or create new groups. For further information, see Modify Group Field.
Rule Modification: Updates firewall rules by adding or removing devices or services in the Source, Destination, and Service fields. For further information, see Rule Modification Field.

Modifying a Rule

Edit policy rules, and provision changes, using the Rule Modification workflow.
Rule Recertification: Recertifies existing rules; some rules may need to have their expiration date extended. For further information, see Rule Recertification Field.

Tools to Process a Workflow

Handlers can use the following automated tools to process a change request:

Designer: Designer is an automatic tool which recommends changes that are needed to process the ticket. For details, see Using Designer. Designer is not available for Rule Recertification workflows.
Risk Analyzer: The Risk Analysis calculates the risks in an Access Request workflow. For details, see Using the Risk Analysis Tool.
Provisioning: In some devices you can provision the changes from SecureChange. For details, see Provisioning and Commit Policy Changes.
Verifier: After provisioning or manually implementing the changes, use Verifier to confirm that the changes were successfully implemented. For details, see Verifying Access Requests. This tool is available in Access Request and Decommission Network Object workflows.
Suggest Target: In workflows that use topology, SecureChange can add a target based on SecureTrack policy and topology information.