Skybox ChangeManager UsersGuide V10!0!300

Skybox Change Manager
User Guide
10.0.300
Revision: 11
Proprietary and Confidential to Skybox Security. © 2019 Skybox Security,
Inc. All rights reserved.
Due to continued product development, the information contained in this
document may change without notice. The information and intellectual property
contained herein are confidential and remain the exclusive intellectual property of
Skybox Security. If you find any problems in the documentation, please report
them to us in writing. Skybox Security does not warrant that this document is
error-free.
No part of this publication may be reproduced, stored in a retrieval system, or
transmitted in any form or by any means—electronic, mechanical, photocopying,
recording, or otherwise—without the prior written permission of Skybox Security.
Skybox®, Skybox® Security, Skybox Firewall Assurance, Skybox Network
Assurance, Skybox Vulnerability Control, Skybox Threat Manager, Skybox
Change Manager, Skybox Appliance 5500/6000/7000/8000/8050, and the
Skybox Security logo are either registered trademarks or trademarks of Skybox
Security, Inc., in the United States and/or other countries. All other trademarks
are the property of their respective owners.
Contact information
Contact Skybox using the form on our website or by emailing
info@skyboxsecurity.com
Customers and partners can contact Skybox technical support via the Skybox
Support portal
Contents
Technical support ..................................................................................... 5
How this manual is organized ..................................................................... 5
Overview of Skybox Change Manager ........................................................ 6
Change management............................................................................... 9
Users and their responsibilities ................................................................... 9
Typical flow of a change request ............................................................... 10
Submitting change requests ..................................................................... 11
Selecting a workflow .......................................................................... 13
Requesting specific access .................................................................. 13
Uploading a file with multiple requests ................................................. 15
Adding an access rule ........................................................................ 16
Modifying access rules ........................................................................ 20
Deactivating and enabling access rules ................................................. 21
Modifying firewall objects.................................................................... 22
Custom change requests .................................................................... 22
Cloning a change request ................................................................... 23
Adding business information to an access rule ....................................... 23
Processing technical details ...................................................................... 23
Reviewing tickets that have no formal change requests .......................... 24
Reviewing the derived change requests ................................................ 24
Assessing risk ........................................................................................ 26
Implementation phase ............................................................................ 28
Verifying a request ................................................................................. 29
Additional workflow actions ...................................................................... 30
Rule recertification ................................................................................. 31

Recertification for rules with multiple owners ............................................. 31
Change implementation .......................................................................... 33

Viewing a specific set of change requests .................................................. 33
Assigning change requests ....................................................................... 34
Implementing change requests................................................................. 34
Viewing change requests in command format ........................................ 34
Marking change requests as implemented............................................. 35
Automatic implementation .................................................................. 36
Reverting automatically implemented change requests ........................... 39
Skybox version 10.0.300 3

Skybox Change Manager User Guide
Exporting information from Change Manager ............................................. 40
Workflow statistics ................................................................................. 41
Administration of Change Manager ........................................................... 42

User management .................................................................................. 42
User roles ......................................................................................... 43
User activities ................................................................................... 44
Creating users and user groups ........................................................... 44
Defining a default user for each group .................................................. 45
Permissions ...................................................................................... 45
Customizing the look and feel of Change Manager ...................................... 47
Configuring Change Manager options ........................................................ 48
Configuring Change Manager settings .................................................. 48
Configuring upload of change requests from files ................................... 49
Creating custom change request types ................................................. 50
Configuring Change Manager display options......................................... 50
Configuring object suggestion ............................................................. 51
Configuring automatic implementation ................................................. 51
Configuring risk assessment................................................................ 52
Configuring tickets ............................................................................. 53
Customizing ticket phases and workflows .................................................. 53
Overview of workflows and phases....................................................... 54
Defining the default work time for ticket workflows ................................ 55
Creating customized workflows ........................................................... 55
Configuring automatic promotion for recertification tickets with multiple
owners ............................................................................................. 60
Editing phases ................................................................................... 61
Multi-tier change requests ....................................................................... 63
Customizing ticket priority levels .............................................................. 64
Enabling users to change the status of their tickets ..................................... 64
Setting up the Application & Service repository .......................................... 65
Maintaining the repository .................................................................. 65
Using application phase approvers as default ticket phase owners ........... 67
Setting up analysis of change requests ...................................................... 68
Triggers................................................................................................. 68
Creating triggers ............................................................................... 68
How notifications work ....................................................................... 70
Customizing notifications .................................................................... 71
Integration with the ServiceNow ticketing system ....................................... 75
Supported workflows.......................................................................... 75
Setting up ServiceNow ....................................................................... 76
Setting up Skybox ............................................................................. 76
Configuration .................................................................................... 78
Working with ServiceNow ................................................................... 79

Preface
Technical support
You can contact Skybox using the form on our website or by emailing
info@skyboxsecurity.com
Customers and partners can contact Skybox technical support via the Skybox
Support portal
When you open a case, you need:
› Your contact information (telephone number and email address)

› Skybox version and build numbers
› Platform (Windows or Linux)
› Problem description
› Any documentation or relevant logs
You can compress logs before attaching them by using the Pack Logs tool (see
Packing log files for technical support, in the Skybox Installation and
Administration Guide).
How this manual is organized

This manual includes the following chapters:
› Overview of Skybox Change Manager (on page 6)

› Change planning (on page 9)
› Rule recertification (on page 31)
› Change implementation (on page 33)
› Exporting information from Skybox Change Manager (on page 40)
› Administration (on page 42)

Chapter 1
Overview of Skybox Change

Manager
Skybox® Security arms security professionals with the broadest platform of
solutions for security operations, analytics, and reporting. By integrating with
more than 100 networking and security technologies organizations, the Skybox
Security Suite merges data silos into a dynamic network model of your
organization’s attack surface, giving comprehensive visibility of public, private,
and hybrid IT environments. Skybox provides the context needed for informed
action, combining attack vector analytics and threat-centric vulnerability
intelligence to continuously assess vulnerabilities in your environment and
correlate them with exploits in the wild. This makes the accurate prioritization
and mitigation of imminent threats a systematic process, decreasing the attack
surface and enabling swift response to exposures that truly put your organization
at risk.

Chapter 1 Overview of Skybox Change Manager
Skybox arms security leaders with a comprehensive cybersecurity management

platform to address the security challenges of large, complex networks. The
Skybox Security Suite breaks down data silos to build a dynamic network model
that gives complete visibility of an organization’s attack surface and the context
needed for informed action across physical, multi-cloud, and industrial networks.
We leverage data by integrating with 120 security technologies, using analytics,
automation, and advanced threat intelligence from the Skybox Research Lab to
continuously analyze vulnerabilities in your environment and correlate them with
exploits in the wild. This makes the prioritization and mitigation of imminent
threats an efficient and systematic process, decreasing the attack surface and
enabling swift response to exposures that truly put your organization at risk. Our
award-winning solutions automate as much as 90 percent of manual processes
and are used by the world’s most security-conscious enterprises and government
agencies, including Forbes Global 2000 companies. For additional information
visit the Skybox website
Change Manager ends risky changes with network-aware planning and risk
assessment that keep your network secure and in continuous compliance with
policies. Change Manager incorporates customizable workflows and provides
comprehensive management of rule lifecycles to automate change processes.
› Fully automates firewall change management workflows, improving

communication and efficiency across security teams

› Validates proposed firewall changes by checking for policy violations, security

gaps and vulnerabilities that could be exposed by the change
› Ensures that changes are made as intended and do not introduce new risk
› Customizes and simplifies workflows to reduce change management time by
80 percent
› Establishes end-to-end rule life cycle management for secure infrastructure
and optimized firewalls
Highlights
› Intelligently automated, closed-loop workflow

• Completely automates change workflows in a web-based application
• Provides a fully integrated ticketing system, including multiple phases,
audit log, comments, attachments, approval promotion, detailed reporting,
automatically verifying that changes are complete and closing the ticket
• Flexible, customizable integration with 3rd-party ticketing, provisioning,
and other workflow systems
› Identifies next-generation application- and user-level changes along with

source, destination and ports for detailed change specifications
› Checks actual connectivity by simulating the firewall access list
› Checks policy compliance requests against out-of-the-box or customized
policies
› Formalizes rule and object changes with the option to push select changes
live
› Delivers email notifications and alerts
› Comprehensive device support
Refer to the Skybox website for a list of supported devices.

Chapter 2
Change management
Change Manager provides a complete and centralized change workflow so that
you can:
› Identify the firewalls that need changing

› Plan and optimize the details of access rule changes
› Assess security risks
› Verify that appropriate access was granted
In this chapter
Users and their responsibilities ............................................... 9
Typical flow of a change request ........................................... 10
Submitting change requests ................................................. 11
Processing technical details .................................................. 23
Assessing risk..................................................................... 26
Implementation phase ......................................................... 28
Verifying a request.............................................................. 29
Additional workflow actions .................................................. 30
Users and their responsibilities

This section explains the user roles in Skybox Change Manager and the most
common actions for each user.
Requestors
Requestors are users who submit requests for granting connectivity. The
following actions are available:
› Create tickets: Submit requests for connectivity

› Find a ticket by ID: View a specific ticket for follow up
› View my requests: View a list of the tickets that the Requestor created
› View my tickets: View a list of the tickets that the Requestor owns
› Verify the tickets that the Requestor created at the end of the cycle
Analysts
Analysts are users who process tickets. The following actions are available:

› View tickets by phase or by assignee/owner: This list represents the tickets

owned or opened by the analyst (or their group)
› View change requests by firewall or firewall management system (in the
implementation phase)
› Process tickets and promote them to the next phase in the life cycle
Note: In some cases, analysts can view the change requests that relate to
their own firewalls only; change requests for other firewalls are
obfuscated. In this case, each analyst reviews their own change requests.
After each change request is reviewed by its owner, the ticket is
promoted automatically.
› Find a ticket by ID: View a specific ticket for follow up
Workflow supervisors
The following actions are available to workflow supervisors:
› View tickets that have been in the system for some time and do not seem to
be progressing (including overdue tickets)
› Update ticket due dates, change ticket priority
› View tickets by phase: For each phase, make sure that there are no
bottlenecks, that content is coherent, and so on
› Find a ticket by ID: View a specific ticket to resolve a problem with requests
Typical flow of a change request

This is a typical workflow for change assurance management. Each step
represents a phase in the life cycle of a Skybox Change Manager ticket. For a
typical workflow of a recertification request, see Rule recertification (on page
31).
1 Request: A user in your organization submits a change request in the form of
a ticket.
The request can be a general request for access, a source-destination-port
request, or a request to add or modify specific access rules or objects on a
specific firewall or firewall cluster.
Note: When firewalls are clustered, the cluster name is displayed instead
of the names of the individual firewalls. The tooltip for the cluster
provides the names of the individual members.
2 Technical details:
• General requests are refined to include IP addresses and ports, and the
relevant firewalls and clusters. They might be subdivided to several
requests—usually one per firewall.
• Specific requests are checked for validity and sometimes refined (if Skybox
finds a more efficient way to grant access). For example, a request to add
a new rule might be refined into a request to modify an existing (similar)
rule.

Chapter 2 Change management
• Each request is checked to see whether the requested access is already

permitted. If it is, the request is marked as Unnecessary.
• For zone-based or interface-based firewalls, the zone or interface
information is included when calculating Access Update and Add Rule
change requests. This information is available in the Additional Details
column.
The firewall administrator reviews the derived requests to make sure that
they are complete and in line with your policy. The derived requests can be
edited, or additional requests can be added to the ticket. If all the requests
are marked as unnecessary, the ticket will be rejected.
3 Risk assessment: Skybox checks whether each derived request is compliant
and secure.
• Compliant: The request does not cause any access policy violations.
• Secure: There are no vulnerability occurrences that are exposed by
granting this access.
For each request, security analysts can see all the policy violations and
exposed vulnerability occurrences. They then assign a risk level to the ticket
and add any other necessary information.
Skybox shows whether the firewall for each derived request already provides
connectivity for the request.
If the request involves multiple firewalls and some show no connectivity,
changes must be made to the access rules of the firewalls that show no
connectivity. If all firewalls show connectivity, all the permissions necessary
for the request (that is, the access rules) exist, and the ticket can be rejected.
4 Implementation details: Firewall administrators plan and implement the
firewall changes. For some firewall types (for example, Check Point)
implementation may be done automatically.
5 Verification: Skybox verifies that the change requests are fulfilled and marks
the ticket as verified. If the requests are not fulfilled, Skybox reopens the
ticket.
After the ticket is verified, its owner closes it (usually, this is the Requestor
who created the ticket).
Note: The preceding explanation is for the standard workflow using the default
phases. Admins can delete phases, edit their content, or add more phases. They
can also create additional workflows with different sets of phases for different
Business Units or distinctive processes. For information about customizing phases
and creating workflows, see the Customizing Ticket phases and workflows (on
page 53) section in the Skybox Change Manager User Guide.
Submitting change requests

In Skybox Change Manager, you submit a change request by opening a ticket.
The minimum required information is a title, priority, and free-form description of
the request. You can make the request more specific by creating a formal
request to:

› Add, modify, activate, or deactivate an access rule

› Add specific access (source, destination, and service)
› Modify a firewall object
In some workflows, you can add or change the business attributes of an access
rule, including the rule owners and their email addresses.
To open a ticket
1 In the control panel, click Create New Ticket.
If you have multiple workflows and no default workflow, select a default
workflow or a workflow for this ticket. See Selecting a workflow (on page 13).
2 Provide the basic request information (title, priority, and free-form

description).
This information can be edited in later phases.
3 If you have no other information to add, skip to step 10.
4 If View Rules is displayed, use it to view the rules in any firewall:
a. Select the firewall.
b. Provide a search string (use “*” as the search string to view all the rules).
5 Add requests to the ticket:
Note: Web Ticket Requestors might be limited in the requests that they
are permitted to add.
• Request specific access (on page 13) between a source and a destination
• Add an access rule (on page 16)
• Modify access rules (on page 20)
• Deactivate or enable access rules (on page 21)
• Modify firewall objects (on page 22)
• Add multiple requests for specific access by uploading a file (on page 15).
Alternatively, you can add a custom change request (see page 22) of a type
created specifically for your organization.

6 Click Save.
Note: For non-recertification tickets, Skybox checks whether the changes

