Multi-device object change workflow

This topic describes the events that occur in each stage in a default multi-device object change workflow.

In this topic:

Request

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

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.

Back to top

Plan

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

Back to top

Approve

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.

Back to top

Implement

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.

Back to top

Validate

In the Validate stage, the network operation user validates the implemented device object changes against the change request. This stage consists of the following steps:

1. The network operations user validates the implemented device policy changes against the change request.
2. If validation indicates that the implemented changes did not achieve the desired result specified in the change request, then the network operations user re-initiates the Implement stage.
3. The network operations user composes an email message in FireFlow, notifying the requestor that the requested changes were implemented.
4. FireFlow sends the email to the requesting privileged user.
5. The network operations user resolves the change request.

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.

Back to top

Resolved

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

Back to top

Audit

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

Back to top