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 Coat 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
Note for Panorama and FortiManager devices: Only rules with user any can be edited in the Implement stage.
To modify a rule that has specified users or groups (not any):
Do the following:
-
View the change request. For details, see View change requests.
-
If the change request has multiple devices or policies, click next to a device.
-
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:
-
If your change request includes only an Allow action, edit the values recommended by FireFlow as needed. Do the following:
-
At the top of the Work Order Recommendations area, click .
The Edit Work Order window appears.
-
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.
-
-
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:
-
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.
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.
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 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.
|
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/ESG values selected for the new rule.
FireFlow support for EPGs/ESGs
-
When relevant, FireFlow will first look for the narrowest existing EPG or ESG that satisfies the requirements and automatically suggested it.
-
If no relevant EPG/ESG exists at all, FireFlow will create a new one as part of the request.
-
You can work with both EPGs and ESGs but you can only use one type within a single traffic line.
FireFlow support for application profiles
For traffic change requests for IP addresses that are not sub-sets of existing EPGs/ESGs, the work order will recommend creating a new EPG/ESG . Application profiles are handled as follows:
- If the application profile is known, either from another EPG/ESG in the traffic line, or because the user has edited the work order, an EPG/ESG is created under the same application profile.
- When multiple application profiles are known, the EPG/ESG 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/ESGs
The Edit Work order dialog enables you to make changes to your work order, including to any new EPGs/ESGs 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. |
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.
-
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:
-
You can move a rule from the Inline to the Ordered Layer by changing the Before Rule Number.