are required—if the access already exists, you can reject the ticket at
this point; there is no need for it.
7 Click Attachments to add an attachment (or view the existing attachments).
8 (Optional) Click Add Comment to add additional information to the ticket.
9 Click Promote.
10 To change the owner for the next phase, click (next to the suggested
owner’s name) and select a different owner.
11 Click OK.
The ticket is promoted to the Technical Details phase.
SELECTING A WORKFLOW
Skybox supports multiple workflows for tickets—different ticket types can have
different sets of phases, different due date calculations, and different users.
When you submit a change request for the 1st time, you might find that you
have multiple workflows that you can use. You must select a workflow to
continue submitting the change request. You can either select a workflow only for
the current ticket or select a default workflow. Until you select a default
workflow, you must select a workflow for each new change request. However,
even if you select a default workflow, you can select a different workflow when
necessary.
To select a workflow when there is no default

1 (If you have not already done so, click Create New Ticket in the control
panel.)
2 Look at the list of available workflows.
3 Select the workflow to use for the current ticket.
4 To select a default workflow, select the workflow that is used most often and
click Set Default.
5 Click OK.
To select a workflow when a default exists

1 In the control panel, click the arrow next to Create New Ticket
( )
2 Click Choose Workflow, select the workflow you want, and click OK.
REQUESTING SPECIFIC ACCESS

If you know the source, destination, and desired ports, you can submit a change
request for specific access. After you promote the ticket, Skybox:
› Checks the Skybox model

› Identifies the firewalls and access rules that must be changed to permit
access
› Derives specific change requests from the original request for the identified
firewalls and access rules
To request specific access between a source and a destination

1 Click Access Update.
2 Fill in the fields. The fields are described in the following table.
3 Click OK.
Access update properties

The access update properties available for Skybox Change Manager requests are
described in the following table.
Property Description
Source
Addresses • For Requestors (if there is a repository): Applications
that represent the assets of the source. Click to
search for specific application objects.
• For other users: The original representation of the
source addresses in firewall objects. If there is a
repository, application objects are also listed. Click
to search for specific objects (see page 19).
Type IP Addresses A comma-separated list of source IP addresses for which
access is requested to be added or blocked.
• Separate the values of a range with a hyphen.
Users The users for whom access is needed.
Possible values:
• Any
• Unknown User
• Known User
• Specific users or user groups (select Specific and then
type in the user and group names)
Destination
Addresses • For Requestors (if there is a repository): Applications
that represent the assets of the destination. Click
to search for specific application objects.
destination addresses in firewall objects. If there is a
Type IP Addresses A comma-separated list of destination IP addresses for
which access is requested to be added or blocked.
Services & Applications
Services & • For Requestors (if there is a repository): Objects that
Applications represent the services (ports) used for the access.
Click to search for specific service objects.
ports in firewall objects. If there is a repository,

service objects are also listed. Click to search for
specific objects (see page 19).
Type Port The services (ports) for which access is requested to be
added or blocked.
Use application If an application is selected, Skybox sets the service to be
default ports as the default service for that application. You can select a
services different service.
Additional fields
Rule Logging Specifies whether changes to the relevant access rules
are logged in the firewall.
Create Shared Specifies whether objects needed for this access rule are
Objects created as shared for all the firewalls managed by a
(Panorama only) specific Panorama device.
Install on Any Specifies whether the requested change should be added
(Panorama only) to all firewalls in the specified device group.
Expiration Date The expiration date of the access rule.
Comment A comment to add to the change request.
UPLOADING A FILE WITH MULTIPLE REQUESTS

If your organization has configured this, you can create an Excel or CSV file that
contains the information for multiple Access Update change requests and then
upload the file directly to a Change Manager ticket.
For Change Manager to use the change requests in your file, both the file and the
data must obey certain rules. For example, Change Manager looks for each part
of the change request in columns of specific names. You must format the data
correctly.
If your organization has created a template file, you can download it to use for
creating your change requests.
To download the template file

1 In a new ticket, click Upload.
2 Click the link in the Template field to download the template file.
After filling in the change requests and saving the file, use the following
directions to upload it to a Change Manager ticket.
To upload a file of access update change requests to Change Manager

1 Open a new ticket.
2 Click Upload.
3 Next to the File field, click .
4 Navigate to the file and click Open.
Note: Change Manager requires that the file include the fields that were
configured; use the template and only enter information in that format.
Otherwise, the file cannot be uploaded.

5 After the file is previewed a dialog box appears. You can see all the change
requests in the file.
If Change Manager detected an error or missing value in any field of a change
request, there is an X in the problematic field and in the Valid field of that
request. Change requests that are not valid are not added to the ticket.
6 You can make changes to a change request by selecting it and clicking Edit;
you can delete a change request from the list by selecting it and clicking
Remove.
7 When you are finished, click OK.
The valid change requests are added to the ticket.
ADDING AN ACCESS RULE

You can use Skybox Change Manager to request that a specific access rule be
added to a specific firewall.
To request a new access rule on a firewall

1 Click Add Rule.
2 Fill in the fields, as specified in Access rule properties (on page 16).
3 Click OK.
4 (Optional) Set the rule’s business attributes (on page 20).
Positioning of new access rules

The first time that a ticket is saved or promoted, Change Manager checks the
requests to see if they are necessary or if their coverage already exists. For
necessary rules, Change Manager then checks the requested rule against existing
rules in the ACL to suggest where in the list to add the new rule. For new rules
that are partially or completely blocked by existing rules, Change Manager
suggests adding the new rule before the 1st blocking rule. All other rules can be
added at the end of the list.
Access rule properties

The properties of access rules available for Skybox Change Manager requests are
described in the following table. Some properties (for example, Create After)
are not available for all request types.
Firewall The firewall or cluster to which to add the rule.
Type The type of the access rule.
Source
Addresses • For Requestors (if there is a repository): Objects that
represent the assets of the source. Click to search
for specific application objects.
source addresses in firewall objects. If there is a
Type IP Addresses A comma-separated list of source IP addresses for this

rule (the permitted source addresses for a packet).
• To permit all source addresses except those selected,
select NOT.
Negate Specifies whether to use all valid sources (IP addresses or
objects) except those selected.
Users The users that the request is for.
Possible values:
• Any (default)
• Unknown
• Known User
• Specific users or user groups (Select Specific and
then type in the user and group names)
Destination
Addresses • For Requestors (if there is a repository): Objects that
represent the assets of the destination. Click to
search for specific application objects.
destination addresses in firewall objects. If there is a
Type IP Addresses A comma-separated list of destination IP addresses for
this rule (the permitted destination addresses for a
packet).
• To permit all destination addresses except those
selected, select NOT.
Negate Specifies whether to use all valid destinations (IP
addresses or objects) except those selected.
Services & Applications
Services & • For Requestors (if there is a repository): Objects that
Applications represent the services (ports) used for the access.
Click to search for specific service objects.
ports in firewall objects. If there is a repository,
service objects are also listed. Click to search for
Type Ports The services (ports) for this rule (the permitted services
for a packet).
Negate Specifies whether to use all valid services (ports or
objects) except those selected.
Rule Group The rule group to which to add this access rule when the
rule is created.
Note: This information is not added to the access rule.
NAT
Hide Source Specifies whether source networks are hidden behind the
Behind Gateway gateway IP address (they are translated to the IP address
of the gateway or firewall).

Source
Addresses A comma-separated list of source NAT IP addresses for
this rule (the permitted source addresses for a packet).
• To permit all source addresses except those selected,
select NOT.
Objects The original representation of the source NAT addresses
in firewall objects. Click to search for specific objects
(see page 19).
Destination
Addresses A comma-separated list of destination NAT IP addresses
for this rule (the permitted destination addresses for a
packet).
• To permit all destination addresses except those
selected, select NOT.
Objects The original representation of the destination NAT
addresses in firewall objects. Click to search for
Services
Ports The service NATs (ports) for this rule (the permitted
services for a packet).
Objects The original representation of the service NATs in firewall
objects. Click to search for specific objects (see page
19).
Additional Fields
Comment A comment or additional information about the change
request.
Create After Information about where to create the rule for the user
who makes the actual change on the firewall.
Note: This information is not added to the access rule.
VPN Specifies the VPN over which to send data.
Expiration Date The expiration date of the access rule.
Security Profile Specifies the security profile group to use for the access
Group rule.
(Panorama only)
Rule Logging Specifies whether changes to this rule are logged in the
firewall.
Create Shared Specifies whether objects needed for this access rule are
Objects created as shared for all the firewalls managed by a
(Panorama only) specific device.
Install on Any Specifies whether the requested change should be added
(Panorama only) to all firewalls in the specified device group.

Object finder
To find an object using the Object Finder dialog box

1 Select the firewall, firewall cluster, or management system in which to search
for the object.
Note: In many situations, this field is read-only.
2 In the Search field, type a string.

You can use the characters ? and * for standard pattern matching; type * to
display all rules.
3 Click .
The objects that meet the search requirements are listed in the Matching
Objects box. If there is a repository, there are separate tabs for firewall
objects, repository objects, and all objects.
4 Select desired objects from each tab and click to move them to the
Selected Objects box. Click OK.
5 If a firewall object that you need does not exist, use the following instructions
to open a request to create it.
To create a request for a new firewall object from within the Object Finder
1 Click New Object.
2 Provide the necessary information about the new object, according to the
following table.
3 Click OK.
• A change request for the new object is created.
• The new object is added to the set of searchable objects for the firewall or
management system for which it was created. If the new object is used in
additional change requests, it appears as a link to its change request.
The properties of a new object are described in the following table.
Name A name for the new object.
Type (read-only) The type of the object (network or service).
Value The value of the new object. For a network object, this is
the IP addresses or IP address ranges; for a service
object, it is the ports or port ranges.
Members For group objects, the members of the group, consisting
of either existing objects or new objects. You can only add
one layer of members.
Create as Shared (For Panorama only) Specifies whether this object is
created as shared.
Comment Any information about this object for the firewall
administrator.

Setting business attributes for an access rule

You can set the business attributes of an access rule for which there is a change
request.
To set rule attributes

1 In the list of change requests, select the change request with the desired
access rule.
2 Click Set Attributes.
3 Make the necessary changes and click OK.
MODIFYING ACCESS RULES

You can use Skybox Change Manager to request the following modifications to
specific access rules:
› Adding or removing specific access from the rule

› Changing the services and applications to which the rule applies
› Changing the rule owners
› Changing the position of the rule in the policy
› Changing whether the rule is logged in the firewall
Note: Each change requires a separate change request.
To request that specific access rules be modified

1 Click Modify Rules.
2 In the Modify Rules – New Change Request dialog box, click to select the
access rules to change.
3 In the Select Access Rules dialog box, select the desired firewall or cluster.
4 In the Search field, type a string that is part of the access rules that you
want to modify.
You can use the characters ? and * for standard pattern matching; type * to
display all rules.
5 Click .
The access rules that match the search criteria are displayed.
6 Select the rules to modify and click the arrow to move them to the Selected
Access Rules box.
7 Click OK.
8 In the Modification Details pane:
a. Select the field to modify.
b. Make the required changes, either manually or by clicking to search for
Note: Selecting Rule Logging toggles the rule logging of the selected
rules; you do not have to make any additional changes.

Note: Unless you selected Users or # (Rule Position), you can negate
the value of the selected field.
9 Click OK.
10 If necessary, update the rule’s business attributes (on page 20).
DEACTIVATING AND ENABLING ACCESS RULES

You can use Skybox Change Manager to request that specific access rules be
deactivated (disabled or deleted) to block access or cleanup unnecessary rules.
You can also request that specific disabled rules be activated (enabled).
To request that specific access rules be deactivated

1 Click Deactivate Rules.
2 In the Deactivate Rules dialog box:
b. In the Search field, type a string to use in identifying the access rules to
be deactivated.
Type * to display all rules.
c. Click .
d. Select the rules that you want to deactivate and click the arrow to move
them to the Selected Access Rules box.
e. To delete the rules rather than disable them, select Delete Rules in the
Action Required field.
f. Click OK.
To request that specific access rules be activated (enabled)

1 Click Activate Rules.
2 In the Activate Rules dialog box:
b. In the Search field, type a string to use in identifying the access rules to
be deactivated.
Type * to display all rules.
c. Click .
d. Select the rules that you want to activate and click the arrow to move
them to the Selected Access Rules box.
e. Click OK.

MODIFYING FIREWALL OBJECTS

You can use Skybox Change Manager to request that specific firewall objects be
modified. You do this by adding or deleting entities or objects from the selected
object.
To request changes to firewall objects

1 Click Modify Object.
2 Select the object to modify:
a. In the Selected Object area, click the Browse button to open the Object
Finder.
b. Click the Browse button next to the Firewalls/Management Server
field.
c. Select the firewall management systems or individual firewalls to which the
object is relevant, and click the arrow to move them to the right-hand
field.
d. In the Search field, type a string.
e. You can use the characters ? and * for standard pattern matching; type *
to display all objects for the selected firewalls.
f. Click .
g. The objects that match the search criteria are displayed.
h. Select the object to modify and click the arrow to move it to the Selected
Object box.
i. Click OK.
3 Define the properties of the object that you want to change in the Modification
Details pane. The pane is filtered according to the type of the selected object;
you can only enter entities or select objects to add or delete that match the
object type.
a. Use the Name field to change the name of the object.
b. In the Modification Details pane, type entities or select objects (see page
19) add to or delete from this object.
c. Add a comment.
4 Click OK.
CUSTOM CHANGE REQUESTS

In addition to the regular change request types provided by Skybox,
administrators might have created custom change request types that you can
use to enter requests.
To make a custom change request

1 Click More and then select the change request type.
The New Change Request dialog box appears.
2 Select whether the change request relates to a firewall or management
server, or to access rules.

3 Click the Browse button and select the relevant firewall or management
server, or the relevant access rules.
4 Fill in the values of the fields, as you would for any change request.
Mandatory fields are marked with an asterisk.
• In the Change Details field, provide a description of the requested
change and any other necessary information.
• Add an expiration date.
• Add additional comments.
5 Click OK.
CLONING A CHANGE REQUEST

When you create a ticket with multiple change requests, you can clone a change
request and then change the necessary details.
Only original change requests can be cloned, not derived ones.
To clone an original change request
› Select the change request in the list and click Clone.

If you do not make any changes to the new request, an information icon in
the Change Type field informs you that the change request is identical to the
one on which it was based.
ADDING BUSINESS INFORMATION TO AN ACCESS RULE

