Web filtering change workflow

This topic describes the events that occur in each stage in a default web filtering change workflow.

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

Request

In the Request stage, a requestor submits a request to filter a URL, initiating the FireFlow change request lifecycle. This stage consists of the following steps:

  1. The requestor selects a template on which to base their request.
  2. If the template specifies a workflow, FireFlow assigns the request to that workflow.

  3. The requestor submits the request to FireFlow.

    The request includes information about the relevant user group, URL, category, and action for the Web filtering rule. For example, the requestor may submit the following request:

  4. FireFlow receives the request information and creates a change request.
  5. If a workflow has not yet been assigned, FireFlow assigns a workflow. For more details, see Request templates and workflows.
  6. The default assignee of the role handling new change requests (by default, the Network Operations role) is assigned as the change request's owner.
  7. FireFlow sends an email message informing the requestor that the change request was created, and specifying the change request ID in the format [FireFlow #<number>], for example [FireFlow #49].

Back to top

Plan

In the Plan stage, a user with the network operations role plots out the technical changes needed in order to satisfy the change request. This stage consists of the following steps:

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

    • The change request owner assigns it to a user with the network operations role.
    • A network operations user chooses to take responsibility for the change request.
  2. FireFlow initiates a query to identify relevant devices.

  3. The network operations user uses FireFlow to confirm which devices are relevant to the requested change.

  4. If the network user modified the Web filtering change request, FireFlow tests whether the requested URL is already allowed/denied to the specified users/user groups. If the URL is already allowed/denied, the network operations user closes the change request, and FireFlow sends an email message to the requestor indicating that the change request was closed.
  5. If there is more than one device that is relevant to the change, the network operations user selects the devices on which to implement the change.
  6. The network operation user sends the change request on to the next stage.
  7. If the network operations user selected multiple devices, FireFlow will generate a sub-request for each.

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. 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.
    • Contacts the requestor and asks for more information.

Back to top

Implement

In the Implement stage, the network operations user plans and executes request implementation. If the request was created for multiple devices, this stage must be performed separately for each sub-request.

This stage consists of the following steps:

  1. The change request's ownership is returned to the network operations user.

  2. The network operations user chooses an organizational methodology to use for implementing the requested change.

  3. FireFlow creates a work order and displays a list of recommendations for implementing the requested change.

  4. The network operations user edits the work order, by adding notes to the work order.
  5. The network operations user implements the requested changes on the security device according to the work order.
  1. The network operation user sends the change request on to the next stage.

Back to top

Validate

In the Validate stage, the network operation user validates the implemented device policy changes against the change request. The requestor then checks that the request was implemented, and the network operations user resolves the change request. This stage consists of the following steps:

  1. The network operations user composes an email message in FireFlow, notifying the requestor that the requested changes were implemented.

  2. FireFlow sends the email to the requestor.
  3. The requestor checks that the requested change was implemented and the desired result was achieved.

  4. One of the following things happens:

    • If the desired result was not achieved, the requestor responds via an email message or via the Web interface, and the network operations user then re-initiates the implementation stage.
    • If the desired result was achieved, the requestor responds via an email message or via the Web interface, and the network operations user then resolves the change request.
    • If the requestor does not respond, the network operations user can choose to resolve the change request anyway.

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 matched to the relevant change(s), it enters the Resolved stage.

Back to top

Audit

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

Back to top