Edit work orders

FireFlow enables you to edit work orders by adding notes to the work order, by editing the list of recommendations, or renaming the objects that FireFlow creates for the work order.

Supported editing scope

You may want to edit a FireFlow work order, such as when you want to provide specific names for objects on your device. Depending on your configuration or the device you're making the change to, editing may be required before continuing on in the flow.

In other cases, editing a work flow is not supported at all, such as for work orders with a drop action, or for AWS or Symantec Blue CoatClosed As of A32.20 AlgoSec will no longer support adding new Symantec Blue Coat devices. Existing deployed Blue Coat devices will still be functional. devices.

When editing a workflow, keep in mind that change requests that include traffic with NAT only include the relevant addresses in the request, as follows:

  • Requests for devices that are located before NAT only include the before-translation address.
  • Requests for devices that are located after NAT only include the after-translation address.
  • Requests for devices that perform NAT includes both the before- and after-translation addresses.

Edit a work order

Do the following:

  1. View the change request. For details, see View change requests.

  2. If the change request has multiple devices or policies, click next to a device.

  3. If the work order is not available, or the device policies have changed since the work order was created, refresh the work order by clicking Recalculate.

    The work order and any device action buttons are shown in the Work Order Recommendations area.

    For example:

    This area shows FireFlow's recommendations for implementing the change specified in the change request.

    Note: If the traffic is already allowed by the device, your recommendation may be No action required.

    For more details, see:

  1. If your change request includes only an Allow action, edit the values recommended by FireFlow as needed. Do the following:

    1. At the top of the Work Order Recommendations area, click .

      The Edit Work Order window appears.

    2. Edit the fields as needed, and click Save Changes. For more details, see Work order recommendation details.

      Note: If CLI commands were generated, editing the work order will cause the CLI commands to be regenerated.

  2. To view the query on which the recommendation is based, in the Work Order Recommendations area, click . The query details open in a new tab. For example:

  3. To add comments, scroll down to the Implementation Notes area at the bottom, and click Edit.

    Enter your comment in the text box, and then click OK back up at the top.

Your work order is updated.

Work order recommendation details

Work order recommendations and editing scope vary greatly, depending on your scenario, configurations, and device types. For example:

  • Fields where exactly one suitable option exists will be pre-filled with the relevant option and read-only.
  • If no suitable object option exists, you may be able to enter the name of a new object to create. Your object name must be valid and unique.
  • For source, destination, and service fields, use the Advanced Editing wizard to access additional options. For details, see The Advanced Editing wizard

Related Topics:

IP ranges are not split for the sake of omitting irrelevant traffic from the work order recommendations. This means:

  • If the action is Drop, and some of the traffic is already blocked, the work order will suggest blocking all the traffic, including traffic that is already blocked.
  • If some of the requested traffic is already allowed, work orders may still recommend allowing that traffic.

Editing a work order enables you to manually enter a new name, or FireFlow can be configured to automatically set a rule name via a hook. For more details, see FireFlow hooks.

Tip: We recommend consulting with AlgoSec professional services when configuring a hook to set rule names.

FireFlow may be configured as follows:

  • Always recommend creating a new rule. The New Rule button does not appear in this case, and FireFlow recommends creating new rules by default.
  • Allow new users to add new rules instead of modifying existing ones. In this case, click the New Rule button instead of Recalculate. Clicking Recalculate will always prefer a modify rule recommendation.
  • Prevent new rules. If FireFlow is not configured to create new rules at all, the New Rule button does not appear, and FireFlow always recommends modifying rules.

For more details, see FireFlow configuration parameter reference.

Policy-Based change requests

FireFlow uses policy-based change requests for Palo Alto Networks Panorama, Check Point, Fortinet Fortimanager, and Junos Space Security Director.

In the work order, FireFlow will choose objects from the same domain in which the policy exists, or higher domains. FireFlow will recommend installing the change on all devices with the policy. If desired, you can set FireFlow to only install changes on the relevant devices or simply to always use device-based change requests.

For more details, see FireFlow configuration parameter reference.

Zone spanning support

Zone spanning support differs as follows:

Juniper devices