You can add business information about the access rule to a change request in
the Request and Technical Details phases.
To add this information, select the change request in the ticket and click Set
Attributes.
You can add the following information:
› Rule Owners: The owners of the access rule and their email addresses
› Next Review Date: The date when the access rule should be reviewed
› Business Function: The business function of the access rule
› Comment: A comment about the rule
› (Optional) Custom Attribute fields: If custom business attributes were
defined, you can add their information here
Processing technical details

Technical users review new tickets that are in the Technical Details phase.
The 1st job in this phase is to make sure that there are formal change requests
in the ticket. If the original request was added as a free-text description only,
users in this phase must formalize it to create change requests (on page 24).
After the ticket contains formal change requests, Skybox checks these requests
against the model. The results of the checking process are derived change
requests, which are listed underneath the list of original requests.
These derived change requests must be reviewed to make sure that they are
correct and necessary (on page 24).
REVIEWING TICKETS THAT HAVE NO FORMAL CHANGE REQUESTS

To review a new ticket that does not include any formal change requests
1 Open the ticket.
The Technical Details tab is displayed.
2 In the ticket details at the top of the page, examine the Title and
Description to understand the requested access.
3 Add requests to the ticket:
• Request specific access (on page 13) between a source and a destination
• Add an access rule (on page 16)
• Modify access rules (on page 20)
• Deactivate an access rule (on page 21)
• Modify firewall objects (on page 22)
• Multiple requests for specific access (by uploading a file (on page 15))
Alternatively, you can add a custom change request (see page 22) of a type
created specifically for your organization.
4 Save the ticket.
REVIEWING THE DERIVED CHANGE REQUESTS

The main task in this phase is reviewing and updating the derived change
requests:
› Check whether the changes are necessary. If the requested access exists, the
changes are unnecessary. If all the derived change requests are unnecessary,
you can close (reject) the ticket.
› Access Update change requests are not firewall-specific. When Change
Manager derives requests from them, it might miss a firewall or suggest
changing the wrong firewall because of inaccurate or incomplete routing rules
on the firewalls. Users in this phase must validate that the breakdown is
correct and fix it.
To review the derived change requests of a new ticket

1 Open the ticket.
The Technical Details tab is displayed.
2 Look at the Original Change Requests panel. If none of the requests are
required (that is, all the Change Required values are No), all the requested
access exists. Click Reject to send the ticket back to the requester for
closure.

3 Look at the Derived Change Requests panel. Check whether the derived
change requests suggested by Skybox cover all the necessary firewalls, make
sense, and are in line with your firewall policy.
Note: If some of the derived change requests in the ticket are obfuscated,
they are for firewalls owned by other users. In this case, mark your
change requests as Reviewed (select a change request and click
Review).
If the derived change requests are not what you expected, edit the original
change request or add additional requests. You can delete derived change
requests by selecting them and clicking Remove.
4 Derived change requests that are unnecessary have linked explanations as to
why they are unnecessary. Click the link to see the existing rules that cover
this request.
5 To add additional firewalls to or delete unnecessary firewalls from the selected

derived request, click and add or remove the relevant firewalls.
Skybox creates the corresponding derived change requests for these firewalls.
6 If the ticket is overdue, revise the due date for the current phase. The due
dates for future phases are revised accordingly.
7 Click Promote.
To change the owner for the next phase, click (next to the suggested
owner’s name) and select a different owner.
Note: If you do not have permissions for all the change requests, there is
a Review button instead of Promote.
8 Click OK.
• For tickets with a single owner, the ticket is promoted to the next phase
(usually Risk Assessment).
• For tickets with multiple owners, the ticket is only promoted after all the
owners have reviewed their change requests.

Assessing risk
In the Risk Assessment phase, security analysts review the tickets to check
whether the requested access is justified in terms of risk.
The risk of the requested changes to your organization is displayed in the Risk
Assessment tab. For each change request there is a list of:
› All the Access Policy and Rule Policy violations that the requested change
would cause
› All the vulnerability occurrences to which the requested change would expose
your organization
Note: Skybox does not calculate risk for change requests that add Deny rules.
These requests are considered both compliant and secure.
Analysts reviewing tickets in the Risk Assessment phase:
1 Check the due date of the ticket. If it is overdue or seems unreachable, revise
the due date for the current phase (and Skybox modifies subsequent due
dates).
2 Check whether each request is compliant with your organization’s Access
Policy and Rule Policy and view the violations if it is not.
3 Check whether each request exposes your organization’s network to any
Vulnerability Definitions and view the exposed Vulnerability Definitions.
4 Based on the 2 previous steps, determine the overall risk of the ticket.
5 If there are policy violations, decide whether to approve them, and whether to
limit your approval until a specific expiration date. After the ticket is verified,
these changes are no longer displayed as violations in Change Manager or
Firewall Assurance until their expiration date is reached.
6 If the risk continues to be very high, decide whether to demote the ticket to a
previous phase (or to the Requestor) with an explanation. Otherwise,
promote the request to the next phase.
To assess the risk of a ticket

1 Select a ticket (in the Risk Assessment phase).
The Risk Assessment tab is displayed.
In the Risks pane, the list of original change requests shows whether each
change request is compliant with your organization’s Access Policy and Rule
Policy, and secure from Vulnerability Definitions.
2 After you look at the overall risk of each original change request, change the
view to Derived Change Requests.
3 Review each change request that is not compliant.
a. With the request selected in the table, look at the Compliance: Policy
Violations table. Each violation shows the policy type and the part of the
affected policy that would be violated if this request is implemented.
Because violations might exist for other reasons also, violations that are
only a result of the request are marked as new.
Note: If you are working with recertification requests, all the policy
violations and vulnerability occurrences for the access rule are listed,
to help you to determine the risk of recertifying the rule.
b. If you decide that the risk of the change request is acceptable (at least
temporarily), click Approve.
c. In the Approve Request dialog box, select either Approve Until or
Approve with No Expiration. If you select Approve Until, an expiration
date is displayed. This date is determined by the highest severity of all the
violations. Higher severities have closer expiration dates. (You can change
the expiration date.)
Note: For recertification requests, Skybox uses the expiration date as

the date on which the access rule must be reviewed again.
For each violation, an exception is created (but not yet activated). After
the ticket is verified, the exceptions are activated, and the violations are
again not displayed in either Change Manager or Firewall Assurance until
after the expiration date.
4 Review each change request that is not secure. With the request selected in
the table, look at the Security: Vulnerability Definitions with Exposed
Assets table. If the change request is implemented, the network is exposed
to these Vulnerability Definitions. Vulnerability Definitions that were not
exposed before and are only exposed due to the change request, are marked
as new.
• You can check the available solutions for each exposed Vulnerability
Definition by clicking the link in the Solutions column.
5 Based on your review, specify the risk of the ticket:
a. Assign a risk value: High, Medium, or Low.
b. In the Assessment Details box, type your assessment of the risk. This
can include separate risks for each request.
Note: This assessment is added to the Comment field of any

exceptions that are created.
6 If the risk is reasonable in your opinion, or if a supervising manager gave

clearance (outside Skybox) for the request, Promote the ticket to the next
phase (usually Implementation Details). You can add an attachment or a
Risk Justification comment.
Reasonable risk usually means that the request is acceptable and
valid/legitimate.

If the risk is too high, demote the ticket to a previous phase for additional
review and update of the requests or back to the Requestor to revise the
requests. Make sure to add a comment explaining the problem.
Note: If you do not have permissions for all the change requests, there is
a Review button instead of Promote. After all the change requests in the
ticket are reviewed by their owners, it is promoted automatically.
7 If there are no approved change requests when you promote the ticket, you
are asked whether to approve the change requests as part of the promotion.
The effects of approval are the same as those explained in step 3.
Implementation phase
The Implementation Details tab includes a list of changes to be made on the
firewalls. Use this tab to track and comment on tickets, and for tickets that
require urgent implementation. We recommend that the actual implementation
be done via the Pending Implementation view, where change requests are
grouped by firewalls, in a way that is suitable for the firewall administrators that
implement the changes.
The tasks in this phase are often split between the following users:
› Firewall administrators, who implement the changes on the firewalls

› Users who oversee the tickets
Users in this phase:
1 Check whether the ticket is overdue, and whether the current phase due date
can be met. If necessary, revise the due date of the current phase. Due dates
of subsequent phases are revised accordingly.
• Make the necessary changes on the firewalls.
For information about the Pending Implementation view, see Change
implementation (on page 33).
2 Promote the ticket to the Verification phase, so that Skybox can reanalyze
the connectivity of the change request based on the updated firewalls.
To implement the change requests in a ticket

1 Select a ticket in Implementation Details phase.
2 To view a preview of implementation changes for selected not-yet-
implemented change requests in a separate window, select the change
requests and click Implementation Preview.
Note: If you do not have permissions for all the change requests, you
only see the requests that you own.
3 (Optional) Set a target date for the implementation and add details.
Some organizations require a target date.
4 For firewall administrators (do one of the following):
• Switch to the Pending Implementation view and implement the change
requests (on page 34) for the firewall.

• Select the changes to implement in this ticket and click Implement

Change Requests.
Note: Even if you are using automatic implementation, you must perform
this step.
5 Tickets whose change requests are all marked as implemented are promoted
automatically and are no longer listed in Pending Implementation. If the
ticket was not promoted, promote it manually to the final phase (usually
named Verification or Pending Closure). (When you promote a ticket, its
change requests are marked as implemented.)
By default, tickets are sent to their Requestors for verification. After the
Requestor reviews the ticket, they usually close it.
Note: After a ticket is promoted to the verification phase, the existing

requests can no longer be changed, even if the ticket is later demoted to
earlier phases. If you need to make additional changes, you can add new
requests to the ticket or create a new ticket.
Verifying a request
After the firewall changes are implemented, Skybox rechecks the change
requests the next time firewall data is imported. An Analysis – Change
Tracking task, scheduled to run after the import cycle, checks the requests.
› If all the change requests are implemented (that is, there is access between
the source and destination over the specified port), Skybox changes the
status of the ticket to Verified, and the ticket is sent back to its original
Requestor, who usually closes it.
If notifications are set up for Access Change tickets, then the owner receives
a notification about the change in the ticket status.
› If there are unimplemented change requests, Skybox reopens the ticket.

Usually, the Requestor then checks the ticket and closes it.
Optionally, workflow supervisors can review the tickets in this phase and decide
to close the verified tickets or add additional suggestions to reopened tickets.
Rejected tickets
A ticket that is rejected for any reason is given a status of Rejected and
returned to its Requestor. It should usually be closed, but the Requestor can
reopen it and fix the properties.
To close a ticket
1 Select the ticket.
2 Click .
3 Add a comment to the ticket before you close it.
4 Click OK.

Additional workflow actions

In addition to handling existing tickets in a specific phase, you can use Skybox
Change Manager to:
› Request recertification of an access rule, if this action is enabled

› Clone a ticket—create a new ticket based on an existing ticket
The new ticket does not have the history or attachments of the original ticket,
but all other fields are the same. You must make at least one change in the
new ticket before you can save it.
› Reassign a ticket to a different user

› Revise the due date of the current phase (Skybox revises the due dates of
subsequent phases)
› Add a comment to a ticket
› Add attachments to a ticket and view the existing attachments
› View the history (change log) of a ticket
› Change the status of open tickets (if this option is enabled)
Open tickets have a status of New, In Progress, Reopened, or any custom
status whose status group value is Open.
› Reject a ticket
› View statistics for any workflow
Note: Requestors can only manage the first and last phases of the tickets.

Chapter 3
Rule recertification
Rule recertification tickets are opened by users in Skybox Firewall Assurance or
Skybox Network Assurance, or automatically for access rules that are schedule to
be reviewed in the near future (via rule recertification ticket policies). Each
recertification ticket includes at least 1 access rule.
After recertification tickets are opened, they are handled in Change Manager.
They generally go through a different workflow than other tickets, with fewer
steps.
Typical rule recertification workflow

1 In the request (1st) phase of rule recertification tickets, review the requests
and determine the access rules to certify and those to reject (not recertify).
You can view all the violations and vulnerability occurrences for each access
rule to help you to decide the risk of recertifying it. You can also add or
update business attributes (for example, rule owners and email addresses) in
the access rules, and you can update the next review date.
If you are the only owner of the rule: after determining whether to certify or
reject each rule, promote the ticket to the next phase.
2 In the assessment (2nd) phase, review and modify the decisions made in the
1st phase (which rules to certify or reject), by someone who is a higher
security authority.
The ticket cannot be promoted until all the access rules are marked as either
certified or rejected.
3 In the verification (final) phase, close the ticket. After the ticket is closed, the
changes are applied to the access rules, including the change to their status
and any changed business attributes.
4 If any access rules were rejected rather than recertified, we recommend that
you open tickets on those access rules to disable or modify them as needed.
Reviewing access rules for recertification

You can view access rules that are waiting for your certification or rejection in
the Pending Review view, and certify or reject them directly from there.
Pending Review is accessible from the control panel on the left-hand side.
Recertification for rules with multiple owners

Recertification of access rules with multiple owners requires review by each
owner.
In the recertification process, each of the rule owners must review the rule, and
either certify or reject it. If an owner rejects the rule, they must add a comment.

Pending Review
Rule owners can use the Pending Review section to view and respond to each
of the rules they own that are in the process of recertification. When there are
multiple owners of a rule, each owner can see the status selected by all the other
owners.
If your organization is working with automatic ticket promotion, a recertification

ticket with multiple rule owners will not be promoted until all the rule owners
have either certified or rejected the rule.
Statuses
When a recertification ticket for a rule with multiple owners is promoted, the rule
will have one of the following statuses:
› Certified: The rule was certified by all the owners

› Rejected: The rule was rejected by all the owners
› Partially Rejected: The rule was rejected by one or more owners and
certified by one or more owners

Chapter 4
Change implementation
For firewall administrators who must implement change requests, it is helpful to
view the requests grouped by firewalls. To do this, use the Pending
Implementation view, which lists all change requests from tickets in the
implementation phase.
When you work in the Pending Implementation view, you can:
› View a list of change requests that are ready to be implemented

› Assign change requests to specific users or user groups (for implementation)
› Mark change requests as implemented (or not implemented)
› Automatically implement change requests for Check Point, Palo Alto
Panorama, and Fortinet FortiManager devices
› View each change request in command format (the format used on the
firewall itself)
You can select multiple change requests to view their commands together.
› Add comments to change requests
In this chapter
Viewing a specific set of change requests ............................... 33
Assigning change requests ................................................... 34
Implementing change requests ............................................. 34
Viewing a specific set of change requests

