Multi-device object change workflow

This topic describes the phases of the multi-device object change workflow. You can choose the default workflow, or alternatively, you can enable zero touch capabilities for this workflow to automate the Approve and Implement stages.

Note: FireFlow is fully configurable, and your system may differ. For more details, see Manage request templates.

Request

In the Request stage, a privileged user submits a request for a multi-device object change, initiating the FireFlow change request lifecycle.

Note: A multi -device object change request cannot be created in the Web Interface. It can only be created with the FireFlow REST API.

If licensed, AppChange, layered over AppViz can also initiate these change requests when editing an object. This option depends on your AppViz configuration. For more details, see Create a device object change request and Customize interactions with AFA and FireFlow.

This stage consists of the following steps:

  1. The requesting privileged user initiates the request via a REST call, directly or from AppViz.

    The request includes information about a device object to create, delete, or modify.

  2. FireFlow receives the request information and creates a change request.
  3. The default assignee of the role handling new change requests (by default, the Network Operations role) is assigned as the change request's owner.
  4. FireFlow sends an email message informing the requesting privileged user that the change request was created, and specifying the change request ID in the format [FireFlow #<number>], for example [FireFlow #49].

The change request ID number additionally appears in the response of the REST call.

Plan

Multi-device object change requests automatically proceeds through the plan stage to the approve stage.

Approve

Note: To automate this stage: Set the ObjectMultiDeviceWorkFlowSkipApproval parameter to:

  • 1 - to skip to next stage only if there are no affected rules

  • 2 - to always skip to next stage

For instructions to set this parameter, see Override FireFlow system defaults.

By default, the Approve stage consists of the following steps:

  1. The default assignee of the role handling change requests in the Approve stage (by default, the Information Security role) is assigned as the change request's owner.

  2. The change request may change ownership in one of the following ways:

    • The change request owner assigns it to a user with the information security role.
    • An information security user chooses to take responsibility for the change request.

  3. FireFlow initiates a search for rules that would be affected by the requested object change.

    FireFlow returns a list of affected rules:

  4. The information security user does one of the following:

    • Approves the change request and sends it on to the next stage.
    • Rejects the change request. In this case the change request returns to the start of the Approve stage.
    • Rejects and closes the change request. In this case, an email message is sent to the requesting privileged user, indicating that the request is denied.
    • Contacts the requestor and asks for more information.

Implement

Note: To automate this stage: Set the ObjectMultiDeviceWorkFlowImplementAutomatically parameter to:

  • 1 - to always implement automatically.

For instructions to set this parameter, see Override FireFlow system defaults.

The Implement stage for multi-device object change requests is similar to that of single-device object change requests, with the addition of ActiveChange support, depending on the device type.

For more details, see Implement changes with ActiveChange and the AlgoSec support matrix.

Validate

Starting with ASMS version A32.00, the validation phase is triggered automatically:

  1. The implemented device policy changes are validated against the change request.
  2. If validation indicates that the implemented changes did not achieve the desired result specified in the change request, the network operations user can re-initiate the Implement stage.
  3. A mail notification is sent automatically to the requesting privileged user, informing that the requested changes are implemented .
  4. The change request is resolved automatically.

At this point, the change request's lifecycle has effectively ended, and no further user action is required. However, the change request remains available in the system for auditing purposes, as described in the final stages.

Resolved

Once the change request has been validated, it enters the Resolved stage.

Audit

The Audit stage for object change request lifecycles is identical to the Audit stage for traffic change request lifecycles. See Audit.