Re-certification workflow

This topic describes the events that occur in each stage in a default re-certification change.

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

Request

In the Request stage, a network operations user submits a request to recertify an expired traffic change request, initiating the FireFlow change request lifecycle. This stage consists of the following steps:

  1. The network operations user views a list of change requests that are due to be recertified.

  2. The network operations user then selects the change request to recertify.

    Note: It is possible to select multiple change requests to recertify.

  3. FireFlow creates a change request and assigns the request to the Request-Recertification workflow.
  4. The default assignee of the role handling new change requests (by default, the Network Operations role) is assigned as the change request's owner.

Certify

In the Certify stage, the network operations user determines the network issues entailed in satisfying the 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. The network operations user initiates a search for change requests whose traffic intersects that of the Allow traffic that was added by the expired change request.

    FireFlow returns a list of related change requests:

  3. The network operations user then specifies which of the related change requestors (and optionally other users) should receive a notification that the Allow traffic will be deleted.
  4. FireFlow sends an email to the selected requestors.
  5. The requestors respond via email message.
  6. The network operations user does one of the following:

    • Extends the due date of the change request, giving related change requestors more time to respond.
    • Certifies the traffic, sending the change request on to the Resolved stage.
    • Plans the traffic's removal, sending the change request on to the next stage.

Implement

In the Implement stage, the network operations user plans and executes request implementation. This stage consists of the following steps:

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

  2. The network operations user edits the work order, by adding notes to the work order.
  3. The network operations user implements the requested changes on the device or policy according to the work order, by using the relevant management system (for example, Check Point Dashboard or Juniper NSM) to implement the changes.
  4. The network operation user sends the change request on to the next stage.

Validate

In the Validate stage, the network operation user validates the implemented removal of the Allow traffic against the recertification request. This stage consists of the following steps:

  1. The network operations user validates the implemented Allow traffic removal against the change request.

  2. If validation indicates that the traffic is still allowed, then the network operations user re-initiates the Implement stage.
  3. Once the Allow traffic's removal has been successfully validated, 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.

Resolved

Once the Allow traffic has been certified or the recertification request has been validated, the change request enters the Resolved stage.

Audit

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