The default display in the Pending Implementation view shows all change
requests that are not yet implemented. Use the View field to display a different
set of change requests.

Assigning change requests

You can assign change requests to yourself or to another user.
› To assign change requests to yourself, select the change requests and click
Assign to Me.
› To assign change requests to a specific user, select the change requests and
click Assign; select the user.
In both cases, you must add a comment to the change request.
Implementing change requests

You can implement change requests in the Pending Implementation view in
either of 2 ways:
› View the change requests in command format (see page 34) and then mark
them as implemented (see page 35) in Skybox
This format can help you to understand the changes that you need to make.
It saves time because you can copy and paste relevant parts of the command
text directly. Sometimes, these are generic representations. For many request
types on Cisco devices, a representation of the command is displayed in Cisco
format.
› Automatically (see page 36)
VIEWING CHANGE REQUESTS IN COMMAND FORMAT

For devices on which automatic implementation is not supported, you can view
the change requests in command format.
› Select change requests from the list and click Implement.

Chapter 4 Change implementation
A separate window shows the commands to use on the firewall for each
selected change request.
Sometimes, these are generic representations. For the following changes on

Cisco devices, a representation of the command is displayed in Cisco format:
› Add Rule
› Modify Rule
› Deactivate Rule
› Add Object
› Modify Object
You can copy the commands in this window directly to the CLI, but they might
need editing to make them completely compatible with the command format
used on the firewalls.
MARKING CHANGE REQUESTS AS IMPLEMENTED

After you finish manually implementing a change request on the firewall or
firewall server, select the change request and click Mark as Implemented. Add
any relevant information to the change request as a comment.

Note: Use Mark as Not Implemented if a change request was mistakenly

marked as implemented.
When all the change requests for a specific ticket are marked as implemented,
the ticket is promoted to the Verification phase and its change requests are no
longer listed in Pending Implementation.
AUTOMATIC IMPLEMENTATION
Change Manager provides the option of automatically implementing some change
requests directly to Check Point, Cisco ASA and Firepower, Palo Alto Panorama,
and Fortinet FortiManager devices.
Supported device types and versions

The tested versions of each supported device type are listed in the following
table, together with other relevant information.
Note: For best results, we recommend that you use these versions.
Device Version Additional Add Add Modify Modify Delete Global
type information Rule Object Rule Object /Disab Object
le Rule
Check R77 • Expiration dates  
Point are not supported
CPMI in Add Rule.
• Modify Rule is not
supported.
• Implementation
fails if other read-
write sessions are
open at the same
time.
• Automatic
implementation is
not supported on
R77 MDS CMAs
(Check Point
limitation).
Check R80, • Modify Rule is    
Point R80.10, supported from
Security R80.20 R80.10 and
Manage higher.
ment
Cisco 9.3(2),     
ASA 9.9(2)
Cisco 6.2.3, You must implement  
Firepow 6.3 the Add Object and
er Add Rule change
requests at the same
time.
Fortinet 5.2, The policy must be    
FortiMa 5.4, 5.6 installed on a VDOM.
nager
Palo PA OS An administrator can     
Alto 7.1, PA define whether the

Device Version Additional Add Add Modify Modify Delete Global

type information Rule Object Rule Object /Disab Object
le Rule
Panora OS 8.0, new rules are added
ma PA OS as Pre Rules or Post
9.0 Rules (in Tools >
Options > Server
Options > Change
Manager >
Implementation
Automation).
Supported change request types

The following change request types can be automatically implemented on all
supported devices unless noted otherwise in the preceding section (on page 36).
› Add Rule
Support is available for expiration dates, comments, networks, hosts, ranges,
and TCP, UDP, and ICMP services.
› Add Object
Support is available for source, destination, service, and object comments.
› Modify Rule
Support is available for Allow rules, Deny rules, source, destination, and
service.
Global rules cannot be modified.
› Modify Object (Fortinet FortiManager only)

For details, see Implementation of Modify Object change requests (on page
37).
Change request types that are not supported for automatic

implementation
The following change requests can only be implemented manually:
› Change requests with NAT

› Change requests that include negated source, destination, or service values
› Change requests that include users and applications
› Modify Object (except in Fortinet FortiManager)
› Deactivate Rule (except in Check Point R80)
Implementation of Modify Object change requests

Automatic implementation of Modify Object change requests is supported only for
Fortinet FortiManager.
The following changes are supported per object type.
› For single objects (hosts, networks, IP address ranges, services):

• Add / remove / replace values in the object

› For object groups (groups of hosts, networks, IP address ranges or services):

• Add / remove objects (single or lists)
Note: Nested objects (in sub-groups) are not removed.

The following actions are not supported:
› Object renaming
› Changes to global objects
Implementing the change requests

Changes are calculated and implemented on the active policy only. After the
changes are made and saved, the policy must be installed (activated/deployed)
manually.
During automatic implementation:
› If the same field of a rule is modified in 2 separate requests, a collection task

must be run before implementing the 2nd request.
› A collection task must be run before using a new object in a ticket.
To implement change requests

1 Select the relevant change requests in the list and click Implement.
A list of changes to be implemented appears. Usually, in addition to the
change requests that you suggested, there are additional change requests in
this list. For example, if you select an Add Rule change request, all the Add
Object change requests that are necessary for the Add Rule are in the list and
are also selected. There may be other change requests for the same
management server.
If you selected any change requests that cannot be implemented
automatically, they are listed in a pop-up.
2 Review the list and select any other change requests to be implemented; you
can clear any change requests that you do not want to implement now.
3 Click Implement Changes.
4 Add an implementation comment and click OK.
Change Manager performs implementation in the background and the status
of each change request is updated appropriately. On success, requests are
marked as implemented and shown in the Implemented tab. Failed requests
remain in the pending list and you can view their failure reason.
What happens to change requests that are successfully implemented?

Whenever possible, Change Manager adds each new rule to the policy before the
first rule that blocks its traffic (as calculated in the Skybox Access Analyzer). If
this is not possible, the rule is added as the last rule in the policy. In this case,
an Admin must open the policy on the management server and reposition each
new rule.
After implementation:

1 Change Manager does not push/deploy/install/activate the updated policy on

any devices; an Admin must do this.
2 When data is collected from management servers from any vendor, Skybox
gets the latest changes even if they were not pushed to the devices.
REVERTING AUTOMATICALLY IMPLEMENTED CHANGE REQUESTS

In some cases, you may need to revert automatically implemented change
requests after they are implemented. Change Manager enables reversion of
automatically implemented change requests as follows:
› The ticket must be in the Implementation or Verification phase.

› Currently supported change requests:
• Add Rule (derived) change requests for firewalls of type Check Point R80
that were automatically implemented by Change Manager.
How to do it:
› If the ticket is in the Implementation phase, select each change request to

revert, and click Revert.
For every change request to be reverted, a change request to delete the rule
is added to the ticket.
› If the ticket is in the Verification phase, open the Implementation tab, select
each change request to revert, and click Revert.
The ticket is demoted to the Implementation phase. For every change
request to revert, a change request to delete the rule is added to the ticket.
Note: When a change request is reverted, the ticket will not move automatically
to the Verified phase. This must be done manually.
Reverting other change requests

To revert a change request that cannot be reverted automatically, open a ticket
with the appropriate change request on the rule that you want to change. For
example, if a change request for a new rule must be reverted, open a ticket with
a change request of type Deactivate Rule, select the new rule, and select
Delete Rules as the action.

Chapter 5
Exporting information from

Change Manager
You can export tables from Change Manager to CSV files, whether the table is
inside a ticket or takes up the entire workspace. To export a table, click .
Exporting workspace tables

For workspace tables, Skybox uses the following naming convention, where the
view can be any of those in the control pane or a selected analysis:
› <view name>_<timestamp>.csv
Exporting tables within tickets

Skybox uses the following naming convention:
› <panel name>_<phase name>_phase_Ticket_<ticket#>_<timestamp>.csv

In the Risk Assessment phase, the tables depend on which change request is
selected and Skybox uses the following convention:
› <panel name>_<request>_<phase
name>_phase_Ticket_<ticket#>_<timestamp>.csv

Chapter 6
Workflow statistics
The Workflow Statistics view displays statistics for each workflow; for example,
the number of tickets that have change requests that were opened during the
selected period, the firewalls for those change requests, a breakdown of change
requests per type, and the total number of change requests for the workflow.
› Select the dates to use in the display and click Display.

› You can view the tickets in each workflow using the number of tickets link.
Exporting the data

You can export the data to an Excel file. The first page contains the same table
as in the workspace. There is a separate page in the file for each workflow
corresponding to the Workflow Tickets page.

Chapter 7
Administration of Change
Manager
Administration is via Skybox Manager, not the Skybox Change Manager web
interface.
In this chapter
User management .............................................................. 42
Customizing the look and feel of Change Manager................... 47
Configuring Change Manager options .................................... 48
Customizing ticket phases and workflows ............................... 53
Multi-tier change requests.................................................... 63
Customizing ticket priority levels .......................................... 64
Enabling users to change the status of their tickets ................. 64
Setting up the Application & Service repository ....................... 65
Setting up analysis of change requests .................................. 68
Triggers ............................................................................. 68
Integration with the ServiceNow ticketing system ................... 75
User management
All Skybox Change Manager users must be registered Skybox users with the
appropriate user role (see page 43) for their job. We recommend that you define
user groups that classify the Skybox Change Manager users according to their
tasks or departments.

Chapter 7 Administration of Change Manager
The Skybox Admin window (Tools > Administrative Tools > Users), displays
users and user groups in the tree, and a list of users and their properties in the
workspace.
Note: This section explains aspects of user management that are specific to
Skybox Change Manager. For additional information, see the User management
section in the Skybox Installation and Administration Guide.
USER ROLES
The following user roles can work with Skybox Change Manager:
› Admin or Admin – Assurance: These users can perform all actions in

Skybox and Change Manager, including Change Manager setup in Skybox
Manager.
Note: All administration is done in Skybox Manager; it cannot be done in

Change Manager.
› User or User – Assurance: These users can create and work with tickets
both in the Manager and in Change Manager:
Analysts and administrators working with Change Manager must have a user
role of User or User – Assurance.
› Web Ticket User: These users can manage tickets in Change Manager.
› Web Ticket Requestor: This role is intended specifically for users whose
main job in Skybox is to create tickets in Change Manager. These users can
create tickets (that is, submit change requests) in Change Manager and close
tickets that they created.
› Read-only User and Read-only User – Assurance: These users can
manage tickets in Skybox Change Manager.
› Custom roles based on Admin – Assurance, User – Assurance, or Read-
only User – Assurance.

USER ACTIVITIES
The actions that can be performed on tickets in Change Manager and by which
users are listed in the following table. Admins can perform all actions on all
tickets.
Action Who can do it Additional information
Create a ticket Usually done by Web Ticket The user must have
Requestors but can be done permissions for the 1st phase
by any user. of the workflow in which they
want to create the ticket.
Edit a ticket The ticket owner or another
member of the owner’s user
group who has full
permissions for the current
workflow phase.
Promote (or The user who created or Depending on permissions,
demote) a ticket updated the ticket can then after the ticket is promoted,
that you created promote it to the next phase, Web Ticket Requestors
or updated assigning it to any user with might not be able to view or
full permissions for that edit it.
phase.
Delete a ticket This depends on what Tools > Options > Change
attachment permissions were defined for Manager > Permissions >
ticket attachments. You can Attachment Permissions
specify that ticket
attachments cannot be
deleted at all.
Reassign a ticket The ticket owner or another
member of the owner’s user
group who has full
permissions for the current
workflow phase.
Reopen a closed Only Admins.
ticket
CREATING USERS AND USER GROUPS

When you create users to work with Change Manager only, we recommend that
you use the following roles:
› Web Ticket Requestor: For users whose main job in Change Manager is
turning requests into Skybox tickets and, later, closing these tickets
› Web Ticket User: For users who have permissions to perform various tasks
in Change Manager
Note: Skybox Admin, User, and User-Assurance users can work with Change
Manager.
By grouping users who share the same permissions, you can assign permissions
in Skybox to the whole group rather than to each user separately. Users in the
same group can edit each other’s tickets, if the group is assigned permissions.
Create a default user for each group (see Defining a default user for each group
(on page 45)).
For information about how to create user groups, see the User groups topic in
the Skybox Installation and Administration Guide. For information about how to
create users, see the Users topic in the same book.
DEFINING A DEFAULT USER FOR EACH GROUP

We recommend that you define a generic user for each group and then assign
this user as the default owner for the group’s tickets. All group users can edit
tickets owned by the generic user.
To create a generic user, create a user with a name that represents the user
group and assign the required role. Make sure to give this user Change Manager
permissions for the relevant workflows and phases.
Defining a group’s default user

After you define a user group, add users, and (optionally) create a generic user,
you must specify the default user for the group. Usually, this is the generic user.
By default, when tickets are promoted (or demoted) to this group, the system
assigns them to this user.
1 Select the group in the tree.
2 In the workspace, right-click the desired user in the table and select Mark as
Default Group Member.
PERMISSIONS
To work with Change Manager tickets, users must have permissions for specific
workflows or workflow phases. You can grant these permissions to individual
users or (preferably) to groups of users via Tools > Admin Tools > Users,
either when you create the users and user groups or by editing them later.
Permissions by user role
› Admins have permissions for all workflows and phases. They can reopen
tickets.
› Grant Users, Web Ticket Users, and Read-only Users permissions for any
workflow phases in which they must create tickets or edit them.
› Grant Web Ticket Requestors permissions for any workflows in which they
must create tickets, and for any workflow phases in which they must view or
edit the tickets.
Limitations on Web Ticket Requestors

All Web Ticket Requestors have additional limitations on the types of change
requests that they can create and view:
› You can define the types of change requests that Requestors can create. By
default, they can only create Access Update change requests.
› You can define whether Requestors can view and revise ticket due dates. By
default, they cannot.
› You can define whether all Requestors can see all tickets. By default,
Requestors can only view tickets that they themselves or a member of their
user group created.

› You can define whether Requestors can view detailed information about
access rules that permit or block access. By default, Requestors cannot view
this information.
You can change these permissions in Tools > Options > Server Options >
Change Manager Settings > Permissions > Requestor Permissions.
Permission to edit specific tickets

