Professional Documents
Culture Documents
Contents
Introduction ................................................................................................................................................... 1
FireFlow Advanced Configuration ............................................................................................................................................... 1
Configuration Options ................................................................................................................................................................. 1
Advanced Configuration Options ................................................................................................................................................ 2
Advanced Configuration Tools .................................................................................................................................................... 3
Consulting Log Files ................................................................................................................................................................... 4
Contacting Technical Support ..................................................................................................................................................... 5
AlgoSec FireFlow
Release 6.3
Contents
Setting the Default Workflow................................................................................................................................................... 133
Deleting Workflows ................................................................................................................................................................. 133
Viewing the Workflow XML ..................................................................................................................................................... 134
Viewing Individual Workflows' XML Files ........................................................................................................................ 134
Viewing the Workflow Configuration File ......................................................................................................................... 134
Installing Workflows ................................................................................................................................................................ 134
Discarding Workflow Changes ................................................................................................................................................ 135
Examples ................................................................................................................................................................................ 136
Example: Removing the Notify Requestor Stage ............................................................................................................ 136
Example: Allowing the Network Group to Approve Change Requests ............................................................................ 137
Example: Adding Another Approve Stage ....................................................................................................................... 139
AlgoSec FireFlow
Release 6.3
Contents
AlgoSec FireFlow
Release 6.3
Index........................................................................................................................................................... 269
CHAPTER 1
Introduction
This section introduces the AlgoSec FireFlow advanced configuration options and tools, as well as this
guide.
In This Chapter
FireFlow Advanced Configuration ..................................... 1
Configuration Options ........................................................ 1
Advanced Configuration Options ....................................... 2
Advanced Configuration Tools .......................................... 3
Consulting Log Files .......................................................... 4
Contacting Technical Support ............................................ 5
Configuration Options
You can perform the following customizations of FireFlow:
AlgoSec FireFlow
Release 6.3
Introduction
In addition, you can replace the text that appear throughout the FireFlow user interface, either with
custom texts, or with translations into any language. See Modifying FireFlow Interface Text (on page
222).
Integrating FireFlow with a third-party Change Management System
See Integrating FireFlow with External Change Management Systems (on page 235).
Using the FireFlow Web service
See Configuring the FireFlow Web Service (on page 255).
Configuring the import of user data from an LDAP server into FireFlow
See Importing User Data from an LDAP Server (on page 233).
Performing change request migration
AlgoSec provides an API for performing a one-time migration of historic change requests from an
existing Change Management System to FireFlow. For further information, contact AlgoSec.
Customizing the incoming email parsing format
In organizations where submitting requests to FireFlow via email is supported, all request emails must
confirm to the following format by default:
Source: <source>
Destination: <destination>
Service: <service>
Action: <action>
where:
<source> is the IP address, IP range, network, device object, or DNS name of the connection
source.
<destination> is the IP address, IP range, network, device object, or DNS name of the
connection destination.
<service> is the device service or port for the connection.
<action> is the device action to perform for the connection. This can be either of the following:
allow - Allow the connection.
drop - Block the connection.
If desired, you can change the required format for request emails. For further information, contact
AlgoSec.
AlgoSec FireFlow
Release 6.3
FireFlow includes a set of original configuration files that contain various FireFlow default settings. In
order to modify the default settings in a particular file, you create an override configuration file whose
content is copied from the original file and modified to suit your needs. If the override file exists,
FireFlow ignores the original file and refers only to the override file.
In order to access original and override files, you must log in to the FireFlow server via SSH with the
username "root". The default password for this user on an AlgoSec Hardware Appliance or a VM is
"algosec".
FireFlow restart utility
FireFlow includes a utility for restarting it after certain configuration changes are made. In order to use
this utility, you must log in to the FireFlow server via SSH with the username "root". The default
password for this user on an AlgoSec Hardware Appliance or a VM is "algosec". For further
information, see Restarting FireFlow (on page 11).
AlgoSec Firewall Analyzer user interface
In order to perform advanced configurations via the AlgoSec Firewall Analyzer user interface, you must
log in as an AFA administrator. For information on logging in to AlgoSec Firewall Analyzer, refer to the
AlgoSec FireFlow User Guide, Logging into the AlgoSec Firewall Analyzer Web Interface, or the
AlgoSec Firewall Analyzer User Guide.
Note: In order to access these log files directly, you must log in to the FireFlow server via SSH with the
username "root". The default password for this user on an AlgoSec Hardware Appliance or a VM is
"algosec".
Introduction
CHAPTER 2
2 Click FireFlow.
AlgoSec FireFlow
Release 6.3
Chapter 2
Advanced configuration settings can be accessed by clicking the Configuration and Advanced
Configuration main menu items. When domains are enabled, domain level administrators will not see the
Advanced Configuration option in the main menu.
CHAPTER 3
Restarting FireFlow
After making certain FireFlow configuration changes, it is necessary to restart all FireFlow workers that are
running background tasks, as well as restart Apache. The FireFlow restart utility enables you to perform all
the necessary restart actions with a single command.
Note: The procedures that require restarting FireFlow are marked as such in this guide.
To restart FireFlow
1 Log in to the FireFlow server using the username "root" and the related password.
2 Enter the following command:
restart_fireflow
All FireFlow workers that are currently running background tasks are restarted.
Apache is restarted.
11
CHAPTER 4
In This Chapter
Overview ............................................................................ 13
Customizing the Home Page Globally ............................... 14
Customizing the Home Page per Group ............................. 18
Customizing Pre-defined Search Results ........................... 22
Overview
If desired, you can customize the Home page on any of the following levels:
Globally
Global customization affects the Home page of all users. It enables adding or removing any screen
element.
See Customizing the Home Page Globally (on page 14).
Per group
Per-group customization affects the Home page of all users belonging to a specific user group. It enables
adding screen elements to the Home page, but not removing those that were added via global
customization.
See Customizing the Home Page per Group (on page 18).
Per user
Per-user customization affects the Home page of a specific user only. It enables adding screen elements
to the Home page, but not removing those that were added via global or per-group customization.
Refer to the AlgoSec FireFlow User Guide, Customizing the FireFlow Home Page.
Elements that can be added to the Home page include the following:
13
AlgoSec FireFlow
Release 6.3
Note: When domains are enabled, domain level administrators will not see the Advanced Configuration
option in the main menu. To login as management do not enter a domain name.
3 Click Global.
14
Chapter 4
5 For each element you want to add to the Home page, do the following:
a) In the Available list box, select the element you want to add.
15
AlgoSec FireFlow
Release 6.3
or
Pre-defined search results consisting of a list of open change requests in the system
that have a due date that has passed, that is the current date, or that is the day after the
current date.
Pre-defined search results consisting of a list of change requests in the system that
are owned by the Controllers group.
Pre-defined search results consisting of a list of change requests in the system that
are owned by the Network group.
Pre-defined search results consisting of a list of change requests in the system that
are owned by the Security group.
"N" Change Requests Relevant Pre-defined search results consisting of a list of change requests in the system that
to My Groups
are relevant to the user groups to which you belong.
"N" Change Requests that are
due to be recertified
Pre-defined search results consisting of a list of traffic change requests in the system
that expired, and which should be recertified.
"N" Change Requests Flagged Pre-defined search results consisting of a list of change requests in the system that
by Requestor as "Change Does have been flagged by the requestor as "Change Does Not Work".
Not Work"
"N" Change Requests that
Received Requestor's
Response
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Validate stage and received the requestor's confirmation that the
requested change was implemented successfully.
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Approve stage.
"N" Change Requests to Create Pre-defined search results consisting of a list of change requests in the system that
Work Order
are currently in the Implement stage and awaiting a work order to be created.
"N" Change Requests to
Expire in the Next 30 days
Pre-defined search results consisting of a list of change requests in the system that
will expire within the next 30 days.
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Implement stage and awaiting implementation.
Pre-defined search results consisting of all change requests in the system that are
currently in the Plan stage.
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Review stage and awaiting a controller's review.
16
Chapter 4
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Approve stage, and for which a rule removal notification will be
sent to the rule's traffic requestors.
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Validate stage.
"N" Change Requests Waiting Pre-defined search results consisting of a list of change requests in the system that
for Removal Response from
are currently in the Approve stage and awaiting confirmation from the rules traffic
Rule Requestors
requestors that the requested rule removal is approved.
"N" Change Requests Waiting Pre-defined search results consisting of a list of change requests in the system that
for Requestor's Response
are currently in the Validate stage and awaiting the requestor's confirmation that the
requested change was implemented successfully.
"N" New Change Requests
Pre-defined search results consisting of a list of change requests in the system that
are new and still in the Request stage, and whose traffic has already been checked
against devices.
Pre-defined search results consisting of a list of change requests in the system that
are currently open.
Pre-defined search results consisting of a list of parent requests in the system that are
currently in the Implement stage and awaiting implementation of the relevant
sub-requests.
Pre-defined search results consisting of all recertification requests in the system that
are currently in the Plan stage.
"N" Recertification Requests Pre-defined search results consisting of a list of recertification requests in the system
to Send Recertify Notification that are currently in the Approve stage, and for which a recertification notification
to Traffic Requestors
will be sent to the traffic requestors.
"N" Recertification Requests
to Validate
"N" Rejected Change Requests Pre-defined search results consisting of a list of change requests in the system that
were rejected.
"N" Resolved Change
Requests
Pre-defined search results consisting of a list of change requests in the system that
have been resolved.
Pre-defined search results consisting of a list of all change requests in the system that
are new and still in the Request stage, including change requests whose traffic has
not yet been checked against devices.
17
AlgoSec FireFlow
Release 6.3
Bookmarked Change Requests A list of change requests that the user bookmarked.
My Change Requests
Pre-defined search results consisting of a list of change requests in the system that
are owned by you.
RefreshHomepage
Pre-defined search results consisting of a list of change requests in the system that
currently have no owner.
A custom search that was saved under "FireFlow's saved searches", and which is
available to your user role.
For information on saving searches, see Saving Searches.
Chart Name
A chart that was saved under "FireFlow's saved searches", and which is available to
your user role.
For information on saving charts, see Saving Charts.
18
Chapter 4
3 Click Groups.
The Select a group page appears.
19
AlgoSec FireFlow
Release 6.3
a) In the Find groups whose area, select the desired options in the drop-down lists, and type the search
string in the field provided.
b) To include disabled groups in the search, select the Include disabled groups in listing check box.
c) Click Go.
The groups matching the search criteria are displayed.
5 Click the desired group's name.
The Editing membership for group page appears.
20
Chapter 4
7 For each element you want to add to the Home page, do the following:
a) In the Available list box, select the element you want to add.
For information on each element, see Home Page Elements (page 16).
b) Click
.
The selected element moves to the right list box. The order that the elements appear in the box
represents the order in which they will appear in the Home page.
Note: All custom elements will appear above the globally added pre-defined search results in the
Home page.
c) To move the element up or down in the box, select the element and click the
buttons.
d) To delete the element, select it and click Delete.
Your changes are saved.
8 To reset the page's fields to their default values, click Reset to default.
or
21
AlgoSec FireFlow
Release 6.3
3 In the Load saved search drop-down list, under FireFlow's saved searches, select the relevant
pre-defined search.
22
Chapter 4
4 Click Load.
The search is loaded.
5 In the Display Columns area, modify the search results' appearance as desired.
For information, refer to the AlgoSec FireFlow User Guide, Column Format Fields.
6 Click Save.
The pre-defined search's definition is modified.
7 Click Apply.
The Query Builder page reappears with your changes.
8 Click Save.
The pre-defined search's definition is modified.
23
CHAPTER 5
In This Chapter
Disabling Privileged Users ................................................. 25
Enabling Privileged Users .................................................. 27
25
AlgoSec FireFlow
3 Click Users.
The Select a user page appears.
26
Release 6.3
Chapter 5
a) In the Find all users whose area, select the desired options in the drop-down lists, and type the search
string in the field provided.
b) Click Go.
The users matching the search criteria are displayed.
5 Click on the desired user's name.
The Modify the user page appears.
27
AlgoSec FireFlow
Release 6.3
3 Click Users.
The Select a user page appears.
4 Search for the desired user, by doing the following:
a) In the Find all users whose area, select the desired options in the drop-down lists, and type the search
string in the field provided.
b) Select the Include disabled users in search check box.
c) Click Go.
The users matching the search criteria are displayed.
5 Click on the desired user's name.
The Modify the user page appears.
6 Select the User enabled check box.
7 Click Save.
The user is enabled.
28
CHAPTER 6
In This Chapter
Adding User Groups........................................................... 29
Editing User Groups ........................................................... 32
Managing Group Members ................................................ 33
Assigning Global and Queue Rights to User Groups ......... 35
Configuring Group Rights for Custom Fields .................... 36
Disabling User Groups ....................................................... 41
Enabling User Groups ........................................................ 41
29
AlgoSec FireFlow
3 Click Groups.
The Select a group page appears.
30
Release 6.3
Chapter 6
5 Complete the fields using the information in Group Fields (page 31).
6 Click Save.
7 Specify which users and groups should be members in the new user group.
See Managing Group Members (on page 33).
Note: If desired, this step can be skipped and performed later on, as described in the AlgoSec FireFlow
User Guide, Adding Users to FireFlow User Groups.
8 If you did not copy settings from another group, or if you copied settings and would like to modify them,
do the following:
a) Customize the group's Home page.
See Customizing the Home Page per Group (on page 18).
b) Assign global and queue rights to the user group.
See Assigning Global and Queue Rights to User Groups (on page 35).
c) Configure the group's rights for each custom field.
See Configuring Group Rights for Custom Fields (on page 36).
Group Fields
In this field...
Do this...
Name
Description
Group LDAP DN
31
AlgoSec FireFlow
Release 6.3
Enabled
To assign this group the same settings as another group, select the group from which to
copy settings.
The following settings will be copied from the selected group:
Group rights
Global permissions
Queue permissions
Rights for custom fields
Home page settings
Note: It is recommended to select this option when creating a new group, as it
significantly shortens the group creation process.
To revoke any group rights that were assigned to this group, but which are not assigned
to the group in the Copy Group Rights and Home Page Settings from group field, select
this option.
This field only appears when editing a user group.
32
Chapter 6
3
4
5
6
33
AlgoSec FireFlow
Release 6.3
34
Chapter 6
Note: If you do not specify a user, then the first member of the group will become the default assignee.
9 Click Save.
By viewing a single user group and then assigning it the desired global and queue rights
See Configuring a Group's Global and Queue Rights (on page 35).
By viewing all global rights and then assigning them to the desired user group
See Configuring Global Rights for Groups (on page 178).
By viewing all queue rights and then assigning them to the desired user group
See Configuring Queue Rights for Groups (on page 183).
35
AlgoSec FireFlow
Release 6.3
The Editing Rights on Global actions area enables you to grant rights for global actions, and the Editing
Rights on Queue actions area enables you to grant rights for queue rights.
7 To assign rights, do the following in the relevant area:
a) In the New rights list box, select the rights you want to assign this group.
To select multiple rights, press Ctrl while you click on the desired rights.
b) Click Modify Rights.
The selected rights appear in the Current rights area.
8 To revoke rights, do the following in the relevant area:
a) In the Current rights area, select the check boxes next to the rights you want to revoke.
b) Click Modify Rights.
The selected rights are removed from the Current rights area.
36
Chapter 6
For information on both types of custom fields, see Working with Custom Fields (on page 43).
37
AlgoSec FireFlow
38
Release 6.3
Chapter 6
5 Complete the fields using the information in Modify Group Rights Fields (page 39).
6 Click Submit.
Modify Group Rights Fields
In this field...
Do this...
System groups
In this area, select the level of rights that each system (built-in) group should have for
this field.
The system groups are:
Everyone. Represents all users, including both privileged and unprivileged users.
Privileged. Represents all information security and network operations users, as
well as any user-defined user groups.
Unprivileged. Represents requestors.
The available levels of rights are:
AdminCustomField. Users in this group can view and modify the field's
definition (for example, they can modify the field's name, disable it, and so on).
ModifyCustomField. Users in this group can modify the field's value, but cannot
view the field.
SeeCustomField. Users in this group can view the field, but cannot modify its
value.
(no value). Users in this group cannot view or modify the field.
In this area, select the level of rights that each user-defined user group should have
for the field.
The available levels of rights are:
AdminCustomField. Users in this group can view and modify the field's
definition (for example, they can modify the field's name, disable it, and so on).
ModifyCustomField. Users in this group can modify the field's value, but cannot
view the field.
SeeCustomField. Users in this group can view the field, but cannot modify its
value.
(no value). Users in this group cannot view or modify the field.
Reset
Click this button to remove all your unsaved modifications to the fields on this page.
39
AlgoSec FireFlow
40
Release 6.3
Chapter 6
AlgoSec FireFlow
5
6
7
8
42
Release 6.3
CHAPTER 7
In This Chapter
Overview ............................................................................ 43
Adding User-Defined Custom Fields ................................. 44
Editing User-Defined Custom Fields ................................. 49
Editing FireFlow Fields ...................................................... 49
Disabling User-Defined Custom Fields.............................. 51
Enabling User-Defined Custom Fields............................... 51
Configuring the Order of User-Defined Custom Fields ..... 52
Overview
FireFlow includes two types of custom fields:
You can edit, disable, configure the order of, and configure groups rights for custom fields. For
information on configuring a custom field's group rights, see Configuring Group Rights for
User-Defined Custom Fields (on page 37).
FireFlow fields
43
AlgoSec FireFlow
Release 6.3
FireFlow comes with a set of built-in custom fields called FireFlow fields. You can modify the display
name and description of such fields. In addition, you can configure groups rights for them, as described
in Configuring Group Rights for FireFlow Fields (on page 39).
44
Chapter 7
5 Complete the fields using the relevant information in Custom Field Page Fields (page 46).
6 Click Create.
Additional fields appears.
45
AlgoSec FireFlow
Release 6.3
7 Complete the fields using the relevant information in Custom Field Page Fields (page 46).
8 Click Save.
If the new field is a list (that is, you chose one of the "Select" options in the Type field), and you chose to
specify which values should be included in the list in the Values area of this page (that is, you chose
Provide list of values below in the Field values source field), additional fields appear in the Value area.
Do any of the following:
To add more values to the list, do the following for each value you want to add:
1. Complete the new fields using the relevant information in Create a Custom Field Page Fields
(page 46).
2. Click Save.
The value is added, and additional fields appear in the Value area.
To delete existing values from the list, do the following:
1. Select the check box next to each value you want to delete.
2. Click Save.
The specified values are deleted.
The new field appears throughout the FireFlow user interface.
Note: By default, all user groups (including the Unprivileged group) are granted SeeCustomField and
ModifyCustomField rights for the new custom field, except for the Read-Only group, which is granted only
SeeCustomField rights. The Admin group is also granted AdminCustomField rights for the new custom
field. If you would like to modify group rights for the new custom field, see Configuring Group Rights for
User-Defined Custom Fields (on page 37).
Custom Field Page Fields
In this field...
Do this...
Name
Description
Display Name
Type the name that should represent the field in the FireFlow interface.
Category
46
Chapter 7
additional for destination. Allows creating a custom field that appears below a traffic
change request's Destination field. For example, select this category if you want to
add a comment field next to a traffic destination.
additional for service. Allows creating a custom field that appears below a traffic
change request's Service field. For example, select this category if you want to add a
comment field next to a traffic service.
Type
If the new field is a list (that is, you chose one of the "Select" options in the Type field),
select the source of the values that should appear in the list. This can be any of the
following:
Provide list of values below. The list of values specified in the Value area at the
bottom of this page
Firewall names
Firewall hostgroup names
Firewall service group names
Available Workflows
Applies To
47
AlgoSec FireFlow
Link values to
Release 6.3
If you want the field's value to link to a Web page, enter the URL that should open upon
clicking the link.
The URL can include parameters, which FireFlow will replace as follows:
FireFlow will replace this parameter...
With this...
__id__
The record ID
__CustomField__
If you want the field to display a Web page, enter the URL of the desired Web page.
The URL can include the same parameters as Link values to.
For example, if you specify the URL
https://Third-party_system/show_ticket?id=__CustomField__,
and the field's value for a specific change request is 123, then the field will display the
Web page https://3rd_party_system/show_ticket?id=123.
Default Value
Validation
Select the form of validation to perform for this field. This can be any of the following:
(?#Mandatory). The field is mandatory. FireFlow will require this field to be filled
in.
(?#Digits).^[d\.]+$. The field's value must be a number.
(?#Year).^[12]\d{3}$. The field's value must be a year.
None. To specify that FireFlow should not perform validation for the field, do not
select a value.
Select this option to indicate that the custom field should only appear in the FireFlow
interface if it has a value.
Enabled
Values
If the new field is a list (that is, you chose one of the "Select" options in the Type field),
and you chose to specify which values should be included in the list in the Values area of
this page (that is, you chose Provide list of values below in the Field values source field),
then specify the desired values using the fields in this area.
Sort
Type a whole number indicating the value's position in the list. For example, if the value
should appear first in the list, type 1.
Name
Description
48
Chapter 7
5 Modify the fields as desired, using the information in Custom Field Page Fields (page 46).
6 Click Save.
AlgoSec FireFlow
50
Release 6.3
Chapter 7
AlgoSec FireFlow
Release 6.3
52
Chapter 7
Within each category, the fields are listed in the order that they will appear in the FireFlow Web
interface.
53
CHAPTER 8
In This Chapter
Customizing the Suggested Sources/Destinations List ...... 55
Customizing the Common Services List ............................ 56
Controlling Whether Wizard Tabs Appear ........................ 57
You can customize this list as desired, and even remove the Suggested tab entirely.
55
AlgoSec FireFlow
Release 6.3
Note: This is the original suggested sources/destinations list file, and it can be used to revert to defaults,
as needed. Do not modify this file.
3 Under the directory /usr/share/fireflow/local/etc/site/, copy the contents of the original
file into an override file that is also called SuggestedAddressObjects_Config.xml.
4 Open the override file.
5 To add a suggested source/destination to the list, add the following tags, anywhere between <objects>
and </objects>:
<object name="objectName">
<value>objectValue</value>
</object>
Where:
objectName is the source/destination name that should appear in the Suggested list.
objectValue is the value to which FireFlow should resolve the source/destination name.
For example, to add the source/destination "lab", which FireFlow should resolve to IP address
192.168.2.0/24, add the following:
<object name="lab">
<value>192.168.2.0/24</value>
</object>
Note: The source/destination "my computer" is built-in. FireFlow resolves it to the IP address of the
user's computer, which FireFlow automatically detects from the browser.
6
7
8
9
To remove a suggested source/destination from the list, delete the relevant tags.
To remove the Suggested tab from the wizards, delete the contents of this file.
Save the override file.
Restart FireFlow.
See Restarting FireFlow (on page 11).
56
Chapter 8
You can customize this list as desired, by adding, editing, and deleting custom services in AlgoSec Firewall
Analyzer. For instructions, refer to the AlgoSec Firewall Analyzer User Guide.
Privileged users
See Controlling Whether Wizard Tabs Appear for Privileged Users and Requestors (on page 57).
Requestors
See Controlling Whether Wizard Tabs Appear for Privileged Users and Requestors (on page 57).
Anonymous users using the No-Login Web form
See Controlling Whether Wizard Tabs Appear in the No-Login Form (on page 60).
57
AlgoSec FireFlow
3 Click Global.
The Admin/Global configuration page appears.
58
Release 6.3
Chapter 8
59
AlgoSec FireFlow
Release 6.3
5 In the FireFlow_SiteConfig.pm file, set these configuration items' values to one of the following:
1 - Display this tab. This is the default.
0 - Do not display this tab.
For example, to remove the Common tab, set the configuration item as follows:
Set($AllowAnonymousUserSeeCommonServiceObjects, 1);
60
CHAPTER 9
In This Chapter
Overview ............................................................................ 61
Configuring Change Request Creation from File ............... 62
Disabling Change Request Creation from File................... 64
Overview
Requestors can create new change requests from files attached to change requests. The process is as follows:
1 The requestor chooses a request template that supports creating change requests from file, such as
FireFlow's built-in sample template "240: Sample - Upload change requests from Excel". The requestor
then attaches a file specifying the desired change's details.
Note: In order to support creating change requests from file, a request template's Create change requests
from file field must be set to "Yes", and the Request Type field must be set to "Traffic Change".
2 The requestor submits the change request.
3 FireFlow runs a parsing script that converts the attached file to XML format.
If the parsing script is configured for single change request creation, then all traffic lines in the file are
interpreted as multiple traffic lines in a single change request. If the script is configured for multiple
change request creation, then each traffic line in the file is interpreted as a separate change request, (and
the change requests will all be linked to each other via their Depends On field).
4 FireFlow converts the XML to one or more change requests.
By default, FireFlow uses an out-of-the-box parsing script,
/usr/share/fireflow/local/bin/parse_excel_example.pl, which supports creating multiple
change requests from file, where all of the change request data is on a single worksheet and the file format is
one of the following:
If desired, you can configure change request creation from file in the following ways:
AlgoSec FireFlow
Release 6.3
You can view a sample worksheet filled with data that is expected by the out-of-the-box parsing script under
/usr/share/fireflow/local/extras/Firewall Rules Request Example.xls.
62
Chapter 9
c) Uncomment the my $mode line that reflects the mode you want to use, and comment the my $mode
line that reflects the mode you do not want to use.
d) For example, to create a single change request from file, modify the lines as follows:
# In this example: Multiple tickets mode
# my $mode = $MULTIPLE_TICKETS_MODE;
# Set mode to $SINGLE_TICKETS_MODE if you wish to work in single ticket mode
my $mode = $SINGLE_TICKETS_MODE;
63
AlgoSec FireFlow
Release 6.3
64
CHAPTER 10
In This Chapter
Overview ............................................................................ 65
Modifying Email Templates ............................................... 66
Overview
FireFlow sends emails to users upon various events in the change request lifecycle. It uses the following a
set of templates to create the emails' content.
FireFlow Templates
This template...
Transaction
Correspondence
Requestors
Resolved
Requestors
Autoreply
Requestors
65
AlgoSec FireFlow
3 Click Global.
66
Release 6.3
Chapter 10
67
AlgoSec FireFlow
68
Release 6.3
Chapter 10
Represents...
For example...
{$Ticket->id}
364
{$Ticket->Subject}
{$Ticket->Status}
plan
{$Ticket->RequestorAddresses}
john.doe@mycompany.com
{$Ticket->OwnerObj->Name}
{$Ticket->getTicketAsXML()}
The change request in XML format (a See Flat Ticket Example (on page 116).
flat ticket)
69
AlgoSec FireFlow
Release 6.3
70
The date and time at which the email Mon Nov 17 16:58:44 2008
is sent
CHAPTER 11
In This Chapter
Overview ............................................................................ 71
About VisualFlow .............................................................. 73
Getting Started with VisualFlow ........................................ 74
Adding Workflows ............................................................. 78
Workflow Condition Syntax .............................................. 81
Editing Workflows ............................................................. 87
Working with Statuses........................................................ 87
Working with Actions ........................................................ 95
Working with SLAs ........................................................... 129
Reordering Workflows ....................................................... 133
Setting the Default Workflow ............................................ 133
Deleting Workflows ........................................................... 133
Viewing the Workflow XML ............................................. 134
Installing Workflows .......................................................... 134
Discarding Workflow Changes .......................................... 135
Examples ............................................................................ 136
Overview
FireFlow assigns each change request to a workflow that controls the change request's lifecycle, including
the actions that can be performed on the change request, the behavior associated with each action, and the
possible change request statuses. In order to determine which workflow to use for a change request,
FireFlow performs the following steps:
1 FireFlow refers to the template that the requestor selected for the change request.
2 If the template specifies a workflow, FireFlow assigns the change request to that workflow.
3 If the template does not specify a workflow, then FireFlow refers to a set of conditions that determine
which workflow should be assigned.
4 If FireFlow fails to assign a workflow based on the set of conditions, then FireFlow assigns the change
request to the default workflow (which, by default, is the Standard workflow).
71
AlgoSec FireFlow
Release 6.3
FireFlow comes with the following set of built-in workflows, located under
/usr/share/fireflow/local/etc/Workflows/:
Built-In Workflows
Workflow
File Name
Description
Standard
Standard_Config.xml
Generic
Generic_Config.xml
Request
Approve
Implement
Validate
Resolved
Audit
Multi-Approval
Multi-Approval_Conf
ig.xml
Request
Plan
Approve
Review
Implement
Validate
Match
Resolved
Audit
Parallel-Approva Parallel-Approval_C
onfig.xml
l
Request
Plan
Approve
Review
Implement
Validate
Resolved
Audit
Change-Object
Change-Object_Confi
g.xml
Request
Approve
Implement
Validate
Resolved
Audit
Rule-Removal
Rule-Removal_Config
.xml
Request
Approve
Implement
72
Lifecycle Stages
Request
Plan
Approve
Implement
Validate
Match
Resolved
Audit
Chapter 11
Web-Filter
Web-Filter_Config.x
ml
Request-Recertif Request-Recertifica
tion_Config.xml
ication
Validate
Resolved
Request
Plan
Approve
Implement
Validate
Match
Resolved
Audit
Request
Approve
Implement
Validate
Resolved
Audit
You cannot modify the built-in workflows; however, you can create new ones as desired. For you
convenience, FireFlow allows you to create variations of existing workflows (both built-in and custom
ones), by duplicating the relevant workflow and then modifying it.
Furthermore, you can modify the set of conditions determining which workflow should be assigned, when
the template does not specify a workflow.
You can work with workflows in the following ways:
This section explains how to work with workflows using VisualFlow. For information on working with
workflows via XML, see Working with Workflows via XML (on page 143).
About VisualFlow
VisualFlow enables you to add, edit, and delete custom workflows in a Web interface, without any need to
manually edit the workflow XML files.
All workflow changes are saved locally as drafts. In order for the changes to take effect, you must install the
workflows on FireFlow. The changes are exported to the workflow XML files (overwriting the existing
settings), which are then imported to FireFlow. See Installing Workflows (on page 134).
If you have not yet installed your changes, you can choose to discard them. VisualFlow will be refreshed
from the existing workflow XML files. See Discarding Workflow Changes (on page 135).
73
AlgoSec FireFlow
Accessing VisualFlow
To access VisualFlow
1 Log in to FireFlow for advanced configuration purposes.
See Logging in for Advanced Configuration Purposes (on page 7).
2 In the main menu, click Advanced Configuration.
The Advanced Configuration page appears.
3 Click VisualFlow.
74
Release 6.3
Chapter 11
VisualFlow opens in a new browser tab, displaying the List of Workflows page.
75
AlgoSec FireFlow
Release 6.3
Toolbar. Displays your username and a link to information about the VisualFlow version.
76
Chapter 11
For information on the various layout elements, click Show legend or see the following table.
3 To zoom in, click the
icon.
The workflow layout is magnified. Use the scroll bar to view the desired part of the layout.
4 To zoom out, click the
icon.
The workflow layout returns to its regular size.
5 To print the workflow layout:
a) Click
.
The workflow layout opens in a new tab.
b) Use your browser's Print button to print the layout.
6 To view only the layout elements that are related to a specific action or status, click on the desired
action/status.
The Edit Action or Edit Status page appears, and the Layout area displays only those elements that are
directly related to the selected action/status.
Represents...
A single workflow stage.
A status.
Click to edit the status's details.
A status that is currently being edited.
An action.
77
AlgoSec FireFlow
Release 6.3
A conditional action.
A parallel action.
Exiting VisualFlow
To exit VisualFlow
Adding Workflows
Adding new workflows is done by creating a copy of an existing workflow and then modifying the copy.
78
Chapter 11
For example, if you duplicated the Standard workflow, and there is already a workflow called
Standard-Copy-1, then the new workflow will be called Standard-Copy-2.
A message at the top of the screen informs you that changes have been made to the workflows.
4 Do one of the following:
Next to the new workflow, click Edit.
Click on the workflow's name.
79
AlgoSec FireFlow
Release 6.3
5 In the Edit workflow details area, complete the fields using the information in Workflow Details Fields
(page 80).
When domains are enabled, there is a Domains selection box in the Edit workflow details area.
6 Click Save Draft.
7 Add, edit, and delete workflow statuses as desired.
See Working with Statuses (on page 87).
8 Add, edit, and delete workflow actions as desired.
See Working with Actions (on page 95).
9 Add, edit, and delete SLOs in the workflow's SLA as desired.
See Working with SLAs (on page 129).
Workflow Details Fields
In this field...
Do this...
Name
Domains
Specify the domains in which the workflow should be available, by doing one of the
following:
To specify that the workflow should be available in all domains, select the All check
box.
To specify that the workflow should be available only in specific domains, clear the
All check box, then hold down the Ctrl key while clicking on the desired domains'
80
Chapter 11
names.
Description
Configuration File
Type a prefix for the workflow file name associated with this workflow. The workflow
file is named Prefix_Config.xml, where Prefix is the string you enter in this field.
By default, the prefix is the workflow's name.
Enabled
Specify whether this workflow should be enabled, by choosing one of the following:
Yes. The workflow is enabled and will appear in the FireFlow interface.
No. The workflow is disabled. It will not appear in the FireFlow interface, and no
change requests will have this workflow.
The default value is Yes.
Condition
Type the condition under which a workflow should be assigned to change requests,
when the change request's template does not specify a workflow.
For information on the required syntax, see Workflow Condition Syntax (on page 81).
Where field is a supported field in FireFlow, and value is the field's value. For information on supported
fields, see Supported Fields (on page 81). For example, the following query specifies that the change
request status must be "new":
Status = 'new'
You can use != to indicate "not". For example, the following query specified that the change request must
not be "new":
Status != 'new'
It is possible to use Boolean operators between field-value pairs. For a list of supported operators, see
Supported Boolean Operators (on page 86). For example, the following query specifies that the change
request status must be "new", and the owner must be John Smith:
Status = 'new' AND Owner = 'John Smith'
For more intricate queries, you can use parentheses to group field-value pairs and operators. For example,
the following query specifies that the change request status must be "new" or "plan", and the owner must be
John Smith or Sue Michaels.
(Status = 'new' OR Status = 'plan') AND (Owner = 'John Smith' OR Owner = 'Sue
Michaels')
Supported Fields
There are two types of supported fields:
Standard fields
81
AlgoSec FireFlow
Release 6.3
These fields should be written as they appear in Standard Fields (page 82). For example:
Subject = 'Allow Web Access'
Custom fields
These fields include those listed in Custom Fields (page 84), as well as any fields added by users. They
should be used in the following format:
'CF.{field}'
Where field is the name of the custom field.
For example:
'CF.{Firewall Brand}' = 'Check Point'
Standard Fields
Field
Description
Id
Subject
Content
Text that appears in the original change request description or in a comment or reply
added to the change request.
Content-Type
Filename
Status
Owner
Creator
LastUpdatedBy
Requestor.EmailAddress
Requestor.Name
Requestor.RealName
Requestor.Nickname
Requestor.Organization
Requestor.Address1
Requestor.Address2
Requestor.WorkPhone
Requestor.HomePhone
Requestor.MobilePhone
Requestor.PagerPhone
Requestor.id
Cc.EmailAddress
The email address of a user who receives copies of email messages for the change
request.
Cc.Name
The username of a user who receives copies of email messages for the change
request.
82
Chapter 11
Cc.RealName
The full name of a user who receives copies of email messages for the change
request.
Cc.Nickname
The nickname of a user who receives copies of email messages for the change
request.
Cc.Organization
The organization of a user who receives copies of email messages for the change
request.
Cc.Address1
The primary mailing address of a user who receives copies of email messages for the
change request.
Cc.Address2
The secondary mailing address of a user who receives copies of email messages for
the change request.
Cc.WorkPhone
The office telephone number of a user who receives copies of email messages for the
change request.
Cc.HomePhone
The home telephone number of a user who receives copies of email messages for the
change request.
Cc.MobilePhone
The mobile telephone number of a user who receives copies of email messages for
the change request.
Cc.PagerPhone
The pager telephone number of a user who receives copies of email messages for the
change request.
Cc.id
The ID of a user who receives copies of email messages for the change request.
Owner.EmailAddress
Owner.Name
Owner.RealName
Owner.Nickname
Owner.Organization
Owner.Address1
Owner.Address2
Owner.WorkPhone
Owner.HomePhone
Owner.MobilePhone
Owner.PagerPhone
Owner.id
Created
Resolved
Last.Updated
Due
Priority
RefersTo
The ID numbers of change requests to which this change request refers, separated by
spaces.
83
AlgoSec FireFlow
ReferredToBy
Release 6.3
The ID numbers of change requests that refer to this change request, separated by
spaces.
Custom Fields
Field
Description
Expires
Requested Source
The IP address, IP range, network, device object, or DNS name of the connection
source, as specified in the original request.
Requested Destination
The IP address, IP range, network, device object, or DNS name of the connection
destination, as specified in the original request.
Requested Service
The device service or port for the connection, as specified in the original request.
Requested Action
The device action to perform for the connection, as specified in the original request.
The source NAT value to which the connection's source should be translated, as
specified in the original request.
The port value to which the connection's port should be translated, as specified in the
original request.
Workflow
Owning Group
CMS ticket id
Firewall Name
Firewall IP Address
Firewall Brand
Firewall Policy
The date and time at which the last report for this device was generated.
Change Description
Change Source
The IP address, IP range, network, device object, or DNS name of the connection
source, as planned during the Plan stage.
Change Destination
The IP address, IP range, network, device object, or DNS name of the connection
destination, as planned during the Plan stage.
Change Service
The device service or port for the connection, as planned during the Plan stage.
Change Action
The device action to perform for the connection, as planned during the Plan stage.
84
Chapter 11
The source NAT value to which the connection's source should be translated, as
planned during the Plan stage.
The port value to which the connection's port should be translated, as planned during
the Plan stage.
The type of NAT (Static or Dynamic), as planned during the Plan stage.
Change Implementation Notes The words that appear in the change request's implementation notes, if the change
request has completed the Implement stage.
Request Risk Check Result
The number and/or and severity of risks that implementation of the planned change
would entail.
Form Type
The type of form used for the change request (Traffic Change, Object Change, or
Generic Change).
Risks Number
The number of risks detected for the planned change, if the change request has
completed the risk check in the Approve stage.
Risks Details
Details about the risks detected for the planned change, if the change request has
completed the risk check in the Approve stage.
Translated Source
Translated Destination
The action for an object change request, as specified during the Plan stage
(AddIPsToObject / RemoveIPsFromObject / NewObject / DeleteObject).
Translated Service
Automatically Implemented
An object's name, as specified for an object change request in the Plan stage.
The IP addresses to add to an object, as specified for an object change request in the
Plan stage.
The IP addresses to remove from an object, as specified in the original object change
request.
The IP addresses to remove from an object, as specified for an object change request
in the Plan stage.
The object scope, as specified for an object change request in the Plan stage.
85
AlgoSec FireFlow
Release 6.3
Create tickets from attachment An indication of whether the change request was created from a file.
Affected Rules Result
The device rules that are affected by a suggested object change request.
Firewall Provider-1
Description
AND
OR
One or both of the field-value pairs joined by this operator must be true.
In the following example, the condition is met for change requests that are new,
change requests that are owned by John Smith, and new change requests owned by
John Smith:
Status = 'new' OR Owner = 'John Smith'
Comprehensive Example
In the following example, the workflow will be assigned when the change request's template does not
specify a workflow, and one of the following conditions are met:
86
Chapter 11
Editing Workflows
Note: You can edit the workflow details of built-in workflows; however, you cannot change their statuses
and actions.
Adding Statuses
To add a status
87
AlgoSec FireFlow
88
Release 6.3
Chapter 11
5 Complete the fields using the information in Status Fields (page 91).
89
AlgoSec FireFlow
90
Release 6.3
Chapter 11
Do this...
Name
Type the name of the status as it appears in the FireFlow interface. This is also a unique
key.
The name can include up to 50 characters of Latin character set. Spaces are allowed.
This field is mandatory.
Note: Some statuses cannot be renamed. When editing such a status, this field is
read-only.
Stage
The name of the image used in the lifecycle diagram at the top of the change request
page.
This field is mandatory.
91
AlgoSec FireFlow
Release 6.3
Responsible group
Select the single user group responsible for change requests in this status.
Note: Usually, this group is configured to see these change requests in its Home page
(see Customizing the Home Page per Group (on page 18)).
When an action is performed on the change request, and the action transitions the
change request to a new status for which the change request owner is not responsible, the
change request is re-assigned to the default assignee of the new statuss responsible
group, and the current user is re-directed to their Home page.
If you want to designate a new responsible group for the status, first create the group in
the FireFlow Configuration page, then access VisualFlow again. The new group will
appear in this list, and you can select it.
This field is mandatory.
Additional responsible
groups
DD - Needs further
explanation for groups
under domains
All user groups that are responsible for change requests in this status, other than the
group specified in the Responsible group field.
This field is read-only, and it only appears for statuses that are the source status of a
parallel action.
Enabled
Specify whether this status should be enabled, by choosing one of the following:
Yes. The status is enabled and will appear in the FireFlow interface.
No. The status is disabled. It will not appear in the FireFlow interface, and no change
requests will have this status.
The default value is Yes.
Note: Some statuses cannot be disabled. When editing such a status, this field either does
not appear or is read-only.
Advanced
Specify whether it is possible to plan the change when a change request is in this status.
Planning the change involves modifying any of the following fields:
Source
Destination
Service
Action
NAT
Choose one of the following:
Yes. These fields can be modified.
No. These fields cannot be modified.
The default value is No.
Select the next status to assign the change request, when incoming correspondence from
the change requests unprivileged requestor to the change request occurs.
If this field is not set, then the change request status will not change upon incoming
correspondence.
This field only appears for statuses where an email response is possible.
Await Requestor's
Response
Specify whether a change request should appear in the Change Requests Awaiting
Response page for unprivileged users.
The default value is No.
92
Chapter 11
Specify whether a change request in this status is considered "closed", by choosing one
of the following:
Yes. Consider the change request "closed", and display it in the Closed Change
Requests tab in the FireFlow requestor interface.
No. Do not consider the change request "closed".
The default value is No.
This field does not appear for the "new" status.
Specify whether there are additional statuses that a change request must achieve before
completing the stage, by choosing one of the following:
Yes. There are additional statuses that a change request must achieve before
completing this stage.
No. This is the last status in the stage. The stage will be marked with a check mark.
The default value is No.
This field must be set to No for exactly one status per stage.
Select the status to which the change request should transition after it has been assigned
an owner.
This field only appears for the "new" status.
Editing Statuses
To edit statuses
93
AlgoSec FireFlow
Release 6.3
Reordering Statuses
You can control the order in which statuses appear in a workflow's list of available statuses.
To reorder statuses
next to a status you want to move, and drag it to the desired location in
Deleting Statuses
To delete a status
94
Chapter 11
In the workflow layout, click on a status to which you want to add an action.
95
AlgoSec FireFlow
Release 6.3
The Edit Status page appears with a list of inbound and outbound actions for the status.
96
Chapter 11
5 Complete the fields using the information in Action Fields (page 101).
97
AlgoSec FireFlow
98
Release 6.3
Chapter 11
99
AlgoSec FireFlow
Release 6.3
6 If you set the Parallel field to Yes, set the action's responsible groups by doing the following:
a) Click the Set responsible groups link.
The Responsible groups dialog box appears.
The Responsible group field displays the user group responsible for change requests in this status.
b) In the Additional responsible groups list, select the additional user groups responsible for change
requests in this status.
To select multiple user groups, press Ctrl while you click on the desired user groups.
c) Click OK.
7 Click Save Draft.
The action is added to the list of actions.
Action Type
This action type...
Does this...
Change status
Internal comment
Adds a comment to the change request that is hidden from the requestor.
Reply to user
Adds a comment to the change request that is seen by the requestor. Includes sending an
email to the requestor. Includes sending an email to the requestor.
Take ownership
Assign
Initial plan
Risk check
Implementation plan
Manual reconcile
Opens a dialog box that allows a user to manually match the change request with a
change record. Relevant only for traffic change requests.
It is recommended to consult with AlgoSec before using this action type.
No change record
Opens a dialog box that allows a user to manually match the change request, while
specifying that there is no associated change record. Relevant only for traffic change
requests.
100
Chapter 11
Performs validation of a traffic change request. Relevant only for traffic change
requests.
It is recommended to consult with AlgoSec before using this action type.
Enables a user to view an existing work order and edit it. Relevant controls will appear
in UI only for Check Point and Juniper devices. Relevant only for traffic change
requests.
It is recommended to consult with AlgoSec before using this action type.
Active change
Enables a user to implement planned changes via ActiveChange. Relevant controls will
appear in UI only for Check Point devices using OPSEC. Relevant only for traffic
change requests.
It is recommended to consult with AlgoSec before using this action type.
Performs validation of an object change request. Relevant only for object change
requests.
It is recommended to consult with AlgoSec before using this action type.
Affected rules
Finds affected rules for an object change request. Relevant only for object change
requests.
It is recommended to consult with AlgoSec before using this action type.
Related tickets
Finds change requests that are related to a change request. Relevant only for rule
removal requests.
It is recommended to consult with AlgoSec before using this action type.
Notify requestors
View correspondence
Allows a user to view correspondences with other users regarding the impending
removal/disablement of a device rule. Relevant only for rule removal requests.
It is recommended to consult with AlgoSec before using this action type.
Performs validation of a rule removal request. Relevant only for rule removal requests.
It is recommended to consult with AlgoSec before using this action type.
Action Fields
In this field...
Do this...
Name
A unique key value for the action. Used when the action's behavior is to be overridden
for a specific status.
This field is mandatory. It is only available when working with a workflow's list of
actions.
Type
Select the action's type, which describes what it does. See Action Types (page 100).
This field is mandatory. It is only available when working with a workflow's list of
actions.
Category
101
AlgoSec FireFlow
Release 6.3
Source status
Use the fields in this area to specify the status or statuses from which the change request
must transition, before this action can be performed.
Target status
Use the fields in this area to specify the status or statuses to which the change request
will transition when the action is performed.
Specify whether the user must be granted a specific right, in order for the action to
appear in the Other drop-down list, by selecting the relevant right.
Note: This is a cosmetic issue only. Actions that require the user to have a specific right
will not succeed if the user does not have the right.
Return to homepage
Specify whether the user should be re-directed to the Home page after executing the
action, by choosing one of the following:
Yes. Redirect the user to the Home page.
No. The user should remain on the current page.
The default value is No.
Enabled
Specify whether this action should be enabled, by choosing one of the following:
Yes. The action is enabled and will appear in the FireFlow interface.
No. The action is disabled and will not appear in the FireFlow interface.
The default value is Yes.
Specify whether the action should be available via an explicit button next to the Other
drop-down list, by choosing one of the following:
Yes. Make the action available via a button. The button will always be visible,
unless the Display action button when field is empty field is set to a field name.
No. Do not make the action available via a button.
The default value is No.
Advanced
Use the fields in this area to specify a set of conditional target statuses that the change
request can transition to.
FireFlow will check the conditions in the order listed; therefore, if the first condition is
met, FireFlow will not check the second condition, and so on.
If none of the conditions are met, the change request will transition to the status
specified in the Edit action details area's Target status field, by default.
Target status
Select a new status that the change request should transition to when the action is
performed, if the condition(s) in the Condition field are met.
Condition
Type an XQL query specifying the conditions under which the change request will
transition to the status specified in the Target Status field.
For example, to specify the condition that the number of risks must be zero, type:
Ticket[RisksNumber = "0"]
For information on the required query syntax, see Action Condition Syntax (on page
105).
Message to user
Type a message that should appear onscreen when transitioning to the new status.
102
Chapter 11
Parallel
Specify whether the action will be performed in parallel to a second, identical action.
Choose one of the following:
Yes. The action will be performed in parallel to a second, identical action.
No. The action will be performed sequentially to all other actions.
The default value is No.
It is possible to add more parallel action logic. See Adding Parallel Action Logic (on
page 126).
This field is enabled only for statuses of the following types: Change status, Internal
comment, and Reply to user.
The strategy used to determine whether the parallel action has been completed.
To specify that the action should be considered completed only when all responsible
groups have performed it, select all.
If desired, you can configure other strategies. For example, you can configure a strategy
specifying that if a specific group performs the action, then the action should be
considered completed; otherwise, FireFlow should wait for all other groups to perform
the action. For information on configuring additional strategies, contact AlgoSec.
Display action button when Specify whether the action should be available via an explicit button next to the Other
field is empty
drop-down list only if a specific change request field is empty, by selecting the relevant
change request field.
Display action button when Specify whether the action should be available via an explicit button next to the Other
current user is not the
drop-down list only if the current user is not the change request's owner. Choose one of
owner
the following:
Yes. Display the action button if the current user is not the change request's owner.
No. Do not make displaying the action button dependent on whether the current user
is the change request's owner.
The default value is No.
Display action button when Specify whether the action should be available via an explicit button next to the Other
change request is
drop-down list only if the change request is not assigned to a user. Choose one of the
unassigned
following:
Yes. Display the action button if the change request is not assigned to a user.
No. Do not make displaying the action button dependent on whether the change
request is assigned to a user.
The default value is No.
Display action button when Specify whether the action should be available via an explicit button next to the Other
field value is true
drop-down list only if a specific change request field's value is "true", by selecting the
relevant change request field.
This is useful for actions that are restricted to certain devices types. For example, editing
a work order can only be done for is Check Point devices; therefore, this action should
only be available if a custom field called "Check Point" is set to "true".
Modify Field Title
Type the message that should appear when this action is performed, instructing the user
to complete the field specified in the Field Name field.
This field is only relevant if the Type field's value is Modify custom field.
Field Name
If the action requires a field's value as input, select the field's name.
To select multiple fields, hold down the CTRL key while clicking on the desired fields.
This field is only relevant if the Type field's value is Modify custom field.
103
AlgoSec FireFlow
Release 6.3
Display in workflow layout Specify whether the action should be displayed in the workflow layout when viewing a
workflow, by choosing one of the following:
Yes. Display the action in the workflow layout.
No. Do not display the action in the workflow layout.
The default value is No.
Note: When viewing a status for which this action is an outbound action, the action will
be displayed in the workflow layout, regardless of this attribute's value.
Applies to change requests Select the check boxes next to the types of change requests for which the action is
of type
relevant, and for which the action should appear.
This can be one or more of the following:
Regular. The action is relevant to regular change requests.
A regular change request is relevant to only one device.
Parent. The action is relevant to parent requests.
A parent request is relevant to multiple devices and has a sub-request for each
device.
Sub request. The action is relevant to sub-requests. A sub-request is relevant to one
device, out of the multiple devices that are relevant to its parent request.
If you do not select any of the check boxes, the action will be relevant to all change
request types.
User confirmation needed
Specify whether a confirmation message should appear when a user performs the action,
by choosing one of the following:
Yes. Display a message when the action is performed.
No. Do not display a message when the action is performed.
The default value is No.
Mail content
Type the default text that will appear in the main message box when commenting on a
change request or replying to the user.
This field is relevant only for actions of the type Reply to user and Internal comment.
Specify whether after the action is performed, the change request's "auto-matching
status" should be set to a specific value, and the change request should be displayed in
the Auto Matching page, by selecting the relevant status.
The default value is No.
Specify whether certain change request fields are mandatory, in which case if the fields
are not filled in when the action is performed, a message will appear prompting the user
the fill them in. The fields in question are:
Source
Destination
Service
Action
Firewall
Choose one of the following:
Yes. These fields are mandatory.
No. These fields are optional.
The default value is No.
104
Chapter 11
Specify whether the action should not appear in the Other drop-down list, if it is not
available via an explicit button next to the Other drop-down list. Choose one of the
following:
Yes. Hide this action in the Other drop-down list, if it does not appear via an explicit
button.
No. Display this action in the Other drop-down list, regardless of whether it
appears via an explicit button,
The default value is No.
Specify whether after the action is performed on a parent request, the user should be
redirected to the Home page, which displays a list of the parent request's sub-requests.
Choose one of the following:
Yes. Redirect the user to the Home page with a list of the parent request's
sub-requests.
No. The user should remain on the current page.
The default value is No.
This field is relevant only for actions of the type Change status, Reply to user and
Internal comment.
Specify whether after the action is performed on a sub-request, the user should be
redirected to the parent request, by choosing one of the following:
Yes. Redirect the user to the parent request.
No. The user should remain on the current page.
The default value is No.
Elements
An element may be any node in the XML of a change request, called a flat ticket. A flat ticket's root node
is <Ticket>, which is written in an XQL query as Ticket.
In order to specify a sub-node, use "/". For example, to specify a flat ticket's <Firewall> node, write:
Ticket/Firewall
You can use an asterisk "*" to specify a wildcard. For example, to specify any sub-node of Firewall,
write:
Ticket/Firewall/*
For information about available flat ticket nodes, see Flat Ticket Nodes (on page 106). For an example
of a flat ticket, see Flat Ticket Example (on page 116).
Filters
In order to apply a condition to an element, use square brackets "[ ]" in the following format:
Element[condition]
105
AlgoSec FireFlow
Release 6.3
Comparison operators
Elements in a sub-query may be compared via comparison operators in the following format:
element operator "value"
Where operator is a supported comparison operator, and value is the element's desired value.
In the previous example, the sub-query used the = operator as follows:
Brand = "Juniper Netscreen"
For a list of supported comparison operators, see Supported Comparison Operators (on page 125).
Boolean operators
It is possible to use Boolean operators between sub-queries. For example, the following query specifies
that the change request must be assigned to the Standard workflow, and the status must be "new":
Ticket[Workflow = "Standard"] $and$ Ticket[Status = "new"]
For more intricate queries, you can use parentheses to group sub-queries. For example, the following
query specifies that the change request must be assigned to the Standard workflow, and the change
request status must be "new" or "plan".
Ticket[Workflow = "Standard"] $and$ (Ticket[Status = 'new'] $or$
Ticket[Status = 'plan'])
For a list of supported Boolean operators, see Supported Boolean Operators (on page 126).
Description
Sub-nodes
Action
106
Chapter 11
AffectedRulesResult
AlreadyWorksFirewalls
None
Sub-node of Ticket.
Relevant for traffic change requests only.
AutomaticallyImplemented
None
Sub-node of Ticket.
Relevant for traffic change requests only.
Brand
None
Sub-node of Firewall.
Cc
None
Sub-node of Ticket.
ChangeFullData
None
Sub-node of Ticket.
ChangeImplementationNote The change request's implementation notes, None
s
if the change request has completed the
Implement stage.
Sub-node of Ticket.
Relevant for traffic change requests only.
City
None
ClosedAt
CMSticketid
code
None
Country
107
AlgoSec FireFlow
Created
Release 6.3
None
Sub-node of Ticket.
Createticketsfromattachmen Indicates whether the change request was
t
created from a file.
None
Sub-node of Ticket.
Description
None
Sub-node of Ticket.
description
None
Destination
Due
None
Sub-node of Ticket.
EmailAddress
Expires
None
Sub-node of Ticket.
Firewall
FormType
Brand
IPAddress
LastReport
LastReportDate
ManagementServer
Name
Policy
108
Chapter 11
HomePhone
Id
None
Sub-node of Ticket.
InitialPlanStartTime
None
Sub-node of Ticket.
IPAddress
None
Sub-node of Firewall.
IPsToAdd
IPsToRemove
IsActiveChangeApplicable
IsWorkOrderEditable
LastReport
None
Sub-node of Firewall.
LastReportDate
The date and time at which the last report for None
this device was generated.
Sub-node of Firewall.
LastUpdated
None
Sub-node of Ticket.
LastUpdatedBy
109
AlgoSec FireFlow
ManagementServer
Release 6.3
None
Sub-node of Firewall.
Name
None
Sub-node of Firewall.
name
None
Sub-Node of Risk.
Relevant for traffic change requests only.
New
None
ObjectName
None
Organization
None
OwningGroup
110
City
Country
EmailAddress
HomePhone
Id
Organization
RealName
None
Chapter 11
PlannedTraffic
Policy
Action
Destination
IPsToRemove
IPsToAdd
ObjectName
Requestedaction
RuleDisplayId
RuleId
RuleRemovalRelatedTickets
RuleRemovalRelatedTicketsReque
stors
RuleRemovalRuleAction
RuleRemovalUserstoNotify
Scope
Service
Source
None
Sub-node of Firewall.
Priority
None.
Sub-node of Ticket.
RealName
Requestedaction
None
Action
Destination
IPsToRemove
IPsToAdd
ObjectName
Requestedaction
RuleDisplayId
RuleId
RuleRemovalRelatedTickets
RuleRemovalRelatedTicketsReque
stors
RuleRemovalRuleAction
RuleRemovalUserstoNotify
Scope
Service
Source
111
AlgoSec FireFlow
Requestor
Release 6.3
Risk
RisksDetails
City
Country
EmailAddress
HomePhone
Organization
RealName
code
description
name
severity
Risk
Sub-node of Ticket.
Relevant for traffic change requests only.
RisksNumber
None
Sub-node of Ticket.
Relevant for traffic change requests only.
RuleDisplayId
None
None
None
112
None
Chapter 11
None
severity
None
Source
Status
None
Sub-node of Ticket.
Subject
None
Ticket
AffectedRulesResult
AlreadyWorksFirewalls
AutomaticallyImplemented
Cc
ChangeFullData
ChangeImplementationNotes
ClosedAt
CMSticketid
113
AlgoSec FireFlow
Release 6.3
TicketTemplateName
Createticketsfromattachment
Description
Due
Expires
Firewall
FormType
Id
ImplementaionDate
InitialPlanStartTime
IsActiveChangeApplicable
IsWorkOrderEditable
LastUpdated
LastUpdatedBy
New
ObjectChangeValidationResult
Owner
OwningGroup
Planned Traffic
Priority
RequestedTraffic
Requestor
RiskDetails
RisksNumber
Status
Subject
TicketTemplateName
TrafficChangeTime
TranslatedDestination
TranslatedService
TranslatedSource
Workflow
None
Sub-node of Ticket.
TrafficChangeTime
None
Sub-node of Ticket.
Relevant for traffic change requests only.
TranslatedDestination
None
Sub-node of Ticket.
Relevant for traffic change requests only.
TranslatedService
114
None
Chapter 11
TranslatedSource
Value
None
None
Sub-node of Ticket.
115
AlgoSec FireFlow
Release 6.3
116
Chapter 11
<Brand>Check Point</Brand>
<IPAddress>10.132.32.1</IPAddress>
<LastReport>eliezer-13656</LastReport>
<LastReportDate>2012-03-31 21:34:09</LastReportDate>
<ManagementServer>m_10_132_31_1</ManagementServer>
<Name>fw3</Name>
<Policy>yaara_10.W</Policy>
</Firewall>
<FormType>Traffic Change</FormType>
<Id>1320</Id>
<InitialPlanStartTime>1333277359.81826</InitialPlanStartTime>
<IsActiveChangeApplicable>1</IsActiveChangeApplicable>
<IsWorkOrderEditable>true</IsWorkOrderEditable>
<LastUpdated>Sun Apr 01 13:54:55 2012</LastUpdated>
<LastUpdatedBy>eliezer.weiss+locadmin@algoseclabs.com</LastUpdatedBy>
<Moshe></Moshe>
<ObjectChangeValidationResult></ObjectChangeValidationResult>
<OrganizationMethodology></OrganizationMethodology>
<Owner>
<City>tel aviv</City>
<Country></Country>
<EmailAddress>eliezer.weiss+locnet@algoseclabs.com</EmailAddress>
<HomePhone></HomePhone>
<Id>67</Id>
<Organization>Algosec</Organization>
<RealName>local network</RealName>
</Owner>
<OwningGroup>Network</OwningGroup>
<PendingResponsibleGroups></PendingResponsibleGroups>
<PlannedTraffic>
<Action>
<Value>Allow</Value>
</Action>
<Destination>
<Value>10.10.10.2</Value>
</Destination>
<Destination>
117
AlgoSec FireFlow
Release 6.3
<Value>10.10.10.3</Value>
</Destination>
<DestinationNAT>165.13.12.11</DestinationNAT>
<NATType>Static</NATType>
<PortTranslation>tcp/8080</PortTranslation>
<Service/Application>
<Value>tcp/21</Value>
</Service/Application>
<Source>
<Value>192.168.3.186</Value>
</Source>
<SourceNAT>178.16.1.18</SourceNAT>
<application>mail server</application>
</PlannedTraffic>
<Priority>0</Priority>
<RecertificationCandidateDevices></RecertificationCandidateDevices>
<RecertificationRelatedTicketsCalculationDate></RecertificationRelatedTicketsC
alculationDate>
<RecertificationStatus>Stand by</RecertificationStatus>
<RecertifiedTrafficTicket></RecertifiedTrafficTicket>
<RecommendReimplement></RecommendReimplement>
<RequestedCategory></RequestedCategory>
<RequestedTraffic>
<Action>
<Value>Allow</Value>
</Action>
<Destination>
<Value>10.10.10.2</Value>
</Destination>
<Destination>
<Value>10.10.10.3</Value>
</Destination>
<DestinationNAT>165.13.12.11</DestinationNAT>
<NATType>Static</NATType>
<PortTranslation>tcp/8080</PortTranslation>
<Service/Application>
118
Chapter 11
<Value>ftp</Value>
</Service/Application>
<Source>
<Value>192.168.3.186</Value>
</Source>
<SourceNAT>178.16.1.18</SourceNAT>
<application>mail server</application>
</RequestedTraffic>
<RequestedURL></RequestedURL>
<RequestedUserGroup></RequestedUserGroup>
<RequestedWebAction>Allow</RequestedWebAction>
<Requestor>
<City></City>
<Country></Country>
<EmailAddress>eliezer.weiss+locadmin@algoseclabs.com</EmailAddress>
<HomePhone></HomePhone>
<Id>65</Id>
<Organization>Algosec</Organization>
<RealName>Local FireFlow admin</RealName>
</Requestor>
<RiskLevel>No Risk</RiskLevel>
<RisksDetails></RisksDetails>
<RisksNumber>0</RisksNumber>
<Status>validate</Status>
<Subject>FTP access to mail servers</Subject>
<TicketTemplateID></TicketTemplateID>
<TicketTemplateName></TicketTemplateName>
<TrafficChangeTime></TrafficChangeTime>
<TranslatedDestination>10.10.10.2-10.10.10.3</TranslatedDestination>
<TranslatedService>tcp/21</TranslatedService>
<TranslatedSource>192.168.3.186</TranslatedSource>
<Workflow>Standard-With-SLA</Workflow>
<reportpdf>6208</reportpdf>
</Ticket>
Traffic Change Flat Ticket (Inclusion of User-Defined Custom Traffic Fields Disabled)
119
AlgoSec FireFlow
<Ticket>
<AddTraffic>Yes</AddTraffic>
<Cc></Cc>
<ClosedAt></ClosedAt>
<Created>Mon Jun 28 07:21:13 2010</Created>
<Description></Description>
<Due></Due>
<Firewall>
<Brand>Juniper Netscreen</Brand>
<IPAddress>100.0.0.1</IPAddress>
<LastReport>michal-8247</LastReport>
<LastReportDate>2010-06-27 19:32:18</LastReportDate>
<Name>192_168_2_53_root</Name>
<Policy>192_168_2_53_root.nsc</Policy>
</Firewall>
<Id>1567</Id>
<InitialPlanStartTime>1277717369.39996</InitialPlanStartTime>
<LastUpdated>Mon Jun 28 09:33:08 2010</LastUpdated>
<LastUpdatedBy>a123@algosec.com</LastUpdatedBy>
<Owner>
<City></City>
<Country></Country>
<EmailAddress>a123@algosec.com</EmailAddress>
<HomePhone></HomePhone>
<Id>25</Id>
<Organization></Organization>
<RealName>JohnSmith</RealName>
</Owner>
<PlannedTraffic>
<Action>Allow</Action>
<Destination>*</Destination>
<Service>*</Service>
<Source>*</Source>
</PlannedTraffic>
<Priority>0</Priority>
<RequestedTraffic>
<Action>Allow</Action>
120
Release 6.3
Chapter 11
<Destination>*</Destination>
<Service>ssh</Service>
<Source>*</Source>
</RequestedTraffic>
<Requestor>
<City></City>
<Country></Country>
<EmailAddress>a123@algosec.com</EmailAddress>
<HomePhone></HomePhone>
<Organization></Organization>
<RealName>JaneBrown</RealName>
</Requestor>
<RisksDetails>
<Risk>
<code>I01</code>
<description>"Any" service can enter your
network</description>
<name>I01-inbound-any</name>
<severity>high</severity>
</Risk>
</RisksDetails>
<RisksNumber>3</RisksNumber>
<Status>check</Status>
<Subject></Subject>
<TrafficChangeTime>1277717369.02893</TrafficChangeTime>
<Workflow>Standard</Workflow>
<CustomField1>1</CustomField1>
</Ticket>
121
AlgoSec FireFlow
<ChangeFullData></ChangeFullData>
<ChangeImplementationNotes></ChangeImplementationNotes>
<ClosedAt></ClosedAt>
<Created>Mon Feb 14 08:22:13 2011</Created>
<Createticketsfromattachment>No</Createticketsfromattachment>
<Description></Description>
<Due></Due>
<Expires></Expires>
<Firewall>
<Brand>Check Point</Brand>
<IPAddress>10.20.17.1</IPAddress>
<LastReport>michal-12327</LastReport>
<LastReportDate>2011-02-07 20:23:19</LastReportDate>
<ManagementServer>m_10_20_16_1</ManagementServer>
<Name>Kartiv</Name>
<Policy>Standard.W</Policy>
</Firewall>
<FormType>Object Change</FormType>
<Id>2128</Id>
<ImplementaionDate></ImplementaionDate>
<InitialPlanStartTime></InitialPlanStartTime>
<IsActiveChangeApplicable>1</IsActiveChangeApplicable>
<IsWorkOrderEditable>true</IsWorkOrderEditable>
<LastUpdated>Mon Feb 14 08:22:52 2011</LastUpdated>
<LastUpdatedBy></LastUpdatedBy>
<New></New>
<ObjectChangeValidationResult></ObjectChangeValidationResult>
<Owner>
<City></City>
<Country></Country>
<EmailAddress>a123@algosec.com</EmailAddress>
<HomePhone></HomePhone>
<Id>25</Id>
<Organization></Organization>
<RealName>m</RealName>
</Owner>
<OwningGroup>Network</OwningGroup>
122
Release 6.3
Chapter 11
<PlannedTraffic>
<Action>Remove IPs from Object</Action>
<IPsToRemove>10.10.17.3</IPsToRemove>
<ObjectName>a_10.10.17.2-3</ObjectName>
<Scope>Local</Scope>
</PlannedTraffic>
<PlannedTraffic>
<Action>Remove IPs from Object</Action>
<IPsToRemove>10.40.17.0-10.40.17.255</IPsToRemove>
<ObjectName>RemoteAccess</ObjectName>
<Scope>Global</Scope>
</PlannedTraffic>
<Priority>0</Priority>
<RequestedTraffic>
<Action>Remove IPs from Object</Action>
<IPsToRemove>10.10.17.3</IPsToRemove>
<ObjectName>a_10.10.17.2-3</ObjectName>
<Scope>Local</Scope>
</RequestedTraffic>
<RequestedTraffic>
<Action>Remove IPs from Object</Action>
<IPsToRemove>10.40.17.0-10.40.17.255</IPsToRemove>
<ObjectName>RemoteAccess</ObjectName>
<Scope>Global</Scope>
</RequestedTraffic>
<Requestor>
<City></City>
<Country></Country>
<EmailAddress>a123@algosec.com</EmailAddress>
<HomePhone></HomePhone>
<Organization></Organization>
<RealName>m</RealName>
</Requestor>
<RisksDetails></RisksDetails>
<RisksNumber></RisksNumber>
<Status>implement</Status>
<Subject>For NZ</Subject>
123
AlgoSec FireFlow
<TicketTemplateName>130: Object Change Request</TicketTemplateName>
<TrafficChangeTime></TrafficChangeTime>
<TranslatedDestination></TranslatedDestination>
<TranslatedService></TranslatedService>
<TranslatedSource></TranslatedSource>
<Workflow>Change-Object</Workflow>
</Ticket>
Release 6.3
Chapter 11
<PlannedTraffic>
<Requestedaction>Remove Rule</Requestedaction>
</PlannedTraffic>
<RequestedTraffic>
<Requestedaction>Remove rule</Requestedaction>
<RuleDisplayId>1</RuleDisplayId>
<RuleId>57E7BF23-D6BD-498A-9DDA-9071ECC47E46</RuleId>
<RuleRemovalRelatedTickets>748</RuleRemovalRelatedTickets>
<RuleRemovalRelatedTickets>471</RuleRemovalRelatedTickets>
<RuleRemovalRelatedTickets>323</RuleRemovalRelatedTickets>
<RuleRemovalRelatedTickets>5</RuleRemovalRelatedTickets>
<RuleRemovalRelatedTicketsRequesotrs>65</RuleRemovalRelatedTicketsRequesotrs>
<RuleRemovalRelatedTicketsRequesotrs>37</RuleRemovalRelatedTicketsRequesotrs>
<RuleRemovalRuleAction>accept</RuleRemovalRuleAction>
<RuleRemovalUserstoNotify>65</RuleRemovalUserstoNotify>
<RuleRemovalUserstoNotify>37</RuleRemovalUserstoNotify>
</RequestedTraffic>
<Workflow>Rule-Removal</Workflow>
</Ticket>
Description
Equal
!=
Not equal
=~
Contains
!~
<
Less than
>
Greater than
125
AlgoSec FireFlow
Release 6.3
Description
$and$
$or$
One or both of the sub-queries pairs joined by this operator must be true.
In the following example, the condition is met for change requests that are new,
change requests owned by John Smith, and new change requests owned by John
Smith:
Ticket[Status = "new"] $or$ Ticket/Owner[RealName = "John
Smith"]
Comprehensive Example
The following XQL query specifies that one of the following must be true, in order for the condition to be
satisfied.
50% of the responsible groups must meet certain criteria, in order to trigger this action.
The "Managers" user group must meet certain criteria in order to trigger this action.
126
Chapter 11
my $pendingGroups = shift;
}
Where logicName is the name of the parallel logic. This can be any string.
The function will receive the following parameters as input:
$additionalGroups - The additional responsible groups field after update
$pendingGroups - The pending responsible groups field after update
The function will return a Boolean value:
1 - The logic is satisfied, and the action will be triggered.
0 - The logic is not satisfied, and the action is still in parallel status.
4 Save the file.
5 Restart FireFlow.
See Restarting FireFlow (on page 11).
Editing Actions
Editing an action will modify the action's default settings throughout all statuses in the workflow.
To edit an action
127
AlgoSec FireFlow
Release 6.3
Reordering Actions
You can control the order in which actions appear in a workflow's list of actions.
To reorder actions
next to an action you want to move, and drag it to the desired location in
Deleting Actions
To delete an action
128
Chapter 11
The stage's starting point, which is when the change request enters a certain status
The stage's ending point, which is when the change request leaves a certain status
The stage's name
FireFlow uses the information specified in an SLO to measure the amount of time spent on the relevant
stage; and once the change request has completed its lifecycle, FireFlow can use all of the SLA's SLOs
together to calculate the amount of time spent on the entire lifecycle.
FireFlow then uses the calculated SLA information to generate reports on change requests that meet certain
criteria (for example, change requests in which have spent more than a certain number of days in a particular
stage), and display those reports in searches, charts, and dashboards. For information on configuring SLA
notifications, see Working with SLA Notifications (on page 189).
Adding SLOs
To add an SLO to a workflow's SLA
129
AlgoSec FireFlow
The Available SLA page appears with all of the SLOs comprising the workflow's SLA.
130
Release 6.3
Chapter 11
5 Complete the fields using the information in SLO Fields (page 131).
6 Click Save Draft.
The new SLO is added to the workflow's SLA.
SLO Fields
In this field...
Do this...
Name
Enabled
Specify whether this SLO should be enabled, by choosing one of the following:
Yes. The SLO is enabled and will be used for SLA calculations.
No. The SLO is disabled. It will not be used for SLA calculations.
The default value is Yes.
Statuses
Select one or more statuses that represent the starting point for the workflow stage
represented by this SLO. To select multiple statuses, hold down the Ctrl key while
clicking on the desired statuses. The selected statuses are highlighted in the diagram at
the top of the workspace.
Alternatively, click Enable visual edit, and then click on the desired statuses in the
diagram at the top of the workspace. The selected statuses appear in green. When
finished, click Finish visual edit.
131
AlgoSec FireFlow
Release 6.3
Time limit
To configure a time limit for the workflow stage represented by this SLO, type in the
number of time units in the field provided, and select the type of time unit in the
drop-down list.
Select the status to which the change request should transition, when the specified time
limit has been exceeded.
This field is only enabled, if you configured a time limit for the SLO.
Clear on revisit
Specify whether when re-visiting the SLO or one of its statuses, the time counter should
be reset to zero, by choosing one of the following:
Yes. Reset the time counter, then begin timing from zero.
No. Resume timing, without resetting the time counter.
The default value is No.
End trigger
Specify what event should trigger the end of the SLO, by choosing one of the following:
Change request leaves the status. End the SLO, when the change request leaves the
status.
Parallel action done by group. End the SLO, when a parallel action is performed by a
certain responsible group. You must select the desired responsible group in the
drop-down list provided.
This field appears only for SLOs that contain a status with a parallel action.
Editing SLOs
To edit an SLO in a workflow's SLA
Deleting SLOs
To delete an SLO from a workflow's SLA
132
Chapter 11
Reordering Workflows
You can control the order in which workflows appear in VisualFlow.
To reorder workflows
Deleting Workflows
Note: You cannot delete built-in workflows. For a list of built-in workflows, see Overview (on page 71).
Important: If you delete a workflow, then any change requests that are assigned to that workflow will be
re-assigned to the default workflow the next time they are accessed. Furthermore, if their current status does
not exist in the default workflow, the change requests will transition to the "new" status.
AlgoSec FireFlow
Release 6.3
Installing Workflows
Installing workflows imports all workflow changes into FireFlow.
To install workflows
1 Do one of the following:
In the VisualFlow main menu, click Workflows.
The List of Workflows page appears.
In the VisualFlow main menu, click Workflow Installation.
134
Chapter 11
135
AlgoSec FireFlow
Release 6.3
The message informing you that changes have been made to the workflows disappears.
Examples
Example: Removing the Notify Requestor Stage
The following comprehensive example describes how to modify a copy of the Standard workflow, so that
FireFlow does not wait for user acceptance after implementing change request.
Once implementation is complete, the Network user can simply resolve the change request (or re-implement
it, if an error was detected). Notification is only sent to the user upon the resolve action.
136
Chapter 11
137
AlgoSec FireFlow
Release 6.3
9 Edit the "Initial Plan" action to transition the change request to the new "pre-check" status as follows:
Set the Target status field to pre-check.
See Editing Actions (on page 127).
10 Edit the "Risk Check" action to transition the change request to the new "pre-check" status as follows:
Set the Target status field to pre-check.
See Editing Actions (on page 127).
11 Add a "risk_check" outbound action to the "pre-check" status as follows:
Set the Display action button when field is empty field to Request Risk Check Result, so that the "Risk
Check" button will appear for change requests in the "pre-check" stage when this field is empty.
Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in
the workflow layout.
See Adding Actions (on page 95).
12 Add a "send_to_security" outbound action to the "pre-check" status as follows:
Set the Display action button field to Yes, so that the "Send to Security" button will appear for change
requests in the "pre-check" stage.
Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in
the workflow layout.
See Adding Actions (on page 95).
13 Add an "approve" outbound action to the "pre-check" status as follows:
Set the Display action button field to Yes, so that the "Approve" button will appear for change
requests in the "pre-check" stage.
Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in
the workflow layout.
See Adding Actions (on page 95).
14 Add a "re_plan" outbound action to the "pre-check" status as follows:
Set the Display Name field to "Not Approve", so that this button's name will appear for change
requests in the "pre-check" stage.
Set the Display action button field to Yes, so that the "Not Approve" button will appear for change
requests in the "pre-check" stage.
Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in
the workflow layout.
Set the User confirmation needed field to No, so that this action will not trigger an "Are you sure?"
pop-up for change requests in "pre-check" stage.
Set the Mail content field to "Your request has not been approved and needs to be re-planned", so that
this text will appear in emails sent to the requestor for change requests in "pre-check" stage.
See Adding Actions (on page 95).
15 Add a "re_implement" outbound action to the "pre-check" status as follows:
Set the User confirmation needed field to No, so that this action will not trigger an "Are you sure?"
pop-up for change requests in "pre-check" stage.
See Adding Actions (on page 95).
16 Delete the "Risk Check" outbound action from the "approve" status, so that the risk check button will
not appear for change requests in "Approve" stage.
See Deleting Actions (on page 128).
138
Chapter 11
139
AlgoSec FireFlow
Release 6.3
7 Reorder the statuses so that the new "second check" status appears immediately after the "approve"
status.
See Reordering Statuses (on page 94).
8 Add an "approve" outbound action to the "second check" status as follows:
Set the Display action button field to Yes, so that the "Approve" button will appear for change
requests in the "second check" stage.
Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in
the workflow layout.
See Adding Actions (on page 95).
9 Add a "re-plan" outbound action to the "second check" status as follows:
Set the Display Name field to "Reject", so that this button's name will appear for change requests in
the "second check" stage.
Set the Display action button field to Yes, so that the "Reject" button will appear for change requests
in the "second check" stage.
Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in
the workflow layout.
Set the User confirmation needed field to No, so that this action will not trigger an "Are you sure?"
pop-up for change requests in "second check" stage.
Set the Mail content field to "Your request has been rejected and needs to be re-planned", so that this
text will appear in emails sent to the requestor for change requests in "second check" stage.
See Adding Actions (on page 95).
10 Add a "re-implement" outbound action to the "second check" status as follows:
Set the User confirmation needed field to No, so that this action will not trigger an "Are you sure?"
pop-up for change requests in "second check" stage.
See Adding Actions (on page 95).
11 Add a new action to the workflow as follows:
Set the Name field to "first_approve".
Set the Type field to Internal comment.
Set the Display Name field to "First Approve".
Set the Target status field to second check.
Set the Required action right field to UserDefinedRight02.
Set the Applies to change requests of type field to Parent and Regular.
Set the Traffic fields required field to yes.
See Adding Actions (on page 95).
12 Reorder the workflow's actions, so that the new "First Approve" action immediately after the "Risk
Check" action.
See Reordering Actions (on page 128).
13 Edit the "Approve" action as follows:
Set the Display Name field to "Final Approve".
See Editing Actions (on page 127).
14 Add a "first_approve" outbound action to the "approve" status as follows:
140
Chapter 11
Set the Display action button field to Yes, so that the "First Approve" button will appear for change
requests in the "approve" stage.
Set the Display in workflow layout field to Yes, so that the outbound action will appear as an arrow in
the workflow layout.
See Adding Actions (on page 95).
Delete the "Final Approve" outbound action from the approve status.
See Deleting Actions (on page 128).
Assign the UserDefinedRight02 global right to the Security user group.
See Configuring a Group's Global and Queue Rights (on page 35).
Members of the Security group can now perform the "First Approve" action.
Install the workflow.
See Installing Workflows (on page 134).
Log in to the FireFlow server via SSH, using the username "root" and the related password.
Restart FireFlow.
See Restarting FireFlow (on page 11).
15
16
17
18
19
141
CHAPTER 12
In This Chapter
Editing the Workflow Configuration File .......................... 143
Adding Workflows ............................................................. 146
Modifying Workflows ........................................................ 164
Disabling Workflows ......................................................... 165
Deleting Workflows ........................................................... 165
Reverting to the System Default Workflow via XML ....... 166
Which workflow should be assigned by default, when FireFlow fails to assign a workflow based on the
conditions
Whether a given workflow is enabled in FireFlow
The conditions in which a workflow should be assigned, when the change request's template does not
specify a workflow
143
AlgoSec FireFlow
Release 6.3
5 Add or modify condition tags to specify the conditions in which a workflow should be assigned, in
the event that the change request's template does not specify a workflow.
See Condition Tag Syntax (on page 145) for information on the condition tag's syntax.
6 Save the override file.
7 Restart FireFlow.
See Restarting FireFlow (on page 11).
Description
Possible Values
Permitted Change
name
Any
description
Any
144
Chapter 12
filename_prefix
There is no reason to
change this attribute. If
you do change it, then you
must ensure consistency
throughout the XML file.
default
Any
enabled
Any
This can be one of the
following:
1. The workflow is enabled.
0. The workflow is
disabled.
The default value is 1.
Where condition is a query specifying the desired condition. This query is composed of pairs in the
following format:
field = 'value'
Where field is a supported field in FireFlow, and value is the field's value. For information on supported
fields, see Supported Fields (on page 81). For example, the following query specifies that the change
request status must be "new":
Status = 'new'
You can use != to indicate "not". For example, the following query specified that the change request must
not be "new":
Status != 'new'
It is possible to use Boolean operators between field-value pairs. For a list of supported operators, see
Supported Boolean Operators (on page 86). For example, the following query specifies that the change
request status must be "new", and the owner must be John Smith:
Status = 'new' AND Owner = 'John Smith'
145
AlgoSec FireFlow
Release 6.3
For more intricate queries, you can use parentheses to group field-value pairs and operators. For example,
the following query specifies that the change request status must be "new" or "plan", and the owner must be
John Smith or Sue Michaels.
(Status = 'new' OR Status = 'plan') AND (Owner = 'John Smith' OR Owner = 'Sue
Michaels')
Comprehensive Example
In the following example, the Special workflow will be assigned when the change request's template does
not specify a workflow, and one of the following conditions are met:
Adding Workflows
To add a custom workflow
1 Log in to the FireFlow server using the username "root" and the related password.
2 Create the custom workflow, by doing the following:
a) Under the directory /usr/share/fireflow/local/etc/site/Workflows/, create a new
XML file with the required structure.
See Workflow File Structure (on page 148).
b) Add actions and statuses to the change request lifecycle.
See Action Tag Attributes (on page 149) and Status Tag Attributes (on page 160) for information
on the relevant tag attributes.
c) Save the file.
3 Add the custom workflow to the workflow configuration file, by doing the following:
a) Under the directory /usr/share/fireflow/local/etc/, locate the file
Workflows_Config.xml.
Note: This is the original system settings file, and it is required for reverting to system default
settings. Do not modify this file.
b) Under the directory /usr/share/fireflow/local/etc/site/, copy the contents of the
original file into an override file that is also called Workflows_Config.xml.
c) Open the override file.
d) Add a workflow tag for the new workflow.
146
Chapter 12
See Workflow Tag Attributes (on page 144) for information on the relevant tag attributes.
e) Save the override file.
4 Restart FireFlow.
See Restarting FireFlow (on page 11).
5 Specify when the custom workflow should be used, by doing one or more of the following:
To assign change requests to the new workflow when a specific template is used, do one of the
following:
Modify an existing template to specify the new workflow.
Add a new template that specifies the new workflow.
For information on working with templates, refer to the AlgoSec FireFlow User Guide, Managing
Request Templates.
To assign change requests to the new workflow based on the workflow conditions, edit the
workflow configuration file and specify the conditions in which the workflow should be used.
See Editing the Workflow Configuration File (on page 143).
147
AlgoSec FireFlow
Release 6.3
148
Chapter 12
Description
Possible Values
title
Any
type
Actions of the
internal_comment
type can be changed to the
reply_to_user or
change_status type
and vice versa.
No other changes are
permitted to pre-defined
actions.
Permitted Change
149
AlgoSec FireFlow
Release 6.3
150
Chapter 12
enabled
Any
key
There is no reason to
change this attribute. If
you do change it, then you
must ensure consistency
throughout the XML file.
category
Any
Any string
151
AlgoSec FireFlow
Release 6.3
ticket_member_typ The types of change requests for This can be one or more of the There is no reason to
change this attribute.
e
which the action is relevant, and following:
for which the action should
Regular. The action is
appear.
relevant to regular change
This attribute is optional.
requests.
A regular change request is
relevant to only one device.
Parent. The action is
relevant to parent requests.
A parent request is relevant
to multiple devices and has
a sub-request for each
device.
SubTicket. The action is
relevant to sub-requests. A
sub-request is relevant to
one device, out of the
multiple devices that are
relevant to its parent
request.
The default value is no value, in
which case the action will be
relevant to all change request
types.
Multiple values must be
separated by commas.
Relevant only for traffic change
requests. (Object change
requests do not have
sub-requests.)
recommend
152
Any
Chapter 12
actions are available via an
explicit button next to the Other
drop-down list.
This attribute is optional.
true
1
false
0
Any
153
AlgoSec FireFlow
Release 6.3
Any
Any
Any
154
Any text.
Any
The default confirmation
message is:
Are you sure you want
to <TITLE>?
Where <TITLE> is the title of
the action.
Chapter 12
There is no reason to
The name of a global right.
Popular rights that may be used change this attribute.
are:
AllowActiveChange
AllowAffectedRules
AllowApprove
AllowChangeValidation
AllowDeleteTicket
AllowImplementationDone
AllowImplementationPlan
AllowInitialPlan
AllowManualCheck
AllowNotifyRequestor
AllowObjectChangeValidat
ion
AllowReImplement
AllowRePlan
AllowReject
AllowRequestorResponse
AllowResolve
AllowReview
AllowRiskCheck
ModifyChanges
ModifyReconciliation
UserDefinedRight01
UserDefinedRight02
UserDefinedRight03
UserDefinedRight04
UserDefinedRight05
UserDefinedRight06
UserDefinedRight07
UserDefinedRight08
UserDefinedRight09
There is no reason to
change this attribute.
155
AlgoSec FireFlow
Release 6.3
UserDefinedRight10
For additional rights, contact
AlgoSec.
The default value is no value.
goto_homepage
Any
goto_parent
156
There is no reason to
change this attribute.
There is no reason to
change this attribute.
Any
Chapter 12
mail_content
transition_to_matc
h_status
Any
Any
Any
157
AlgoSec FireFlow
Release 6.3
Any
Any
The conditionKey
attributes of one or more
conditions.
Multiple attributes must be
separated by commas (,).
158
Any
Chapter 12
In the following example, the action "Initial Plan" is of the type "initial_plan" (that is, it performs initial
planning). This action will appear in the FireFlow interface only if a valid FireFlow license exists, only for
regular and parent requests, and only for users that have been granted the right AllowInitialPlan.
Executing this action changes the change request status to "check".
<action title="Initial Plan"
type="initial_plan"
key="initial_plan"
transition_to_status="check"
require_login_with_valid_license="true"
require_ticket_right="AllowInitialPlan"
ticket_member_type="Parent,Regular" />
In the following example, the action "Re-Plan" is of the type "reply_to_user" (that is, it comments on the
change request and sends an email to the user). The default email text is "Your request needs to be
re-planned". When this action is executed, a confirmation message will appear prompting the user to
approve the change request before continuing. The change request's status changes to "open", which appears
as "plan" in the FireFlow interface. This action will appear only for regular and parent requests, and only for
users that have been granted the right AllowRePlan.
<action title="Re-Plan"
type="reply_to_user"
key="re_plan"
transition_to_status="open"
need_user_confirm="true"
mail_content="Your request needs to be re-planned"
require_ticket_right="AllowRePlan"
ticket_member_type="Parent,Regular" />
Note: The following pre-defined actions are always available in the Other drop-down list and can always be
performed on a change request, regardless of the changes made to the lifecycle:
Comment, Reply - appear at the beginning of the list
Duplicate, Save As Template - appear at the end of the list
Additional actions defined in the XML file appear between these two sets of actions in the Other drop-down
list.
159
AlgoSec FireFlow
Release 6.3
Description
Possible Values
Permitted Change
name
enabled
160
Any
Chapter 12
A comma-separated list of
responsible groups
image
incoming_cor
respondence_
transition_to_
status
Any
Any
Important: Initial planning will
not succeed if the change
request's current status is
configured to have this
attribute set to false.
Any
161
AlgoSec FireFlow
Release 6.3
162
Chapter 12
In addition, a status can have a nested <actions> tag that overrides global action attributes, when the
change request is in the status.
In the following example, the status "new" is assigned the "new" lifecycle image. The Network user group is
responsible for this status. While the change request is in this status, modification of traffic fields is allowed.
Also note that there is an action override: When the change request is in this status, the initial planning
action (identified using the key initial_plan which is equal to the key in the main <actions> node) is
recommended.
<status name="new" image="new" responsible="Network"
allow_to_plan_change="true">
<actions>
<action key=1348 recommend="true"/>
<!-- more actions here -->
</actions>
</status>
Note: Most illegal changes to the XML file will cause the whole file to not be read. In this case, only the
default actions (comment, duplicate, etc.) will be available, and the FireFlow log file
/usr/share/fireflow/var/log/fireflow.log will describe the problem. Also, logging in as a
privileged user will cause the log snippet to be displayed onscreen in a warning message. Other local illegal
changes are detected only upon executing the specific action that contains the illegal change. In this case,
too, the FireFlow log file will explain the problem, once the action is attempted.
Note: Some changes that are listed in the preceding table as not permitted will not be detected by
FireFlow. They will simply cause erratic undocumented behavior by the system.
Description
Possible Values
The new status that the change
Any existing status name
request should transition to when
the action is performed, if the
condition(s) in the condition
attribute are met.
Permitted Change
Any
conditionKey
Any
Any string.
Cannot contain a comma ","
163
AlgoSec FireFlow
msgToUser
Release 6.3
Any string.
Any
In addition to these attributes, every condition tag must contain one check sub-tag. The sub-tag's syntax
is as follows:
<check><![CDATA[query]]></check>
Where query is an XQL query specifying the desired condition's requirements. For information on the
required query syntax, see Action Condition Syntax (on page 105).
In the following example, when the RiskCheck action is performed, FireFlow will check the noRisks
condition first. If the number of risks equals zero, then FireFlow will transition the change request to the
"create work order" status (called "implementation plan" in the XML). It will not check the
priorityLessThan7 condition.
However, if the number of risks is different than zero, FireFlow will check the priorityLessThan7 condition.
If the change request priority is less than 7, FireFlow will transition the change request to "review" status. If
the change request priority is not less than 7, FireFlow will transition the change request to "approve" status
(called "check" in the XML).
<action title="RiskCheck" ...
transition_to_condition="noRisks,priorityLessThan7" transition_to_status="check"/>
<condition conditionKey="noRisks" GoToStatus="implementation plan" msgToUser="OK
to implement">
<check><![CDATA[Ticket[RisksNumber = "0"]]]></check>
</condition>
<condition conditionKey="priorityLessThan7" GoToStatus="review" msgToUser=Need
to be reviewed>
<check><![CDATA[Ticket[Priority < 7]]]></check>
</condition>
Modifying Workflows
FireFlow does not allow overriding the following built-in workflows, which are located in the directory
/usr/share/fireflow/local/etc/Workflows/:
164
Standard_Config.xml
Change-Object_Config.xml
Multi-Approval_Config.xml
Non-Firewall_Config.xml
Parallel-Approval_Config.xml
Request-Recertification_Config.xml
Rule-Removal_Config.xml
Standard-With-SLA_Config.xml
Chapter 12
Web-Filter_Config.xml
These workflows can only be disabled. See Disabling Workflows (on page 165).
If you want to modify a built-in workflow, copy it under a different name, then modify the newly named
workflow and disable the built-in one.
The following procedure can be used to modify custom workflows.
To modify a workflow
1 Log in to the FireFlow server using the username "root" and the related password.
2 Under the directory /usr/share/fireflow/local/etc/site/Workflows/, open the desired
workflow file.
3 Make the desired modifications to the change request lifecycle.
You can add new actions and new statuses to the change request lifecycle. See Action Tag Attributes
(on page 149) and Status Tag Attributes (on page 160) for information on the relevant tag attributes.
4 Save the file.
5 Restart FireFlow.
See Restarting FireFlow (on page 11).
Disabling Workflows
You can disable both built-in and custom workflows.
To disable a workflow
1 Under the directory usr/share/fireflow/local/etc/site/Workflows/, open the workflow
configuration file Workflows_Config.xml.
2 Locate the desired workflow's line, and add the following to it:
enabled="false"
to
<workflow name="Custom" enabled="false" description="This is a custom workflow"
filename_prefix="Custom" />
Deleting Workflows
Note: FireFlow allows deleting only custom workflows, not built-in workflows.
To delete a workflow
1 Log in to the FireFlow server using the username "root" and the related password.
165
AlgoSec FireFlow
Release 6.3
166
CHAPTER 13
Using Hooks
This section explains how to use hooks with FireFlow.
In This Chapter
Overview ............................................................................ 167
Using Hooks to Control Parameters ................................... 167
Hook Functions .................................................................. 169
Comprehensive Example.................................................... 176
Overview
It is possible to configure FireFlow to extract certain parameters on the fly, by using hooks. This helps
streamline the change request lifecycle and is particularly helpful for MSPs.
For example, during the Initial Plan stage of the change request lifecycle, FireFlow checks the requested
traffic against the ALL_FIREWALLS group, by default. If you have several customers, each of which is a
large organization with numerous devices, checking traffic against all of the devices of each organization is
unnecessary and time consuming. By using hooks, it is possible to configure FireFlow to check traffic only
against the devices of the organization that issued the change request.
You can use hooks to do the following:
Retrieve the name of the workflow to assign the change request in the Request stage
Retrieve the device group against which traffic should be checked in the Initial Plan stage
Retrieve the name of the user group responsible for the change request in each lifecycle stage
Retrieve appearing in the Requestors Web Interface
Validate a change request before its creation
Suggest host names to match IP addresses with no associated hostname in a work order
Add suffixes to add to suggested rule comments in a work order
Validate host names, groups, and comments in a manually edited work order
Run additional risk checks on external systems
167
AlgoSec FireFlow
Release 6.3
The file can have any name. For example, you can create the file
/usr/share/fireflow/local/Hooks/MyHooks.pm, which begins with the line:
package FireFlow::Hooks;
168
Chapter 13
Using Hooks
Hook Functions
GetExternalRisks
Syntax
sub GetExternalRisks
Description
This function is called for every change request, after FireFlow has finished running a risk check. It receives
the change request as input, along with a list of devices on which a risk check should be run. The risk check
is run on an external system, and the function then returns the risk check results. These results are displayed
in FireFlow after the FireFlow risk check results, for example:
Input Parameters
$ticket
169
AlgoSec FireFlow
$firewall
Release 6.3
Return Values
A Perl hash reference containing the following keys:
RiskList. An array of all the risks that were detected, sorted from high to low severity, where each risk is
represented by a hash reference containing the risk's name, description, code, and severity.
profile. The risk check's profile.
high. The number of risks at the High severity level.
low. The number of risks at the Low severity level.
medium. The number of risks at the Medium severity level.
suspected high. The number of risks at the Suspected High severity level.
Note: If there are no risks at a certain severity level, the relevant key will have no value defined.
GetFirewallGroupName
Syntax
sub GetFirewallGroupName
Description
This function is called for every change request just before initial planning is executed on the change
request. It receives the change request as input and returns the name of the device group against which
FireFlow will check traffic in the Initial Plan stage.
Input Parameters
$context
Return Values
One of the following values:
The desired device group's name
This must be the group's real name, not its display name.
""
Use the default behavior: FireFlow will check traffic against the group
configured as $FAQueryDefaultGroup in the configuration file. (The
default is the ALL_FIREWALLS group.)
170
Chapter 13
Using Hooks
GetRealGroupName
Syntax
sub GetRealGroupName
Description
This function is called for every change request, when the change request transitions from one status to
another. It receives the change request as input, as well as the meta group name that the change request's
workflow specifies as the responsible group for the change requests new status. It returns the name of the
user group that is responsible for the change request in its current status.
Input Parameters
$context
$metaGroup
Return Values
One of the following values:
The desired user group's name
""
Use the default behavior: The user group specified in the workflow
configuration will be responsible for the change request.
171
AlgoSec FireFlow
Release 6.3
GetRequestorSearches
Syntax
sub GetRequestorSearches
Description
This function allows adding searches to the Requestors Web Interface. It receives the requestor's user
properties as input, as well as the name of the page in the Requestors Web Interface on which the search
should appear. It returns a search on the specified page.
Note: By default, requestors can only view change requests that they requested themselves. Therefore, if the
hook returns a search query with change requests that other users requested, those change requests will not
be displayed in the Requestor Web Interface. To enable the display of change requests requested by other
users, it is necessary to grant requestors more permissive rights. See Working with Rights (on page 177).
Input Parameters
$requestor
$friendly_status
The Requestors Web Interface page that is currently being displayed. This can
have the following values:
Open
Awaiting Response
Closed
Return Values
An array, in the following format:
my $search = {Field1 => Value1, Field2 => Value2, ...};
Where each field in the array is a hash reference representing a search.
Supported fields are:
172
Chapter 13
Using Hooks
Title
The search's title. This will appear in the Requestors Web Interface.
This field is mandatory.
Format
Query
OrderBy
Order
An array indicating the default sort order of the search results. This can have
the following values:
For example:
my $search = {
Title => "The title of the search",
Format => $Format,
Query => $Query,
Order => @Order,
OrderBy => @OrderBy,
Rows => $Rows;
173
AlgoSec FireFlow
Release 6.3
GetWorkFlowName
Syntax
sub GetWorkFlowName
Description
This function is called for every change request, when the change request is created and its workflow must
be determined. It receives the change request as input and returns the name of the workflow that FireFlow
should assign the change request.
Input Parameters
$context
Return Values
One of the following values:
The desired workflow's name
""
SuggestCommentSuffix
Syntax
sub SuggestCommentSuffix
Description
This function is called for every change request, in which the work order contains a suggested rule
comment. It receives the change request as input, as well as the original rue comment and the rule comment
suggested by FireFlow. It returns a suffix to be added to the rule comment suggested by FireFlow.
Input Parameters
$ticket
$origComment
$commentValue
Return Values
A suffix to be added to the rule comment suggested by FireFlow.
174
Chapter 13
Using Hooks
SuggestHostName
Syntax
sub SuggestHostName
Description
This function is called for every change request, in which the work order contains an IP address or subnet
that is not associated with a hostname. It receives the change request as input, as well as the IP
address/subnet and an indication of whether the IP address/subnet is a source or destination. It returns a
suggested hostname for the IP address/subnet.
Input Parameters
$ticket
$ip
$field
The IP address or subnet's function. This can have the following values:
Source
Destination
Return Values
A suggested hostname for the IP address/subnet.
ValidateTicket
Syntax
sub ValidateTicket
Description
This function is called for every change request that is created via the Web interface. It receives the change
request as input. It returns a return code and a list of error messages, so as to validate the change request.
Input Parameters
$ticket
Return Values
A return code and a list of error messages.
175
AlgoSec FireFlow
Release 6.3
ValidateWorkOrderEdit
Syntax
sub ValidateWorkOrderEdit
Description
This function is called for every change request, in which the work order contains hostnames, host and
service groups, and/or comments that were manually edited. It receives the change request as input, as well
as the edited work order elements. It returns the elements that are invalid.
Input Parameters
$ticket
$validationHash
A Perl hash reference containing the work order elements that were manually
edited.
Return Values
$invalidHash
A Perl hash reference containing the work order elements that were found to be
invalid.
Comprehensive Example
For a comprehensive example, refer to the following files on the FireFlow server:
176
CHAPTER 14
In This Chapter
Overview ............................................................................ 177
Configuring Global Rights for Groups ............................... 178
Configuring Global Rights for Users ................................. 181
Configuring Queue Rights for Groups ............................... 183
Configuring Queue Rights for Users .................................. 186
Overview
FireFlow enables you to assign rights to users and user group. Each right represents an action that the user or
user group can perform.
There are two types of rights:
Built-in rights
FireFlow includes a set of built-in rights that represent specific actions users can perform.
User-defined rights
FireFlow includes a set of user-defined rights that are labeled UserDefinedRight01 through
UserDefinedRight10. Unlike the built-in rights, which are tied to specific actions, user-defined rights can
be used to represent any custom action, in order to restrict the performance of those actions to certain
users.
For example, let's say you want to modify the Standard workflow so that it includes a custom action
called "First Approve", and you want to restrict this action to users who have "First Approval" rights. As
"First Approval" rights do not exist in the FireFlow system, you can decide that UserDefinedRight01 will
represent "First Approval" rights, and assign these rights to the desired user groups.
Note: You cannot rename user-defined rights.
When assigning rights to a user group, all members of the group (both users and sub-groups) will
automatically inherit the rights.
Note: It is recommended to assign rights to user groups, rather than to individual users. This approach
enables you to quickly configure a new user's rights, by simply adding the user to the desired group.
You can assign rights to the following types of user groups:
System groups
Includes Everyone, Privileged, and Unprivileged (requestors).
User roles
Includes Cc, Requestor, and Owner.
177
AlgoSec FireFlow
Release 6.3
Rights assigned to a user role are only relevant for users who are filling that role in relation to a specific
change request. For example, if you assign "ShowTicket" rights to the Requestor role, then a user who is
the requestor for a specific change request will be able to view that change request. The same user will
not be able to view other change requests for which they are not the requestor, unless the user also
belongs to a system or user-defined group with "ShowTicket" rights.
Note: The AdminCc user role is not in use and should be ignored.
User-defined groups
Includes Network, Security, and any other group defined by a user.
Global
Assign rights at the global level for actions that should be performed on all change requests and for
actions that are not related to change requests. You can assign both user-defined and built-in rights.
See Configuring Global Rights for Groups (on page 178) and Configuring Global Rights for Users
(on page 181).
Queue
Assign rights at the queue level for actions that should only be performed on change requests belonging
to a certain queue.
Only built-in rights can be assigned at the queue level.
See Configuring Queue Rights for Groups (on page 183) and Configuring Queue Rights for Users (on
page 186).
178
Chapter 14
3 Click Global.
The Admin/Global configuration page appears.
179
AlgoSec FireFlow
Release 6.3
Description
DeleteMatches
Allows users in the group to delete matching output for all change requests. This right is
required for manual matching.
ModifyChanges
180
Chapter 14
ModifyMatches
Allows users in the group to modify matching output for all change requests. This right
is required for manual matching.
ShowChanges
Allows users in the group to view change records for all change requests.
ShowMatches
Allows users in the group to view matching output for all change requests.
AlgoSec FireFlow
Release 6.3
182
Chapter 14
For example, if you want to modify the Standard workflow so that it includes a custom action called
"First Approve", and you want to restrict this action to users who have "First Approval" rights, you
would choose UserDefinedRight01 to represent the right to perform the "First Approve" custom action.
2 Assign the user-defined right to the user that should be allowed to perform the custom action, by doing
the following:
a) Log in to FireFlow for advanced configuration purposes.
See Logging in for Advanced Configuration Purposes (on page 7).
b) In the main menu, click Advanced Configuration.
The Advanced Configuration page appears.
c) Click Global.
The Admin/Global configuration page appears.
d) Click User Rights.
The Modify global user rights page appears.
e) For each user to which you want to assign the user-defined rights, select the relevant rights in the
New rights list box.
f) Click Modify User Rights.
In our example, you would assign UserDefinedRight01 rights to the users that should be allowed to
perform the "First Approve" action.
3 Modify the custom action to restrict its use to users with the selected user-defined right.
For information on modifying workflow actions, see Working with Workflows in VisualFlow (on page
71).
183
AlgoSec FireFlow
3 Click Firewalls.
The Editing Configuration for queue Firewalls page appears.
184
Release 6.3
Chapter 14
AlgoSec FireFlow
Release 6.3
Description
AllowActiveChange
Allows users in the group to implement changes on Check Point devices for which
ActiveChange is enabled, for change requests in the queue.
AllowAffectedRules
Allows users in the group to find affected rules of change object requests in the queue.
AllowApprove
AllowChangeValidation
Allows users in the group to perform change validation for change requests in the queue.
AllowDeleteTicket
AllowImplementationDone Allows users in the group to declare implementation as complete for change requests in
the queue.
AllowImplementationPlan
Allows users in the group to create a work order for change requests in the queue.
AllowInitialPlan
Allows users in the group to perform initial planning for change requests in the queue.
AllowManualCheck
Allows users in the group to perform a manual check for change requests in the queue.
Used by the built-in Generic workflow.
AllowNotifyRequestor
Allows users in the group to notify the requestor that change request validation is
required for change requests in the queue.
AllowObjectChangeValida Allows users in the group to perform change validation for object change requests in the
tion
queue.
AllowReImplement
AllowRePlan
AllowReject
AllowRequestorResponse
Allows users in the group to respond to change requests in the queue, specifying that the
change works or does not work. This right is typically granted to the requestor role
instead of to a system or user-defined group.
AllowResolve
AllowReview
Allows users in the group to review change requests in the queue. Used by the built-in
Multi-Approval workflow.
AllowRiskCheck
Allows users in the group to perform risk checks for change requests in the queue.
186
Chapter 14
3 Click Firewalls.
The Editing Configuration for queue Firewalls page appears.
4 In the main menu, click User Rights.
The Modify user rights for queue Firewalls page appears.
187
CHAPTER 15
In This Chapter
Overview ............................................................................ 189
Adding SLA Notifications.................................................. 189
Editing SLA Notifications .................................................. 194
Managing Email Subscriptions to SLA Notifications ........ 196
Deleting SLA Notifications ................................................ 197
Overview
FireFlow enables you to create custom pages displaying a specific set of SLO data. These pages are called
SLA notifications, and they can be made available to yourself only, certain user groups, or system-wide.
In addition, users can be subscribed to SLA notifications, so that they periodically receive the SLA
notifications' content via email.
189
AlgoSec FireFlow
190
Release 6.3
Chapter 15
191
AlgoSec FireFlow
Release 6.3
8 For each element you want to add to the SLA notification, do the following:
a) In the Available list box, select the element you want to add.
For information on each element, see SLA Notification Elements (page 192).
b) Click
.
The selected element moves to the right list box. The order that the elements appear in the box
represents the order in which they will appear in the SLA notification.
c) To move the element up or down in the box, select the element and click the
buttons.
d) To delete the element, select it and click Delete.
Your changes are saved.
or
Pre-defined search results consisting of a list of open change requests in the system
that have a due date that has passed, that is the current date, or that is the day after the
current date.
Pre-defined search results consisting of a list of change requests in the system that
are new and still in the Request stage, and whose traffic has already been checked
against devices.
Pre-defined search results consisting of a list of change requests in the system that
are currently open.
Pre-defined search results consisting of a list of parent requests in the system that are
currently in the Implement stage and awaiting implementation of the relevant
sub-requests.
Pre-defined search results consisting of all recertification requests in the system that
are currently in the Plan stage.
"N" Recertification Requests Pre-defined search results consisting of a list of recertification requests in the system
to Send Recertify Notification that are currently in the Approve stage, and for which a recertification notification
to Traffic Requestors
will be sent to the traffic requestors.
"N" Recertification Requests
to Validate
192
Chapter 15
"N" Rejected Change Requests Pre-defined search results consisting of a list of change requests in the system that
were rejected.
"N" Resolved Change
Requests
Pre-defined search results consisting of a list of change requests in the system that
have been resolved.
Pre-defined search results consisting of a list of change requests in the system that
are owned by the Controllers group.
Pre-defined search results consisting of a list of change requests in the system that
are owned by the Network group.
Pre-defined search results consisting of a list of change requests in the system that
are owned by the Security group.
"N" Change Requests Relevant Pre-defined search results consisting of a list of change requests in the system that
to My Groups
are relevant to the user groups to which you belong.
"N" Change Requests that are
due to be recertified
Pre-defined search results consisting of a list of traffic change requests in the system
that expired, and which should be recertified.
"N" Change Requests Flagged Pre-defined search results consisting of a list of change requests in the system that
by Requestor as "Change Does have been flagged by the requestor as "Change Does Not Work".
Not Work"
"N" Change Requests that
Received Requestor's
Response
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Validate stage and received the requestor's confirmation that the
requested change was implemented successfully.
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Approve stage.
"N" Change Requests to Create Pre-defined search results consisting of a list of change requests in the system that
Work Order
are currently in the Implement stage and awaiting a work order to be created.
"N" Change Requests to
Expire in the Next 30 days
Pre-defined search results consisting of a list of change requests in the system that
will expire within the next 30 days.
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Implement stage and awaiting implementation.
Pre-defined search results consisting of all change requests in the system that are
currently in the Plan stage.
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Review stage and awaiting a controller's review.
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Approve stage, and for which a rule removal notification will be
sent to the rule's traffic requestors.
Pre-defined search results consisting of a list of change requests in the system that
are currently in the Validate stage.
"N" Change Requests Waiting Pre-defined search results consisting of a list of change requests in the system that
for Removal Response from
are currently in the Approve stage and awaiting confirmation from the rules traffic
Rule Requestors
requestors that the requested rule removal is approved.
193
AlgoSec FireFlow
Release 6.3
"N" Change Requests Waiting Pre-defined search results consisting of a list of change requests in the system that
for Requestor's Response
are currently in the Validate stage and awaiting the requestor's confirmation that the
requested change was implemented successfully.
"N" Total New Change
Requests
Pre-defined search results consisting of a list of all change requests in the system that
are new and still in the Request stage, including change requests whose traffic has
not yet been checked against devices.
Bookmarked Change Requests A list of change requests that the user bookmarked.
My Change Requests
Pre-defined search results consisting of a list of change requests in the system that
are owned by you.
RefreshHomepage
Pre-defined search results consisting of a list of change requests in the system that
currently have no owner.
A custom search that was saved under "FireFlow's saved searches", and which is
available to your user role.
For information on saving searches, see Saving Searches.
Chart Name
A chart that was saved under "FireFlow's saved searches", and which is available to
your user role.
For information on saving charts, see Saving Charts.
194
Chapter 15
or
195
AlgoSec FireFlow
Release 6.3
196
Chapter 15
Do this...
Frequency
Specify how often emails containing SLA notification content should be sent. This
can have the following values:
hourly. Emails will be sent once an hour.
daily. Emails will be sent once a day.
weekly. Emails will be sent once every specified number of weeks on the
specified day.
monthly. Emails will be sent once a month on the specified day of the month.
never. Emails will not be sent.
Hour
Select the hour in the displayed timezone, at which emails containing SLA
notification content should be sent.
Note: The timezone can be configured in your user settings. Refer to the AlgoSec
FireFlow User Guide, Configuring User Settings.
Rows
Select the number of change requests in each saved search that should appear in
emails containing dashboard content.
Recipient
Type a list of email addresses to which emails containing SLA notification contents
should be sent. The email addresses must be separated by commas.
If this field is left empty, emails will be sent only to the email address associated with
your FireFlow user account. However, if this field is filled in, emails will not be sent
to the email address associated with your FireFlow user account, unless you include
your email address in the list.
197
CHAPTER 16
In This Chapter
Overriding System Default Settings ................................... 199
Overriding Specific System Default Settings ..................... 200
Reverting to System Defaults ............................................. 231
199
AlgoSec FireFlow
Release 6.3
200
Chapter 16
Configuring the Time Frame for Items Displayed in Auto Matching Page
Lists
By default, FireFlow shows matches made in the last 30 days in each sub-list in the Auto Matching page. You
can modify this system default using the following procedure.
Note: This system default can also be overridden by individual users via the page Preferences > Auto
Matching.
To configure the time frame for items displayed in Auto Matching page sub-lists
1 Log in to the FireFlow server using the username "root" and the related password.
2 Under the directory /usr/share/fireflow/local/etc/site/, open
FireFlow_SiteConfig.pm.
3 Add the configuration item ReconciliationLastDays, and set its value to the desired number of
days for which to display matches in each sub-list in the Auto Matching page.
To specify an unlimited number of days, set it to an empty string ''.
For example, to set the number of days to 365, add the following item:
Set($ReconciliationLastDays, '365');
201
AlgoSec FireFlow
Release 6.3
Priority
Due
Describe the issue
Cc
The default value is empty list, meaning that none of the fields are hidden.
202
Chapter 16
203
AlgoSec FireFlow
Release 6.3
To configure work order creation for "No Action Required" change requests
1 Log in to the FireFlow server using the username "root" and the related password.
2 Under the directory /usr/share/fireflow/local/etc/site/, open
FireFlow_SiteConfig.pm.
3 Add the configuration item ForceCreateWorkOrderForNA.
4 Do one of the following:
To specify that work orders should state "No Action Required" when FireFlow detects that traffic is
not routed through the device, set the configuration item's value to 0.
This is the default value.
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, set the configuration item's value to 1.
204
Chapter 16
For example, the following forces FireFlow to create work orders suggesting a rule to add to the device
policy, even if FireFlow determines that no action is required:
Set ($ForceCreateWorkOrderForNA, 1);
Instruct FireFlow to check traffic at the end of the Plan stage, instead of at the end of the Request stage
Instruct FireFlow to refer to periodic AlgoSec Firewall Analyzer device reports when checking traffic
against devices, instead of referring to real-time monitoring data
205
AlgoSec FireFlow
Release 6.3
Note: New change requests appear in the Home page's New Change Requests list once traffic checking is
complete or when ten minutes have elapsed since the change request's creation, whichever occurs first.
Therefore, when traffic checking occurs at the end of the Request stage, new change requests appear in
the Home page, as soon as traffic checking is done; however, when traffic checking occurs at the end of
the Plan stage, ten minutes will pass before new change requests appear in the Home page.
In order to cause new change requests to appear in the Home page immediately, regardless of when
traffic checking occurs, customize the Network Operations group's Home page as follows: Remove the
"N" New Change Requests element, and add the "N" Total New Change Requests element. New change
requests will appear in the Home page's Total New Change Requests list immediately upon change
request creation.
For information on customizing a group's Home page, see Customizing the Home Page per Group (on
page 18).
4 To specify which data FireFlow should refer to when checking traffic against devices, do the following:
a) Add the configuration item UseMonitorDataForFirewallQuery.
b) Do one of the following:
To specify that FireFlow should refer to real-time monitoring data, set the configuration item's
value to 1.
To specify that FireFlow should refer to AlgoSec Firewall Analyzer reports, set the
configuration item's value to 0.
For example, the following instructs FireFlow to refer to AlgoSec Firewall Analyzer monitoring
data:
Set($UseMonitorDataForFirewallQuery,'1');
5 To enable/disable automatic closing of change requests that already work, do the following:
a) Add the configuration item AutomaticCheckAlreadyWorks.
b) Do one of the following:
To enable automatic closing of change requests that already work, set the configuration item's
value to 1.
206
Chapter 16
To disable automatic closing of change requests that already work, set the configuration item's
value to 0.
For example, the following enables automatic closing of change requests that already work:
Set($AutomaticCheckAlreadyWorks,'1');
Configuring the Risk Check Method for Change Requests with Multiple
Devices
In the Approve stage of traffic change request's lifecycle, FireFlow performs a risk check, to determine
whether implementing the change specified in the change request would introduce risks. The risk check is
run on the device specified in the change request, using the Risk Profile that the device was assigned when
generating the last successful report in AlgoSec Firewall Analyzer.
When performing a risk check for a parent request with sub-requests, there are multiple devices and
potential multiple Risk Profiles involved. You can configure FireFlow to use any of the following risk check
methods:
One
FireFlow runs the risk check on one random device out of all the sub-request devices.
For example, let us assume that there are three sub-requests, as follows:
Sub-request
500
Device
Check Point A
Risk Profile
r1
501
Check Point B
r2
502
Cisco C
r1
FireFlow will select a device at random (such as Cisco C) and run the risk check on it (using Risk Profile
r1).
Only risk check results for the selected device will be displayed.
Profile
FireFlow runs the risk check on one random device per Risk Profile used by the sub-request devices.
207
AlgoSec FireFlow
Release 6.3
In our example, there are two Risk Profiles, r1 and r2. FireFlow will select a device at random (either
Check Point A or Cisco C) to run the risk check on using Risk Profile r1, and it will also run a risk check
on Check Point B using Risk Profile r2.
Risk check results will be displayed per risk profile.
208
All
FireFlow runs the risk check on each of the sub-request devices.
In our example, FireFlow will run a risk check on Check Point A, Check Point B, and Check Point C,
using their respective Risk Profiles.
Note that the risk check may take a while, and the results for each device may be similar.
Chapter 16
To set the default risk check method for change requests with multiple devices
1 Log in to the FireFlow server using the username "root" and the related password.
2 Under the directory /usr/share/fireflow/local/etc/site/, open
FireFlow_SiteConfig.pm.
3 Add the configuration item RiskCheckOnParentTicket.
209
AlgoSec FireFlow
Release 6.3
Chapter 16
AlgoSec FireFlow
Release 6.3
212
Chapter 16
The supported policy rule fields are: FirewallName, FirewallRuleNum, Name, Comment, Source,
Destination, Service, SourceExpanded, DestinationExpanded, ServiceExpanded,
Action, Enable, Track, Time, Install, Vpn, FromZone, ToZone, ACL, Interface, SourceNat,
and DestinationNat.
Note: SourceExpanded, DestinationExpanded, and ServiceExpanded are the IP addresses (and
protocol/ports) represented by the rules object names. Therefore, for example, when adding Source to
IgnoreRuleFieldsInReconciliation, changes in a rules source object names will be approved
automatically, while changes to the actual source IP addresses will not.
For example, to configure FireFlow to automatically approve changes to rules that involve logging
and/or comments only, add the following item:
Set (@IgnoreRuleFieldsInReconciliation, qw(Track Comment));
Leave the configuration item's value empty to specify that the FireFlow server's email address should be
used.
4 Save the file.
5 Restart FireFlow.
See Restarting FireFlow (on page 11).
213
AlgoSec FireFlow
Release 6.3
To configure the amount of time the device objects list is stored in cache
1 Log in to the FireFlow server using the username "root" and the related password.
2 Under the directory /usr/share/fireflow/local/etc/site/, open
FireFlow_SiteConfig.pm.
3 Add the configuration item FirewallObjectRefreshTime, and set its value to the desired number of
seconds that the device objects list should be stored in cache.
For example, to set the time in cache to two minutes (120 seconds), add the following item:
Set($FirewallObjectRefreshTime,'120');
214
Chapter 16
To specify that emails to related change requestors should include a table with the rule to be
removed, set the configuration item's value to 1.
This is the default value.
To specify that emails to related change requestors should not include a table with the rule to be
removed, set the configuration item's value to 0.
For example, the following specifies that a table with the rule to be removed should not be included in
emails to related change requestors:
Set($ShowRuleInfoWhenNotifyRuleToRemove,0);
Configuring the Default Due Date for Change Requests Marked for
Future Recertification
When marking change requests for future recertification, the due date for the change request(s) is deferred to
365 days from the original due date, by default. If desired, you can change this default value.
To change the default due date for change requests marked for future recertification
1 Log in to the FireFlow server using the username "root" and the related password.
2 Under the directory /usr/share/fireflow/local/etc/site/, open
FireFlow_SiteConfig.pm.
3 Add the configuration item DefaultExpirationPeriod, and set its value to the number of days after
the original due date that the change request should be due.
For example, to specify that the default due date for such requests should be 90 days after the original
due date, add the following item:
Set($DefaultExpirationPeriod,90);
AlgoSec FireFlow
Release 6.3
216
City
Country
EmailAddress
HomePhone
Id
Organization
RealName
Custom user fields. These fields will appear without spaces as hash keys. For example, a custom field
named "Custom Field" will appear as: "CustomField".
Chapter 16
For example, the user properties hash translated to XML format may appear as follows:
<User>
<City></City>
<Country></Country>
<EmailAddress>requestor1@mycompany.com</EmailAddress>
<HomePhone></HomePhone>
<Id>6894</Id>
<Organization></Organization>
<RealName>Rachel Requestor</RealName>
<CustomField></CustomField>
</User>
4 To add items to the user properties list, add the desired user properties to
@UserFieldsForHooksSearch, in single quotation marks, separated by commas.
You can add any of the properties listed in the following table.
For example, to include the user's nickname as a property, write:
Set(@UserFieldsForHooksSearch,('Id', 'RealName', 'HomePhone', 'Organization',
'EmailAddress', 'City', 'Country', 'Nickname'));
Note: You must use only supported properties. Otherwise, a warning will be written to the log and the
search will not be displayed.
5 To remove items from the user properties list, delete the relevant user properties from
@UserFieldsForHooksSearch.
6 Save the file.
7 Restart FireFlow.
See Restarting FireFlow (on page 11).
Supported User Properties
Property
Description
Address1
Address2
AuthSystem
City
217
AlgoSec FireFlow
Release 6.3
Comments
Country
Created
Creator
EmailAddress
HomePhone
Id
Lang
LastUpdated
LastUpdatedBy
MobilePhone
Name
Nickname
Organization
PagerPhone
Password
RealName
Signature
State
TimeZone
WorkPhone
Zip
218
Chapter 16
219
AlgoSec FireFlow
220
Release 6.3
Chapter 16
Code
Chinese (PRC)
zh_CN
Chinese (Taiwan)
zh_TW
Croatian
hr
Czech
cs
Danish
da
Dutch
nl
English
en
Finnish
fi
French
fr
German
de
Hebrew
he
Hungarian
hu
Indonesian
id
Italian
it
Japanese
ja
Norwegian Bokmal
nb
Polish
pl
Portuguese
pt
Portuguese (Brazillian)
pt_BR
Russian
ru
Spanish
es
Swedish
sv
Turkish
tr
221
AlgoSec FireFlow
Release 6.3
To translate the Add More Files link to French, the file should include the following lines:
msgid "Add More Files"
msgstr "Ajouter d'autres fichiers"
You can also translate text that includes placeholders (in the format %x), by including the same
placeholders in the translation. For example:
msgid "Owner changed from %1 to %2"
msgstr "Propritaire chang de %1 en %2"
Chapter 16
FireFlow will refer to the new *.po file for strings. If a string does not appear in the file, FireFlow will
refer to the original English-language *.po file for the missing string.
Source NAT
Destination NAT
NAT Type
Port Translation
Note: The following procedure will remove the standard NAT fields for all users except FireFlow
configuration administrators. If it is necessary to remove these fields for FireFlow configuration
administrators as well, contact AlgoSec Professional Services.
2 For each of the NAT-related FireFlow fields listed in the table below, do the following:
a) Click FireFlow Fields.
223
AlgoSec FireFlow
Release 6.3
Chapter 16
d) In each user group's Current rights area, select the SeeCustomField and ModifyCustomField check
boxes.
Note: These check boxes might not appear for all user groups.
e) Click Submit.
NAT-related FireFlow Fields
FireFlow Field
Description
Displays the type of NAT (Static or Dynamic), as planned during the Plan
stage.
Change Port Translation: Change port Displays the port value to which the connection's port should be translated, as
planned during the Plan stage.
translation
Change Source NAT: Change source Displays the source NAT value to which the connection's source should be
NAT
translated, as planned during the Plan stage.
Requested Destination NAT:
Requested destination NAT
Displays the port value to which the connection's port should be translated, as
specified in the original request.
225
AlgoSec FireFlow
Release 6.3
Displays the source NAT value to which the connection's source should be
translated, as specified in the original request.
The new NAT fields will appear below the standard NAT fields throughout the FireFlow Web interface, for
example in work orders or when editing a change request.
226
Chapter 16
5 Restart FireFlow.
See Restarting FireFlow (on page 11).
5 If you enabled handling of NAT-only traffic changes, configure whether FireFlow should use NAT
information in risk checks, by doing the following:
a) Add the configuration item sendNATinformationInRiskCheck.
227
AlgoSec FireFlow
Release 6.3
Note: When this feature is enabled, the Source NAT and Destination NAT fields will be used in risk
checks. However, if the optional Source after NAT field is enabled, it will be used instead of the Source
NAT field. Likewise, if the optional Destination after NAT field is enabled, it will be used instead of the
Destination NAT field. For information on these optional fields, see Adding/Removing Optional NAT
Fields in Change Requests (on page 226). If you enabled handling of NAT-only traffic changes,
configure whether FireFlow should display NAT information in work orders, by doing the following:
c) Add the configuration item showAllNatTable.
d) Do one of the following
To enable displaying NAT information in work orders, set the configuration item's value to 1.
To disable displaying NAT information in work orders, set the configuration item's value to 0.
This is the default value.
For example, the following enables displaying NAT information in work orders:
Set($showAllNatTable,'1');
228
Chapter 16
c) Click Scrips.
The Modify scrips which apply to all queues page appears.
AlgoSec FireFlow
Release 6.3
230
Chapter 16
231
CHAPTER 17
233
AlgoSec FireFlow
Release 6.3
Where:
FF_CustFieldX - The name of a user field in FireFlow to which you want to import data. This
can be a a built-in field or a user-defined custom field.
LDAP_AttrX - The name of a user field in the LDAP server from which you want to import
data.
In order to map a user-defined custom field called "Department" to an LDAP attribute called
"department", set the following value:
LDAP_AttrCustom=Department,department
Note: In this example, the LDAP server field names are taken from Active Directory. If a different
LDAP server is used, the names must be changed accordingly.
e) Save the file.
234
CHAPTER 18
In This Chapter
Overview ............................................................................ 235
Integrating FireFlow via the REST Interface ..................... 235
Integrating FireFlow via a CMS's Web Service ................. 239
Integrating FireFlow via Email .......................................... 244
Overview
FireFlow can be integrated with an organization's main Change Management System (CMS), such as BMC
Remedy, HP Service Center and Service Manager (formerly Peregrine), and more. Communication between
the two systems can be based on the following protocols:
REST interface
The CMS can use the REST interface to create change requests in FireFlow via HTTP.
See Integrating FireFlow via the REST Interface (on page 235).
Web service
FireFlow can establish a uni-directional connection with a CMS's Web service. This enables FireFlow to
send the CMS requests to open a change request or update its status.
See Integrating FireFlow via a CMS's Web Service (on page 239).
Email
FireFlow can send email messages to the CMS and receive requests to open a change request or update
its status via email. If the CMS has these same capabilities, it is possible to achieve an email-based
integration.
Email is the easiest protocol to configure and allows for bi-directional communication.
See Integrating FireFlow via Email (on page 244).
Regardless of the protocol selected, integrating FireFlow with a CMS requires customization on both sides.
235
AlgoSec FireFlow
Release 6.3
236
Chapter 18
For information on the available keys and their values, refer to the following table.
For example, you can create a change request by posting the following:
on0 /FireFlow/REST/1.0/ticket/new
Queue: 1
Requestor: req@algosec.com
Subject: Creating ticket via REST
CF.{Requested Source}: 1.1.1.1
CF.{Requested Source}: 2.2.2.2
CF.{Requested Destination}: 3.3.3.3
CF.{Requested Service}: ssh
CF.{Requested Service}: https
REST Change Request Creation Keys
Set this key...
To this value...
Requestor
Queue
Subject
Status
Owner
Due
The date by which this change request should be resolved, in the following format:
YYYY-MM-DD HH:MM:SS
This key is optional.
Priority
237
AlgoSec FireFlow
CF.{customField}
Release 6.3
To this value...
Expires
The date on which this change request will expire, in the following format:
YYYY-MM-DD HH:MM:SS
Requested Source
The IP address, IP range, network, device object, or DNS name of the connection
source.
Requested Destination
The IP address, IP range, network, device object, or DNS name of the connection
destination.
Requested Service
The device service or port for the connection (for example "http" or "tcp/123").
Requested Action
The device action to perform for the connection. This can be either of the following:
Workflow
Owning Group
CMS ticket id
238
Chapter 18
Firewall Name
Form Type
The request template type. This can have the following values:
Object Change
Traffic Change
Generic Change
The requested action in an object change request. This can have the following values:
AddIPsToObject
RemoveIPsFromObject
NewObject
DeleteObject
If you are not sure whether your CMS includes a Web service and a WSDL file, or if you need other
assistance in integrating FireFlow with a Web service, contact AlgoSec Professional Services.
AlgoSec FireFlow
Release 6.3
240
Chapter 18
10 Click Scrips.
241
AlgoSec FireFlow
242
Release 6.3
Chapter 18
243
AlgoSec FireFlow
Release 6.3
FireFlow
Notified
The following example describes an email-based integration between FireFlow and BMC Remedy Change
Management Application.
Note: The instructions provided are specific to Remedy Action Request System 7.1.00 and may vary for
different Remedy versions.
For information on integrating FireFlow with other change management systems, contact AlgoSec.
244
Chapter 18
Preparation
Email Addresses
Use the table below to record email addresses used by both Remedy and FireFlow to receive change request
submissions and send change request updates.
FireFlow Email Address
Remedy Email Address
Remedy User
Create or select an existing Remedy user that will perform actions on behalf of FireFlow, then choose an
alpha-numeric string to serve as a security key for this user. Use the table below to record the user's
username, password, and security key.
Username
Password
Security Key
To specify that FireFlow should not send email and notifications to the Remedy Server, leave this item
empty.
4 Add the configuration item ExternalCMSSenderEmails, and set its value to a space-separated list of
email addresses, from which the Remedy Server is expected to send emails to FireFlow upon change
request creation.
For example:
Set(@ExternalCMSSenderEmails, qw(remedy@my.organization.com
remedy-alias@my.organization.com));
245
AlgoSec FireFlow
246
Release 6.3
Chapter 18
247
AlgoSec FireFlow
248
Release 6.3
Chapter 18
In order to configure Remedy to send email upon change request submissions, you must specify a filter
using the following procedure.
Note: For more detailed instructions on how to configure Remedy for email integration, refer to the
Configuring the email engine for modify actions and Defining workflow to send email notifications
sections in the BMC Remedy Action Request System Administering BMC Remedy Email Engine
document. This document for version 7.0 is located here:
http://documents.bmc.com/supportu/documents/84/75/58475/58475.pdf
249
AlgoSec FireFlow
250
Release 6.3
Chapter 18
251
AlgoSec FireFlow
Release 6.3
252
Chapter 18
Password: <password>
Key: FireFlow
Action: Modify
Form: CHG:Infrastructure Change
Request ID: $Request ID$
Server: <remedy server>
User Name: <username>
Password: <password>
Key: FireFlow
Action: Modify
Form: CHG:Infrastructure Change
Request ID: $Request ID$
Server: <remedy server>
User Name: <username>
Password: <password>
Key: FireFlow
Action: Modify
Form: CHG:Infrastructure Change
Request ID: $Request ID$
Server: <remedy server>
User Name: <username>
Password: <password>
Key: FireFlow
Action: Modify
Form: CHG:Infrastructure Change
Request ID: $Request ID$
253
CHAPTER 19
In This Chapter
Overview ............................................................................ 255
FireFlow Services ............................................................... 255
Data Types.......................................................................... 259
Overview
FireFlow has its own Web service. A Web service is an API that can be accessed and executed over the
network, thus allowing Web service clients, which are the machines used by authenticated FireFlow users, to
perform remote operations on the Web service server, which is FireFlow. Supported operations are
described in XML format in FireFlow's Web service's WSDL (Web Services Description Language) file,
available at https://<algosec_server>/WebServices/FireFlow.wsdl where
<algosec_server> is the AlgoSec server URL. Web clients refer to the WSDL file when performing
operations on FireFlow.
FireFlow Services
FireFlowAuthenticateRequest
Description
Authenticates a user.
Once authenticated, the client will receive a session identifier. This identifier will be required as proof of
authentication for future requests.
Header Elements
Element
Type
Mandatory
Description
version
String
Yes
opaque
String
No
255
AlgoSec FireFlow
Release 6.3
Message Elements
Element
Type
Mandatory
Description
username
String
Yes
password
String
Yes
Returns
A FireFlowAuthenticationResponse response. See FireFlowAuthenticationResponse (on page
257).
FireFlowCreateTicketRequest
Description
Creates a new FireFlow change request.
Header Elements
Element
Type
Mandatory
Description
version
String
Yes
sid
String
Yes
onBehalfOf
String
No
opaque
String
No
Element
Type
Mandatory
Description
template
String
Yes
ticket
Ticket
Yes
Message Elements
Returns
A FireFlowCreateTicketResponse response. See FireFlowCreateTicketResponse (on page 258).
256
Chapter 19
FireFlowTerminateSessionRequest
Description
Terminates the current session.
Header Elements
Element
Type
Mandatory
Description
version
String
Yes
sid
String
Yes
opaque
String
No
Message Elements
None.
Returns
A FireFlowTerminateSessionResponse response. See FireFlowTerminateSessionResponse (on
page 258).
FireFlowAuthenticationResponse
Description
The response to an authentication attempt.
Header Elements
Element
Type
Mandatory
Description
version
String
Yes
opaque
String
No
Message Elements
Element
Type
Mandatory
Description
result
Integer
Yes
sid
String
Yes
message
String
No
257
AlgoSec FireFlow
Release 6.3
FireFlowCreateTicketResponse
Description
A general response to various services.
Header Elements
Element
Type
Mandatory
Description
version
String
Yes
opaque
String
No
Message Elements
Element
Type
Mandatory
Description
result
Integer
Yes
message
String
No
ticketId
Integer
Yes
FireFlowTerminateSessionResponse
Description
The response to the session termination request.
Header Elements
Element
Type
Mandatory
Description
version
String
Yes
opaque
String
No
Message Elements
Element
Type
Mandatory
Description
result
Integer
Yes
sid
String
Yes
message
String
No
258
Chapter 19
Data Types
Ticket
Description
A FireFlow change request.
Elements
Element
Type
Mandatory
Description
owner
String
No
requestor
String
Yes
cc
List of Strings
No
subject
String
Yes
due
String
No
expire
String
No
priority
Integer
No
refersTo
Integer
No
referredBy
Integer
No
externalId
String
No
devices
List of Strings
No
description
String
No
trafficLines
List of
TrafficLine
objects
No
customFields
List of
CustomField
objects
No
259
AlgoSec FireFlow
Release 6.3
TrafficLine
Description
A traffic tuple in a FireFlow change request.
Elements
Element
Type
Mandatory
Description
trafficSource
List of
TrafficAddres
s objects
Yes
trafficDestinat List of
ion
TrafficAddres
s objects
Yes
trafficService
List of
TrafficServic
e objects
Yes
nat
TrafficNAT
No
action
Integer
Yes
List of
CustomField
objects
No
TrafficAddress
Description
An address in a traffic tuple.
Elements
Element
Type
Mandatory
Description
address
String
Yes
customFields
List of
CustomField
objects
No
260
Chapter 19
TrafficService
Description
A service in a traffic tuple.
Elements
Element
Type
Mandatory
Description
service
String
Yes
customFields
List of
CustomField
objects
No
TrafficNAT
Description
Network Address Translation (NAT) information for a traffic tuple.
Elements
Element
Type
Mandatory
Description
source
String
Yes
destination
String
Yes
port
String
Yes
type
Integer
No
0. Static NAT.
1. Dynamic NAT.
CustomField
Description
A custom field in a FireFlow change request.
Elements
Element
Type
Mandatory
Description
Key
String
Yes
value
String
Yes
261
CHAPTER 20
In This Chapter
Overview ............................................................................ 263
Creating a Customizations File .......................................... 266
Loading a Customizations File to the Target Site .............. 267
Overview
The AlgoSec FireFlow copy customization utility can be used to copy the following user customizations
between sites:
Database entities
Configuration files
Translation files
Scripts for uploading change requests from file
Hook files
Web Service clients
Database Entities
The utility copies the following database entities:
Queues
The following information is copied for each queue:
Description
CorrespondAddress
CommentAddress
InitialPriority
FinalPriority
DefaultDueIn
SubjectTag
Disabled
Attributes: AdminGroupID, SecurityGroupID, NetworkGroupID, ReadOnlyGroupID,
ControllersGroupID (according to the ID of the created groups)
263
AlgoSec FireFlow
Release 6.3
Note: If a queue's name is changed on the original site, the utility will create both a queue with the
original name and a queue with the new name on the target site.
Groups
The following information is copied for each group:
Description
Disabled
Global rights, including rights for roles
Queue rights per queue, including rights for roles
Group rights
Home Page settings
The group's membership in other groups
Note: When updating FireFlow, global rights, queue rights, and group rights that are not in a
customization file will be revoked.
Note: If a group's name is changed on the original site, the utility will create both a group with the
original name and a group with the new name on the target site.
Note: Since the utility does not copy users and their group memberships, it will be necessary to define
the users as members of the new group on the target site.
Custom fields
All custom fields are copied, including those for change requests, users, and groups.
The following information is copied for each custom field:
Description
DisplayName
Type
ValuesClass
LookupType
Pattern
LinkValueTo
IncludeContentForValue
Category
DefaultValue
Disabled
HideIfEmpty
Note: When updating FireFlow, custom fields that do not appear in the customization file will be
removed. Furthermore, custom fields referring to queues, system group rights, or user-defined group
rights that do not appear in the customization file will be removed.
Note: If a custom field's name is changed on the original site, the utility will create both a custom field
with the original name and a custom field with the new name on the target site.
264
Request templates
The following information is copied for each request template:
Description
All defined values
Chapter 20
Note: If a request template's name is changed on the original site, the utility will create both a template
with the original name and a template with the new name on the target site.
Note: Request templates cannot be disabled; therefore, the utility will not remove them from the target
site.
Email templates
All email templates are copied, including both global and per queue.
The following information is copied for each email template:
Name
Description
Content
Note: Email templates cannot be disabled; therefore, the utility will not remove them from the target site.
Scrips
All scrips are copied, including both global and per queue.
The following information is copied for each scrip:
Description
Stage
CustomIsApplicableCode (in case of a user-defined condition)
CustomPrepareCode (in case of a user-defined action)
CustomCommitCode (in case of a user-defined action)
ScripAction name
ScripCondition name
Email Template name
Note: FireFlow scrips have no name; therefore, if two scrips have the same description, only one of them
will be updated.
Saved searches
Global Home Page settings
Configuration Files
The utility copies the following configuration files:
265
AlgoSec FireFlow
Release 6.3
The utility adds all parameters in the file that do not include the words Email, Password, Address, or
FAUser to the the parallel file on the target site, that is, all user and password-related parameters are not
copied. Other parameters are updated or added to the end of the file on the target site.
The file on the original site is backed up before it is edited.
Translation Files
The utility copies all translation files located under /usr/share/fireflow/local/etc/site/po.
Hook Files
The utility copies all hook files and related configuration files located under
/usr/share/fireflow/local/Hooks and /usr/share/fireflow/local/etc/site/Hooks.
target site.
Description
-f CustFile
266
Chapter 20
-e
Description
-f CustFile
-u
Update existing elements on the target site with data from the customizations file.
If this flag is not used, only new elements will be added.
-r
Remove database entities that do not appear in customizations file from the target site.
The entities will be marked as disabled.
267
Index
A
About VisualFlow 73
Accessing Online Help 78
Accessing VisualFlow 74, 136, 137, 139, 267
Action Condition Syntax 102, 105, 164
Action Tag Attributes 146, 149, 165
Adding Actions 95, 136, 137, 138, 140, 141
Adding Parallel Action Logic 103, 126
Adding SLA Notifications 189
Adding SLOs 129
Adding Statuses 87, 137, 139
Adding the 22, 23
Adding User Groups 29, 139
Adding User-Defined Custom Fields 44, 233
Adding Workflows 78, 136, 137, 139, 146
Adding/Removing Optional NAT Fields in
Change Requests 226, 228
Adding/Removing Standard NAT Fields in
Change Requests 223
Advanced Configuration Options 2
Advanced Configuration Tools 3
Assigning Global and Queue Rights to User
Groups 31, 33, 35
Automatically Sending Work Orders to an
Implementation Team 228
C
Comprehensive Example 86, 126, 146, 176
Condition Tag Attributes and Syntax 163
Condition Tag Syntax 144, 145
Configuration Files 265
Configuration Options 1
Configuring a Group's Global and Queue Rights
35, 139, 141
Configuring Authentication to FireFlow 236
Configuring Automatic Approval of Minor Rule
Changes 212
Configuring Automatic Initial Planning 205
Configuring Change Request Creation from File
2, 61, 62
Configuring FireFlow for Use with Remedy
244, 245
Configuring FireFlow to Use a Web Service 240
Configuring FireFlow's Default Interface
Language 220
AlgoSec FireFlow
D
Data Types 259
Database Entities 263
Release 6.3
E
Editing Actions 127, 136, 138, 140
Editing FireFlow Fields 49
Editing SLA Notifications 194
Editing SLOs 94, 132
Editing Statuses 93
Editing the Workflow Configuration File 143,
147
Editing User Groups 32
Editing User-Defined Custom Fields 49
Editing Workflows 87, 136, 137, 139
Email Addresses 245, 249, 251
Email Integration Steps 244
Enabling Privileged Users 27
Enabling User Groups 41
Enabling User-Defined Custom Fields 51
Enabling/Disabling Automatic Creation of
Requestors upon Authentication 211, 233
Enabling/Disabling Inclusion of User-Defined
Custom Traffic Fields in Flat Tickets 106,
108, 113, 115, 216
Enabling/Disabling Multiple Traffic Rows in
Change Requests 202
Enabling/Disabling Sub-Request Traffic
Modification 203
Enabling/Disabling Traffic Field Validation
203, 204
Enabling/Disabling Translation of Object IP
Addresses and Ports in Work Orders 205
Enabling/Disabling User Group Authentication
during Initial Planning 227
Example
Adding Another Approve Stage 139
Allowing the Network Group to Approve
Change Requests 137
Removing the Notify Requestor Stage 136
Examples 136
Chapter 20
Exiting VisualFlow 78
F
FireFlow Advanced Configuration 1
FireFlow Services 255
FireFlowAuthenticateRequest 255
FireFlowAuthenticationResponse 256, 257
FireFlowCreateTicketRequest 256
FireFlowCreateTicketResponse 256, 258
FireFlowTerminateSessionRequest 257
FireFlowTerminateSessionResponse 257, 258
Flat Ticket Example 69, 105, 116, 169, 170,
171, 174, 175, 176
Flat Ticket Nodes 105, 106
G
GetExternalRisks 169
GetFirewallGroupName 170
GetRealGroupName 171
GetRequestorSearches 172
Getting Started with VisualFlow 74
GetWorkFlowName 174
H
Hiding Change Request Fields 202
Hook Files 266
Hook Functions 168, 169
I
Importing User Data from an LDAP Server 3,
211, 233
Installing Workflows 73, 134, 136, 139, 141
Integrating FireFlow via a CMS's Web Service
235, 239
Integrating FireFlow via Email 235, 244
Integrating FireFlow via the REST Interface
235
Integrating FireFlow with External Change
Management Systems 3, 235
Introduction 1
L
Loading a Customizations File to the Target Site
267
Logging in for Advanced Configuration Purposes
3, 7, 14, 18, 22, 23, 25, 27, 29, 32, 33, 35, 41,
44, 49, 51, 52, 57, 66, 74, 136, 137, 139, 178,
181, 183, 189, 194, 196, 197, 228, 240, 246
Index
M
Managing Email Subscriptions to SLA
Notifications 196
Managing Group Members 31, 33
Modifying Email Templates 66
Modifying FireFlow Email Templates 2, 65
Modifying FireFlow Interface Text 3, 222
Modifying Workflows 164
O
Overriding FireFlow System Defaults 2, 199
Overriding Specific System Default Settings
199, 200
Overriding System Default Settings 60, 199
Overview 13, 43, 61, 65, 71, 133, 143, 167, 177,
189, 235, 255, 263, 266, 267
P
Preparation 244, 245
R
Remedy Filter Text 251, 252
Remedy User 245, 249
Reordering Actions 128, 137, 140
Reordering Statuses 94, 137, 140
Reordering Workflows 133
Replacing the Logo 2, 218
REST Interface Integration Steps 236
Restarting FireFlow 4, 11, 56, 60, 63, 64, 127,
135, 136, 139, 141, 144, 147, 165, 166, 168,
199, 200, 201, 202, 203, 204, 205, 207, 210,
211, 212, 213, 214, 215, 216, 217, 221, 222,
227, 228, 231, 240, 245
Reverting to System Defaults 231
Reverting to the System Default Workflow via
XML 166
S
Setting the Default Workflow 133
Status Tag Attributes 146, 160, 165
SuggestCommentSuffix 174
SuggestHostName 175
Supported Boolean Operators 81, 86, 106, 126,
145
Supported Comparison Operators 106, 125
Supported Fields 81, 145
T
The VisualFlow User Interface 75
AlgoSec FireFlow
U
Upload Change Requests from File Scripts 266
Using Hooks 2, 167
Using Hooks to Control Parameters 167
Using the AlgoSec FireFlow Copy Customization
Utility 263
V
ValidateTicket 175
ValidateWorkOrderEdit 176
Viewing Individual Workflows' XML Files 134
Viewing the Workflow Configuration File 134
Viewing the Workflow XML 134
Viewing Workflow Layouts 75, 76
W
Web Service Clients 266
Web Service Integration Steps 239
Workflow Condition Syntax 81
Workflow Configuration File Structure 134,
144
Workflow File Structure 134, 146, 148
Workflow Tag Attributes 143, 144, 147
Working with Actions 80, 87, 95
Working with Custom Fields 1, 37, 43
Working with Rights 2, 172, 177
Working with SLA Notifications 1, 129, 189
Working with SLAs 80, 87, 129
Working with Statuses 80, 87
Working with User Groups 1, 29, 233
Working with Users 25
Working with Workflows in VisualFlow 2, 32,
71, 143, 181, 183
Working with Workflows via XML 2, 73, 143
Release 6.3