Manage traffic change requests

This topic describes the default process for working with various types of traffic change requests.

Manage basic traffic change requests

The following table describes the default process for working with most traffic change requests.

For more details, see Traffic change workflow.

Do the following:

User type Step Reference
Requestor or privileged user Create a change request using the Basic, Standard, 110: Multi-Approval Request, or 150: Parallel-Approval Request template. Request changes
Network operations user

Perform initial planning for the change request.

FireFlow will generate a separate change request for each device or policy to be modified.

 Initial planning
Drop actions
Network operations user

If the change request includes a "Drop" action, do the following:

  1. Search for any change requests for traffic will be blocked by the new Drop action.
  2. Notify the requestors of these change requests that the traffic is slated to be blocked.

FireFlow sends an email to the selected requestors. The requestors have until the change request's due date to respond.

Manage requestor notifications

Requestors Respond via email message or via the requestors web interface. Respond to change requests
Network operations user Re-notify requestors if needed, and review responses from requestors. Implement changes
Allow actions
Information security user If the change request includes an "Allow" action, FireFlow initiates a risk check to determine whether implementing the change specified in the change request would introduce risks. Examine risk check results
Information security user

Do one of the following:

  • Approve the change request and send it on to the next stage.

    FireFlow creates a work order that consists of a list of recommendations for implementing the requested change.

  • Reject the change request.

    The change request returns to the Plan stage, and you can perform initial planning again.

  • Reject and close the change request.

    An email message is sent to the requestor, indicating that the request is denied. The change request's lifecycle is ended, and no further user action is required.

 Approve planned changes
Multi-Approval or Parallel-Approval workflow
Controller If the change request uses the Multi-Approval or Parallel-Approval workflow, review the change request. Review change requests
All change requests
Network operations user Edit the work order as needed. Edit work orders
Network operations user Implement changes manually or with ActiveChange. Implement changes

Implement changes with ActiveChange

Network operations user FireFlow initiates validation of the implemented device policy changes against the change request. Validate changes
Network operations user

Do one of the following:

  • If validation indicates that the implemented changes achieved the desired result specified in the change request, notify the requestor that the requested changes were implemented.
  • If validation indicates that the implemented changes did not achieve the desired result specified in the change request, re-initiate the Implement stage and repeat change validation until the change is successful.
 Notify change requestors

Resolve or return change requests