Permission to edit a specific ticket is determined by the following combination:
› The user must have permission to edit tickets in this workflow phase.
Workflow phase permissions are defined per user or user group in the CM
Permissions tab.
› The ticket must be assigned either to the user or to someone in the same
user group. If the ticket was assigned to a different user who is not in the
same user group (but who also has permission to edit tickets in this workflow
phase), the user cannot edit the ticket.
For example, John owns a ticket in workflow1, phase 2. Mary can edit the
ticket if she and John are in the same group and the group is permitted to edit
tickets in this workflow phase. If Mary is not in John’s group, even if her
group has permissions for this workflow phase, she cannot edit the ticket.
Note: If Tickets can only be edited by their owner is selected (in
Tools > Options > Server Options > User Settings > User
Permissions), then only the ticket owner can edit each ticket, not other
members of the owner’s group.
› If Ticket creator cannot edit this phase is selected for a phase (in Tools >
Options > Server Options > Change Manager Settings > Workflows),
the user who created the ticket cannot edit the ticket in that phase.
Permission to view and edit information from relevant firewalls

only
You can assign Firewall Assurance permissions to Change Manager. This is done
via Tools > Options > Server Options > User Settings > User
Permissions: Apply Firewall Assurance permissions to Change Manager
tickets. For additional information, see Multi-tier change requests (on page 63).
If you assign these permissions to Change Manager, each derived request in a
ticket is only visible to the users who have permissions for its firewall; other
users see obfuscated (blurred) data and cannot review the change request at all.
Permission to delete ticket attachments

By default, administrators and all users who are permitted to access a ticket
have permission to delete any attachments to that ticket. However, you can
specify that attachments can never be deleted or you can select different groups
of users who can delete them (for example, administrators only).
To change these permissions, go to Tools > Options > Server Options >
Change Manager Settings > Permissions > Attachment Permissions.

Customizing the look and feel of Change Manager

You can customize the look and feel of Change Manager to be similar to that of
your organization.
For example, you can use your company logo on the top left of the screen,
change the company name, the logo users see on the home page, and even the
image used on the login screen.
› Use Tools > Options > Server Options > Customization to define the
display settings.
The parts of the screen that can be customized are described in the following
table.
Note: If you change the text, logos, and website address, the navigation pane
includes the message: “Powered by Skybox”.
Logo
Company Name The company name to display; default is SKYBOX.
Website Address Specifies the URL that opens when users click the logo at
the top left of the Change Manager or Skybox Horizon
page; default is www.skyboxsecurity.com
Logo Image The logo to be shown at the top left of the Change
Manager or Skybox Horizon page.
Note: The logo must be in PNG format and should be 75
x 43 pixels. Larger images are resized to 75 x 43 for
display.
Welcome Logo The logo to be shown at the top of the Change Manager
Image home page.
display.
Login Screen The logo to be shown on the login screen of Change
Image Manager and Skybox Horizon.
display.
Toolbar The colors to display on the Change Manager or Skybox
Background Horizon toolbar.
Colors
Toolbar The colors of the text to display on the Change Manager
Foreground Colors or Skybox Horizon toolbar. Note: Each text color is
displayed directly underneath the background color on
which it will be used. (There is no text on the 3rd section
of the toolbar.)

Message of the Day
Enter message of The message to display after a user logs in to Skybox
the day in HTML Change Manager.
format Note: The <html>, <body>, <header>, and <script>
tags cannot be used in the message.
Dashboards
Maximal number The maximum number of dashboards in a Skybox web
of dashboards interface.
Note: To revert to using the Skybox look and feel, click Return to Default.
Configuring Change Manager options

Configure the behavior of Skybox Change Manager at Tools > Options >
Server Options > Change Manager Settings.
CONFIGURING CHANGE MANAGER SETTINGS

Configure Change Manager settings in Tools > Options > Server Options >
Change Manager Settings.
Optimization settings
Access Update and Add Rule change requests can be optimized into Modify Rule
change requests; modifying an existing access rule rather than creating a new
rule usually makes rule maintenance an easier task (as there are fewer rules to
maintain). However, some organizations prefer separate rules for different
scenarios.
Change requests are checked against existing access rules to see if their fields
match those of any access rules. Optimization (to Modify Rule change requests)
is performed when at least 2 fields of the change request match the
corresponding fields of an access rule. You can specify:
› Identical Match: At least 2 of the fields of the change request match the
same 2 fields of the access rule exactly.
› Contained within: At least 2 of the fields of the change request are
contained within (or identical to) the fields in the access rule.
• The sub-option Include Contained in Any provides an even broader
basis for matching: Consider fields as matching if the value of the field in
the access rule is Any.
Change Manager mode

The mode defines how Change Manager identifies the firewalls in Access Update
change requests (in firewall or network mode), and how it calculates policy
compliance violations that will be caused by change requests (by firewall network
interface access or by network access).
In general, this depends on how your organization’s Skybox model is set up:

› If the model does not include routers or is not fully connected, use firewall
mode.
Note: In firewall mode, access requests to a network device’s interface

cannot be used as a source or destination.
› If the model includes routers and is fully connected, use network mode.
In network mode, you can also define the Access Policy scope to use for
calculating policy violations.
For additional information, see the Change Manager Settings topic in the Skybox
Installation and Administration Guide.
Verification
Change Manager verifies change requests by matching the main fields (source,
destination, and services) of the requests with those of the access rules.
Additional fields can be used in the verification:
› Source and network interfaces

Change Manager calculates the network interfaces (or zones) for which new
access rules should be added. However, this information is not automatically
used as part of the verification process.
› Rule expiration dates

If rule expiration dates are specified in the change requests, Change Manager
can use them as part of the verification process (making sure that the
expiration dates in the change request and the access rules are the same)
and as part of the reconciliation process for change tracking.
CONFIGURING UPLOAD OF CHANGE REQUESTS FROM FILES

You can configure Change Manager to enable Access Update change requests to
be added to a ticket by uploading them from an Excel or CSV file. You create a
template file and upload it to Skybox; Change Manager users can then download
the template, fill in the fields, and upload their change requests to a ticket.
Before you start

Create a template file to upload. The template must include a separate column
for each field of the change request and for any rule business attributes to be
included. In addition, users must know how to format the information in each
field. We recommend that you have a row of sample data to show the format to
use for each column.
Note: All the parameters must use valid syntax (as used in other Change
Manager requests).
To enable uploading of Access Update change requests to a ticket

1 Go to Tools > Options > Server Options > Change Manager Settings >
Change Requests.
2 Select Enable uploading change requests from file.
3 Next to the File Name field, click Upload, and upload your template file.

4 Use the General and Rule Business Attributes areas to map the column names
in the file to the change request fields (including source, destination, and
service).
5 If you are uploading from anything other than the 1st sheet in an Excel file
that has multiple sheets, add the name of the sheet in the Excel Sheet field
in the Advanced area.
6 If the change request files may include expiration dates, next review dates, or
any other dates, either make sure that the dates are listed in standard date
format (MM/dd/yyyy) or change the expected date format in the Date
Format field in the Advanced area.
CREATING CUSTOM CHANGE REQUEST TYPES

You can create custom change request types for use in Access Change tickets
(for example, Add VPN or Add Firewall User) according to your requirements.
These change request types give you more control over the change planning
process.
Custom change request types are available when creating workflows and when
users of Skybox Change Manager create tickets.
To create a new change request type

Change Requests.
2 In the Custom Change Requests area, click Add.
3 In the dialog box, type the name of the new change request type.
4 For each required field in the new change request type:
a. Click Add.
b. Give the field a name and select its type.
For List fields, enter a list of possible values.
c. (Optional) Add a text hint for users in Field Hint. The text hint is shown in
the field until the user starts typing.
d. If a value must be entered for this field, select Mandatory.
e. Click OK.
5 Click OK.
CONFIGURING CHANGE MANAGER DISPLAY OPTIONS

Use Tools > Options > Server Options > Change Manager Settings >
Display Settings to define the following display settings:
› Records Per Page

You can specify how many tickets or change requests are displayed per page
in Change Manager tables.
› Custom Fields
You can specify how many custom fields are displayed in a single row in
Change Manager tickets.

CONFIGURING OBJECT SUGGESTION

When change requests are created using IP addresses or ranges, and ports and
services, Skybox can translate these entities to firewall objects. This is useful for
firewalls that use objects for implementation. The entities are translated while
the derived change requests for the ticket are calculated. Skybox looks for
existing objects that are an exact match for the requested network or service. If
such an object is found, Skybox uses it in the derived request; otherwise,
separate Add Object change requests are added to the ticket and then the main
derived change requests use those objects.
If the newly created objects are not what is needed (for example, if there is a
similar existing object that can be used), users can edit them as they would edit
any derived change request.
To configure object suggestion

Object Suggestion.
2 Select Convert addresses and services to objects.
3 Define the naming convention to use when creating each type of object (host,
IP address range, network, and service). These conventions must include a
tag to identify the object and any text that helps in the identification process.
If the naming convention for a host is Host_<IP address>, the name of the
object based on the IP address 192.0.2.0 is Host_192.0.2.0.
4 Define the formula to use for the comment on each object.
CONFIGURING AUTOMATIC IMPLEMENTATION

Change Manager can be configured to implement change requests automatically
on Check Point, Cisco, Palo Alto Panorama, and Fortinet FortiManager devices.
The following change requests can be implemented automatically:
› Add Rule
› Add Object
› Modify Rule
› Modify Object (Fortinet FortiManager only)
› Delete/Disable Rule (Check Point R80 only)
For information about automatic implementation, including supported device
versions, see Automatic implementation (on page 36).
To configure automatic implementation

1 From the Tools menu, select Options > Server Options > Change
Manager Settings > Implementation Automation.
2 Select Enable automatic implementation of pending requests for Check
Point, FortiManager and Panorama devices.
Note: Object suggestion is automatically enabled when automatic
implementation is enabled.

3 Specify whether Change Manager suggests implementing other relevant

pending requests for the same management server when a user elects to
implement specific pending requests. For example, if a user elects to
implement the pending requests for firewall_A, and firewall_B has the same
management server and has pending requests, Change Manager suggests to
the user that the requests for firewall_B can also be implemented.
4 Set the default values to use when automatically implementing new rules.
5 Define the formula to use for the comment on each new rule.
6 For Panorama, define whether the rules are added as Pre Rules or Post Rules.
Configuring support for automatic implementation in Check Point CPMI

devices
Before you can use automatic implementation with a CPMI:
1 Set up a Permissions Profile on the CPMI with Read/Write All permissions
that the Skybox collection task can use. See Creating a Permissions Profile, in
the Skybox Reference Guide.
2 Set up and run a collection task for this CPMI with the above user. The
parameters used for automatic implementation are taken from the task, no
matter which Change Manager user requests the implementation.
Note: Implementation fails if other read-write sessions are open at the same
time.
Activating the implemented changes

Skybox implements the changes by adding or updating the requested rules and
objects in the firewall’s rule policy on the management server. However, for
security reasons, the updated rule policy must be activated on the management
server itself (not via Skybox).
CONFIGURING RISK ASSESSMENT

Configure risk assessment in Tools > Options > Server Options > Change
Manager Settings > Risk Assessment.
Risk Assessment
To make it mandatory for users to comment in the Risk panel before promoting a
ticket, select Enforce Risk Justification comment.
If you have a Firewall Assurance-only license, vulnerability occurrences are not
available by default in Change Manager. To make vulnerability occurrences
available, select the Show Exposed Vulnerability Occurrences field.
Approve Risk
When you approve the risk of a change request in the Risk Assessment phase,
the Approve Request dialog box provides an expiration date for the approval,
based on the highest violation severity caused by the change request. Skybox
uses these expiration dates to create the corresponding exceptions, based on the
approval. For each risk level, a period is specified for calculating the expiration
date. When you approve a change request, this period is added to the current
date to provide the expiration date.
You can change the expiration period for each severity according to your policy.
To specify the expiration periods
› For each risk level for which you want to change the expiration period:
1. Select the level in the Approve Risk table and click Modify.
2. In the Default Approve Expiration Date dialog box, change the value.
3. Click OK.
CONFIGURING TICKETS
You can define various options for tickets via the Tools > Options > Server
Options > Change Manager Settings > Tickets page.
Automatic closure of tickets

You can specify:
› Whether Skybox closes tickets whose change requests are all implemented
› Whether Skybox closes ticket that are in the final phase (usually Pending
Closure or Verified) after a specified number of days
› The status assigned to tickets that Skybox closes
Default ticket priority

You can change the default priority of newly created tickets.
Rule logging default settings

You can specify whether new rules are added with rule logging enabled or
disabled by default.
Users can change this per change request. For example, if rule logging is enabled
by default, but a specific rule should not be logged, rule logging can be turned off
in the request to create this rule.
Shared Objects default settings

You can specify whether new objects in change requests are created by default
as shared or local on Panorama devices. Users can change this per change
request.
Customizing ticket phases and workflows

Skybox Change Manager supports ticket workflows using phases. The standard
workflow uses the following phases:
1 Request
2 Technical Details
3 Risk Assessment
4 Implementation
5 Verification
It is not necessary to use all (or any) phases. If your workflow is different, you
can customize the phases. In addition, you can create additional workflows for
different business purposes.

There is a separate standard workflow for recertification. The phases are:

1 Recertification Request
2 Recertification Review
3 Verification
Note: Even if you work with the standard workflow phases and make no changes
to them, you must assign permissions for these phases to the users and user
groups that work with them. We recommend that you also specify default owners
for the phases. See Defining default owners for ticket phases (on page 62).
OVERVIEW OF WORKFLOWS AND PHASES

Workflows
A workflow is a sequence of phases. Skybox includes 2 standard workflows for
Change Manager – 1 regular, and 1 for recertification. In addition to editing
these, you can create as many additional workflows as you need for your
organization. For example, you might want separate workflows per region, or per
business unit.
Workflows are managed from Tools > Options > Server Options > Change
Manager Settings > Workflows.
Creating workflows
There are several ways to create a new workflow:
› Click > Template Workflow to base the new workflow on a standard

