Work order parameters

This section provides a reference of the work order configuration parameters available from the FireFlow ADVANCED CONFIGURATION area.

Note: Restart FireFlow after configuring the following parameters.

Configure work order creation for "No Action Required" change requests

In the Implement stage of a traffic change request lifecycle, FireFlow creates a work order consisting of a list of recommendations for implementing the requested change. If FireFlow detects that traffic is not routed through the device, then the work order states that no action is required.

In some cases involving Layer-2 devices, routing information may be missing, causing FireFlow to erroneously state that no action is required. You may therefore prefer to force FireFlow to create work orders suggesting a rule to add to the device policy, even when it has determined that no action is required.

Note: Such work orders will include a disclaimer stating the following: "The recommended change may contain irrelevant traffic due to missing routing information."

Name Value
ForceCreateWorkOrderForNA

0. To specify that work orders should state "No Action Required" when FireFlow detects that traffic is not routed through the device. (Default)

1. To force FireFlow to create work orders suggesting a rule to add to the device policy, even when FireFlow has determined that no action is required.

2. To only prevent removing parts of the traffic from the work order recommendation in case it is not routed.

Back to top

Configure work orders to include already allowed or blocked traffic

If a traffic line in a change request to allow or block traffic has already been allowed or blocked, the work order will not automatically include the already allowed or blocked traffic because nothing remains to be implemented on the device for this traffic. However, you can configure FireFlow to include already allowed or blocked traffic requested in work orders by setting the parameter ForceCreateWorkOrderForAlreadyAllowed to 1. If the existing policy already allows or blocks any traffic, then the work order will suggest adding new rules for these traffic lines.

Name Value
ForceCreateWorkOrderForAlreadyAllowed