Requestors Verify that the requested change was implemented and the desired result was achieved Verify change request results
Network operations user
  • If the requestor indicates that the implemented changes achieved the desired result specified in the change request, resolve the change request.
  • If the requestor indicates that the implemented changes did not achieve the desired result specified in the change request, re-initiate the Implement stage and repeat change validation until the change is successful.

    • Note: If the requestor does not respond, you can choose to resolve the change request anyway.

    		Resolve or return change requests

    Back to top

    Manage IPv6 traffic change requests

    The following table describes the default process for working with IPv6 traffic change requests.

    For more details, see IPv6 traffic change workflow.

    Do the following:

    User type Step Reference
    Requestor or privileged user Create a a change request using the 170: Traffic Change Request (IPv6) template. Request changes
    Network operations user

    Select devices for the change request.

    If multiple devices were selected, FireFlow will generate a separate change request for each device or policy to be modified.

    		 Initial planning
    Information security user

    Do one of the following:

    • Approve the change request and send it on to the next stage.

      FireFlow creates a work order that consists of a list of recommendations for implementing the requested change.

    • Reject the change request.

      The change request returns to the Plan stage, and you can perform initial planning again.

    • Reject and close the change request.

      An email message is sent to the requestor, indicating that the request is denied. The change request's lifecycle is ended, and no further user action is required.

    		 Approve planned changes
    Network operations user Edit the work order. Edit work orders
    Network operations user Implement the changes manually or with ActiveChange. Implement changes

    Implement changes with ActiveChange

    Network operations user Notify the requestor that the requested changes were implemented. Notify change requestors
    Requestors

    Verify that the requested change was implemented and the required result was achieved.

    		 Validate changes
    Network operations user
  • If the requestor indicates that the implemented changes achieved the desired result specified in the change request, resolve the change request.
  • If the requestor indicates that the implemented changes did not achieve the desired result specified in the change request, re-initiate the Implement stage and repeat change validation until the change is successful.

    • Note: If the requestor does not respond, you can choose to resolve the change request anyway.

    		Resolve or return change requests

    Back to top

    Manage Multicast traffic change requests

    The following table describes the default process for working with multicast traffic change requests.

    For more details, see Multicast traffic change workflow.

    Do the following:

    User type Step Reference
    Requestor or privileged user Submit a change request using the 180: Traffic Change Request (Multicast) template. Request changes
    Network operations user

    Select devices for the change request.

    If multiple devices were selected, FireFlow will generate a separate change request for each device or policy to be modified.

    		 Initial planning
    Information security user

    Do one of the following:

    • Approve the change request and send it on to the next stage.

      FireFlow creates a work order that consists of a list of recommendations for implementing the requested change.

    • Reject the change request.

      The change request returns to the Plan stage, and you can perform initial planning again.

    • Reject and close the change request.

      An email message is sent to the requestor, indicating that the request is denied. The change request's lifecycle is ended, and no further user action is required.

    		 Approve planned changes
    Network operations user Edit the work order. Edit work orders
    Network operations user Implement the changes manually or with ActiveChange. Implement changes

    Implement changes with ActiveChange

    Network operations user Notify the requestor that the requested changes were implemented. Notify change requestors
    Requestors

    Verify that the requested change was implemented and the required result was achieved.

    		 Validate changes
    Network operations user
  • If the requestor indicates that the implemented changes achieved the desired result specified in the change request, resolve the change request.
  • If the requestor indicates that the implemented changes did not achieve the desired result specified in the change request, re-initiate the Implement stage and repeat change validation until the change is successful.

    • Note: If the requestor does not respond, you can choose to resolve the change request anyway.

    		Resolve or return change requests

    Back to top

    Manage automatic traffic change requests

    The following table describes the default process for working with automatic traffic change requests.

    Do the following:

    User type Step Reference
    Requestor or privileged user Submit a change request using the 115: Automatic Traffic Change Request template. Request changes
    Network operations user

    Perform initial planning for the change request.

    Note: If the requestor specified all relevant device(s) in the change request form, the change request continues through this stage without confirmation.

    FireFlow will generate a separate change request for each device or policy to be modified.

    		 Initial planning
    Information security user FireFlow initiates a risk check to determine whether implementing the change specified in the change request would introduce risks. Examine risk check results
    Information security user

    If the risk check does not produce any critical or high risks, it is approved automatically, and the change request continues on to the Implement stage.

    Otherwise, do one of the following:

    • Approve the change request and send it on to the next stage.

      FireFlow creates a work order that consists of a list of recommendations for implementing the requested change.

    • Reject the change request.

      The change request returns to the Plan stage, and you can perform initial planning again.

    • Reject and close the change request.

      An email message is sent to the requestor, indicating that the request is denied. The change request's lifecycle is ended, and no further user action is required.

    		 Approve planned changes
    Network operations user

    The work order is implemented on the devices automatically, but validation of the changes cannot occur until the devices are analyzed by AlgoSec Firewall Analyzer.

    You can wait for the devices to be analyzed via scheduled monitoring, or you can expedite validation by manually anayzing the relevant devices.

    		Managing Analyses
    Network operations user FireFlow initiates validation of the changes implemented on the device or policy against the change request. Validate changes
    Network operations user
  • If the validation indicates that the implemented changes achieved the desired result specified in the change request, resolve the change request.
  • If the validation indicates that the implemented changes did not achieve the desired result specified in the change request, re-initiate the Implement stage and repeat change validation until the change is successful.
    		•  Resolve or return change requests
    Requestor Verify that the requested change was implemmented. Validate changes
    Network operations user
  • If the requestor indicates that the implemented changes achieved the desired result specified in the change request, resolve the change request.
  • If the requestor indicates that the implemented changes did not achieve the desired result specified in the change request, re-initiate the Implement stage and repeat change validation until the change is successful.

    • Note: If the requestor does not respond, you can choose to resolve the change request anyway.

    		 Resolve or return change requests

    Back to top