Traffic change workflow

This topic describes the events that occur, by default, in each stage of a traffic 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 for a device traffic change, 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 must include information about the relevant source, destination, service/application, and action for the change. 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].
  8. FireFlow checks the traffic specified in the change request against the network security policy. If the traffic is already allowed (in case of a request to allow traffic), then FireFlow automatically closes the change request and sends you an email indicating that the change request was closed.

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.
    • Conditional logic was configured to dynamically choose the responsible role, based on request properties.

  2. FireFlow initiates a query on the indicated device group (by default, the ALL_FIREWALLS group) to identify relevant devices or policies.

    If the requestor did not provide adequate information, the network operations user contacts the requestor to clarify the request details and then modifies the request details as needed.

  3. The network operations user uses the FireFlowinitial plan results to identify the devices or policies that are relevant to the requested change.
  4. If the network user modified the traffic, FireFlow tests whether the requested traffic is already allowed. If the traffic is already allowed, 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 or policy that is relevant to the change, the network operations user selects the devices or policies on which to implement the change.
  6. The network operation user confirms the devices, sending the change request to the next stage.
  7. If the network operations user selected multiple devices or policies, FireFlow will generate sub-requests for each.

Approve

In the Approve stage, a user with the information security role determines the security risks entailed in satisfying the request. This 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.
    • Conditional logic was configured to dynamically choose the responsible role, based on request properties.

  3. If the change request includes an "Allow" action, FireFlow initiates a risk check, to determine whether implementing the requested Allow traffic change will introduce risks.

    FireFlow returns the number and severity of risks detected:

    In the case of policy-based requests, the risk check runs on one of the devices with the policy.

    The user can view a risk assessment of each risk:

  4. If the change request includes a "Drop" action, the following happens:

    1. The network operations user initiates a search for change requests whose traffic will be blocked by the "Drop" action.

    2. 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 traffic will be blocked.

    4. FireFlow sends an email to the selected requestors.
    5. The requestors respond via an email message or the web interface.

  5. 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 and returns it to the Plan stage.
    • Rejects and closes the change request. In this case, an email message is sent to the requestor, indicating that the request is denied.
    • Contacts the requestor and asks for more information.

Review

If the request uses the Multi-Approval or Parallel-Approval workflow, then its lifecycle includes a Review stage, in which a controller reviews the change request. This stage consists of the following steps:

  1. The controller examines the change request.

  2. The controller then composes an email message in FireFlow, notifying the requestor that the change request was reviewed and approved for implementation.

  3. FireFlow sends the email to the requestor.
  4. The change request is sent 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. The change request's ownership is returned to the network operations user.

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

  3. The network operations user can edit the work order.

    For most devices, the user can edit the list of recommendations. For all devices, the user can add notes to the work order, to be viewed by the implementing team.

  4. The network operations user implements the requested changes on the security device according to the work order, by doing one of the following:

    • The user manually implements the changes or implements the changes using the relevant management system (for example, Check Point Dashboard or Juniper NSM).
    • The user implements the changes from FireFlow using ActiveChange.

    Note: In order to use ActiveChange, it must be licensed and enabled. For more details, see Implement changes with ActiveChange.

  1. The network operation user sends the change request on to the next stage.

Validate

In the Validate stage, FireFlow validates the implemented device policy changes against the change request and presents validation results to the network operation user. 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. FireFlow validates the implemented device policy changes against the change request.

  2. The validation process checks both that the requested traffic is not allowed or blocked, and also that the changes were done according to the work order.

  3. 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.

  4. For the Standard, Multi-Approval, or Parallel-Approval workflows:

    Once the changes have been successfully validated, the network operations user composes an email message in FireFlow, notifying the requestor that the requested changes were implemented.

  5. FireFlow sends the email to the requestor.

  6. The requestor checks that the requested change was implemented and the desired result was achieved.

  7. One of the following 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 change request is resolved automatically.

    • 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.

Match

According to a configurable schedule, FireFlow automatically checks all devices for rule changes and determines the following:

  • Each change is associated with a change request.
  • Each change request is associated with a change.
  • Each change is associated with the correct change request.
  • The scope of each change matches the approved scope in the associated change request.

If there are no problems with a given change request, FireFlow automatically marks it as matched.

For control purposes, an information security user periodically checks that all change requests were matched successfully, and resolves any problems that FireFlow may have detected during auto matching. The Match stage consists of the following steps:

  1. The information security user checks whether FireFlow detected any matching problems with the validated change requests in the system.

  2. If a problem is detected for a change request, the information security user does one of the following:

    • Re-opens the change request.
    • Manually approves the mismatch.

Note: It is recommended to perform these steps on a weekly or monthly basis.

Resolved

Once the change request has been matched to the relevant change(s), it enters the Resolved stage.

Audit

FireFlow enables you to perform a variety of auditing tasks, including:

  • Viewing the full history of any change request, including who requested the change, who approved the change request, what device rule changes were implemented, and comments on the change request.
  • Searching and filtering according to dates, requestor, device, and other criteria.
  • Generating a variety of reports, including reports based on:
  • Change request owner
  • Change request status
  • Create, due, update, or resolve date, for a daily, monthly, or annual period
  • Specific fields in the request
  • SLA parameters

Reports can be viewed in FireFlow or exported to a .csv file (that can be viewed in Excel, for example).