workflow and give it a new name; edit the new workflow ( ) if any changes
are necessary.
› Select an existing workflow and click Create Like.
› Use the workflow wizard to create a customized workflow. Click to start
the wizard.
Phases
Each phase has an owner, due date, start date and end date. Each phase also
has a list of field groups (panels) that defines the information that is accessible in
Skybox Change Manager when a ticket is in that phase.
When a ticket is created, it contains the list of phases that it is to pass through
according to its workflow. Initially, the ticket is assigned to the 1st phase and the
1st phase owner. During the life cycle of the ticket, the ticket can progress from
1 phase to the next or go back to the previous phase. You can specify that
specific phases are skipped automatically if they meet the conditions that you set
for them.
When a phase owner finishes working on a ticket, they promote it to the next
phase. This updates the end date of the phase and moves the ticket to the next
owner. If a phase owner sees a problem in a ticket, they can demote it to the
previous phase, adding a comment to specify the problem.

The verification phase is always the final phase in each workflow. It is the final
step in the life cycle of each ticket; completed tickets are automatically passed to
this phase. In some organizations, the administrator uses this phase to review
the work that was done and validate its completion. If your organization is not
interested in using this final check, you can complete the work by moving the
ticket to the verification phase.
DEFINING THE DEFAULT WORK TIME FOR TICKET WORKFLOWS

To define the work time
1 Select the standard work days for your organization.
2 Type the dates of the holidays on which your organization does not work or
click to navigate to a text file (on page 55) containing these dates.
Make sure to use the date format specified in the Holiday Dates field.
Comma-separate the dates. Dates are displayed to users according to their
regional settings.
3 (Optional) Specify the default work hours for your organization. Skybox uses
these when calculating ticket SLAs in hours rather than days.
Creating a text file with holiday dates

You can create the file using any text editor. Note that:
› The file must be in TXT format

› The dates must be written in the date format that you are using
› The dates must be comma-separated or be entered 1 per line
After the file is imported into Skybox, the dates are displayed to each user
according to their regional settings.
CREATING CUSTOMIZED WORKFLOWS

To create a customized workflow using the wizard
1 From the Tools menu, select Options > Change Manager Settings >
Workflows.
2 Click Add.
The wizard opens with the Basic Settings page displayed.
3 Provide a name and description for the workflow.
4 In some cases, you might decide to limit the workflow to a specific firewall
scope, so that all change requests in the workflow are created only for
firewalls in this scope. To do this, click the Browse button next to Firewall
Scope and select the desired scope.
5 Select the change request types that can be submitted via the workflow.
6 To enable users to make changes to business attributes of the access rules in
the workflow, select Enable business attributes updates.
These changes can only be made as an addition to changes to the rule itself.
Changes only to business attributes must be made directly in Firewall
Assurance.

7 Click Next.
The Phases page is displayed.
8 Add phases to the workflow in order. The final phase is added automatically;
by default, it is named Pending Closure.
For information about adding phases, see Adding new phases to a workflow
(on page 57).
9 Specify the phase (if any) of the workflow that is visible in the Approved
Requests view.
The Pending Implementation view enables firewall administrators to see all
change requests from tickets in the implementation phase, so that they can
implement them per firewall rather than per ticket. You can control whether
this view is displayed in Change Manager and how it works.
a. In the Pending Implementation View area, select Enable Pending
Implementation View.
b. In Based on Phase, select the phase for which the view is visible. Use the
implementation phase of the workflow.
c. To automatically promote tickets to the next phase when all their requests
are implemented, select Automatically promote tickets.
10 Click Next.
The Ticket SLA page is displayed. Use this page to define how due dates for
each phase of the workflow are added. You can use the default work time or
define a work time specifically for this workflow.
11 Specify whether the 1st phase is included in the timetable for tickets of all
priorities. The 1st phase is for creating and submitting tickets. Sometimes,
you want the age of each ticket to be calculated only after the ticket passes
this phase.
If you do not want the 1st phase to be included in the timetable for each
ticket, clear Include the first phase in the timetable.
12 Define the maximum phase lengths for each priority level:
a. Select the priority and click Modify.
b. In the table, click each phase in turn and type the maximum number of
days in which that phase must be completed.
You must provide the maximum length of every phase. (If you cleared
Include the first phase in the timetable, you do not need to provide a
maximum length for the 1st phase.)
Note: The Maximum time to complete phases by priority section

includes a read-only table that displays the maximum length of each
phase for each priority.
c. Click OK.
13 Specify the work week and the holiday schedule for the workflow:
• For a standard schedule, select Use Default Settings.
— For information about defining the standard schedule, see Defining the
default work time for ticket workflows (on page 55).

• If the schedule of the workflow is non-standard, define the schedule:

a. Select the standard work days for your organization.
b. Type the dates of the holidays on which your organization does not
work or click to provide the location of a text file containing these
dates.
For information about creating such a file, see Creating a text file with
holiday dates (on page 55).
c. Make sure to use the date format specified in Holiday Dates. Comma-
separate the dates. Dates are displayed to users according to their
regional settings.
14 Click Finish.
Adding new phases to a workflow

When you add a new phase, you can select where it is added relative to the
existing phases. The verification phase (pending closure) is always the final
phase.
Note: After a phase is added, you cannot change the order except by deleting it
and then adding it in the correct position.
When you add a phase, you define the information to display on that page in
Change Manager by adding field groups (panels). You can add existing field
groups that are also displayed in other phases, or custom field groups. Custom
field groups contain custom fields that you define. You can mark each field group
(existing or custom) that you add as read-only if you do not want users to edit it
in that phase.
To add a new phase to a workflow

Note: This section assumes that you are editing a workflow and that you are on
the Phases page.
1 For the 1st phase in a workflow, click Add.
For subsequent phases:
a. Select an existing phase that is either immediately before or immediately
after the phase that you want to add.
b. Click the down arrow next to Add and select the location of the new
phase.
2 In the New Phase dialog box:
a. Type the phase name.
b. Select the default owner for the phase.
c. (Optional) Add a comment about the phase.
d. Specify the field groups that are displayed in this phase. You can choose
from existing field groups (see page 58) or create new field groups (see
page 59).
To select an existing field group, click the arrow next to Add and select
Add Existing Group; select the group that you want in the Group type

field, select Read-only, if necessary, and click OK. You can change the
order of the field groups by moving them up or down.
Note: A phase (usually the 1st phase) is considered a request phase

when it includes the Change Requests field group.
e. If the phase can be skipped under specific conditions (for example, if there
are no policy violations), select Automatic Phase Skip – Enable
automatic phase skip and define the conditions.
For additional information, see Defining automatic phase skipping for ticket
phases (on page 62).
f. If you do not want ticket creators to edit their tickets in this phase, select
Permissions – Ticket creator cannot edit this phase.
g. To enable users to view the firewall rule base in a request phase, select
Permissions – Allow users to view firewall rules.
A View Rules button is added in the Request phase.
h. Click OK.
3 Click OK.
For information about the fields of a phase, see Editing phases (on page 61).
Using existing field groups
After creating a field group, you can use it again in additional phases. The same
panel is shown in all the phases of a ticket where this field group was added.
Change Manager includes the following predefined field groups for use in
different workflows:
› Change Requests: In the 1st phase, used for creating, viewing, and editing
change requests
› Comments: In any phase, enables users to add a comment to the ticket
› General Information: Title, priority and description of the ticket
› Implementation Details: Used by firewall administrators in the
Implementation phase to add a target date for implementation and any
relevant details
› Implementation List: Used by firewall administrators in the
Implementation phase; shows each change request separately with the
details of the changes needed on the firewall
› Recertification: Used for recertification workflows; shows the rules for which
recertification was requested and enables the ticket owner to certify or reject
each rule
› Review Change Requests: Used in the 1st or 2nd phase; enables users to
review the original and derived change requests, and to make changes
› Risk Assessment: Used when reviewing the risk of change requests; you
can change the risk level and add assessment details (text)
› Risks: Used to review the risk of both original and derived change requests;
enables you to view risk information (compliance and security of the risk), to
add a comment for risk justification, and to approve the risk of the change
requests

› Sponsoring Application: Used to create a connection between a change

request and the relevant business application (in the Application & Service
repository). When this is done, approvers who are assigned to the application
are used as the suggested approver/owner for each phase of the ticket.
› Verification: Used in the final phase of all ticket types; a list of all the
change requests in the ticket, what changes were made for each request, and
whether the implementation was verified (by collecting new data from the
assets that shows whether the changes were made)
To reuse a field group

1 Open (or create) the desired phase.
2 In the Field Groups pane, click the arrow next to Add and select Add
Existing Group.
3 Select the group to add.
4 If appropriate for this phase, select Read-only.
Creating new field groups
When you add a new phase, you specify the fields to display in that phase. You
can add all the fields as a single field group or divide the necessary information
into logical field groups. Each field group is displayed as a pane on the phase’s
page in Change Manager.
Note: You can mark field groups as read-only. Individual fields cannot be read-
only; to make fields read-only in this phase, create separate field groups for
them.
You can create a field group that is a link to an URL. This enables the ticket
owner to view information about the ticket from an external ticketing system
(see Linking to an external ticketing system (on page 60)).
To create a new field group

1 Click the arrow next to Add and select Add New Group.
2 In the New Field Group dialog box:
a. Type a name for the field group.
b. Add existing fields: If any required fields exist in other field groups, click
the arrow next to Add and select Add Existing Field; select the required
fields and click OK.
Note: If a field is mandatory in one phase or field group but not
another, define it as 2 separate fields.
c. Add new fields:

i. Click Add.
ii. Give the field a name and select its type: String, Number, Boolean,
Date, List, IP, or User.
For List fields, enter a comma-separated list of possible values.
iii. (Optional) Add a text hint for users in Field Hint. The text hint is shown
in the field until the user starts typing.

iv. If a value for the field must be entered in this phase, select Mandatory.
v. Click OK.
vi. Repeat these steps to add another new field.
d. To make the fields read-only for users in this phase, select Read-only.
e. Click OK.
Linking to an external ticketing system
You can show ticket-related information to users in phases. This information can
come from your organization’s ticketing system or from any other organizational
system that holds such information. You can add a panel to any phase that
shows the desired information.
To add a panel showing external information

1 Click the arrow next to Add and select Add URL Group.
2 Provide the information specified in the following table.
Field Description
Name The name of the panel that users see in Change Manager.
Panel Height (in The height of the panel display in pixels. The panel
pixels) includes a scroll bar so that users can see the whole page.
Present the The page to display in the panel. You can customize the
contents of the link by adding any of the tags listed in the second half of
following URL this table.
For example, https://address/ticket=<SBV ticket
ID>&user name=<SBV user ID>
Optionally, add the following tags to the URL
Ticket ID Adds the ticket ID to the specified URL with the format
<SBV ticket ID>
External Ticket ID Adds the external ticket ID to the specified URL with the
format <SBV external ticket ID>
User Name Adds the user ID to the specified URL with the format
<SBV user ID>
Ticket Owner Adds the ticket owner to the specified URL with the format
<SBV ticket owner>
CONFIGURING AUTOMATIC PROMOTION FOR RECERTIFICATION

TICKETS WITH MULTIPLE OWNERS
In some cases, one access rule has multiple owners. To recertify such access
rules, each owner must review the rule (and either certify it or reject it). By
default, such tickets must be promoted manually to the next phase after all the
owners have reviewed the rule.

To enable automatic promotion of tickets for access rules with multiple

owners after all the owner have reviewed the rule
1 In Tools > Options > Server Options > Change Manager Settings >
Workflows, find the relevant recertification workflow.
2 On the Phases page, select Automatically promote recertification tickets
that were fully reviewed.
Note: Make sure that there is a default owner for the next phase of these tickets.
EDITING PHASES
You can make the following changes to an existing phase of a workflow:
› Change the default owner

› Add or edit field groups
› Specify whether a ticket creator can edit the ticket in this phase
› Define whether (and how) this phase is automatically skipped during the
ticket workflow
The properties of phases are described in the following table.
Phase Name The name of the phase.
Default Owner The default owner of the phase. This user receives all the
tickets of the phase unless users select a different
assignee for specific tickets.
For additional information, see Specifying default owners
for ticket phases (on page 62).
User Comments Information about the phase that is included in the list of
phases. This can be useful if you expect additional users
to edit the phases.
Field Groups The fields to display in the phase. You can add all the
fields as a single field group or divide the necessary
information into logical field groups. Each field group is
displayed as a separate pane on the phase’s page in
Change Manager.
For additional information, see Creating new field groups
(on page 59).
Automatic Phase You can configure Change Manager to skip phases if
Skip predefined criteria are met that mean that the phase is
not relevant to the workflow of the specific ticket. As each
ticket is promoted from the previous phase, it is tested. If
it meets the criteria, the phase is skipped and a note is
written in the ticket history.
For additional information, see Defining automatic phase
skipping for ticket phases (on page 62).

Permissions – By default, the creator of a ticket can edit the ticket in
Ticket creator any phase. You can specify that ticket creators cannot
cannot edit this edit this phase.
phase Note: Some phases cannot be edited by Web Ticket
Requestors, but this field prevents ticket creators,
regardless of their user role, from editing their own
tickets in this phase.
Defining default owners for ticket phases

For each ticket phase, you can specify a default owner. This user receives all the
tickets of the phase unless you select a different assignee for a specific ticket.
We recommend that you create a generic user for each user group that receives
tickets and then select that user as the default owner of the phase. For example,
if tickets in the Risk Assessment phase are handled by the IT Risk group,
create a user named IT Risk Default Owner and specify this user as the default
owner for the Risk Assessment phase. For additional information, see Defining
a default user for each group (on page 45).
To specify default owners for ticket phases

Workflows.
2 Double-click the workflow for which you want to specify default owners.
3 In the Workflow Configuration wizard, click Next.
4 In the Phases page of the wizard, for each phase for which you want to
specify an owner:
a. Click the phase and then click .

b. In the Default Owner field, select the desired user.
c. Click OK.
5 Click Next and then click Finish.
Note: If your organization has created an Application & Service repository, you
can add owners (approvers) for workflow phases per application. These owners
are then used as the default phase owners for tickets that relate to the
applications. For additional information, see Using application phase approvers as
the default phase owners of application-related tickets (on page 67).
Defining automatic phase skipping for ticket phases

You can configure Change Manager to skip phases of a ticket if criteria are met
that mean that the phase is not relevant to the workflow of the specific ticket. As
each ticket is promoted from the previous phase, it is tested. If it meets the
criteria, the phase is skipped, a note is written in the ticket history, and the user
is notified (in the Promote dialog box) as to which phase is being skipped.
Note: In some cases, consecutive phases can be skipped.

