Rule modification workflow

This topic describes the events that occur in each stage in a default rule modification change workflow.

Request

In the Request stage, a privileged user submits a request to modify a device rule, initiating the FireFlow change request lifecycle. This stage consists of the following steps:

1. The requesting privileged user 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 requesting privileged user submits the request to FireFlow.

   The request includes information about which device rule to modify, and how it should be modified. 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 requesting privileged user that the change request was created, and specifying the change request ID in the format [FireFlow #<number>], for example [FireFlow #49].

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.

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

   FireFlow returns the number and severity of risks detected. The user can view a risk assessment of each risk:

   

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

   1. The network operations user initiates a search for change requests 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 email message or 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.

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. If the rule has changed while the change request was being processed, the network operations user will have the option to re-plan. Re-planning updates the rule values in FireFlow.
3. The network operations user edits the work order, by adding notes to the work order.
4. The network operations user implements the requested changes on the security device according to the work order, by using the relevant management system (for example, Check Point Dashboard or Juniper NSM) to implement the changes.
5. 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 rule modification against the change request. This stage consists of the following steps:

1. The network operations user validates the implemented rule modification against the change request.

   

2. If validation indicates that the specified rule was not modified, then the network operations user re-initiates the Implement stage.
3. Once the rule modification 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.

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

Resolved

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

Audit

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