Zone spanning support for Juniper devices includes only Junos Space Security Directors. For all other Juniper devices, the work order will always recommend adding a single rule even though you must add 2 or more rules (one for each source zone / destination zone pair).

When ActiveChange is enabled for Juniper devices which do not support zone spanning, CLI generation will fail when zone spanning occurs.

You can edit the CLI command field and still use ActiveChange to execute the commands directly from FireFlow. See Implement changes with ActiveChange.
Palo Alto and Fortinet Devices

By default, when a rule with zone spanning is recommended for Palo Alto or Fortinet devices, FireFlow will recommend the zone "any".

If desired, you can configure FireFlow to recommend the specific multiple zones.

For more details, see FireFlow configuration parameter reference.

For layer 3 protocols (non-TCP/UDP/ICMP), the work order will only recommend using services that are already defined on the device. FireFlow will not recommend adding a new service for these protocols.

If the layer 3 protocol that was used in the change request is not found on the device, FireFlow issues a warning, and in the case when CLI recommendations would have been generated, they are aborted. For more details, see Change request field references.

Default recommendations will be to remove allowing rules.

Editing a request for Cisco ACI devices enables you to change details such as rule name, application profile, and service graph, as well as the EPG values selected for the new rule.

FireFlow support for EPGs

  • When relevant, FireFlow will first look for an EPG that matches the request exactly. If none is found, the narrowest existing EPG that satisfies the requirements will be automatically suggested.

  • If no relevant EPG exists at all, FireFlow will create a new one as part of the request.

FireFlow support for application profiles

For traffic change requests for IP addresses that are not sub-sets of existing EPGs, the work order will recommend creating a new EPG. Application profiles are handled as follows:

  • If the application profile is known, either from another EPG in the traffic line, or because the user has edited the work order, an EPG is created under the same application profile.
  • When multiple application profiles are known, the EPG is created with one of them only.
  • If no application profile is known, ActiveChange is disabled, and the user is prompted to specify the application profile. In such cases, add an application profile by editing the work order.

Advanced editing for EPGs

The Edit Work order dialog enables you to make changes to your work order, including to any new EPGs being created. For example, modify the name for a new EPG in the Name field, or click the Advanced Editing button to make additional changes.

The following image shows an example of how to select an Application Profile for a new Consumer EPG:

vzAny objects

By default, vzAny objects are not selected, but you can edit the change request to select them manually.

For example:

For Cisco ASA, to avoid object nesting in Work Order Recommendations:

When a service group contains the string ‘FireFlow’ in its name (for example "gr-FireFlow-25"), a new group is created that contains the contents of the previous group (eliminating nesting depth in service groups) plus any recommended changes.

Cloud device behavior differs as follows:

Amazon Web Services (AWS)

FireFlow will never recommend changing the rules in the NACL. If the traffic is completely blocked by the NACL, a warning appears in the work order stating this is the case. If the traffic is only partially blocked, a warning appears stating that the traffic might be blocked by the NACL.

If the relevant security group is full, a message appears. You must create a new security group and re-plan the change request.
Microsoft Azure

If a security set has only one network security group or subnet network security group, FireFlow will recommend changing it. If a security set has a network security group and a subnet network security group, FireFlow will not recommend changing the subnet network security group (even when it blocks the desired traffic).

If the relevant network security group is full, a message appears.

For Junos Space Security Director recommendations with zone spanning, you can deselect source / destination zone pairs for which you do not want to create a new rule.

For example:

Users can edit the NSX-T work order recommendation by:

  • Replacing groups (using advanced editing)

  • Re-positioning rules (using the Before Rule ID field)

    Note: Rules cannot be placed in a default Layer 3 section.

  • Adding or modifying the ‘context profile’ field

  • Adding or modifying the 'rule applied to' field

Note: Whenever the user edits the 'before rule' field, the ‘category’, ‘policy name’ and 'policy applied to' values may change after Save Changes is clicked.

  1. You can change the Ordered Layer index for Check Point R80.10 devices and higher. This allows you to locate tickets in the most suitable place in the Policy.

    To change the Ordered Layer Index in the Work order:
    Edit the Ordered Layer # field.

    The Ordered Layer # is shown in the policy:

  2. You can move a rule from the Inline to the Ordered Layer by changing the Before Rule Number.