Use the following criteria to determine whether to skip a phase:
› The change requests in the ticket do not trigger any policy violations
› The change requests in the ticket do not cause any vulnerability occurrences
› Policy violations triggered by the change requests in the ticket are at or lower
than a specified severity level (Info, Low, Medium, High, or Critical)
› Vulnerability occurrences caused by the change requests in the ticket are at
or lower than a specified severity level (Info, Low, Medium, High, or
Critical)
To define automatic skipping for a phase

Workflows.
2 Select (open) the workflow for which you want to define automatic skipping
and click Next to get to the Phases page.
3 For each phase for which you want to define skipping criteria:
a. Select the phase and click Modify.
b. In the Automatic Phase Skip area, select Enable phase skip and specify
the criteria under which the phase is skipped.
c. Click OK.
Multi-tier change requests

Skybox Change Manager supports multi-tier change requests—original change
requests with multiple derived change requests that belong to different users.
Each derived change request can have a different owner, based on firewall
permissions, who is not the ticket owner. In this way, the derived change
requests can be reviewed and approved simultaneously.
The owners of the derived change requests have firewall permissions on the
relevant firewalls. Each firewall owner can receive notifications about the derived
change requests for the firewalls under their responsibility and must review these
change requests.
Users who do not have relevant firewall permissions cannot access all the data in
the ticket (including the routes); all confidential information that does not belong
to them is obfuscated.
Multi-tier change requests are automatically promoted to the next phase when all
firewall owners have completed the ticket phase review. If one user has
permissions for all the change requests in the ticket, they can promote the ticket
manually after reviewing all the change requests.
Prerequisites for using multi-tier change requests

To use multi-tier change requests, firewall permissions must already be in use.
To check this, do the following:
› In Tools > Options > Server Options > User Settings > User
Permissions, verify that Permissions for Firewall Assurance, Network
Assurance (Access Analyzer) & Vulnerability Control is selected.
› Verify that Firewall Assurance user permissions are assigned.

Activating multi-tier change requests

Multi-tier change requests are not activated by default.
To activate multi-tier change requests
› In Tools > Options > Server Options > User Settings > User
Permissions, select Apply Firewall Assurance permissions to Change
Manager tickets.
To set up notifications
Note: If you work with multi-tier change requests, notifications can be sent to all
firewall administrators or to the user group’s default owner.
1 Select Tools > Administrative Tools > Triggers.
2 In the Skybox Admin window, right-click Triggers and select New Trigger.
3 In the New Trigger dialog box, select the Ticket trigger type and fill in the
fields as specified in the Skybox Reference Guide.
4 Click OK.
Customizing ticket priority levels

By default, Skybox includes 5 ticket priority levels: Critical, High, Medium,
Low, and Very Low. If you do not need all the priority levels, you can disable
some of them, and you can change the level names and add a comment to a
level.
To customize the ticket priority levels

1 Go to Tools > Options > Server Options > Ticket Configuration > Ticket
Priorities and Phases.
2 In the Ticket Priority Levels area, select a specific priority.
3 As required:
• Change the name of the level.
• Disable the level.
If you disable a priority level, you also disable all lower levels. If there are
any tickets with these priority levels, they are reassigned to the lowest
remaining priority level.
• Enable the level.
If you enable a priority level, you also enable any higher levels that are
disabled. For example, if levels P3, P4 and P5 are disabled and you enable
level P5, levels P3 and P4 are also enabled.
Enabling users to change the status of their tickets

By default, ticket statuses are changed by Skybox when the tickets are moved to
a different phase; they cannot be changed by users. However, you might want to
enable users to change the status of their tickets without changing the phase.

To enable users to change ticket statuses
› Set enable_manual_ticket_status_change to true in

<Skybox_Home>\server\conf\sb_server.properties.
Note: Ticket status can only be changed manually for active tickets. The status of
‘finished’ tickets (those with Resolved, Rejected, or Closed status) cannot be
changed manually. The status of a ticket with a custom status can only be
changed manually if its status is in the Open status group.
Setting up the Application & Service repository

The Application & Service repository is a collection of the applications and
services used by the firewalls in your organization. This information can be
imported from a configuration management database (CMDB) or created
manually. The purpose of this repository is to help non-technical Ticket
Requestors in Change Manager to open tickets on the correct entities.
In some cases, when these users open tickets, they are not familiar with the
firewall objects in the organization. Also, there might be many firewall objects
with similar names (from different firewalls), and these users do not know the
object to use. It is easier for them to open a change request on familiar entities.
In other cases, these users are not permitted to view firewall objects for security
reasons. Repository objects provide a good alternative.
› Applications in the repository include the following fields:

• Entity ID (EID)
• Name
• Value: IP addresses or IP address ranges
• Application Groups of which the application is a member
• (Optional and can only be added manually) An owner for the application
and default approvers for each workflow phase of tickets related to the
application
› Services (ports) in the repository include the following fields:

• EID
• Name
• Value: At least 1 service
• Service Groups of which the service is a member
For information about importing a CMDB, see the Example of iXML code for an
Application & Service repository topic in the Developer Guide.
MAINTAINING THE REPOSITORY

Maintaining the Application & Service repository includes adding, modifying, and
deleting repository objects and the groups that contain them.

Adding to the repository
To add an object to the repository

1 Click either New Application or New Service.
2 Type a name for the new object. The type is either Application Object or
Service Object.
3 Add the value of the object.
• For application objects, this is an IP address or IP address range.
• For service objects, this is at least 1 service, including the protocol port
and protocol name.
4 (Optional) Add a comment about the object.
5 For application objects, click the Owners & Approvers tab to add an owner
for the application and phase approvers for any workflows that are relevant to
the application. The owner is the user responsible for the application. Phase
approvers are the users who are responsible for this application in each
workflow phase.
Note: If the owner and approvers for an application are the same as those
of its application group, you do not need to define them again in the
application.
To add a group to the repository

1 Click New Group and then specify the type of group that you are adding:
Application Group or Service Group.
2 Type a name for the group.
3 Add the members of the group (either application objects or service objects).
4 (Optional) Add a comment about the group.
5 For application group objects, click the Owners & Approvers tab to add an
owner for the application group and phase approvers for any workflows that
are relevant to the application group. The owner is the user responsible for
the application group. Phase approvers are the users who are responsible for
this application group in each workflow phase.
Modifying, deleting, disabling and enabling, and copying entities in

the repository
› To modify an entity in the repository, right-click it and select Properties.

Note: Skybox uses the modified values in new tickets with the selected
entity. The value in existing tickets is not changed.
› To delete an entity from the repository, right-click it and select Delete.

› You can disable or enable any entity in the repository. Disabled entities are
not visible to repository users in Skybox Change Manager.
› To copy an entity in the repository, right-click it and select Create <Entity
type> Like.

USING APPLICATION PHASE APPROVERS AS DEFAULT TICKET

PHASE OWNERS
For each application or application group in the repository, you can specify an
owner, and separate owners (approvers) for each workflow phase of tickets that
are related to this application or application group. If phase approvers are
specified, they can then be used as the default owners of the relevant phases for
tickets that are opened on the application, instead of the default owners defined
for the phases.
Note that if you create an application group and assign phase approvers, you do
not need to assign phase approvers for each phase of each of the group’s
applications (unless they are different). If you associate an application with a
ticket and the application does not have phase owners, the phase owners are
taken from the application group.
To use application phase approvers as the default phase owners of

application-related tickets
1 For each relevant application or application group in the repository, define
approvers for phases of the relevant workflows.
a. Click Tools > Application & Service Repository.
b. In the tree, select Applications (or Application Groups).
Note: The Owner field is for future use; it is not necessary to define
application Owners.
2 Define in which phases of which workflows users can define (or change) the
application or application group associated with a ticket.
Note: Without this step, users of Change Manager cannot associate

applications or application groups with their tickets.
a. Click Tools > Options > Change Manager Settings > Workflows.
b. Double-click the workflow in which you want users to be able to associate
an application with their tickets.
c. In the Workflow wizard, click Next to get to the Phases page of the
wizard.
d. Double-click the phase in which you want users to be able to associate an
application with a ticket or change the application that is associated with a
ticket.
e. In the Phase Properties dialog box, click the drop-down arrow on the Add
button, and select Add an Existing Group. Add a Sponsoring
Application field group.
In Skybox Change Manager, if a user selects an application for the ticket
using this panel, the phase approver settings of the selected application (if
any) or its application group define the default owners for the ticket
phases. If there are no approvers defined for the application or its
application group for any phases, the default phase owners for those
phases are those defined for the ticket phases.
f. Repeat steps b through e for each workflow phase in which users can
associate an application with the ticket.

Setting up analysis of change requests

Change requests are verified by Skybox Analysis – Change Tracking tasks.
These tasks verify:
› Connectivity between the source and destination over the selected services
› Compliance with your Access Policy
› That tickets with Resolved or Verified status were implemented
If the tickets were implemented, and connectivity now exists, the ticket status
is changed to Verified. If connectivity does not exist, the task changes the
ticket status to Reopened.
Analyze change tracking after reimporting the relevant firewalls, so that the
analyzed information is up-to-date; create a task sequence that includes offline
file import or online collection tasks for the analyzed firewalls, followed by an
Analysis – Change Tracking task.
For information about task sequences, see the Task sequences section in the
Skybox Firewall Assurance User Guide.
Triggers
Skybox uses triggers (rules) to:
› Send email notifications about ticket events in Skybox Change Manager

Skybox can send email notifications about ticket events, so that users are
notified when a change occurs. Skybox includes default notification templates
for a variety of events and you can create customized notification templates
to meet specific requirements. For example, you can create a trigger that
sends notifications to all members of the Implementation group every time
that a ticket is promoted to the Implementation phase.
› Run scripts when ticket events occur

Scripts are run via the Tool – Script Invocation task.
CREATING TRIGGERS
You can create triggers that send notifications, run scripts, or both.

To create a trigger
2 In the Skybox Admin window, right-click the Triggers node and select New
Trigger.
3 In the General pane, provide a name for the trigger and select Ticket as the
notification type.
4 Fill in the other fields in the General tab as described in the following table.
5 If you want a non-standard notification for the events covered by this trigger
(as specified in the Notification Events tab), or if you want different
notifications for the same event (for example, for different user roles), see
Customizing notifications (on page 71).
6 Click OK.
Events tab
Ticket Events
Any ticket change Triggers notifications and scripts every time that a ticket
(including (that matches all the filters) is created, changed, or
creation and deleted.
deletion)
Specific actions Triggers notifications and scripts every time that a
and updates specified change occurs to a ticket that matches all the
filters.
Use the Actions and Updates property to specify the
change types that trigger notifications.
Actions and A list of change types that, if selected, trigger
Updates notifications and scripts when they occur.
Overdue
Notify on overdue Specifies whether notifications and scripts are triggered
tickets when a ticket becomes overdue (misses the due date for
the current phase).
Ticket Filter tab
Network Scope (Skybox Vulnerability Control and Threat Manager only)
The assets and container entities for which to send
notifications.
Type The type of ticket for which to trigger notifications and
scripts.
Ticket Phases Triggers notifications and scripts if the ticket is in a
selected phase.
Ticket Owner Triggers notifications and scripts if the ticket belongs to a
selected owner.
Owner Lookup If owners are specified in Ticket Owner, specifies
whether to search for the selected ticket owners in the
current phase of each ticket or in specific phases.
If you select Specific Phases, select the desired phases
in the Owner Phases field.

Owner Phases The phases in which to search for the ticket owner.
Priority Triggers notifications and scripts if the entity for which the
ticket was created has the selected priority.
CVSS Base Score (Skybox Vulnerability Control and Threat Manager only)
Triggers notifications and scripts if the CVSS base score of
the Vulnerability Definition for which the ticket was
created is in the selected range.
CVSS Temporal (Skybox Vulnerability Control and Threat Manager only)
Score Triggers notifications and scripts if the CVSS temporal
score of the Vulnerability Definition for which the ticket
was created is in the selected range.
Trigger Notification tab
Ticket's CC List Sends notifications to all users listed in the cc list of the
ticket.
Ticket Owner Sends notifications to the owner (assignee) of the ticket.
Ticket Owner's Sends notifications to all users who are in the same user
Group(s) groups as the owner (assignee) of the ticket.
Ticket Requestor Sends notifications to the user who created the ticket.
Skybox Users Sends notifications to the selected Skybox users.
External Email Sends notifications to the specified email addresses.
Addresses
When the assignees or cc list recipients of this Ticket change, send
notifications to:
New Recipients (Read-only) Sends notifications to users added to the
ticket.
Former Recipients Sends notifications to users removed from the ticket.
Change Manager If FA permissions are enabled for Change Manager,
Notification specifies who receives notifications about each derived
Recipients change request.
User Groups Specifies whether notifications about each derived change
Default Members request are sent to the default member of all the user
groups to which the relevant firewall owner belongs.
All Firewall Specifies whether notifications about each derived change
Administrators request are sent to all administrators for the relevant
firewall.
Trigger Program tab
Tasks Specifies the Tools – Script Invocation tasks that are
run when the triggering specifications are met.
HOW NOTIFICATIONS WORK

Skybox includes default notifications for various changes in tickets.

Example of a notification about ticket promotion

Email subject line
Subject: Ticket 372 was promoted to phase Technical Details
Content of email
ID: 372
Title: Access from dev desktops to SVN machine
Description: Access from Guy's team to the SVN server in port 1234.
Priority: High
Due Date: 2/5/14
Promoted to: Firewalls

Comment:
URL: https://Nir-PC:8443/skyboxview/#cpl-Ticket:&Ticket=372
Notifications are based on templates that use text and keywords (variables) to
inform the recipients of changes that occurred. The following is the template that
produced the preceding notification.
Subject field
Ticket __TICKET_ID__ was promoted to phase __CURRENT_PHASE__
Primary information field

ID: __TICKET_ID__
Title: __TITLE__
Description: __DESCRIPTION__
Priority: __PRIORITY__
Due Date: __DUE_DATE__
Promoted to: __CURRENT_OWNER_WITH_EMAIL__

Comment: __LAST_USER_COMMENT__
URL: __URL__
The text in this template is the actual text that is in the email notifications. The
keywords (listed in the template as __<KEYWORD_NAME>__) are replaced by the
value of the relevant field in Skybox when a notification is created, as in the
sample at the beginning of this topic.
Skybox’s default templates use specific text and keywords for specific events, but
if you create your own templates you can use any text together with the
appropriate keywords. You can create multiple notification templates for the
same event type (for example, a very basic template for Ticket Requestors
when their tickets are promoted and a more detailed template for the users
responsible for implementing the next phase). You create multiple notification
templates using the Notification Templates tab of the Notification properties
dialog box.
CUSTOMIZING NOTIFICATIONS
You create custom notifications using the Notification Templates tab.