0. To configure work orders not to include already allowed/blocked traffic (the work order will state: "no action required". (Default)

1. To configure work orders to include already allowed/blocked traffic

Back to top

Configure the network object translation method for work order creation

FireFlow provides two methods to perform network object translation: standard algorithms and a grep algorithm. When a large number of network objects are being used, translation is much faster when using the grep algorithm. The default threshold for using the grep algorithm is 500 network objects. If desired, you can change this threshold. In addition, you can disable the grep algorithm.

Name Value
Min_Host_Groups_Grep_Threshold

The desired threshold for number of network objects before using the grep algorithm.

The default value is 500.
Min_Host_Groups_Grep_Threshold 0. To enable the grep algorithm. (Default)

1. To disable the grep algorithm

Back to top

Configure work orders to include partially not-in-path traffic

By default, if part of a traffic line in a change request is not in a network map path that passes through the device, the work order will not include the not-in-path traffic because nothng needs to be implemented on the device for the sake of this traffic. In version 6.7 and below, the not-in-path traffic in a traffic line along with blocked traffic is included in the work order. If desired, you can configure FireFlow to include the not-in-path traffic in work orders.

Note: If the network map is inaccurate (paths are missing), it is advised to disable the FIP algorithm in AFA. In this case, this feature will automatically be disabled, and work orders will include all traffic.

Name Value
RemoveNotInPathAdressesInWorkOrder

0. To configure work orders to not remove not-in-path traffic.

1. To configure work orders to remove not-in-path traffic. (Default)

Back to top

Configure edit work orders to allow wider objects

By default, FireFlow allows editing a work order with objects that may contain more IP addresses than the original request, by using the Wider Object tab in the Advanced Editing Wizard. This allows you to add a subnet without having to re-plan the change request. Optionally, you can specify how wide of an object can be suggested.

If desired, you can disable this feautre, removing the Wider Object tab from the Advanced Editing Wizard.

Note: Allowing wider objects to be added to a work order may introduce risks, since the risk check will not be re-performed.

Name Value
ShowWiderOption

1. To enable the Wider Object tab in the Advanced Editing Wizard. (Default)

0. To disable the Wider Object tab in the Advanced Editing Wizard.
WiderObjectsSizeToSuggest

A copy of the default or current configuration, with the relevant modifications.

Each element includes the following properties:

  • requestedObjectSize. The number of IP addresses in the originally requested object.
  • maxWiderObjectSize. The maximum number of IP addresses for any object that the Advanced Editing Wizard will suggest as a replacement for an object of the size specified in the requestedObjectSize property.

Example:

The following example does the following:

  • Changes the maximum allowed width of suggested objects for objects containing 100 IP addresses to 512 IP addresses (from 256)
  • Includes a new item that specifies that the maximum allowed width of suggested objects for objects containing 512 IP addresses is 1024 IP addresses.

The change is highlighted.

[
 { "maxWiderObjectSize": 512, "requestedObjectSize": 100 },
{ "maxWiderObjectSize": 1024, "requestedObjectSize": 512 },
                 { "maxWiderObjectSize": 65536, "requestedObjectSize": 256 },
                  

              
                 { "maxWiderObjectSize": 16777216, "requestedObjectSize": 65536 }
              
                ]

Back to top

Configure edit work orders to include object naming at external sites

If desired, you can configure FireFlow to support object naming at an external site as a part of editing a work order. When this feature is enabled, a "..." button will appear next to every editable object in the edit work order dialog box. Clicking this button will instigate the following sequence:

  1. A new window opens, displaying the specified site and FireFlow sends the site a field ID.
  2. The user generates the new object name at the external site.
  3. The external site sends the object name and field ID back to FireFlow.
  4. FireFlow updates the field with the generated object name.
  5. When the user saves the work order, FireFlow saves the generated object name as a part of the work order.

Note: To enable this feature, aside from completing the following procedure, you must configure the external site to behave in the above specified manner.

Name Value
UseExternalSiteToGenerateHostNames

1. To enable configuring FireFlow to support object creation at an external site as a part of editing a work order.

0. To disable configuring FireFlow to support object creation at an external site as a part of editing a work order. (Default)
EditWorkOrderExternalSiteURL

The external site's URL.

For example, https://192.168.3.184/AFA/php/test/test.php.

Back to top

Configure edit work orders to allow empty fields

By default, empty fields are considered valid when editing a work order (partial Edit Work Orders can be saved). If desired, you can require that all fields are completed.

Name Value
AllowEmptyFieldsInEditWorkOrder

0. To disable allowing empty fields when editing a work order.

1. To enable allowing empty fields when editing a work order. (Default)

Back to top

Automatically send work orders to implementation team

Sometimes, changes to devices are implemented by a group of people who have no access to the FireFlow system. In this case, you can configure FireFlow to automatically generate a work order in PDF format and send it to the implementation team via email, each time a work order is created.

To automatically send work orders to an implementation team

  1. Log in to FireFlow for configuration purposes. For details, see Log in for configuration purposes.

  2. Enable generating work orders in PDF format, by doing the following:

    1. In the main menu, click Advanced Configuration.

    2. Click Global.

    3. Click Scrips.

    4. Click the Show Disabled link at the top right.

    5. Click 550 On completion of Create Work Order Create Summary PDF.

    6. In the Stage field, select TransactionCreate.
    7. Click Update.

  3. Enable automatic sending of emails with work orders in PDF format attached, by doing the following:

    1. In the main menu, click Advanced Configuration.
    2. Click Global.
    3. Click Scrips.
    4. Click the Show Disabled link at the top right.

    5. Click 560 On completion of Create Work Order Notify Work Order Recipient.

    6. In the Stage field, select TransactionCreate.
    7. Click Update.

  4. To customize the email template used for sending work orders, do the following:

    1. In the main menu, click Advanced Configuration.

    2. Click Global.

    3. Click Email Templates.

    4. Click Notify Work Order Summary.

    5. Edit the email content as desired.
    6. Click Update.

  5. Configure the email recipient, by doing one of the following:

    • When customizing the email template as described in the previous step, type the desired address in the To field.
    • Configure the following parameter:

        Name

    		Value
        WorkOrderRecipientEmail

    The email address to which to send the work order.

Note: If you configure the recipient email address using both methods, the email template overrides the configuration parameter.

Back to top

Configure inclusion of work details in flat tickets

By default, FireFlow does not include work order information in the XML of a change request (a flat ticket). If desired, you can change this.

Name Value
IncludeWorkOrderInXML

0. To disable inclusion of work order information in flat tickets. (Default)

1. To enable inclusion of work order information in flat tickets.

Back to top

Configure work order suggestions for drop traffic change requests

For traffic change requests which include a "Drop" action, the default work order suggestion is to add a drop rule to the policy. If desired, you can configure FireFlow to instead suggest removing a rule in the policy which allows the traffic.

Name Value
DropTrafficUsingDropRule

0. To configure work orders for drop traffic change requests to suggest removing an allow rule.

1. To configure work orders for drop traffic change requests to suggest adding a drop rule. (Default).

Back to top

Configure ACL exclusion for Cisco work orders

When calculating a work order for Cisco devices, FireFlow determines which ACLs should be updated. It is possible to configure FireFlow to exclude some ACLs based on regular expression matching of the ACL name. If an ACL is excluded, the check box next to it will appear unchecked when the user views the work order.

Note: ACLs can be excluded using more complex logic using the ExcludeAcl hook. See Using Hooks (see FireFlow hooks).

Name Value
ExcludeACLsInWorkOrderByName

A regular expression matching the names (or part of the names) of the ACLS to exclude.

' '(empty string). To configure work orders to not exclude any ACLs. (Default)

For example, to configure excluding all ACLs starting with 'mgmt' or 'global', case insensitive, set the configuration parameter to the following value:

gr!^\s*(mgmt|global)!i

Back to top

Configure work order results for F5 BIG-IP

For details, see Configuring Initial Plan Results for F5 BIG-IP.

Back to top

Configure rule position control for Check Point devices

When adding a new rule to a Check Point device, FireFlow determines where the rule can be placed in the policy. In the work order, the Before Rule field indicates that the new rule must appear before a specific rule so that, for example, the traffic is not dropped before it reaches the relevant allowing rule.

By default, you cannot edit the value of the Before Rule field to a value below a blocking rule. This prevents you from compromising the security policy. If desired, you can enable this ability, allowing you to add a rule to the policy wherever you want. This control may be desirable when you want to add a rule under a specific section header.

Note: When this feature is enabled, it is possible to "break" the policy. For example, if you are adding a rule to allow traffic and you add it below a rule which drops the traffic, the traffic will still be dropped. FireFlow will not prevent you from adding the rule as you specify, and a warning appears indicating the issue.

Name Value
SetBelowBlockingRule

0. To disable rule position control for Check Point devices. (Default)

1. To enable rule position control for Check Point devices.

Back to top

Configure rule position control for Palo Alto Panorama devices

When adding a new rule to a Palo Alto Panorama device, FireFlow determines whether the rule should be placed in the "pre" section or "post" section of the device group policy, so that policy is optimized. If desired, you can specify that every rule should always be placed in the "pre" section or "post" section.

Note: When FireFlow is configured to always place rules in the "post" section, it is possible that traffic could be dropped by the "pre" section or by the local rule base. If this is the case, the work order page will display the following warning: "Rules from higher level policies might override the requested traffic."

Name Value
PanoramaDefaultPolicySection

Pre. To specify all rules should be added to the "pre" section of the device group policy.

Post. To specify all rules should be added to the "post" section of the device group policy.

Calculated. To specify FireFlow should determine the most efficient place for each rule. (Default)

Back to top

Configure Check Point work orders to suggest rules only below a specified section

If desired, you can configure FireFlow work orders for Check Point devices to recommend new rules only below a certain section (for example, below stealth rules). FireFlow will search the section headers for the string, and only recommend new rules below the specified section.

Name Value
EditRuleSectionHeader

A part of the section header text.

For example, setting the value to stealth configures work orders to only recommend new rules below the section stealth.

Back to top

Configure security and log forwarding profiles for panorama devices

FireFlow provides the ability to configure a default value for the following fields in all Panorama work orders:

  • Security Profile
  • Log Forwarding Profile

By default, these fields are empty.

Note: Regardless of whether you set default values for these fields, you can modify them by editing individual work orders.

Name Value
PanoramaSecurityProfile

The desired default value for the security profile in all Panorama work orders.

The default value is none.
PanoramaLogForwardingProfile

The desired default value for the log forwarding profile in all Panorama work orders.

The default value is none.

Back to top

Configure shared level object creation for Panorama devices

This is relevant only for the Traffic Work Flow (not the multi-device object WF). By default, FireFlow recommends creating new objects for Panorama devices at the Device Group level. You can configure FireFlow to recommend creating new objects at the Shared level by setting PanoramaObjectsCreation to the value Shared.

Name Value
PanoramaObjectsCreation

The level at which FireFlow should create new objects.
Choose one of the following:

  • Shared

  • Device Group (Default)

Back to top

Configure zone recommendations for Palo Alto and Fortinet devices

FireFlow determines the source and destination zones from the source and destination IP addresses in the change request. By default, FireFlow will not recommend a rule with multiple zones in the source zone or destination zone fields. If the change request requires a rule which includes sources from multiple zones (or destinations from multiple zones), the recommended rule will always specify "any" zone for the source zone and/or destination zone fields.

If desired, you can configure FireFlow to support accurate zone spanning recommendations for Palo Alto and Fortinet devices. The recommendation for the source zone and destination zone fields will always include only the specific relevant zone(s), and you will be able to remove recommended zones while editing the work order. You can optionally enable the ability to select additional zones (from the device's available zones) when editing a work order, even if they were not detected as relevant.

Alternatively, you can configure FireFlow to always recommend the "Global" zone for Fortinet Devices.

Note: Fortinet devices version 4.x and below do not support multiple values in the source zone and destination zone fields.

Name Value
MultipleZonesRecommendation

1. To enable the ability to detect and recommend multiple, specific zones for Palo Alto and Fortinet devices. (Default)

0. To disable the ability to detect multiple, specific zones.
SelectUndetectedZones

1. To enable the ability to select additional zones while editing work orders for Palo Alto and Fortinet Devices. (Only relevant when MultipleZonesRecommendation is enabled.)

0. To disable the ability to select additional zones while editing work orders. (Default)
FortinetAlwaysRecommendGlobalZone

false. The recommended zones will be based on the IP address(es) in the change request. (Default)

true. The recommended zone will always be "Global".

Back to top

Configure the brands used in automatic selection

When a change request is opened for configured brands, FireFlow will first look for an object that matches the request exactly. If none is found, the narrowest existing object that satisfies the requirements will be automatically suggested.

In such cases, FireFlow also enables you to configure the brands available for selection.

Name Value
MinimalWiderObjectAutoSelection

A JSON array that contains all the device brands you want to support when selecting a wider object in change requests.

For example:

[
"ciscoaci"
]

Default: Empty

Back to top

Configure drop traffic request recommendations

FireFlow's default recommendation for drop traffic requests when an existing allow rule is found that perfectly matches the traffic specified in the request is to remove the existing rule.

Some device types also support disabling the rule. For supporting device types, FireFlow administrators can define that work orders always recommend disabling the rule instead of removing it.

Name Value
RemoveOrDisableRulesInTrafficFlow

Determines whether FireFlow recommends that you remove a perfectly matching rule or disable it, when a perfect allow rule match is found for a drop traffic request.

Relevant only for CISCO ASA or Check Point device types that support disabling rules.

0 = Remove

1 = Disable

Default = 0

Back to top

Configure new filters on user or common tenant

The following configuration parameter enables FireFlow administrators to determine whether new Cisco ACI filters are created on the user tenant, or on the common tenant.

Name Value
CiscoACICreateNewFiltersOnCommonTenant

Determine whether new Cisco ACI filters are created on the user tenant, or on the common tenant.

user = (Default) Filters are created on the user tenant

common = Filters are created on the common tenant

Back to top

Configure recommendations type when creating a work order

When a Work Order is created, by default FireFlow recommends modifying an existing rule. You can alternatively set FireFlow recommendations to add a new rule only or to enable the choice to modify or add a new rule.

Name Value
 AddRecTypeWorkOrder

Determines the recommendations type when a work order is created:

0 = (Default) FireFlow recommends modifying an existing rule (only).

1 = FireFlow recommends modifying an existing rule, with an option to add a rule.

2 = FireFlow recommends adding a new rule (only).

Back to top