To create a custom notification

1 Click the Notification Templates tab.
2 Select Use Custom Notification.
Note: This specifies to Skybox to not use the default template that would
otherwise be used for the selected event types. The notification contains
only the information that you add.
3 Skybox uses the text in the Subject field as the subject header of the email
notification:
a. Add appropriate text. For example, “Subject: New Ticket ID ” (without
the quotation marks but including the space at the end).
b. With the cursor placed after the text, click Insert Label.
See Keywords for notifications (on page 72) for a list of all possible
keywords.
c. In the list that appears, double-click the name of the field to add. For this
example, select Ticket ID.
The relevant keyword (for this example, __TICKET_ID__) is inserted in the
text.
d. Add any text to appear in the subject header after the keyword. In this
example, you might add “ Notification” (again, without the quotation
marks; remember to include a space).
4 Skybox uses the text in the Primary Information field as the body of the
email notification. It should provide the changes that were made. Use the
same steps that you used for the Subject field, adding lines of text and
keywords.
Note: The Details field is not necessary in Change Manager notifications;
it provides information used for other types of ticket notifications.
5 Click OK.
The new notification is added to the list of notifications.
Creating additional notifications for the same (or similar) event

You can create additional notifications for the same (or a similar) event. This can
be useful if you need to create multiple notifications for an event. For example,
you might want a very simple notification for the Ticket Requestor and a more
detailed notification for the owner of the next phase, or you might have created a
notification for ticket promotion and want a very similar notification for ticket
demotion.
To create a new custom notification based on an existing notification

1 Right-click the notification and select Create Notification Like.
2 Open the new (copy) notification from the list and make necessary changes.
Keywords for notifications

You can use the keywords in the following table in all ticket notifications.

Ticket field Keyword

ID __TICKET_ID__
Ticket type __TICKET_TYPE__
Title __TITLE__
Ticket description __TICKET_DESCRIPTION__
Priority __PRIORITY__
Phase __CURRENT_PHASE__
Due date __DUE_DATE__
Original phase due date (if __PHASES_ORIGINAL_DATES__
it has changed)
Ticket affected products __TICKET_AFFECTED_PRODUCTS__
Names of additional __ADDITIONAL_FIELDS_UPDATED__
changed fields
<Name of changed field> __UPDATED_FIELD__
<Old value of changed __OLD_VALUE__

field>
<New value of changed __NEW_VALUE__
field>
You can use the keywords in the following table in Access Change ticket
notifications
Ticket field Keyword
The importance of the __IMPORTANCE__
violated Access Check
The test ID of the violated __VIOLATION_ID__
Access Check
The name of the Access __APR_NAME__
Check
The type of the Access __APR_TYPE__
Check (Limited, No-
Access, or Full Access)
The path of the Access __APR_PATH__
Check in the policy tree
The source used in the __SOURCE__
Access Check
The destination used in the __DESTINATION__
Access Check
The original change __ORIGINAL_CHANGE_REQUESTS__
requests of the ticket
The derived change __DERIVED_CHANGE_REQUESTS__
requests of the ticket

Keywords that you can use in ticket notifications for specific events are listed in
the following table.
Ticket field Keyword Event / Note
Creation time __CREATION_OF_TICKET__ Ticket creation (and other
ticket events, when
necessary)
Original ticket ID __ORIGINAL_TICKET_ID__ Cloned ticket
URL __URL__ Displays the URL of the
Change Manager with the
relevant ticket ID.
Done date __DONE_DATE__ Ticket completion
Status __STATUS__ Ticket completion (and
other ticket status change
notifications)
Closure type __CLOSURE_TYPE__ Ticket closure (explains
how the ticket was closed)
Deletion time __DELETION_TIME__ Ticket deletion
Deleted by __DELETED_BY__ Ticket deletion
Current owner __CURRENT_OWNER__ Events (including promote,
demote, or reassign)
Current owner __CURRENT_OWNER_WITH_ Same as
with email EMAIL__ __CURRENT_OWNER__ but
adds the email address in
parentheses. If the user
does not have an email
address defined, then this
is the same as
__CURRENT_OWNER__
Previous owner __PREVIOUS_OWNER__ Events (including promote,
demote, or reassign)
Previous owner __PREVIOUS_OWNER_WITH Same as
with email _EMAIL__ __PREVIOUS_OWNER__
but adds the email address
in parentheses. If the user
does not have an email
address defined, then this
is the same as
__PREVIOUS_OWNER__
Previous phase __PREVIOUS_PHASE__ Phase-changing events
(including promote or
demote)
Current phase __CURRENT_PHASE_NUMBE Displays the number of the
number R__ current phase. If there are
no phases or if the ticket is
closed, this field is empty.

Ticket field Keyword Event / Note

Previous phase __PREVIOUS_PHASE_NUMB For all phase-changing
number ER__ events. Displays the
number of the previous
phase. In all other cases,
this field is empty.
Total number of __TOTAL_NUMBER_OF_PHA Displays the total number
phases SES__ of phases of the ticket. If
there are no phases, this
field is empty.
Latest user __LAST_USER_COMMENT__
comment
Start time of the __CURRENT_PHASE_START_
current phase TIME__
Phase due date __CURRENT_PHASE_DUE_D Overdue ticket
ATE__
Integration with the ServiceNow ticketing system

Setting up integration with the ServiceNow ticketing system involves setup of
both ServiceNow and Skybox.
Note: This feature is in beta.

Setup of ServiceNow integration is an advanced procedure. The following
instructions provide basic guidelines, but additional customization may be
required. Please contact Skybox Professional Services before proceeding with this
integration.
SUPPORTED WORKFLOWS
The following workflows are supported in Skybox when working with ServiceNow.
› Create a ticket
1. A user creates a ticket in Skybox.
2. Skybox extracts all the relevant data from the ticket and uses it to create a
ticket in ServiceNow.
3. The Skybox ticket (External ID field) is updated with the ServiceNow ticket
number.
› Update a ticket
1. A user updates a ticket in Skybox.
2. Skybox finds the parallel ticket in ServiceNow using the (Skybox) ticket's
External ID.
3. Skybox updates the ServiceNow ticket with the relevant Skybox data.
› Upload and attach a report file to a ServiceNow ticket

1. The ticket action that was defined to trigger uploading reports occurs. For
example, a Skybox ticket is promoted from the Request phase to the
Technical Details phase of the General workflow (if this is the defined
trigger).
Note: This workflow uses a sample action that could trigger a report:
ticket promotion from the Request phase to the Technical Details
phase. However, the workflow for different triggers is similar.
2. Skybox collects the data needed for the report and creates an Excel report
file.
3. Skybox uploads the report to ServiceNow as an attachment to the ticket.
SETTING UP SERVICENOW
To set up ServiceNow to work with Skybox Change Manager
1 Create a new dev environment (ServiceNow instance). For example:
https://dev81508.service-now.com/
2 Create a default user.
a. Type “users” in the search bar on the left.
b. Open the Users table and click New.
c. Give the user a user ID and password, first and last name, and email.
d. Click Submit.
3 Disable Business Rules for this table.
a. Find the Change Requests table by typing “change” in the search bar and
selecting Change - All.
If you are using a demo environment created by ServiceNow, the table
should already have tickets.
b. Create a new ticket by clicking New.
c. From the menu, select Configure > Business Rules.
d. Find the rule “State model - Can change state?”.
e. Click the link to edit the rule.
f. Disable the rule by making sure that the Active check box is cleared.
SETTING UP SKYBOX
Each workflow requires both a separate task and a separate trigger. It also
requires a separate phase mapping (on page 78).

Setting up a task for a workflow

1 Create a new task of type Tools – Script Invocation.
2 Fill in the Basic parameters of the task as follows:
a. Run in: Server
b. Program: Provide the full path to your Python. For example
C:\python27\python.exe or
/opt/skyboxview/thirdparty/python2.7/bin/python2.7
c. Arguments: Refer to the table below.
For example:
C:\dev\trunk\solutions\python\adapters\service_now\service_now_
adapter.py -c create_ticket --ticket_id %T --source_user %u --
source_password %p --destination_user %u2 --
destination_password %p2 --debug
3 Fill in the Advanced parameters with the user names and passwords of both
environments, as shown in the following example.
Username and Password refer to Skybox; Additional Username and
Additional Password refer to ServiceNow.
Argument Value and Definition

(path to the The first argument must be the path to the adapter
adapter)
-c Configuration. The value must be one of the following:
• create_ticket
• update_ticket
• upload_report
--ticket_id %T = the ticket ID in Skybox
--source_user %u = the Skybox username
--source_password %p = the Skybox password
--destination_user %u2 = the ServiceNow username
-- %p2 = ServiceNow password
destination_passwor
d
--debug The debug flag

Setting up a trigger for a workflow

2 In the Skybox Admin window, right-click the Triggers node and select New
Trigger.
3 Select Ticket for the Trigger Type.
4 In the Events tab, click Specific actions and updates, and then select the
following events:
• Create ticket workflow: Ticket Created, Ticket Cloned
• Update ticket workflow: All events except Ticket Created, Ticket Cloned,
and Ticket Deleted
• Upload report workflow: Ticket Promoted
5 In the Trigger Program tab, select the task that you set up for the workflow.
6 For the Upload report workflow only: in the Trigger Filter tab, select the
phase or phases for which you want to upload reports.
For the example mentioned earlier, we used General > Technical Details as
the phase. So a report will be uploaded to ServiceNow whenever a ticket is
promoted to this phase.
CONFIGURATION
The following additional configuration is required for the integration:
› Phase mapping
› Destination endpoint
Configuring the phase mapping

Phase mapping is used to indicate which Skybox phase matches each ServiceNow
phase. The phase mappings are configured in
<Skybox_Home>/service_now/conf/phases_mapping.yaml
The following is an example of phases_mapping.yaml for the Skybox phases in
the predefined General workflow.
- skybox_phase_name: 'Request'
service_now_name: 'New'
service_now_state: -5
assignment_group: 'a715cd759f2002002920bde8132e7018'
- skybox_phase_name: 'Technical Details'
service_now_name: 'Assess'
- skybox_phase_name: 'Risk Assessment'
service_now_name: 'Authorize'
- skybox_phase_name: 'Implementation Details'
service_now_name: 'Implement'
- skybox_phase_name: 'Verification'
service_now_name: 'Review'
service_now_state: 0
- skybox_phase_name: 'Closed'
service_now_name: 'Closed'
service_now_state: 3
Definitions
› skybox_phase_name: The name of a Skybox phase.

› service_now_name: The name of the corresponding ServiceNow phase.
› service_now_state: The corresponding number (ID) for each Service Now
phase; ServiceNow phases have both integer IDs and names.
› assignment_group: The sys_id of the group that each ticket will be assigned
to for each phase. Some phases require a ticket to be assigned to a group.
Note: Currently, all tickets are assigned to the Change Management

Group, whose sys_id in ServiceNow is
a715cd759f2002002920bde8132e7018
Configuring the destination endpoint

The address of the destination endpoint, the Service Now instance, must be
configured in each of the configuration files.
For every occurrence of destination_endpoint in a configuration file, substitute
the ServiceNow instance you are using, such as https://dev81508.service-
now.com
Here is an example of how it might look:
WORKING WITH SERVICENOW

When the setup specified in the previous sections is completed, tickets from the
configured phases will be created and updated automatically in both Skybox and
ServiceNow.
› After a new ticket is uploaded to ServiceNow, you must refresh the Skybox
ticket before you continue working with it.
› After a ticket is promoted to a different phase in Skybox, you must refresh
the ticket in ServiceNow to see the new phase.

Skybox ChangeManager UsersGuide V10!0!300

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Skybox ChangeManager UsersGuide V10!0!300

Uploaded by

Copyright:

Available Formats

Skybox Change Manager

Overview of Skybox Change Manager ........................................................ 6

Rule recertification ................................................................................. 31

Change implementation .......................................................................... 33

Skybox version 10.0.300 3

Exporting information from Change Manager ............................................. 40

Workflow statistics ................................................................................. 41

Administration of Change Manager ........................................................... 42

Skybox version 10.0.300 4

› Your contact information (telephone number and email address)

How this manual is organized

› Overview of Skybox Change Manager (on page 6)

Skybox version 10.0.300 5

Overview of Skybox Change

Skybox version 10.0.300 6

Skybox arms security leaders with a comprehensive cybersecurity management

› Fully automates firewall change management workflows, improving

Skybox version 10.0.300 7

› Validates proposed firewall changes by checking for policy violations, security

› Intelligently automated, closed-loop workflow

› Identifies next-generation application- and user-level changes along with

Skybox version 10.0.300 8

› Identify the firewalls that need changing

Users and their responsibilities

› Create tickets: Submit requests for connectivity

Skybox version 10.0.300 9

› View tickets by phase or by assignee/owner: This list represents the tickets

› Find a ticket by ID: View a specific ticket for follow up

Typical flow of a change request

Skybox version 10.0.300 10

• Each request is checked to see whether the requested access is already

Submitting change requests

Skybox version 10.0.300 11

› Add, modify, activate, or deactivate an access rule

2 Provide the basic request information (title, priority, and free-form

Skybox version 10.0.300 12

Note: For non-recertification tickets, Skybox checks whether the changes

To select a workflow when there is no default

To select a workflow when a default exists

REQUESTING SPECIFIC ACCESS

› Checks the Skybox model

Skybox version 10.0.300 13

To request specific access between a source and a destination

Access update properties

Skybox version 10.0.300 14

UPLOADING A FILE WITH MULTIPLE REQUESTS

To download the template file

To upload a file of access update change requests to Change Manager

Skybox version 10.0.300 15

ADDING AN ACCESS RULE

To request a new access rule on a firewall

Positioning of new access rules

Access rule properties

Skybox version 10.0.300 16

Skybox version 10.0.300 17

Skybox version 10.0.300 18

To find an object using the Object Finder dialog box

Note: In many situations, this field is read-only.

2 In the Search field, type a string.

Skybox version 10.0.300 19

Setting business attributes for an access rule

To set rule attributes

MODIFYING ACCESS RULES

› Adding or removing specific access from the rule